依赖清单比漏洞告警更重要：目录站的第三方依赖该怎么管

一个 PHP 或 Node 项目，上线两年后依赖树里有几百个包是很正常的。没人手装过它们，它们都是某个直接依赖带进来的。等到爆出一个高危漏洞，第一个问题是：我们到底用了没有？

这个问题如果答不上来，后面的修复、验证、对外说明全是空谈。所以第一步是先有清单。

图片来源：网络，版权归原作者所有，侵权请联系删除

SBOM 的最小要素

SBOM 就是软件的物料清单。2021 年 5 月的美国行政令 14028 要求商务部给出最小要素，NTIA 在同年 7 月 12 日发布了那份文件，里面把要求分成三块。

类别	内容	说明
数据字段	供应商、组件名、版本、其他唯一标识、依赖关系、作者、时间戳	唯一标识常用 purl 或 CPE
自动化支持	机器可读、自动生成	格式用 SPDX 或 CycloneDX
实践流程	频率、深度、已知未知、分发、访问控制、容错	明确写下什么时候重新生成

2025 年 8 月 CISA 发布了一份更新草案，在原有字段上补了四项：组件哈希、许可证、生成工具名、生成上下文（是从源码、构建时还是成品里取的）。草案还把适用范围扩到了 AI 系统和 SaaS。

对目录站来说，落地方式很简单：在 CI 里加一步自动生成 SBOM，产物和构建包一起存。不用对外发布，出事的时候能立刻查到就行。

锁文件必须进仓库

这一条比 SBOM 更基础，也更容易被忽略。composer.lock、package-lock.json、poetry.lock 进版本库，部署时用锁定版本安装，否则同一个仓库在不同时间构建出来的产物可能完全不同，漏洞排查也就失去了意义。

锁文件还要定期更新，但不要每天自动合并升级 PR——那类 PR 的量能把人淹了，而且大部分是无意义的补丁号跳动。按周或按月批量处理，配自动化测试兜底。

告警的优先级：可达性先看

漏洞扫描工具按 CVSS 分数排序，但分数高不等于你要马上修。正确的顺序是先看这条路径在你站上走不走得通：一个只在命令行工具里被调用的解析函数有反序列化漏洞，而你的站点从不把外部输入传进去，那它的实际风险接近零。

判断顺序建议是：有没有用到这个代码路径 → 输入是否可控 → 利用后果 → 修复成本。只有前两条都成立，才把它排进本周。

工具给出的「无修复版本」也别硬扛，看看是不是可以通过换包、或者在上游加一层校验绕过。

哪些事不值得做

• 追求零漏洞：依赖树里有几百个包，长期零告警不现实，把目标定成「高危且可达的清零」
• 每个告警都手工验证：按上面的顺序筛，剩下的再逐个看
• 为了降告警数量换冷门包：冷门包的维护风险比已知漏洞更高
• 给所有包手工写许可证清单：工具能扫的部分交给工具，人工只看冲突的那几个

真正值得长期投入的是三件：锁文件纪律、自动生成 SBOM、以及一个能快速回答「我们有没有用到某包某版本」的查询入口。有了这三样，任何一次漏洞事件都能在半小时内给出结论。

依赖治理的目标不是消灭风险，是把「不知道」变成「知道但接受」。前者在出事时才暴露，后者是提前做过的决定。