质量门禁与安全扫描

为什么"测试通过"远远不够

很多人以为 CI 的门禁就是"跑单测".但测试只能证明功能符合预期,管不了下面这些同样能搞垮生产的问题:

测试全绿,但是:

• 新写的代码根本没被测试覆盖到 -- 测试"绿"得没意义
• 代码里有 SQL 拼接,存在注入漏洞 -- 功能正常,安全是个洞
• 引入的某个第三方库有已知高危 CVE -- 你的锅,但不是你写的
• 基础镜像 alpine 自带的某个包有漏洞 -- 镜像层面的风险
• 镜像在推送途中被人掉包 -- 部署的不是你构建的那个

这些问题有个共同点:功能测试发现不了,但都会变成生产事故或安全事件.质量门禁的设计,就是为每一类风险配一道专门的自动关卡.我们从"代码本身"由内向外,一层层往镜像和供应链推.

[代码] → [门禁1<br/>测试+覆盖率] → [门禁2<br/>SAST 静态扫描] → [门禁3<br/>依赖扫描] → [构建镜像<br/>(第03篇)] → [门禁4<br/>镜像漏洞扫描 Trivy] → [门禁5<br/>SBOM + 签名] → [可信镜像<br/>进仓库]

门禁一:测试覆盖率

覆盖率(Coverage)衡量"测试到底跑过了多少比例的代码".它堵的是"测试绿得没意义"这个洞--如果新增的 200 行代码一行都没被测到,那测试通过只能说明没被测的部分恰好没崩.

- run: npm test -- --coverage      # 跑测试并统计覆盖率
- run: |
    COVERAGE=$(...)                # 取出覆盖率数字
    if [ "$COVERAGE" -lt 80 ]; then
      echo "覆盖率 $COVERAGE% 低于 80%,门禁拦截"
      exit 1                       # ← 非 0 退出码 = Step 失败 = 流水线红
    fi

实践中更常用现成工具(如 SonarQube,Codecov)来设阈值,但原理就是这个 exit 1:不达标就让 Step 失败,流水线随之中止.这就是第 02 篇"失败即变红,阻止合并"机制的延续.

门禁二:SAST 静态应用安全测试

SAST(Static Application Security Testing,静态应用安全测试):不运行代码,直接扫描源码,找出危险的写法和已知的漏洞模式.它堵的是"功能正常但有安全洞"这一类.

典型能揪出的问题:SQL 注入(字符串拼接 SQL),命令注入,硬编码的密码/密钥,不安全的加密算法,路径穿越等.

常用工具:CodeQL(GitHub 原生,在 Actions 里几行配置就能开),Semgrep,SonarQube.在 GitHub Actions 里启用 CodeQL:

- uses: github/codeql-action/init@v3
  with:
    languages: javascript
- uses: github/codeql-action/analyze@v3
  # 扫描结果直接出现在 PR 的 "Security" 标签里,有高危问题可配置为阻止合并

门禁三:依赖扫描

现代项目里,你自己写的代码可能只占 10%,其余 90% 是第三方依赖.这些依赖里的已知漏洞,就是你应用的漏洞--著名的 Log4j 漏洞就是这么炸全网的.

依赖扫描(也叫 SCA,Software Composition Analysis,软件成分分析)比对你的依赖清单和公开漏洞库(CVE),揪出"你用的某个库的某个版本有已知高危漏洞".

你的 package.json
   └─ 用了 some-lib@1.2.0
        └─ 它又依赖 vulnerable-pkg@0.5.0  ← CVE-2023-XXXX 高危!
                                            (你可能根本不知道有这层间接依赖)

工具:GitHub 自带的 Dependabot(免费,自动提修复 PR),Snyk,以及下面要重点讲的 Trivy(它依赖扫描和镜像扫描都能干).

门禁四:用 Trivy 扫描镜像

前三道门守的是源码和依赖.但第 03 篇构建出的镜像,还包含基础镜像(如 alpine)自带的操作系统包--这些你没写,没直接引入,但同样可能有漏洞.需要直接扫"成品镜像".

Trivy(Aqua Security 出品)是云原生领域最流行的扫描器,一个工具扫多种目标:镜像里的 OS 包漏洞,应用依赖漏洞,配置错误,密钥泄露.在流水线里,它接在第 03 篇构建之后:

- uses: docker/build-push-action@v6   # 第 03 篇:构建镜像
  with:
    tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
    push: false                        # 先别推,扫过再说

- uses: aquasecurity/trivy-action@master
  with:
    image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
    severity: 'HIGH,CRITICAL'          # 只关心高危和严重
    exit-code: '1'                     # ← 发现就让 Step 失败 = 门禁拦截

关键又是 exit-code: 1:扫到高危漏洞就让流水线变红,这个镜像根本不会被推到仓库,更不会上线.门禁的精髓始终是这一下"拦截".

门禁五:供应链安全 -- SBOM 与镜像签名

前面四道门解决"东西本身有没有问题".最后这道门解决一个更隐蔽的问题:我部署的这个镜像,真的是我那条可信流水线构建出来的吗?中途有没有被掉包?里面到底装了什么?这就是软件供应链安全(Software Supply Chain Security).

SBOM:软件物料清单

SBOM(Software Bill of Materials,软件物料清单) 是一份机器可读的清单,精确列出"这个镜像里到底装了哪些包,哪些版本".

构建时用 Trivy 或 Syft 生成 SBOM,随镜像一起存档.等于给每个制品留了一份"出厂成分存根",出事时能秒级排查影响面.

镜像签名:证明"出身清白"

镜像从仓库拉取,在网络上传输,理论上可能被篡改或冒名顶替.镜像签名用密码学手段给镜像盖一个"防伪章":流水线在推送前用私钥签名,集群在部署前用公钥验签--验不过就拒绝运行.

云原生标准工具是 cosign(属于 Sigstore 项目):

# 流水线里:构建推送后签名
$ cosign sign ghcr.io/org/myapp:a1b2c3d

# 集群侧:部署前验签(可由准入策略强制)
$ cosign verify ghcr.io/org/myapp:a1b2c3d
# 验证通过 → 确认这镜像确实由我们的流水线签发,未被篡改

收尾:阶段一的完整 CI 流水线长什么样

把第 01-04 篇所有要点拼起来,一条成熟的 CI 流水线的骨架就清晰了:

[提交/PR]                                       ← 01 篇:事件触发
     │
     ├─ test + lint  (并行,快速失败)              ← 02 篇:Job 并行 / needs
     │     └─ 覆盖率门禁                            ← 04 篇:门禁一
     ├─ SAST 静态扫描                              ← 04 篇:门禁二
     ├─ 依赖扫描                                   ← 04 篇:门禁三
     │
     ▼ (前面全绿才继续)
  [构建镜像]  多阶段 + 缓存 + commit-SHA tag       ← 03 篇
     │
     ├─ Trivy 镜像漏洞扫描门禁                      ← 04 篇:门禁四
     ├─ 生成 SBOM + cosign 签名                    ← 04 篇:门禁五
     │
     ▼
  [推送可信镜像到仓库]
     │
     ▼ (交给阶段二)
  GitOps 自动部署到集群                            ← 第 05 篇起

到这里,流水线已经能自动,可信地把一次提交变成一个经过层层把关的镜像.正因为有这一整套门禁兜底,阶段二才敢让 GitOps 无人工介入地把镜像部署上线--门禁的严密程度,决定了你敢把自动化推进到哪一步.这正好呼应第 01 篇:门禁是敢于自动化的前提.