The Pipeline Is the New Perimeter

The Pipeline Is the New Perimeter

The software supply chain has become the front line of security. The xz-utils backdoor, the SolarWinds compromise, and the steady stream of typosquatted packages have forced a simple conclusion: the code you depend on is code you do not control. By 2026, most teams have accepted this. What they have not accepted is doing anything about it in the pipeline. An SBOM generated once a week and parked in an S3 bucket is not security; it is archaeology. The shift that matters is enforcing supply chain integrity as a build gate — failing the pipeline when the bill of materials is missing, the provenance is unsigned, or the dependency tree carries a known critical vulnerability.

This post walks through a pragmatic, production-ready setup: generating a CycloneDX SBOM on every build, signing SLSA provenance attestations, and wiring both into CI gates that fail closed.

From SBOM Artifacts to Policy Gates

An SBOM is a machine-readable inventory — CycloneDX and SPDX are the two dominant formats — listing every component, its version, and its license metadata. Treating the SBOM as an artifact to archive misses the point. The SBOM only becomes useful when a policy engine reads it and makes a decision: does this dependency tree meet the organization's risk threshold? That decision is the gate.

Gates come in three practical tiers:

• Presence gates — the build fails if an SBOM and provenance attestation were not generated and signed.
• Vulnerability gates — the build fails when known critical vulnerabilities exceed a policy threshold.
• Integrity gates — the deploy fails if the attestation cannot be verified against a trusted root.

SLSA gives this a vocabulary. Levels 1 and 2 are about provenance existence and hosted builds; Level 3 adds signed provenance from a verified build — the point where an attacker can no longer quietly rewrite your build history. Level 4 is reserved for fully hermetic builds.

Wiring the SBOM Gate

The tooling is mature enough that the gate is mostly glue. Syft generates CycloneDX output in seconds; Trivy and Grype scan the tree against vulnerability feeds; Cosign signs the attestations; the SLSA framework produces build provenance on GitHub Actions and GitLab CI.

# CI step: generate the SBOM
syft -q $(pwd) -o cyclonedx-json --file build/bom.cyclonedx.json

# CI step: fail on critical vulnerabilities
trivy fs --format sarif --severity CRITICAL \
  --fail-on-severity CRITICAL . || exit 1

Two details matter. First, gate on the diff, not the whole tree — failing because a four-year-old transitive dependency has a known CVE punishes the team for legacy debt and teaches them to ignore the gate. Second, prefer reachability-aware scanning: Grype and Trivy now model whether a vulnerable function is actually callable, which cuts false positives dramatically and keeps the gate honest.

Provenance: Proving Where the Build Happened

An SBOM tells you what you shipped. Provenance tells you how it was built. The SLSA framework emits a provenance attestation containing the build environment, the source repository and commit, and the command graph — then signs it with Cosign so anyone downstream can verify it.

# GitHub Actions: generate + sign provenance
- uses: slsa-framework/slsa-github-generator@v2
  id: slsa
  with:
    files: dist/*.tar.gz

# Verify the attestation before deploy
cosign verify-blob-attestation --type slsa \
  --certificate-identity "repo/build.yml" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate "attestation/cert.pem" dist/

The verification step is where most teams stop. That is a mistake. The value of provenance is realized only when the deploy pipeline refuses to accept an unsigned artifact — either at the container registry (Sigstore's policy-controller in a cluster admission webhook) or in the release workflow itself.

Enforcement Points That Actually Hold

Each enforcement point should fail closed — no warning mode, no "notify only" grace period longer than a sprint. A gate that can be ignored is a gate that will be ignored.

Failure Modes to Design Around

• Scanning everything, every time. Cache the base image layer and scan only the diff; full-tree scans on legacy repos produce alert fatigue within a week.
• Unsigned SBOMs. An SBOM you cannot attribute is metadata, not evidence. Sign it in the same step that generates it.
• Dev-dependency blind spots. Build tooling and test fixtures are part of the supply chain; exclude them only when the artifact itself excludes them.
• Ignoring transitive dependencies. The vulnerability that matters is almost always two levels deep. Keep depth analysis on.

Supply chain security is not a compliance checkbox. It is a property of the pipeline: if the artifact cannot prove its origin, it should not reach production.

A Minimal Production Gate

Adopting this does not require a security team. In three steps:

1. Add SBOM generation and a vulnerability gate to the main branch build — two commands in the workflow file.
2. Sign the SBOM and provenance with Cosign and the SLSA generator, and store the certificate alongside the artifact.
3. Verify the attestation in the release or deploy pipeline, and add policy-controller to the cluster as a second line of defense.

Start on the main branch, where every artifact is a candidate for production. Extend to pull requests once the noise is under control — the diff-scoped scan makes PR gates surprisingly cheap. From there, the same policy follows you into registries, clusters, and any artifact that claims to be yours.

The pipeline is the new perimeter, and the gate is the wall. Build it early, keep it honest, and make the artifact prove itself every single time.