第38章｜GitHub Actions 供应链安全：CodeQL、依赖审计与签名

1. 威胁模型：从源码到制品，攻击面在哪里？

典型链路：源码 → CI 构建 → artifact / image → 部署。风险包括：第三方依赖漏洞、恶意包、构建步骤被篡改、制品被替换、无审计无签名。流水线里要同时解决检出风险与发布可信。

图 1：供应链分阶段验证。左侧偏“别写坏、别引雷”，右侧偏“构建出来的是什么、能否被替换”。

2. CodeQL：把漏洞查询做成可重复的安全测试

CodeQL 将代码编译为数据库并用查询语言发现漏洞模式；结果以 SARIF 回传到 PR / Security 页。在 Actions 中使用 github/codeql-action，按语言配置 init、autobuild（或自定义 build）、analyze。

# Minimal pattern (language-specific matrices vary)
- name: Initialize CodeQL
  uses: github/codeql-action/init@v3
  with:
    languages: javascript

- name: Autobuild
  uses: github/codeql-action/autobuild@v3

- name: Analyze
  uses: github/codeql-action/analyze@v3

把严重级别与 分支保护 / required checks 对齐：例如阻断可远程利用的高危问题再合并。

3. SCA：依赖审查、许可证与漏洞策略

Dependabot 开 PR 升级依赖；dependency review 在 PR 上对比 base 与 head 的依赖差异，标记新增漏洞。组织可定义：哪些许可证允许、哪些 CVE 级别阻断合并。

图 2：依赖审查关注「PR 引入了哪些新包/版本」以及已知漏洞；适合作为合并门禁的一环。

4. SBOM 与 provenance：说清楚“装了什么、谁构建的”

SBOM（SPDX、CycloneDX）列出组件与版本，是漏洞响应与许可证合规的底座。 Provenance（如 SLSA、in-toto、GitHub attestations）记录构建来源：仓库、commit、workflow、不可伪造的声明。发布流水线里生成 SBOM、附加 attestations，再在部署侧校验。

图 3：制品发布时同时产出 SBOM 与签名；部署侧验证 digest 与签名后再放行。

5. 策略落地：门禁、例外与度量

把规则写进平台：required checks（CodeQL、dependency review）、Code scanning 分支策略、以及发布侧的签名验证脚本。对遗留例外要走审批与限时还债；用指标跟踪 MTTR、漏洞存量、依赖年龄。

图 4：左段偏合并前（代码与依赖），右段偏发布与运行（签名与校验）。中间用分支保护与发布门禁衔接。

6. 最小清单

对主语言启用 CodeQL；严重问题进合并策略。
开启依赖审查 / Dependabot；定义许可证与 CVE 阈值。
发布流水线生成 SBOM；关键制品做签名与 provenance（按组织成熟度渐进）。
例外走审批与期限；用指标驱动欠债清理。

web