软件供应链事件响应实战：发现恶意组件后，如何完成全链路排查？

摘要

供应链安全建设不能只关注“如何防止攻击发生”。

企业还必须回答：

如果今天发现某个依赖被投毒，我们能不能在 30 分钟内知道哪些产品受影响？

软件供应链事件的特殊性在于，一个组件、构建系统或发布凭据被攻陷后，影响可能跨越：

多个仓库 多个制品 多个客户 多个环境

本文提供一套围绕 SBOM、VEX、制品证据和 CI/CD 日志的供应链事件响应流程。

1. 供应链事件和普通漏洞事件有什么不同？

普通漏洞：

CVE ↓ Find Hosts ↓ Patch

供应链事件可能是：

Maintainer Compromise ↓ Malicious Package ↓ Multiple Builds ↓ Multiple Products ↓ Multiple Customers

核心问题不只是：

“哪里有漏洞？”

而是：

“这个不可信输入传播到了哪里？”

2. 常见供应链事件类型

• 开源组件被投毒；
• 私有依赖被替换；
• 构建 Runner 被入侵；
• CI Token 泄露；
• 发布账号被接管；
• 镜像仓库被篡改；
• 制品签名密钥泄露；
• 基础镜像被污染；
• AI 模型或数据集被替换。

3. 第一阶段：立即冻结信任链

如果确认高风险供应链事件，第一步通常不是“马上升级版本”，而是先阻止进一步传播。

建议立即：

Pause Release Revoke Credential Disable Compromised Workflow Quarantine Package Freeze Artifact Promotion

避免新的恶意制品继续生成。

4. 第二阶段：确定 IOC 和受影响对象

需要收集：

Package Name Version Digest Publisher Publish Time Commit Build ID Registry Signature OIDC Identity

如果是容器镜像，还要确认：

Image Digest Base Image Digest Layer Digest

5. SBOM 在事件响应中的价值

没有 SBOM 时：

安全团队问： 哪些产品使用了 package-X@1.2.3？ 研发团队： 我们查一下……

可能要几小时甚至几天。

有 SBOM：

package-X@1.2.3 ↓ Query ↓ Product A Product C Service F

可以显著缩短影响面定位时间。

6. 建立 Component → Product 反向索引

很多团队只有：

Product → SBOM

真正用于响应时，还需要：

Component → Products

例如：

log4j-core@2.14.1 ├── CRM 3.2 ├── Payment 5.6 └── Gateway 1.8

这是供应链事件响应的核心数据结构之一。

7. 第三阶段：判断“存在”还是“受影响”

组件存在：

Component Present

不一定等于：

Exploit Path Exists

因此需要结合：

• VEX；
• Reachability；
• Runtime Exposure；
• 配置状态；
• 部署环境。

形成：

Affected Not Affected Under Investigation Fixed

8. 第四阶段：追溯构建链

如果攻击涉及 CI/CD，就不能只查组件。

还要追溯：

Source ↓ Commit ↓ Workflow ↓ Runner ↓ Build ↓ Artifact ↓ Registry

重点确认：

哪些制品由被攻陷 Runner 构建？

即使制品中暂时没发现恶意代码，也可能需要重新构建。

9. Provenance 的响应价值

如果所有制品都有 Provenance：

Artifact Digest → Build ID → Workflow → Source Commit

就可以迅速回答：

哪些发布物来自这个被攻陷的构建环境？

这是 Provenance 除合规之外最实际的运营价值之一。

10. 第五阶段：重新建立可信基线

供应链事件处置不能只做：

delete malware

还要：

restore trust

常见动作：

• 轮换发布凭据；
• 重建 Runner；
• 更换签名身份；
• 从可信 Commit 重建；
• 重新生成 SBOM；
• 重新生成 Provenance；
• 重新签名；
• 重新发布制品。

11. 为什么需要“可信重建”？

假设：

package v1.4.2

曾经经过被入侵 Runner。

即使扫描没发现恶意行为：

我们也无法证明它可信

最稳妥的是：

Trusted Source + Clean Builder ↓ Rebuild ↓ New Digest ↓ New Signature

12. 第六阶段：客户与内部通知

供应链事件往往需要跨团队沟通：

Security Engineering Product Legal Customer Support Management

通知应该明确：

• 受影响产品；
• 受影响版本；
• 是否确认恶意利用；
• 临时缓解措施；
• 修复版本；
• 升级路径；
• 后续调查状态。

13. 建议建立 Crisis Management Runbook

CISA 的软件供应链实践材料强调，应把 SBOM/VEX 与漏洞和危机响应流程衔接起来。

企业可以提前建立：

Supply Chain Incident Runbook

包含：

触发条件 指挥角色 技术负责人 产品负责人 客户沟通 证据保全 修复审批 恢复条件

14. 一个 60 分钟响应框架

0—15 分钟

确认事件 冻结发布 吊销关键凭据 建立 War Room

15—30 分钟

提取 IOC 查询 SBOM 识别受影响产品 锁定构建批次

30—60 分钟

建立优先级 生成 VEX/影响判断 启动重建 准备内部通知

15. 关键指标

建议记录：

16. 一次事件结束后必须做什么？

Postmortem 不应该只写：

攻击者做了什么

还要问：

为什么恶意输入能进入？ 为什么没有被提前阻断？ 为什么影响面定位慢？ 为什么证据不完整？ 为什么能绕过发布门禁？

最终改进：

Prevention + Detection + Traceability + Response

总结

成熟的软件供应链安全必须同时具备：

Prevent Detect Trace Contain Rebuild Recover

SBOM、VEX、Provenance、签名和构建日志的价值，不只是为了“合规有材料”，更重要的是：

当真正的供应链事件发生时，能够快速判断影响面并重新建立信任。