软件供应链安全入门：依赖、构建与发布的可信链路

现代产品里大部分代码来自第三方：一次依赖投毒、一次构建链泄露，就能绕过你所有业务代码的测试。这篇讲清四个攻击入口、依赖与漏洞治理、SBOM，以及小团队四周就能落地的可信链路。

一、四个入口：攻击者会从哪里进来

你的产品里有多少代码是自己写的？对多数团队来说，答案是"一小半"——剩下的来自开源依赖、基础镜像、构建工具链。供应链安全关注的正是这条链路上"别人的代码"如何一路走到你的生产环境。

业务代码测得再严，链路上一环被替换，一切都归零——供应链安全守的是「别人的代码」到你生产环境之间的每一段路。

二、依赖治理：从「少装一个包」开始

• 最少依赖原则：每个新依赖都是新的信任边界。引入前评估：维护活跃度、下载量与受关注度、近期 issue 响应、需要什么权限（安装脚本、网络、文件写入）
• 锁文件 + 冻结安装：锁死完整依赖树（含传递依赖），用 npm ci 这类"按锁安装"的命令，杜绝"构建时又拉了什么新东西"
• 私有代理：上游包先进内部代理再进项目，既能防上游被删/被替换，也能拦截抢注名的相似包
• 定期审计：SCA 工具（依赖扫描）接进 CI 与定时任务，新漏洞第一时间进入视野

三、漏洞管理：不是所有 CVE 都要立刻修

扫描工具很容易把报告变成"几千条待处理"，然后没人再打开它。有效的做法是分级 + SLA：按可利用性、暴露面（是否可达、是否面对公网）、数据敏感度综合定级；严重漏洞 7 天内修复、高风险 30 天、其余按迭代节奏——并且给出例外记录流程（不修也要有人签字说明原因）。

一个关键判断：「依赖里存在漏洞」不等于「你的系统可利用」。多数扫描只报告版本命中，是否真的可达需要人工或用可达性分析确认——把有限的时间花在真正可达的漏洞上。

四、SBOM：一张「配料表」的威力

SBOM（软件物料清单）是产品里全部组件的清单：名称、版本、来源、依赖关系，格式常用 SPDX 或 CycloneDX。它的价值在"事发那一刻"：某基础库爆出漏洞，你能在五分钟内查清哪些产品、哪些版本受影响——没有 SBOM 就只能人肉翻仓库。它同样常用于应对客户与监管的合规问询。

# 构建时为镜像生成 SBOM（示意，syft 风格）
syft registry/myapp:1.4.2 -o cyclonedx-json > myapp.sbom.json

# 把 SBOM 与制品一起归档：按版本保存，随构建自动更新

三条纪律：随构建自动生成（手工整理必然过期）；随手归档到可检索的位置；别把它当一次性交付物——不随版本更新的 SBOM 就是废纸。

五、签名与验证：让「可信」可以被程序证明

• 制品签名：用 Sigstore / cosign 这类工具给镜像与包签名，证明"它确实来自你的流水线"
• 部署前校验：K8s 准入或部署脚本先验签，签名不符直接拒绝——防止中间任何环节被替换
• 用 digest 引用镜像：部署时锁定摘要（sha256:…），不用浮动 tag——"到底跑的哪个版本"永远可回答
• CI 最小权限：构建凭证短时效、默认只读、按需提权；把它当成"能生产一切制品"的总统钥匙来管

六、落地路线：四周四步走

• 第 1 周 · 打地基：确认锁文件齐全、安装命令都是"冻结模式"；把依赖扫描接进 CI 与每周任务
• 第 2 周 · 立规矩：新依赖评审清单上线；内网代理启用；给扫描结果定分级与修复 SLA
• 第 3 周 · 有清单：构建时自动生成 SBOM 并按版本归档，做一次"假如某依赖爆漏洞"的桌面演练
• 第 4 周 · 可验证：制品签名 + 部署前校验上线；镜像改用 digest 引用；CI 凭证收敛到最小权限

七、五个常见坑

• 只扫直接依赖：传递依赖才是数量和风险的大头——看完整依赖树
• 报告没人看：没有分级、SLA 与负责人的扫描，只是生产没人读的报表
• 用浮动 tag 部署：版本无法追溯，出事后无法回答"线上到底是哪个制品"
• CI 令牌权限过大、长期有效：一次泄露就能把恶意版本推上生产
• SBOM 一次性交付：不随构建更新、不归档检索——真需要它的时候找不到、对不上

速查卡

写在最后

供应链安全不要求你"信任更少"，而是要求你把信任变得可验证：依赖有清单、构建有记录、制品有签名、部署有校验。这条链路不需要一次建满——从锁文件和依赖扫描开始，每周往前走一步，半年后你就拥有了一条别人很难攻破、而你自己完全掌握的可信交付路径。