Software supply chain security: SBOMs, SLSA, and securing your build

Your Build Pipeline Is an Attack Surface

In December 2020, the SolarWinds attack demonstrated that compromising a build pipeline could give attackers access to 18,000 organizations simultaneously. Since then, software supply chain attacks have increased by over 700%. The attack surface isn’t just your code — it’s every dependency, every build tool, every CI/CD action, and every container base image in your pipeline.

The industry response has been a wave of standards and regulations: SBOMs (Software Bills of Materials), SLSA (Supply-chain Levels for Software Artifacts), and frameworks like NIST SSDF. What was a security best practice in 2023 is becoming a regulatory requirement in 2026 — the EU Cyber Resilience Act, US Executive Order 14028, and sector-specific regulations like FDA software requirements all mandate supply chain transparency.

If your team isn’t generating SBOMs and establishing build provenance today, you’re behind.

What SBOMs Are and Why They Matter

A Software Bill of Materials is a machine-readable inventory of every component in your software: direct dependencies, transitive dependencies, their versions, licenses, and known vulnerabilities.

Think of it as a nutrition label for software. When a critical vulnerability like Log4Shell drops, the first question every security team asks is: “Are we affected?” Without an SBOM, answering that question means manually auditing every service, checking lock files, and hoping nothing was missed. With SBOMs, it’s a database query.

SBOM Formats

Two formats dominate:

SPDX (Software Package Data Exchange) — the ISO/IEC 5962:2021 standard. Developed by the Linux Foundation. Strong on license compliance, widely adopted in open-source ecosystems. SPDX 3.0 (released 2024) added security and build provenance support.

CycloneDX — an OWASP standard. Designed specifically for security use cases. Natively supports vulnerability disclosure (VEX), service definitions, and hardware BOMs. Widely adopted in DevSecOps toolchains.

Both are valid choices. CycloneDX has stronger security-specific features; SPDX has broader ecosystem adoption and ISO backing. Most modern tools can generate either format.

Generating SBOMs

Integrate SBOM generation into your CI/CD pipeline so every build produces a current SBOM:

# GitHub Actions: Generate SBOM with Syft
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: ${{ env.IMAGE_NAME }}:${{ github.sha }}
    format: cyclonedx-json
    output-file: sbom.cdx.json
    upload-artifact: true

For container images, tools like Syft and Trivy generate SBOMs by analyzing image layers. For source code, language-specific tools parse lock files (package-lock.json, Gemfile.lock, go.sum) to produce dependency inventories.

The critical point: generate SBOMs at build time, not retroactively. A post-hoc SBOM is a best-effort guess. A build-time SBOM is ground truth.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

SLSA: Proving Your Software Wasn’t Tampered With

SBOM tells you what’s in your software. SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) proves that what you built is what you intended to build — and that nobody tampered with it along the way.

SLSA defines four levels of build integrity, each adding stronger guarantees:

SLSA Level 1: Provenance exists. The build produces a provenance document that describes how the artifact was built — what source was used, what build system ran, and what the output was. This is the minimum baseline.

SLSA Level 2: Hosted build. The build runs on a hosted service (not a developer’s laptop) that generates provenance automatically. This prevents a compromised developer machine from injecting malicious code at build time.

SLSA Level 3: Hardened builds. The build service is hardened against tampering. Build environments are ephemeral (fresh for each build), isolated (one build can’t affect another), and the provenance is non-falsifiable (the build service signs it, not the developer).

SLSA Level 4: Dependencies verified. All dependencies are also built at SLSA Level 3 or higher. This is the target for high-security environments but requires ecosystem-wide adoption.

Implementing SLSA with GitHub Actions

GitHub Actions supports SLSA Level 3 provenance natively through the attest-build-provenance action:

- name: Build and push image
  id: build
  uses: docker/build-push-action@v5
  with:
    push: true
    tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

- name: Generate SLSA provenance
  uses: actions/attest-build-provenance@v2
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: ${{ steps.build.outputs.digest }}
    push-to-registry: true

This generates a signed provenance attestation that anyone can verify: this image was built from this specific commit, on this GitHub Actions runner, at this time. If the image is later found to contain malicious code, the provenance either proves it came from a compromised source repo (and you know exactly which commit) or proves the build was tampered with (because the provenance won’t match).

Securing the Dependency Supply Chain

Pin Everything

Unpinned dependencies are a supply chain attack waiting to happen:

• Lock files — always commit package-lock.json, Gemfile.lock, go.sum. Never run npm install without a lock file in CI.
• Container base images — pin to digest, not tag. node:20 can change at any time. node@sha256:abc123... is immutable.
• CI/CD actions — pin to commit SHA, not version tag. actions/checkout@v4 can be replaced by a compromised maintainer. actions/checkout@abc123def456 cannot.

Scan Dependencies Continuously

Vulnerability scanning at build time catches known CVEs. But dependencies can become vulnerable after you build. Continuous scanning rechecks your SBOMs against updated vulnerability databases:

• Dependabot / Renovate — automated dependency update PRs with vulnerability context
• Grype / Trivy — scan container images and SBOMs against CVE databases
• OSV-Scanner — Google’s open-source vulnerability scanner, backed by the OSV database

Verify Dependency Provenance

npm, PyPI, and other registries are starting to support package provenance. Sigstore-based signing lets you verify that a package was built from its claimed source repository by its claimed CI/CD system. Enable provenance verification where available:

# npm: verify package provenance
npm install --verify-signatures

Build Pipeline Hardening Checklist

The practical steps to harden your build pipeline against supply chain attacks:

Isolation: Each build runs in a fresh, ephemeral environment. No shared state between builds. No persistent build caches that could be poisoned.

Least privilege: Build pipelines have exactly the permissions they need — read-only access to source, write access to artifact registries, nothing else. Separate CI credentials from CD credentials.

Reproducibility: Given the same inputs (source code, dependencies, build config), the build produces the same output. Reproducible builds make tampering detectable — if someone modifies the output, rebuilding from the same inputs won’t match.

Signing: Every artifact is signed at build time. Container images, binaries, SBOMs, and provenance documents all carry cryptographic signatures that can be verified before deployment.

Admission control: Production Kubernetes clusters verify image signatures and provenance before admitting pods. Tools like Sigstore Cosign and Kyverno enforce “only deploy signed images from trusted builds.”

The Regulatory Landscape

Supply chain security is no longer voluntary for many industries:

Even if your industry doesn’t have explicit SBOM mandates yet, your customers are starting to ask. Enterprise procurement increasingly requires SBOM delivery as part of vendor due diligence.

How IAN Secures Your Supply Chain

IAN’s security scanning includes comprehensive supply chain coverage:

1. Automatic SBOM generation — every scanned repository gets a current SBOM in CycloneDX or SPDX format
2. Dependency vulnerability scanning — continuous scanning against CVE databases with severity and exploitability context
3. CI/CD pipeline analysis — flags unpinned actions, overly permissive pipeline credentials, and missing provenance steps
4. License compliance — identifies dependencies with restrictive licenses (GPL, AGPL) that could affect your distribution rights
5. Base image analysis — scans container base images for vulnerabilities and recommends minimal alternatives
6. Remediation PRs — generates fix PRs for vulnerable dependencies, pinning updates, and pipeline hardening

Every finding maps to relevant regulatory frameworks (NIST SSDF, SOC 2, PCI DSS) for audit evidence.

Start Securing Your Supply Chain

The first step is visibility: know what’s in your software, where it came from, and whether it’s vulnerable. Connect your repositories to IAN and get a complete supply chain risk assessment in minutes.

Get a free infrastructure audit → | See pricing →