软件供应链攻击如何防范：从依赖引入到制品发布的完整防线

风险不只来自有漏洞的依赖

攻击者可能接管维护者账号、发布同名恶意包、污染构建脚本或替换镜像。只在上线前扫描已知漏洞，无法发现来源异常和构建过程被篡改。团队应记录从源码、依赖、构建器到最终制品的完整来源，让每个生产版本都能回答由谁、在什么环境、使用哪些材料构建。

依赖引入要有边界

通过内部代理统一下载依赖，锁定精确版本并校验哈希，禁止构建时从任意地址动态执行脚本。新依赖除了漏洞数量，还要评估维护活跃度、发布历史、许可证和替代成本。自动更新工具应创建可审查的变更，而不是直接合并到主分支。删除无用依赖同样重要，因为未调用的组件仍可能进入最终制品。

构建环境必须短暂且隔离

持续集成任务使用一次性执行器，默认无生产网络和长期凭证。不同仓库、分支和外部贡献代码采用不同权限，高风险密钥只在经过保护的发布阶段按需获取。构建日志要过滤敏感信息，缓存需要按信任级别隔离，防止恶意任务污染其他项目。

制品需要身份与证明

生成软件物料清单，记录组件、版本和来源，并将构建证明与制品绑定。镜像、安装包和部署清单使用受控密钥签名，部署平台只接受通过策略验证的制品。签名密钥放入专用密钥系统，设置轮换和审批，不能保存在普通流水线变量中。

把响应能力纳入设计

发现某个依赖受影响时，应能快速查询哪些服务、版本和环境正在使用，并判断是否真正可达。建立紧急替换、回滚和吊销流程，定期演练维护者账号失陷与镜像仓库污染。供应链安全的核心不是收集更多扫描报告，而是让每份上线制品可追溯、可验证且能够迅速撤回。