Software supply chain security: SBOMs and signed builds

A modern application is mostly other people's code. Your team writes a few thousand lines and installs hundreds of packages, a base image and a set of CI actions around them. Attackers noticed. Instead of attacking one company, they compromise a library or a build tool and reach everyone who uses it.

Log4Shell, the SolarWinds breach and the backdoor found in the xz compression library all followed that pattern. The industry response is now fairly settled, and regulation is moving the same way: the United States asks federal software suppliers for a bill of materials, and the EU's Cyber Resilience Act brings similar duties for products sold in Europe.

Four practices make up that response.

1. Know what you ship

A Software Bill of Materials (SBOM) is the ingredient list of a build: every component, its version and its licence. When the next serious vulnerability is announced, the question "are we affected?" becomes a search, not a week of investigation.

Generate one on every build. The two common formats are CycloneDX and SPDX.

npm sbom --sbom-format cyclonedx > sbom.json

Tools such as Syft and Trivy do the same for container images and other ecosystems.

2. Scan automatically

A scanner compares your components with databases of known vulnerabilities. Run it in three places:

• on every pull request, so a risky package is caught before it merges,
• on every build, as a gate before deployment,
• on a schedule, because new vulnerabilities are found in code you shipped months ago.

Fail the pipeline on critical findings. A report nobody reads protects nothing.

3. Pull from sources you trust

• Commit lockfiles, so every build installs the same versions.
• Use an internal registry or proxy for packages and base images.
• Pin CI actions and base images to an exact version or digest, not to a moving tag.
• Check a new package before adding it: who maintains it, how widely it is used, and whether the name is a near copy of a popular one.

4. Sign what you build

Signing answers a different question: is this artifact really the one our pipeline produced? Tools from the Sigstore project, such as cosign, sign container images and verify them at deploy time. Build provenance goes one step further and records which source commit and which workflow produced the artifact.

If the deploy step refuses anything unsigned, a tampered image cannot reach production quietly.

How it fits together

A typical pipeline:

1. Build the application and the image.
2. Generate the SBOM.
3. Scan the SBOM and the image. Stop on critical vulnerabilities.
4. Sign the image and attach the SBOM.
5. Deploy, verifying the signature first.

Where to start

You do not need all of it at once. Turn on dependency alerts in your repository host, add a scanner to CI, and commit your lockfiles. That covers the most common failures. SBOMs and signing follow naturally once the pipeline is in place.

The day-to-day side of this is plain upkeep. See dependency hygiene for npm projects.