攻击者的入口正在向上游移动
软件供应链攻击有一个明显趋势：攻击点从运行时移到了构建与发布环节。过去攻击者要找一个能被利用的漏洞，现在只需要污染一个依赖、篡改一次构建产物、或者抢注一个包名——受害者会在“完全合规地安装更新”的过程中把恶意代码请进门。
这类攻击最麻烦的地方在于它绕过了你对自身代码的信任判断：你的代码没有问题，测试也通过了，但最终产物里包含了攻击者的东西。因此供应链治理的思路必须从“检查自己写的代码”扩展到“检查你信任的每一环”。
四个抓手
抓手一：依赖清单。 先解决“我用到了什么”。软件物料清单（SBOM）的价值不在于格式，而在于当某个组件爆出漏洞时，能不能在几分钟内回答“我们哪些系统受影响”。没有清单，这个问题只能靠人工排查，通常要花几天到几周。
现实中的难点是递归依赖：直接引用的组件可能只有几十个，但传递依赖往往上千。因此清单必须自动生成、随发布更新，而不是上线前人工填一次表格。
抓手二：来源与完整性。 依赖只从受控的私有镜像源拉取，并锁定版本、校验哈希。这一条能同时防住两类攻击：抢注仿冒包名，以及上游包被替换内容。需要特别注意的是，模型生成的代码里经常出现并不存在的依赖包名——如果工程流程里有“装上试试看”的习惯，就等于把这条攻击路径打开了。
抓手三：构建与发布。 构建环境要隔离，构建过程要可复现，构建产物要签名并记录来源。构建服务器是攻击者眼中的高价值目标：攻下它，就能在不接触任何源码仓库的情况下污染所有产物。因此构建机的权限、网络访问与凭据管理，应当按最高等级对待。
抓手四：持续监测。 清单是快照，威胁是持续的。需要建立两类监测：一类是已知漏洞与组件停止维护的提醒，另一类是异常发布的告警——例如某个长期不更新的依赖突然发了新版本、或者同一版本的内容发生了变化。
几个反复出现的问题
- 清单是人工维护的表格，与实际发布脱节，几个月后就没人更新；
- 开发直连公共源，构建流程没有强制走私有镜像；
- 锁定版本只锁了顶层依赖，传递依赖仍随上游漂移；
- 构建机权限过大：既能访问源码，又能推送到生产仓库；
- 缺少“这份产物是谁构建的”的记录，出事时无法定位污染范围。
落地顺序
供应链治理的顺序是先看得见，再管得住：
- 建立自动化的依赖清单，并把它接入漏洞响应流程；
- 收敛依赖来源，禁止开发与构建直连不可控的公共源；
- 加固构建与发布链路，隔离环境、签名产物、记录来源；
- 建立持续监测，把组件风险纳入日常运营，而不是一次性审计。
一句话总结：供应链安全不能靠“信任上游”，只能靠“随时能回答自己用了什么、从哪来、是谁构建的”。这三问答不上来，其余投入都建立在假设之上。