Software Supply Chain Attacks & the Role of SBOM

Modern software is assembled, not written. A typical application is a thin layer of first-party code sitting atop hundreds of open-source packages, each of which pulls in packages of its own. That dependency tree is enormously productive — and it is also an attack surface. Compromise a single widely used component, and the malicious code inherits the trust of every application that depends on it, propagating downstream to users who never had a chance to inspect it.

Why the supply chain is the target

Attacking an organisation's own code is hard and yields one victim. Attacking a component that thousands of organisations depend on is efficient: one compromise, many victims, all of whom trusted the component implicitly. This asymmetry is why supply chain attacks have moved from novelty to mainstream. The attacker no longer needs to breach your perimeter — they wait for you to pull their code in, willingly, as part of your next build.

Dependency risk: direct and transitive

The dependencies you choose deliberately are only the top layer. Each of those pulls in its own dependencies, and those pull in more — the transitive dependencies that make up the bulk of the tree and that almost nobody reviews. In Figure 1, the compromised package is not one the developers selected; it arrived several levels down, invisible in the manifest they actually read. Its malicious code nonetheless propagates upward into the application and outward to users.

Common dependency attack patterns

Attackers seed the tree in several ways. Typosquatting publishes a malicious package with a name close to a popular one, hoping for a mistyped install. Dependency confusion exploits build tools that prefer a public package over a private one of the same name. Account takeover of a legitimate maintainer lets an attacker publish a poisoned update that flows straight into everyone's next build. And protestware or maintainer burnout can turn a trusted package hostile without any external attacker at all.

Build-system risk

Dependencies are only half the story. The build system — the CI/CD pipeline that compiles, tests, and packages your software — is itself a high-value target. If an attacker can inject a step into the build, they can tamper with the final artifact even when every source file and dependency is clean. Because the output is signed and distributed through trusted channels, that tampering is exceptionally hard for downstream consumers to detect. Securing the build means treating pipeline definitions as sensitive code, isolating build environments, and minimising the credentials any single build step can reach.

SBOM: a bill of materials for software

You cannot protect what you cannot enumerate. A Software Bill of Materials (SBOM) is a complete, machine-readable inventory of every component in a piece of software — direct and transitive — with versions and relationships. When a new vulnerability is disclosed in a common library, an SBOM turns the frantic question "are we affected?" into a database lookup. Standard formats such as SPDX and CycloneDX make SBOMs portable across tools, and guidance from CISA has driven their adoption as a baseline expectation for software producers.

An SBOM does not make software secure. It makes software accountable — and accountability is the precondition for every response that follows.

Provenance and SLSA

An inventory tells you what is inside; provenance tells you where it came from and how it was built. Provenance is verifiable metadata that links an artifact back to its source and its build process, so a consumer can confirm the binary they received was produced from the expected source by the expected pipeline — not swapped or tampered with in transit. The SLSA framework (Supply-chain Levels for Software Artifacts) formalises this as a ladder of increasing assurance, from simply generating provenance up to fully hardened, tamper-resistant builds. Each rung raises the bar an attacker must clear to forge a trusted artifact.

Operationalising supply chain security

Putting this into practice is a pipeline concern, not a one-off audit. Generate an SBOM automatically as part of every build, and store it alongside the artifact. Continuously scan those SBOMs against vulnerability feeds so a newly disclosed flaw surfaces the affected releases immediately. Verify provenance before deploying, and pin dependencies to specific, reviewed versions rather than floating ranges. Together these controls form the gate in Figure 1 — the checkpoint that stands between a compromised component and the users who would otherwise inherit the risk.