free-pi
Harden your CI and software supply chain with a terminal agent

Cyber defense

Harden your CI and software supply chain with a terminal agent

Your build pipeline is code that runs with your secrets and publishes what your users install. That makes it worth reviewing as carefully as your application. This guide shows how to point a terminal agent in free-pi at

Published

Your build pipeline is code that runs with your secrets and publishes what your users install. That makes it worth reviewing as carefully as your application. This guide shows how to point a terminal agent in free-pi at your own CI and release setup, using the supply-chain reference from Cloudflare's security-audit skill as a starting point. We build free-pi, so read this with that in mind. Use it only on repositories and pipelines you own or have permission to review.

An illustration of boxes on a conveyor belt passing through four gates, each marked with a shield.

The rules behind the skill's reference

The skill's SUPPLY-CHAIN-AND-RELEASE.md file (https://github.com/cloudflare/security-audit-skill) covers dependencies, CI, release artifacts, signing, updates and plugins. Its core rules are useful even if you never run a full review:

  • A mutable or known-vulnerable dependency is not a finding by itself. Ask who can influence resolution, which build consumes it, and what happens next.
  • Follow integrity across every handoff: source, resolved inputs, build worker, artifact, test result, signature, promotion and the user's update.
  • CI configuration is authorization code. Ask which event triggered a workflow, whose code runs, which secrets exist, and what it may publish.
  • A checksum fetched from the same untrusted place as the artifact proves nothing independent.

Those are good questions to ask your own pipeline. free-pi runs the skill's method in a single agent, without sub-agents or an OS sandbox, so check every claim the agent makes yourself.

Step 1: run a focused review

Start free-pi in your repository and ask for a narrow review rather than a full audit:

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.

Asking for "no changes yet" gives you a list to read before anything is edited.

Step 2: common GitHub Actions checks

Whatever the agent reports, these are common weak points in a GitHub Actions setup, and you can verify each yourself. They are general good practice, not a list from the skill:

  1. Unpinned actions. uses: some/action@v3 follows a tag that its owner can move. Pin to a full commit SHA, and let a dependency-update tool propose bumps.
  2. Broad token permissions. Set permissions: at the top of each workflow to the least it needs, for example contents: read, and grant more per job.
  3. Untrusted input in shell steps. Text from pull-request titles, branch names or issue bodies placed inside run: scripts can inject commands. Pass it through an environment variable and quote it.
  4. Risky triggers. Workflows on pull_request_target or workflow_run can run with secrets while handling code from a fork. Know exactly what they check out and execute.
  5. Secrets reach too far. Check which jobs can read publish tokens, and prefer short-lived credentials where your registry supports them.
  6. Release provenance. Make sure you can say which commit built a published artifact, and that a user can verify it from a trusted root.
  7. Lockfiles and install scripts. Commit lockfiles, install from them in CI, and review packages that run install scripts.

A minimal permission block looks like this:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha>

Step 3: fix one thing at a time

Ask the agent for one change per pull request, each with a short explanation: pin the actions, then tighten permissions, then fix the shell injections. Small changes are easier to review, and a broken pipeline is easier to trace to its cause.

Review each diff yourself. CI files guard your secrets, so do not merge a change you do not understand. Run the workflow on a branch before you merge.

What the agent cannot see

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

When a model declines

If a general model refuses part of a lawful review of your own pipeline, look in the Defense section of the /model picker. See our post on using the Defense section responsibly for the ground rules.