DevSecOps 中的制品安全：为什么漏洞扫描必须前置到 CI

概述

在 DevSecOps 被反复提及的今天，很多团队已经习惯把“安全”理解为上线后的防护能力：WAF、运行时监控、异常告警、应急响应。但现实中的大量安全事件一再证明，真正决定系统安全下限的，并不是运行时，而是制品阶段。

尤其是在 Node.js / React 等前端与中间层生态中，近几年频繁出现的供应链攻击、依赖投毒、构建期注入挖矿木马事件，几乎都有一个共同点： 问题在镜像被构建完成之前就已经发生了。

制品一旦生成，风险就已经“定型”

容器时代的一个常见误区是： “只要镜像跑在安全的集群里，就不会出大问题。”

事实上，容器镜像是一个强不可变对象。 它包含了运行时依赖、系统库、语言运行时、应用代码，一旦构建完成并被发布，其风险结构就已经被锁死。

如果在这个阶段引入了高危漏洞，或者被注入了恶意逻辑，那么后续无论部署在什么环境、跑在什么节点上，它都会以“合法应用”的形式持续运行。

这正是为什么，制品安全必须前置到 CI 阶段，而不是事后补救。

为什么漏洞扫描不能放到部署之后？

从工程视角看，把漏洞扫描放到 CI 之后、甚至上线之后，至少会带来三类问题：

第一，修复成本急剧上升。 CI 阶段失败，最多是一次构建重跑；上线后发现问题，往往意味着回滚、停机、紧急修复，甚至影响用户。

第二，责任边界开始模糊。 构建阶段的问题，本应由开发与平台共同承担；一旦进入运行时，安全问题就会被误认为是“运维事故”或“平台不稳定”。

第三，也是最致命的一点： 你已经允许一个不可信的制品进入了系统边界之内。

安全体系一旦在这里妥协，后续所有防护都只能是止损，而不是防御。

CI 阶段漏洞扫描解决的是什么问题？

以 Trivy 这类工具为代表的漏洞扫描，并不是为了“消灭所有漏洞”，而是为了解决一个更基础的问题：

这个制品当前的风险状态是什么？

在 CI 中引入自动化漏洞扫描，可以明确做到三件事：

• 把已知高危漏洞显式暴露出来
• 用机器可执行的规则阻断高风险制品
• 让“是否允许发布”成为一个可审计的决策，而不是经验判断

例如，在构建完成后直接对镜像进行扫描，并对 HIGH / CRITICAL 级漏洞设置硬性门禁：

- uses: aquasecurity/trivy-action@0.28.0
  with:
    image-ref: ${{ env.image }}
    severity: HIGH,CRITICAL
    exit-code: '1'

一旦触发规则，流水线直接失败，镜像无法进入生产仓库，无法发布到生产环境。

• Node.js / React 生态给 DevSecOps 的现实提醒
• 近期多起 Node.js / React 相关安全事件表明：
• 攻击者越来越倾向于绕过运行时防护，转而污染依赖和构建流程。

在这种攻击路径下，漏洞扫描并不能保证你绝对安全，但它至少可以确保一件事：

你不是在“完全无感知”的情况下，把一个高风险制品推向生产环境。

安全的第一步，不是防御未知攻击，而是不要忽视已知风险。

往期回顾

1. 告别 AccessKey：EC2 / K3S 使用 kube2iam 构建无密钥运行时权限
2. 告别 AccessKey：GitHub Actions OIDC 构建无密钥 CI/CD
3. CloudNeutral 多云 IaC 实践：如何安全打通 IaC、制品构建与发布流水线
4. CloudNeutral 多云 IaC 实践：抽象与复杂度之战
5. CloudNeutral 多云 IaC 实践：安全、合理地管理云资源