Harden-CI：让AI智能体化身CI/CD安全审计员

流水线掌握着密钥，谁来守护流水线？

现代软件交付依赖CI/CD流水线，而这条流水线本身往往握有发布密钥、令牌以及对外发布的各种权限。正因如此，针对依赖和组件的供应链攻击越来越多地不是从应用层面发起，而是从构建过程下手。构建环节一旦被攻破，攻击者就能把恶意代码直接送进生产环境。

问题在于，流水线常常处于无人监管的状态。它或许有测试，但这些测试未必能拦截新引入的漏洞或代码；Actions 和镜像被绑定到 latest 标签而非确定性的 SHA；镜像没有签名；传递性依赖从未有人审查；主分支也没有防护 force push。单看每一项都微不足道、容易修复，但每一项都是留给攻击者的一扇门。

Harden-CI 工作流程示意

Harden-CI 是什么

Harden-CI 的定位很克制：它不是一个要安装的工具，而只是一份给 AI 智能体（Claude Code、Codex、Antigravity 等）阅读的文件。使用方式极为简单——在仓库目录下打开你的 AI 智能体，把网站链接 https://harden-ci.secmy.app/ 发给它即可，无需安装任何软件、无需订阅、也不需要把仓库权限交给第三方。

整个流程分为四步：

审计（Audit）：智能体执行 16 项检查，全程只读，不改动任何文件、分支或项目设置。
报告（Report）：你会得到一个状态矩阵（✅ ⚠️ ❌ ❓），以及按优先级从严重到低排序的问题清单。每条发现都附有事实依据；对于无法自动验证的项，智能体会诚实地标注问号❓，并建议你如何手动核实（例如到 GitHub/GitLab 网页端查看）。
你来决策（Your choice）：由你决定修哪些、不修哪些，智能体不会在未经你同意的情况下做任何改动。
修复阶段（Fixing）：智能体在独立分支中改动，并为每一项修复开一个 PR 或 MR，你只需审查后合并。

这种设计把控制权完全交回开发者手中，避免了自动化工具最常见的「擅自改动」风险。

16 项检查覆盖哪些环节

Harden-CI 的 16 个步骤覆盖了从代码到生产的完整链条，分为八个维度：

代码与依赖

代码层面包括应用资产清点、威胁建模、单元测试和静态应用安全测试（SAST）。依赖层面则关注漏洞扫描，尤其强调传递性依赖——这正是供应链攻击最隐蔽的入口。一个有意思的实践建议是：引入的新版本应至少发布满七天，以规避刚发布就被植入恶意代码的风险窗口。

传递性依赖（transitive dependencies）是指你的直接依赖所引入的依赖，以及更深层级的依赖。一个现代 Node.js 或 Python 项目的直接依赖可能只有数十个包，但完整的依赖树往往包含数百甚至数千个包，其中绝大多数开发者从未主动选择或审查过。供应链攻击正是利用了这一盲区：攻击者无需攻破你直接使用的知名库，只需入侵某个被广泛依赖的底层小包（如 2022 年的 colors.js 事件、2021 年的 ua-parser-js 劫持），就能影响数以万计的下游项目。文中提到的「新版本应至少发布满七天再引入」，正是针对「发布即投毒」这一新型攻击模式的缓解措施——攻击者往往依赖自动更新机制快速扩散恶意版本，而七天的观察窗口为社区发现异常提供了时间。

密钥与流水线

密钥扫描通过 betterleaks 完成，且报告中不应原样暴露敏感值。流水线安全的核心是将 Actions 和镜像固定（pin）到 SHA，而不是浮动的 latest 或其他标签，从而保证构建的可重现性与可追溯性。

将 Actions 和镜像固定到 SHA（即 SHA pinning）是一种防范供应链攻击的关键实践。当你引用 actions/checkout@v3 这样的标签时，标签本身是可变的——仓库维护者（或攻击者）可以在不更改标签的情况下将其指向全新的、甚至是恶意的提交。而当你改用 actions/checkout@abc1234...（完整的 commit SHA）时，引用就变得不可变：任何对该 Action 内容的改动都会产生不同的 SHA，从而在构建时被立即察觉。2021 年的 Codecov 事件和针对 tj-actions/changed-files 的攻击都证明了浮动标签的危险性——攻击者仅需获取上游仓库的写权限，就能悄无声息地在所有下游流水线中植入恶意代码。Dependabot 和 Renovate 等工具可以自动将 SHA 锁定并定期更新，使这一做法兼顾安全性与可维护性。

容器与基础设施

容器需要用 Trivy 之类的工具扫描漏洞，用 Cosign 校验签名，并附带 SBOM（软件物料清单）文件。基础设施涵盖两个面：一是基础设施即代码（IaC），二是平台本身的安全设置，比如 GitLab/GitHub 的主分支保护与 Git 提交签名。

Harden-CI 快速上手

SBOM（Software Bill of Materials，软件物料清单）是一份列举软件所有组成成分的结构化清单，包括直接依赖、传递性依赖及其版本号和许可证信息。其作用类似于食品的配料表：当新的漏洞（如 Log4Shell）被披露时，拥有 SBOM 的团队可以在数分钟内确认自己是否受影响，而无需手动翻查代码库。Cosign 是 Sigstore 项目提供的容器镜像签名工具，它通过将签名信息写入容器镜像仓库的不可篡改记录，使消费方能够验证镜像确实由可信的构建系统产出、且自签名后未遭篡改。两者配合使用，可以为「这个容器到底由什么构成、是谁构建的」提供可审计的证据链，这正是零信任供应链安全的基础。

API、生产与安全卫生

API 与生产环节检查 Swagger 等 API 规范文件，执行动态应用安全测试（DAST），并排查 Docker 镜像里是否误带了调试功能。最后的「安全卫生」维度则包括许可证合规、账户保护和 SECURITY.md 文件是否齐备。

为什么会有这个项目

作者的出发点很朴素：既然现在人人都有自己的 AI 智能体，构建一条安全的 CI/CD 流水线已经变得前所未有的简单，没有理由再偷懒。Harden-CI 本质上是一份清单，帮作者自己、朋友，也可能帮到你。

作者特别强调了实用主义态度：你不必完全遵守所有规则，某些条目可能并不适用于你的环境，忽略它们完全没问题。「哪怕只多做 2-3 个步骤，也比什么都不做强。」如果你对某些规则有不同看法，项目已在 GitHub 开源，可以克隆、定制自己的清单，或提交修改建议。

一分钟上手

无论是独立开发者还是团队，Harden-CI 都适用。它的最大卖点在于「零信任第三方」——所有改动都发生在你自己的机器上，依据公开透明的规则，并经过你本人的审查。整份内容就是一段文本描述，每个阶段和规则你都能亲自读懂。

上手只需三步：

在仓库中启动 AI 智能体（Claude Code / Antigravity / Codex 等）；
粘贴链接 https://harden-ci.secmy.app/；
阅读结果。

小结

Harden-CI 代表了一种轻量化的安全治理思路：不新增工具、不新增依赖、不引入外部服务，而是把现成的 AI 智能体转化为安全审计员。在供应链攻击日益转向构建过程的背景下，这种「清单即能力」的做法降低了安全加固的门槛。它不追求面面俱到的强制合规，而是鼓励渐进式改进——先把那些「容易修复却长期敞开」的门关上。对于缺乏专职安全团队的中小项目来说，这或许是性价比最高的第一步。