★ FEATURED ARTICLE 简介《2024中国软件供应链安全分析报告》是一份面向安全研究人员、软件开发人员及企业安全管理者的年度分析资料聚焦软件供应链攻击手法、自研代码缺陷、开源生态风险与漏洞治理等实际问题适合用于风险评估、安全培训与策略制定。全包仅含1个PDF文件大小约7.31MB便于下载后直接查阅与归档。报告已有105人学习内容基于第一手实测数据展开涵盖编程语言分布、典型安全缺陷检出、大型开源项目与主流包生态漏洞增长、关键基础开源软件TOP50及运维风险并专章剖析NPM生态中恶意开源组件以窃取敏感信息为目标的行为。后半部分还讨论企业平均使用166个开源软件、老旧漏洞长期留存、许可协议与版本运维风险并通过操作系统、PHP及国产数据库供应链攻击实例印证“老漏洞”的威胁。读者可据此理解供应链各阶段风险形成更具体的改进与检查思路。1. 从一张「数字对不上」的报表说起做软件供应链安全评估最容易翻车的不是扫不出问题而是扫出一堆数字之后没人认。某次评审会上一份材料同时写着「整体缺陷密度 12.76 个/千行」和「高危缺陷密度 40.52 个/千行」台下第一句追问就是高危比整体还多这个密度怎么算的软件供应链安全的盘点报告价值从来不在把开源软件漏洞数字做大而在把口径摊开——自研代码按千行缺陷密度算开源生态按项目数和版本数算企业依赖按每项目漏洞数与影响面算漏洞管理才有排序依据。《2024 中国软件供应链安全分析报告》这类年度材料值得拿来当模板正是因为它把「自研代码、开源生态、企业依赖、典型事件」四段拆开每段给了可复算的指标。它适合要交安全评估方案的学生、要给团队立检测基线的工程师也适合需要向管理层解释「今年风险到底降没降」的安全负责人。2. 评估模型四段检测面与三个样本池的口径设计一份能交付的供应链安全评估第一步不是选工具而是先定「在哪几个面上取数」。取数面定歪了后面所有统计都是自说自话。这套报告的骨架是把「自研代码 第三方代码 → 混源代码 → 编译链接 → 交付使用」这条链路切成四段每段对应一类检测对象和一组指标互不混算。下面把模型、指标和样本边界拆开讲这三件事定完方案的可信度就有七成。2.1 把混源代码链路拆成四段检测面第一段是自研源代码看的是研发过程本身的质量对应指标是缺陷密度和典型缺陷检出率第二段是开源生态供给侧看的是整个生态的项目规模、版本膨胀、公开漏洞披露和恶意组件对应指标是项目数、版本数、漏洞总数与年增量第三段是企业项目依赖侧看的是「我的项目到底引了什么」对应指标是每项目平均依赖数、已知漏洞数、存在漏洞的项目占比第四段是运行与运维看的是老旧版本、版本混乱和许可协议这类长期挂着不处理的风险。这四段之间不能简单相加。自研代码的缺陷是「写出来的」依赖侧的漏洞是「引进来的」两者的修复责任方、修复周期、验证方式完全不同。实际做方案时我一般会给每段单独设一个责任人和一条修复 SLA自研高危缺陷按迭代修依赖漏洞按可利用性修许可协议风险按法务评估周期走。混在一个看板里统计「总风险数」除了让数字好看对推动修复没有任何帮助。四段模型的另一个好处是能对上攻击面。报告里复盘的多起事件攻击入口分别落在第二段生态里被投毒的包和第四段长期未更新的老旧组件而不是自研代码。这也是为什么评估不能只做代码扫描只扫自研代码等于默认第三方代码是可信的而这个假设在真实世界里几乎从不成立。2.2 指标口径密度、检出率、漏洞数与影响面四个核心指标各有各的用途也各有各的误用方式。缺陷密度衡量的是「单位代码量的缺陷浓度」适合做同比和横向对比不适合直接当验收红线检出率衡量的是「有多少项目沾上了这类问题」适合判断某类缺陷是否已经普遍化漏洞数衡量的是单个项目的依赖债务规模影响面占比衡量的是风险覆盖面是给管理层看的那一层。指标计算口径主要用途常见误用整体缺陷密度缺陷总数 / 代码总行数 × 1000研发质量同比拿不同语言项目直接横比高危缺陷密度高危缺陷数 / 代码总行数 × 1000判断重点缺陷治理效果把高危和整体密度写反典型缺陷检出率含该类缺陷的项目数 / 项目总数判断缺陷普遍程度与缺陷数量混为一谈每项目已知漏洞数漏洞实例总数 / 项目数依赖债务规模不去重导致重复计数影响面占比存在某级漏洞的项目数 / 项目总数向管理层汇报覆盖面与漏洞数增长率混用口径必须写进方案附录而且要写到「分母是什么、去重规则是什么、高危的定义来自哪个分级标准」这一层。我见过太多方案在正文里只写结论数字附件里没有口径说明评审一问就崩。这份报告做得比较规范的地方是每个数字都带了样本量和统计年度比如自研代码部分明确写了 1858 个项目、4.09 亿行代码读者能自己反算出密度这种可复算性是方案可信的基础。还有一个容易被忽略的点密度类指标对语言非常敏感。Java 项目天然行数多、框架代码占比高C/C 项目内存类缺陷更集中把两类项目的密度直接放一张图上排名结论一定是错的。正确做法是按语言分层统计或者只在同语言项目组内做对比这一点在写方案的方法论章节时必须交代清楚。2.3 三个样本池与采集边界这套评估用了三个互不重叠的样本池1858 个企业自主开发项目、4.09 亿行代码用来算自研缺陷密度2248 个开源项目、3.10 亿行代码用来算开源代码缺陷密度1763 个企业软件项目用来做依赖侧的开源使用与漏洞分析。三个池子的统计单位不同一个是「项目 行数」一个是「项目 依赖清单」混用就会得出「平均每个项目 166 个开源软件所以代码量很大」这种没意义的推论。采集边界也要写清楚自研代码检测统计的是 2023 全年提交检测的项目开源项目检测来自一个持续运行的检测计划依赖分析取的是项目的构建清单含传递依赖。方案里如果不写边界读者会默认你统计了「全中国所有企业」一旦被质疑样本代表性整份材料的可信度就没了。实际交付时我会额外加一条「样本变更说明」本期比上期多了什么、少了什么。这份报告在方法论部分明确写了本期新增 NPM 生态恶意组件分析这种变更说明能让同比数据站得住脚也是答辩时最容易被问到、又最容易加分的细节。3. 自研源代码检测从 12.76 个/千行到十类缺陷的修复排序自研代码这一段是整个评估的地基因为它回答的是「我们自己写出来的东西有多安全」。这段数据最有意思的地方在于方向不一致整体缺陷密度在上升高危缺陷密度却明显下降。这种「一升一降」如果不解释清楚汇报现场必然被追问解释清楚了它反而是整份材料里最有说服力的一个结论。3.1 语言分布与项目规模1858 个项目里一共出现 17 种编程语言项目数前三分别是 Java 1258 个、C/C 246 个、Python 118 个。Java 占比 67.7%比上一年的 76.1% 有所回落Python 则重新回到第三位。总量上4.09 亿行代码共检出安全缺陷 521.6 万个其中高危 21.1 万个折算下来整体缺陷密度 12.76 个/千行高危缺陷密度 0.52 个/千行。这里必须提醒一句0.52 这个数字和 12.76 相差两个数量级转述时极易写错。我见过把这俩写反、写成 40.52、甚至把「个/千行」写成「个/行」的材料一个单位错误就能让整段分析失去意义。方案里凡是涉及密度的地方建议统一写成「数值 单位 分子分母」例如「0.52 个高危缺陷/千行代码211355 / 408909802 × 1000」把算式摆在旁边谁都能验。语言分布的解读也有讲究。Java 占比高说明国内企业项目以业务系统为主这类系统的注入、跨站脚本、输入验证类缺陷会更突出C/C 项目数量虽少但内存安全和 NULL 引用类问题更集中。做分层统计时把这两类项目放在一起算平均密度得到的是一个既不代表 Java 也不代表 C/C 的「平均怪物」。3.2 十类典型缺陷的检出率与修复优先级报告统计的十类典型缺陷是注入、密码管理、日志伪造、跨站脚本、NULL 引用、配置管理、输入验证、资源管理、路径遍历、API 误用。这十类的总体检出率是 71.1%比上一年的 74.1% 略有下降说明沾上至少一类典型缺陷的项目仍然超过七成。结构上输入验证类检出率最高达到 49%跨站脚本紧随其后这两类连续多年排在前两位配置管理和日志伪造连续排最后两位NULL 引用类缺陷的检出率较往年有较大幅度下降这与研发团队对空指针问题的针对性治理直接相关。开源项目侧的十类缺陷总体检出率更高为 76.7%其中输入验证、路径遍历、资源管理三类都在 30% 上下或以上密码管理类较往年有明显上升。修复排序不能按数量排。我的做法是给每类缺陷算一个「可利用性 × 影响面」的分值输入验证和注入类缺陷即使数量不是最多也应该排在最前面因为它们直接对应外部可控输入日志伪造、配置管理类缺陷数量再大多数场景下也只能排到第二个迭代。这个排序规则要提前和研发团队对齐否则你排你的、他修他的最后复盘时两边都对不上账。提示检出率的分母是「项目数」不是「缺陷数」49% 指的是近一半项目里至少存在一个输入验证类缺陷不是「49% 的缺陷属于输入验证」。这两个说法在汇报里经常被混用写方案时最好在指标定义处直接举例说明。3.3 检测流水线与缺陷聚合真实项目里一个中等规模的系统扫描下来动辄几万条结果直接扔给研发只会被当成噪音。我一般会在扫描器和研发之间加一层聚合把上千条规则收敛到十类口径输出「项目 × 缺陷类 × 严重级」的矩阵再算密度和检出率。下面这段脚本就是做这件事的输入是扫描器导出的 SARIF 结果输出是可直接入库的聚合记录。# aggregate_sarif.py # 作用把扫描器的 SARIF 结果收敛为「项目 × 缺陷类 × 严重级」聚合记录 import json import pathlib import collections # 严重级映射不同扫描器对 level 的定义不一致先统一到三档 SEVERITY {error: high, warning: medium, note: low} # 规则归并表把扫描器 ruleId / CWE 收敛到报告口径的十类典型缺陷 CATEGORY { CWE-89: 注入, CWE-78: 注入, CWE-79: 跨站脚本, CWE-476: NULL引用, CWE-259: 密码管理, CWE-798: 密码管理, CWE-117: 日志伪造, CWE-16: 配置管理, CWE-20: 输入验证, CWE-404: 资源管理, CWE-22: 路径遍历, CWE-227: API误用, } def iter_findings(sarif_path): 遍历单个 SARIF 文件逐条产出归一化后的缺陷记录 data json.loads(pathlib.Path(sarif_path).read_text(encodingutf-8)) # 文件名约定 project__module__date.sarif用双下划线切出项目名 project pathlib.Path(sarif_path).stem.split(__)[0] for run in data.get(runs, []): for res in run.get(results, []): props res.get(properties) or {} cwe props.get(cwe) or res.get(ruleId, ) yield { project: project, category: CATEGORY.get(cwe, 其他), severity: SEVERITY.get(res.get(level, warning), medium), rule: res.get(ruleId, ), } def summarize(paths, total_lines): 聚合按项目、缺陷类、严重级计数并计算缺陷密度与检出率 stat collections.Counter() project_hit collections.defaultdict(set) # 用于算检出率 for p in paths: for f in iter_findings(p): stat[(f[project], f[category], f[severity])] 1 project_hit[f[category]].add(f[project]) projects len({p.split(__)[0] for p in map(str, paths)}) for (proj, cat, sev), cnt in stat.items(): if sev high: # total_lines 为该项目代码总行数单位行 print(f{proj}\t{cat}\t高危\t{cnt}\t密度{cnt / total_lines * 1000:.2f}/千行) for cat, projs in project_hit.items(): # 检出率口径含该类缺陷的项目数 / 参与统计的项目总数 print(f检出率\t{cat}\t{len(projs) / projects * 100:.1f}%) if __name__ __main__: sarif_files list(pathlib.Path(./sarif).glob(*.sarif)) summarize(sarif_files, total_lines1_200_000) # 换成实际行数这段代码有三个参数需要按项目情况改CATEGORY映射表要把你自己团队的扫描器规则补齐规则漏映射的会全部落到「其他」里口径就不完整了total_lines必须和扫描范围一致包含还是排除测试代码要事先定死否则密度会失真stem.split(__)是文件命名约定项目名里带下划线会导致切错实践中用「项目 ID 双下划线」最稳妥。聚合结果落到库表之后再按「项目维度」和「缺陷类维度」各出一张透视表。项目维度看谁的风险高缺陷类维度看共性问题。只出其中一张最后都会变成「某某项目代码质量差」的个人指责而不是组织层面的改进项。4. 开源生态与依赖侧规模、漏洞、许可、运维四条线的量化自研代码解决的是「内因」开源这一段解决的是「外因」。这部分最容易被写成罗列数字的清单实际上它需要回答一个很具体的问题我引进来的这些东西风险是从哪来的、这几年在变好还是变坏、我该盯住哪几个指标。四条线分别是生态规模、公开漏洞、活跃度和恶意组件再加上企业依赖侧的应用状况构成完整的供给侧画像。4.1 生态规模与版本膨胀截至 2023 年底八个主流包生态的项目总量从上一年底的约 550 万个涨到约 796 万个一年增长 44.7%平均每个项目有 11.3 个版本。这个增速意味着任何「把依赖清单冻结在某个时间点」的做法三个月后就会显著偏离生态现状。包生态项目数版本数平均版本数Maven727,22817,191,58223.6NPM4,170,64142,692,80610.2Packagist421,9355,380,80912.8PyPI536,5235,540,33010.3Go 模块809,0617,107,8328.8NuGet640,9668,091,15112.6RubyGems178,6931,423,6318.0Swift94,886666,5247.0从结构上看NPM 的项目数和增速都是第一一年增长 79.1%Go 模块以 58.1% 排在第二Maven 生态的项目数不算多但平均每个项目有 23.6 个版本是八个生态里版本迭代最频繁的。这个差异对漏洞管理有直接影响Maven 项目的版本选型空间大容易出现「同一个包十几个版本同时在用」的混乱NPM 这边项目基数大、新增多恶意组件的藏身空间也更大。版本膨胀还会带来一个副作用依赖树里同一个包的不同版本共存。构建工具通常只保留一份但运行时被间接拉起的旧版本仍然存在扫描器按清单扫出来的漏洞和实际跑在线上进程里的组件并不完全一致。方案里如果没有这一步「清单 → 制品 → 运行时」的校验漏洞数量会长期处于虚高状态。4.2 公开漏洞库与大型项目漏洞增长截至 2023 年底主流公开漏洞库中收录的开源软件相关漏洞共 64,938 个其中 7,107 个是当年新增。这个年增量意味着平均每天有近 20 个开源漏洞进入公开库任何依赖清单的漏洞状态都必须定期刷新一次性扫描的结论有效期不超过一个月。大型项目的历史漏洞总数排名里操作系统内核类项目以 5,983 个稳居第一浏览器内核类 3,369 个、浏览器类 2,637 个排在二三位后面是邮件客户端 1,546 个、某关系型数据库 1,430 个。年增量排名同样由内核类项目领跑一年新增 607 个浏览器内核 275 个、浏览器 186 个、某代码托管平台 165 个紧随其后。这组数字容易被误读成「大项目更危险」。恰恰相反内核和浏览器被披露的漏洞多很大程度上是因为它们被研究得最透、审计最密。真正需要警惕的是那些漏洞数不多、但长期无人维护的组件它们的漏洞根本没被披露出来。做漏洞管理时我把「披露数量」和「维护活跃度」放在一起看只有披露少且活跃度低的组件才会被标成高风险。4.3 活跃度与关键基础开源软件活跃度这条线给出的信号比较微妙68.7% 的开源项目处于不活跃状态但这个比例在下降同时版本频繁更新的项目比上一年增长了 21.6%。两个方向同时出现说明生态在分层——头部项目迭代越来越快长尾项目则在缓慢萎缩。报告还给出了主流生态中关键基础开源软件的 TOP50并指出这些组件的漏洞披露情况未见明显改善但整体运维风险有所改观。这两句话并不矛盾漏洞照常在披露说明安全问题的发现机制在运转运维风险改观说明维护者在及时发版。对使用方来说这意味着「基础组件出漏洞」是常态关键要看有没有可用的修复版本、升级路径会不会破坏兼容性。实际做评估时我会单独给关键基础组件建一张表字段包括组件名、当前版本、上游最新版本、已知高危漏洞数、是否有修复版本、升级影响面。这张表比笼统的「依赖漏洞总数」有用得多因为它直接指向动作。4.4 恶意组件识别95% 的动机是窃密恶意开源组件是这两年生态侧最大的变量。报告对 NPM 生态的专项分析显示超过 95% 的恶意组件以窃取敏感信息为目标典型目标包括浏览器凭据、会话数据、环境变量里的访问令牌和云平台密钥。传播手法上域名仿冒用拼写相近的包名冒充热门包和星标劫持把仓库的 star 数指向一个高热度仓库来伪造可信度是两种最常见的套路。报告复盘的事件里有攻击者用仿冒包名向生态投放一批与热门通信、云服务包高度同名的恶意包有平台账号被劫持后攻击者上传了十余个伪造的 Python 流行包用来窃取浏览器历史和支付信息还有一起是通过上游压缩库被植入后门在特定条件下触发影响面覆盖大量发行版只是因为受影响的版本尚未被广泛集成才没有酿成大祸。这类事件的共同点是恶意代码不在你的仓库里而在你信任的上游。离线侧能做的是建一套线索规则把「命名异常 元数据异常 行为异常」三类信号跑一遍。下面这份规则清单可以直接改成扫描脚本的配置# malicious_component_rules.yaml # 用途对依赖清单做离线线索筛查输出待人工确认的高风险组件 rules: - id: typosquat-name desc: 包名与高热度包名的编辑距离 1且下载量与同名热门包差距超过两个数量级 action: flag - id: starjacking desc: 包元数据中声明的源码仓库 star 数很高但仓库地址与包维护者无任何历史关联 action: flag - id: install-hook desc: 安装阶段执行网络请求或子进程调用preinstall / postinstall 脚本 action: block - id: young-package desc: 首次发布时间 30 天且版本号直接跳到 1.0.0 以上模仿成熟包 action: review - id: credential-access desc: 运行期读取浏览器配置目录、环境变量中的令牌或云凭据文件 action: block规则里typosquat-name和starjacking是启发式判断误报率不低所以动作设为flag而不是blockinstall-hook和credential-access是行为型信号一旦命中基本可以确定有问题直接拦截。这套规则只能覆盖已知套路真正的防线还是在引入环节新增依赖必须走人工确认锁文件必须入库构建流水线不允许动态拉取未锁定版本。4.5 企业项目的漏洞、许可与运维指标企业依赖侧的数据最能说明「实际用成了什么样」。1763 个企业项目中平均每个项目使用 166 个开源软件再创新高最流行的开源软件被 37.2% 的项目使用集中度相当高。漏洞侧平均每个项目存在 83 个已知开源软件漏洞含易利用漏洞的项目占 68.1%存在已知漏洞、高危漏洞、超危漏洞的项目占比分别是 88.0%、81.0% 和 71.9%四项指标同比均有下降。许可是另一条独立的风险线。最流行的开源许可协议在 46.9% 的项目中出现超过五分之一的项目使用了含超高危许可协议的开源软件。许可风险的特点是「平时不响、出事很响」一旦进入商业分发环节传染性协议可能要求开源自身代码这个代价远比修一个漏洞大。运维侧的问题则是老生常谈多个二三十年前的老旧开源软件版本仍在被使用同一开源软件的各版本使用依然混乱二十多年前披露的漏洞至今仍存在于多个项目中。这三条基本每年都在重复说明「升级」这件事在组织内的推动难度远高于「扫描」。许可统计可以固化成一条 SQL按项目维度出分布避免每次汇报手工数-- 按许可风险等级统计项目分布分母为参与统计的项目总数 SELECT c.license_risk, COUNT(DISTINCT c.project_id) AS project_cnt, ROUND(COUNT(DISTINCT c.project_id) * 100.0 / (SELECT COUNT(*) FROM projects), 1) AS pct FROM project_components c WHERE c.license_risk IN (超高危, 高危, 中危, 低危) GROUP BY c.license_risk ORDER BY FIELD(c.license_risk, 超高危, 高危, 中危, 低危);这条 SQL 的关键在WHERE条件一定要把未知许可UNKNOWN单独统计而不是混进低危。实践中未知许可的比例往往不低把它当成低危处理等于把风险藏起来了。另外COUNT(DISTINCT project_id)是必须的一个项目里同一个高危协议可能出现在几十个组件上不去重会把占比算爆。5. 避坑五条最容易翻车的点这套评估做下来真正让人返工的不是工具不会用而是几个固定的坑反复踩。下面五条按「现象 → 原因 → 解决」写都是我在实际项目里见过的其中前两条属于口径问题后三条属于判定和落地问题。5.1 口径类的两个坑现象一同一份材料里高危缺陷密度比整体缺陷密度还大。原因很简单转述时把「0.52」写成了「40.52」或者把分子分母写反了也有把「个/千行」当成「个/万行」的。解决方式是把口径写死在模板里密度一律采用「数值分子 / 分母 × 1000」的写法报告正文、附表、汇报 PPT 三处数字由同一个人最后核对一遍。我现在的习惯是让脚本直接输出带算式的字符串人工只做复制不做心算。现象二漏洞总数同比涨了被解读成「安全状况恶化」。原因是漏洞总数受依赖数量影响极大项目平均依赖从 150 个涨到 166 个漏洞总数自然水涨船高。解决办法是同时给出「每项目漏洞数」和「存在漏洞的项目占比」两个归一化指标这份报告的口径就是三项一起看依赖数创新高但每项目漏洞数回落到 83 个、易利用漏洞项目占比降到 68.1%才能得出「状况改善」的结论。只报一个数结论方向都可能反。现象三拿不同语言项目的缺陷密度直接排名。现象是 C/C 项目永远垫底、业务系统永远第一。原因在于语言特性决定了缺陷类型分布Java 的框架代码行数多、分母大C/C 的内存类缺陷密度天然更高。解决办法是分层统计只在同语言、同类型项目组内做对比跨组只比趋势不比绝对值。5.2 判定与落地类的三个坑现象四依赖漏洞扫描结果里一堆「已修复」的误报。原因是很多发行版会把上游补丁回填到旧版本号上版本号没变但漏洞已经修了纯按版本区间匹配就会误判。解决办法是引入发行版补丁状态作为白名单或者用制品指纹文件哈希、编译时间戳替代版本号做匹配。这一步不做研发团队很快就不再信任扫描结果。现象五许可协议只扫直接依赖漏掉传递依赖。现象是自查显示合规商业分发前法务一查就出问题。原因是构建清单里直接依赖只有几十个传递依赖有几百个高危协议往往藏在第三层、第四层。解决办法是把锁文件作为唯一扫描入口直接依赖和传递依赖一视同仁同时对未知许可单独建一张待确认清单不允许默认放行。现象六严格说是流程坑一刀切要求「全部升到最新版本」。现象是升级后兼容性问题集中爆发业务方直接拒绝再配合。原因是开源组件的版本之间存在隐式耦合尤其是基础框架类组件。解决办法是按「可利用性 是否有修复版本 升级影响面」三档分级可利用且有修复版本的立即升不可利用的排期升影响面大的先做灰度验证。给研发一个可执行的排序比给一个「全都升」的指令有效得多。注意恶意组件的启发式规则误报率不低尤其是命名相似度这类规则。上线初期建议只告警不拦截积累两周误报样本调完阈值再收紧否则会把正常依赖卡在流水线里团队很快就会绕过你的检查。6. 验收与答辩把一堆指标收成一页可复算的结论材料做完最后一关是让人信。答辩现场最常被问的三个问题基本固定样本是什么、口径是什么、结论怎么来的。我的做法是把所有内容收成一页「结论页」四个格子分别放基线对比、结构拆解、优先级排序和可执行动作每个数字后面跟一个可复算的算式或样本量。板块放什么验收标准基线对比本期与上期的同口径指标至少三项每项都标注样本量和统计年度结构拆解自研 / 依赖 / 运维三段的贡献占比三段之和能解释总风险变化方向优先级排序前三个改进项及其依据每项能对应到具体指标和责任人可执行动作下一周期的检测频率与修复 SLA有明确时间点和验收方式结构拆解这一步最容易被跳过但它恰恰是答辩的得分点。比如「整体状况改善」这个结论要能拆成自研侧高危缺陷密度下降贡献了多少、依赖侧每项目漏洞数回落贡献了多少、运维侧老旧版本问题基本持平没拖后腿。拆不出来就说明你只是把几个数字并排放着没有真正做完分析。优先级排序要给依据不能给感觉。我一般用「可利用性 × 影响面 × 修复成本」三因子打分把候选改进项排个序取前三项写进结论页。这样评委问「为什么先修这个」你可以直接指着分值说而不是回答「因为这个看起来比较严重」。可执行动作要写得像施工计划不像倡议书。「每季度全量扫描一次依赖清单、高危漏洞 7 天内出修复方案、新增依赖必须人工确认并写入锁文件」这三条能落地「加强开源组件安全管理」落不了地写上去只会扣分。从那以后我每次交这类评估材料都强制走一遍「口径自检 数字复算」所有密度类指标让脚本输出带算式的字符串所有占比类指标确认分母是去重后的项目数所有同比结论确认样本范围没有变。这套动作多花不了半小时但能挡掉评审现场九成的追问。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
