跳到正文
DEV Community· Dennison Bertram·· 3 小時前AI 評分60

CI 與供應鏈安全加固清單:使用終端 Agent 逐項核查

A practical CI and supply-chain hardening checklist you can run with a terminal agent

AI 導讀

文章整理一份可配合終端 Agent 使用的 CI 與供應鏈安全加固清單,參考 Cloudflare 開源 security-audit skill 的 SUPPLY-CHAIN-AND-RELEASE.md 指引。

正文

Cover image for A practical CI and supply-chain hardening checklist you can run with a terminal agent

Dennison Bertram

Your CI is code that runs with your secrets and publishes what your users install. Cloudflare's open-source security-audit skill includes a SUPPLY-CHAIN-AND-RELEASE.md reference whose core rules are useful questions to ask your own pipeline, even without running a full review:

  • A known-vulnerable or mutable dependency is not a finding by itself. Ask who can influence resolution and what the build does next.
  • Follow integrity across every handoff, from source to the artifact a user runs.
  • CI configuration is authorization code: which event triggered it, whose code runs, which secrets exist, what can it publish?
  • A checksum fetched from the same untrusted place as the artifact proves nothing independent.

I work on free-pi, a free terminal agent that bundles the skill's audit method and reference checklists. It runs them in a single agent, without sub-agents or an OS sandbox, so check every claim the agent makes yourself. This guide is illustrative, not a recorded run. Only review pipelines you own or have permission to review.

Ask for a read-only review first

review my CI and release setup for supply-chain risks, using the
supply-chain reference in the security-audit skill. Do not change files yet.

Seven common GitHub Actions checks

These are general good practice, not a list from the skill. You can verify each one yourself.

  1. Unpinned actions: pin uses: to a full commit SHA.
  2. Broad token permissions: set a top-level permissions: with the least needed.
  3. Untrusted input in run: steps: PR titles and branch names can inject shell commands; pass them via env vars and quote.
  4. Risky triggers: pull_request_target and workflow_run can run with secrets while touching fork code.
  5. Secret reach: limit which jobs can read publish tokens; prefer short-lived credentials.
  6. Provenance: know which commit built each published artifact, and let users verify it.
  7. Lockfiles and install scripts: install from committed lockfiles and review packages with install scripts.
permissions:
  contents: read

Fix one thing per PR

Ask the agent for one change at a time and review each diff yourself. CI files guard your secrets, so do not merge what you do not understand, and run the workflow on a branch first.

What it cannot see

Branch protection, registry permissions, hosted-runner settings and signing-service configuration live outside the repo. Check them in your hosting and registry settings.

free-pi has an opt-in Defense model section in /model for when a general model declines lawful work on your own pipeline. More at freepi.ai.

來源:DEV Community · dev.to