DEV Community

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

Posted on Originally published at freepi.ai

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

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)