Dependency and secret hygiene: hardening CI itself

Pinning: a tag is a promise, a SHA is a fact

Your application’s lockfile (package-lock.json, pnpm-lock.yaml, poetry.lock) pins the exact byte-content of every dependency by integrity hash, so npm ci installs the same tree on every machine. That discipline is well understood. The blind spot is the other dependencies your pipeline pulls: the GitHub Actions themselves. Writing uses: actions/checkout@v4 looks like a version pin, but v4 is a mutable git tag — a label the maintainer (or anyone who compromises them) can force-move to a different commit at any time, with no change to your repository. You are not pinning code; you are pinning a promise to keep pointing the tag at good code.

A full commit SHA is the opposite: it is the content-address of an exact tree, and git’s object model means you cannot move it without breaking the hash. uses: actions/checkout@<40-char-sha> runs the same bytes forever. This is the single control that would have neutralised the tj-actions blast radius — the malicious code lived behind the tags, so every SHA-pinned consumer kept running the old, safe commit. Pin third-party actions, and the riskiest first-party ones, by full-length SHA, with a trailing comment recording the human-readable version:

# BAD — mutable tag, default (often broad) token, secrets exposed to everything
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4          # @v4 can be force-moved to malicious code
      - uses: tj-actions/changed-files@v35 # the exact action whose tags were repointed
      - run: ./deploy.sh                   # AWS_KEY in env, available to every step above

# GOOD — pinned by full SHA, least-privilege token, OIDC only where needed
on: push
permissions:
  contents: read                           # default everything to read-only
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write                      # grant OIDC ONLY in the job that needs it
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502  # v4.0.2
        with:
          role-to-assume: arn:aws:iam::111122223333:role/ci-deploy       # short-lived, no stored key
          aws-region: eu-central-1
      - run: ./deploy.sh

Automate updates, or pinning rots into stale CVEs

Pinning by SHA buys security at the cost of toil: a frozen digest never picks up the upstream bugfix or the patch for the next CVE. Left manual, “pin everything” decays into “run vulnerable versions forever.” The resolution is to let a bot do the bumping. Dependabot and Renovate both open pull requests that update pinned dependencies — including action SHAs — and, configured well, they update the SHA and the human-readable version comment together. Group related updates so you review one PR instead of forty; schedule them weekly so they do not interrupt feature work; and reserve auto-merge for genuinely low-risk classes only — a patch bump with passing CI and an unchanged maintainer. Renovate has auto-merge built in (automerge: true in a package rule); Dependabot needs a small Actions workflow using dependabot/fetch-metadata to gate gh pr merge --auto on the update type. The principle is the same: machine bumps the digest, CI proves it still builds, a human approves anything non-trivial.

Secret scanning and push protection: stop the leak at the door

Pinning protects you from other people’s compromised code; the next layer protects the pipeline from your own team’s mistakes. The most common leak is mundane: someone hardcodes an API key, commits it, and it lives in git history forever (and in every fork and clone). Secret scanning matches pushed content against a large library of known credential formats — cloud keys, tokens, connection strings — and alerts on anything detected. Push protection is the proactive half: it inspects the content during the push and blocks the commit before it ever reaches the remote when it matches a high-confidence pattern, so the secret never enters history in the first place. The author either removes it or, rarely, records an explicit justification to bypass. Treating a blocked push as the normal outcome — not an obstacle to route around — is the cultural shift that keeps credentials out of the repo.

Least privilege and short-lived creds: shrink the blast radius

Even a perfectly pinned, leak-free pipeline must assume some dependency will eventually turn malicious. Least privilege is what bounds the damage when it does. Two levers matter most. First, the workflow token: GitHub’s GITHUB_TOKEN has defaulted to read-only since February 2023, but many repos still run with broad write scopes. Declare permissions: explicitly at the top of the workflow, default everything to read, and grant write scopes only on the specific job that needs them — so a malicious dependency running in your test job cannot push to main or publish a package, because the token in that job simply lacks the scope. Second, cloud credentials: a long-lived AWS_SECRET_ACCESS_KEY sitting in repo secrets is a permanent prize — leak it once (to a log, to a compromised action) and it works until someone notices and rotates it. OIDC replaces it with a short-lived, audience-scoped token minted per run: the workflow requests an OIDC token (id-token: write), exchanges it with the cloud provider, and receives credentials that expire in minutes and were never stored anywhere. Nothing durable to steal.

These four controls defend at four different points of failure. Together they mean that even when one fails — a dependency slips through scanning, a token scope is wider than ideal — the others still bound the blast radius. Without any one of them, a single breach unravels the chain.