现代应用的代码里，自研部分往往不到 20%，其余都是开源组件和其传递依赖。这意味着一个系统真正的攻击面，绝大部分不在你自己的代码里，而在你根本没仔细看过的那张依赖图里。
一、SBOM：先解决“我不知道”
SBOM（软件物料清单）是一份描述制品所有组件的清单，通常包含名称、版本、供应商、依赖关系、许可证信息。它的价值不是文件本身，而是把回答“我们有没有中这个漏洞”的时间从几天缩短到几分钟。
两个主流格式：SPDX 与 CycloneDX。前者源于许可证合规场景、偏重法律信息，后者源于安全场景、对依赖层级与漏洞描述支持更好。安全驱动的团队一般选 CycloneDX。
生成方式上，建议在 CI 构建阶段自动产出，并与制品一起归档。手工整理清单在首次发布后就无法维护了。
二、漏洞暴露面：不要只看 CVE 数量
扫描工具动辄报出上千个漏洞，如果全都当待办，团队只会选择忽略。真正应该优先处理的判断维度有四个：
- 是否可达：这个有漏洞的函数是否真的被业务代码调用。不可达的漏洞风险极低。
- 是否在运行态：仅存在于构建工具链的依赖，优先级低于生产运行时依赖。
- 是否暴露在外部：能通过网络触发的问题必须先修。
- 是否已有利用代码：已进入在野利用的漏洞应视为紧急。
按这四个维度排序，上千条告警通常能收敛到十几个真需要当晚处理的问题。
三、治理机制比工具更重要
| 环节 | 关键动作 |
|---|---|
| 引入 | 新依赖必须经过安全审查，禁止未经评估的包进主分支 |
| 构建 | 自动生成 SBOM，锁定依赖版本，禁止直接引用最新版 |
| 运行 | 持续比对 SBOM 与漏洞库，发现新增漏洞自动建单 |
| 响应 | 明确修复时限：严重漏洞 24 小时，高危 7 天 |
建议同时建立依赖白名单与内部镜像仓库。只从内部仓库拉取经审核的组件，可以同时抵御同名包投毒和上游仓库不可用带来的构建中断。
四、几个容易被忽略的风险点
传递依赖不可控。你直接引入的只有五个包，但它们的依赖可能有两百个。SBOM 必须支持多层级展开，否则治理覆盖面会严重不足。
构建工具的依赖也需要覆盖。CI 流水线里运行的构建插件、测试框架同样可能被投毒，而它们往往拿得到代码和密钥。
许可证风险与安全风险要一起看。某些许可证对商业分发有严格要求，引入前应经过法务评估，否则可能在产品发布时才暴露。
SBOM 本身要能被验证。建议对 SBOM 文件做签名，并在部署前校验制品与 SBOM 的一致性，防止清单与实际构建内容脱节。
五、从小处开始
不必一开始就追求全量覆盖。可行的第一步是：选一个核心服务，在 CI 里自动生成 SBOM 并接入漏洞扫描，把告警按可达性排序，只修前几项。把这条链路跑通、让团队看到效果，再推广到其他服务，远比一次性上平台更容易成功。
