Supply Chain Defense

Supply chain defense

The build pipeline is a privileged machine that turns source into artifacts your users trust, and it runs third-party code on every push. If an attacker edits a build step, swaps a base image, or repoints a tag, the malicious output ships signed and looks legitimate. Hardening means pinning what runs, proving where each artifact came from, and signing it so tampering is detectable.

Method

1. Pin CI actions to a commit SHA, not a tag. Write uses: actions/checkout@<40-char-sha> instead of @v4. A tag is mutable and can be repointed at malicious code; a commit cannot. Let Dependabot bump the SHAs so pinning does not go stale.
2. Lock base images by digest. Reference container bases as image@sha256:... in Dockerfiles and CI, never :latest. Rebuilds then use the bytes you reviewed instead of whatever the tag points at today.
3. Grant the pipeline least privilege. Set permissions: contents: read at the top of a GitHub Actions workflow and widen per job only where a step truly needs write or id-token. A compromised step then cannot push to the repo or mint a release.
4. Generate provenance for every artifact. Produce a SLSA provenance attestation with slsa-github-generator or cosign attest, recording the source commit, builder, and inputs. Consumers can then verify the artifact came from the commit you claim, not from someone's laptop.
5. Sign artifacts and verify on deploy. Sign images and packages with Sigstore cosign (cosign sign), keyless through OIDC where possible, and gate deployment on cosign verify. An unsigned or wrongly signed artifact never reaches production.
6. Keep secrets away from untrusted triggers. Do not expose deployment or signing secrets to pull_request workflows from forks. A fork PR must not be able to read the key that signs your releases.

Checks

• Does every uses: and base image reference resolve to a SHA or digest, with zero floating tags?
• Can you verify a production artifact's provenance back to a specific source commit?
• Does the deploy step reject an artifact whose cosign signature fails?
• Do fork pull requests run without access to release or deploy credentials?

Boundaries

This hardens how artifacts are built and released, not the third-party source that goes in (see dependency-auditing) or the runtime that executes the output. Provenance proves origin, not that the source was safe. Follow your platform's mandated attestation format where one exists.