供应链威胁

软件供应链攻击并不是直接攻破某个组织，而是破坏该组织信任并使用的某项内容：库、构建工具、容器基础映像或更新服务器。

现代软件由数百个第三方组件组装而成，因此一个被投毒的环节会被每个下游使用者继承。攻击者只需投入一次，就能影响许多受害者。

• 信任倒置——安全边界移到了您自己的代码之外
• 传递性影响范围——一个恶意软件包会流入数千个构建过程

当您添加一个直接依赖项时，通常还会引入几十个您从未选择过的传递性依赖项。典型的 Node 或 Python 应用只声明少量软件包，但解析后可能包含数百个软件包。

请列出完整的解析后依赖树，而不只是清单，以查看实际交付的内容：

攻击者发布名称近似热门软件包的恶意软件包，赌用户会犯下致命的拼写错误。

• 伪装拼写——用 reqeusts 代替 requests
• 组合抢注——用 python-requests 模仿真实名称
• 依赖混淆——发布一个与您内部私有软件包同名的公共软件包，使配置错误的解析器获取攻击者的版本

通过固定使用受信任的内部注册表，并使用带作用域或命名空间的私有软件包来进行防御。

如果合法且广受信任的软件包的维护者账户遭到入侵，或恶意贡献者获得了发布权限，该软件包就可能变得具有攻击性。

近期的真实事件表明，攻击者会通过钓鱼获取维护者凭据，然后推送被投毒的补丁版本，在安装期间窃取令牌。

• 要求所有发布账户启用双因素认证
• 优先选择使用作用域限定的发布令牌和受保护发布版本的软件包
• 关注关键依赖项中意外出现的新维护者

许多生态系统会在安装时运行代码，早于您的应用启动。一次 npm install 就可能执行 postinstall 钩子，窃取环境变量或 SSH 密钥。

在持续集成环境中禁用任意安装脚本，并审查任何需要这些脚本的软件包：

构建环境本身就是高价值目标。如果攻击者污染了编译器、持续集成运行器映像或构建插件，那么它生成的每个构建产物都会带有后门，即使您的源代码是干净的。

典型例子是被植入木马的更新机制：它使用合法的代码签名密钥为恶意软件签名，使受害者将其当作真实软件接受。

• 将构建基础设施视为生产环境，并进行全面加固
• 使用临时且可复现的构建运行器
• 将签名密钥与构建主机分离

锁定文件会固定确切版本和内容哈希，因此重新解析时不会悄无声息地替换为其他构建产物。请始终提交该文件，并让持续集成环境验证它，而不是任意重新解析依赖项。

完整性字段存储一个哈希值；如果下载的压缩包不匹配，安装就会失败。

已知存在漏洞的版本（以 CVE 进行跟踪）是最常见的供应链弱点。软件组成分析（SCA）工具会将您解析后的依赖项与漏洞数据库进行交叉比对。

在持续集成环境中运行扫描，并在发现严重问题时使构建失败：

浮动版本范围（^1.2.0）会让新版本自动流入，这虽然方便，却会使您暴露于恶意补丁之下。

• 固定为确切版本，并有意审查升级内容
• 对于容器映像，按摘要固定，不要使用 latest 这类可变标签
• 将关键依赖项内置到您自己的代码库或镜像中，避免上游删除导致您无法构建或遭到投毒

保护供应链是一项持续工作，而不是一次性扫描。您需要知道交付了什么、它来自哪里以及它何时会变得易受攻击。

• 为每个发布版本生成SBOM（下一课）
• 记录构建来源证明，以便证明构建产物是如何生成的
• 订阅安全公告，以便新披露的 CVE 触发对已交付构建产物的重新评估

绘制每个不受信任输入进入的阶段：开发者计算机、源代码管理、依赖项注册表、构建系统、构建产物存储以及更新渠道。每个阶段都可能成为注入点。

针对每个阶段询问：谁可以在这里写入内容，攻陷后他们能做什么，以及我将如何检测到这些行为？这样得到的是一份按优先级排列的控制措施清单，而不是通用检查清单。

测试您对一种常见供应链攻击类别的理解。

您已了解依赖项为何会成为攻击向量，以及如何减少这种暴露。

• 信任倒置意味着您的安全性取决于您无法控制的第三方
• 主要威胁包括：伪装拼写、依赖混淆、维护者账户接管、恶意安装脚本和遭入侵的构建工具链
• 核心防御措施包括：带完整性哈希的锁定文件、SCA 扫描、按摘要精确固定版本、为发布者启用双因素认证以及持续监控

下一步，您将使用 SBOM 精确清点软件包含的内容。