供应链入侵

本文约需 2 分钟阅读

供应链攻击是指攻击者介入软件开发、构建或分发的某一环节，将恶意代码注入正规软件的攻击手法。由于它滥用了受信任软件的更新通道，传统的安全措施极难检测。 2024 年的 xz Utils 后门事件凸显了开源维护体系的脆弱性，使人们重新认识到 SBOM (Software Bill of Materials) 的重要性。

校验能确认与不能确认的事项

记录并比对分发物指纹的机制，能够回答所取得的内容是否与所公开的内容相同。它无法回答的是，所公开的内容本身是否正当。如果经过开发方的手续、通过正规渠道公开的版本中含有恶意代码，比对结果仍会一致。这正是此类攻击与传统检测方式不相适应之处：入侵的痕迹并不留在使用者一侧的环境中，而是留在使用者无法查看的上游作业环境里。其次，把版本固定下来这一判断也具有两面性。固定之后不会发生意料之外的替换，但同时也会让修正无法被纳入。在固定状态下经过一段时间，就容易变成继续使用仍留有已公布缺陷的版本。固定与更新并非其中一方才是安全的选项，这一选择归结为把确认的工夫放在何处的分配问题。第三点是所覆盖的范围。在选定要组合进来的部件时，被选中的只是直接写下名称的那些，而实际被纳入的却是包含这些部件所需部件的整体。随着数量增加，从未见过名称的部件所占的比例也会提高。因此，掌握范围并不是列出自己所选内容的清单，而是把由此连带进来的部分一并计入、对整体进行清点。对于尚未掌握的部分，也就无从知晓是否发生过更新。

供应链攻击流程

历史背景

供应链攻击引起全球关注，始于 2020 年的 SolarWinds 事件。 IT 管理工具 Orion 的构建流程中被植入了后门，影响了包括美国政府机构在内的 18,000 多个组织。 2021 年的 Kaseya VSA 事件、 2024 年的 xz Utils 后门事件等，针对供应链的攻击逐年高度化。在 CVE 数据库中，与供应链相关的漏洞报告也在急剧增加。

防御措施

创建和管理 SBOM (Software Bill of Materials) 是防御的基础。掌握所使用的开源库及其版本，并持续监控漏洞信息。提交依赖关系的锁文件 (package-lock.json 、 Gemfile.lock) ，防止意外的版本变更。在构建流水线中，应引入通过签名验证和哈希校验来检测产物被篡改的机制。在代码审查中重点确认依赖关系的新增与变更也很重要。用强随机密码保护 CI/CD 系统和包注册表的账户，防止对构建流程的非法访问。