Published: Last updated:

Software Supply Chain Security

Trust no component without proof of provenance

Software supply chain security secures not the application's own code, but everything that flows into it: bought-in libraries, open-source dependencies and the build pipeline that assembles them. It is an architecture and an operating model, not a single measure.

Modern software consists for the most part of foreign code. An application pulls dozens of direct and hundreds of transitive dependencies, few of which have ever been read. Each of these components is a point of entry, and every step between source code and delivery is a possible point of tampering. An SBOM answers the first question, what is even contained, and is therefore the indispensable inventory. This page orders the layer above it: how the supply chain as a whole can be secured, from the provenance of a component through the integrity of the pipeline to ongoing operations.

Anti-Patterns: Trust without proof

  • Blind trust in dependencies: Packages are pulled from public registries without checking provenance, integrity or maintenance state. Whatever the package manager delivers is taken as good.
  • Unpinned versions: Dependencies are referenced loosely, so a build pulls different building blocks today than yesterday. What is built is neither reproducible nor traceable.
  • Unprotected pipeline: The build environment holds far-reaching rights, downloads tools from the network and is itself barely secured. Whoever compromises it compromises every artefact that leaves it.
  • One-time check: A component is checked once when it is added and never again. Vulnerabilities that become known later stay undetected.

The threat class: attacking the chain instead of the target

An attack on the supply chain does not aim at the target system itself but at a building block that this system trusts. The leverage is reach: whoever compromises a widely used library or build tool reaches everyone who uses it.

Two patterns shape the threat class. In the first, a dependency itself is compromised: a harmless library gains malicious code in a new version, whether through a taken-over maintainer account or a slipped-in package with a similar name. The Log4Shell event showed the force of this class, when a single, ubiquitous library made countless systems vulnerable at once. In the second, the build pipeline is manipulated: not the source code but the path from source to delivered artefact is subverted, so that the end product contains malicious code that no one ever wrote into the repository. The SolarWinds incident followed this pattern and made the pipeline itself the target.

Provenance and signature as proof of integrity

The answer to both patterns is verifiability: every artefact should be able to attest where it comes from and that it is unchanged since its creation. Three building blocks carry this proof.

  1. Signature. An artefact is cryptographically signed so that any later alteration can be detected. Sigstore with the tool cosign has simplified signing by binding short-lived certificates to existing identities, avoiding the burden of classic key management.
  2. Provenance. Through a build attestation, the pipeline verifiably documents from which source, with which tools and in which environment an artefact came to be. This lets a delivered artefact be traced gaplessly back to a specific commit.
  3. Maturity model. The SLSA framework (Supply-chain Levels for Software Artifacts) arranges these measures into levels that build on one another. It turns individual measures into a path along which the protection level reached in an organisation's supply chain can be read off and raised step by step.

Signature and provenance invert the trust model: an artefact counts as trustworthy not because it comes from the usual source, but because it attests its own origin and integrity.

Discipline over dependencies as ongoing hygiene

Before the proof comes the selection. Every dependency taken on widens the attack surface, which is why caring for them is a discipline of its own.

  • Pinning. Dependencies are fixed to exact versions and secured through a lock file with cryptographic checksums. That way every build pulls the same building blocks, and a slipped-in version stands out.
  • Assessing. Before being taken on, a component is judged by its maintenance state, reach and the responsiveness of its maintainers. An unmaintained dependency is a future risk, independent of its present condition.
  • Reducing. The safest dependency is the one not taken on. A small, deliberately chosen set of building blocks is easier to oversee than a sprawling dependency tree.

The operating model: monitor, respond, re-verify

Supply chain security is not a one-time project but a permanent state, because most vulnerabilities become known only after delivery. A component that counts as safe today can be vulnerable tomorrow without anything about it having changed.

The operating model therefore closes a loop. The inventory list from the SBOM is continuously checked against new vulnerability advisories, so that a freshly disclosed flaw can be assigned immediately to the affected systems. A hit is followed by a practised response: assess whether the vulnerability is reachable in the actual use context, update or replace the dependency, and verify the result anew. This loop anchors itself most naturally in the CI/CD pipeline, where SBOM generation, signature, provenance and vulnerability scanning become fixed steps of every build. That way supply chain security does not become a special operation but built-in behaviour.

Practical Example: A new critical vulnerability

A critical flaw becomes known in a widely used library. Without an operating model, a frantic search now begins: which applications use this library, in which version, and where at all. With an established loop it runs the other way. The continuous check matches the advisory against the stored SBOMs and names the affected artefacts in minutes. The provenance traces each of them back to its commit and pipeline, the dependency is updated, the new artefact signed and checked again. An emergency becomes a rehearsed procedure.

FAQ

Is an SBOM not enough?

The SBOM is necessary but not sufficient. It says what is contained and is the basis of every vulnerability check. But it does not say whether an artefact was tampered with along the way or comes from the expected source. Only signature and provenance do that. The SBOM is the inventory, supply chain security is the architecture around it.

Is this only relevant for security-critical software?

No. The supply chain is the same for every piece of software, because every one draws on the same public registries and building blocks. A compromised, widely used dependency hits the simple application just as much as the critical system. Regulatory requirements such as proof of a component list moreover make the evidence an increasing compliance obligation.

Does this slow delivery down?

The additional steps, that is signature, attestation and scan, run automated in the pipeline and cost seconds to minutes per build. Against this stands the incomparably greater effort of an unstructured response to an incident. The discipline shifts effort from the emergency into normal operations, where it is predictable.

References

Related topics

  • SBOM, the machine-readable inventory list on which this operating model builds.
  • CI/CD, the pipeline in which signature, provenance and scan become fixed steps.
  • Compliance, the regulatory requirements that demand proof of the supply chain.
  • Public Code, the open-source building blocks whose provenance and care this discipline secures.

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.