软件供应链安全新规解读：企业必须做的 3 件事

标准体系：一张表看清适用哪一份

标准体系已经给出清晰的"能力地图"，企业的难点在于把它翻译成自己流程里的动作。

第一件事：把 SBOM 做起来

软件物料清单（SBOM）要回答一个最基础的问题：我们的软件里到底有什么。没有清单，出现 Log4j 这类事件时，企业连"我有没有受影响"都说不清，只能靠人逐个问供应商。

落地要点：

• 先覆盖自研系统，把直接依赖与间接依赖都纳入，工具可从构建环节自动生成；
• 对外采购的商业软件，在合同或交付要求中约定供应商提供 SBOM；
• SBOM 要有版本并与发布版本绑定，附件随软件交付物一同归档；
• 格式参照 GB/T 47020-2026，避免每家一份私有格式导致无法比对。

第二件事：建立开源治理机制

开源组件是效率来源，也是风险来源。治理的核心不是"禁用开源"，而是"知道用了什么、能多快响应"。

• 引入审批：新引入组件需评估许可证类型、社区活跃度、已知漏洞与维护状态；
• 许可证合规：区分宽松型与传染型许可证（GPL / AGPL 等），避免商业产品被迫开源；
• 漏洞响应：建立分级响应时限（例如严重漏洞 24 小时内定位、72 小时内修复或缓解），并保留处置记录；
• 持续监测：把组件清单接入漏洞情报源，而不是依赖季度扫描。

第三件事：把安全要求写进交付环节

供应链风险的相当一部分来自"交付即结束"——验收只看功能，不看安全。建议在采购与交付流程中加入四道动作：

1. 供应商分级：按系统重要程度对供应商分级，重要供应商需要提供安全能力证明或接受评估；
2. 合同条款：明确漏洞通知义务、修复时限、安全事件配合义务、SBOM 提供义务、审计权；
3. 交付验收：验收清单中加入安全项——漏洞扫描报告、SBOM、第三方组件清单、默认口令与配置核查；
4. 持续监督：年度复核供应商安全状况，重大版本升级触发重新评估。

一张落地清单

结语

软件供应链安全不是买一套工具就能解决的问题，它的核心是把外部风险内部化：知道自己用了什么，知道风险什么时候来，知道出了问题多久能修。先做台账和流程，再谈平台和能力评估，顺序不要反。