Software Supply Chain Security in 2026: SBOMs, SLSA, and What the Cyber Resilience Act Now Demands

For most of the last decade, "application security" meant scanning the code your own team wrote. That framing is now the smaller half of the problem. The code you ship is overwhelmingly code you did not write - transitive open-source dependencies, base images, build plugins, CI runners - and that is precisely where attackers have moved. If you run delivery for a regulated Benelux team, software supply chain security has stopped being a maturity nicety and become a compliance deadline with a date on it. This is what the terms actually mean, what the EU is about to require, and where the engineering work lands.

CI/CD pipeline diagram showing build, test and security stages where SBOM generation and build provenance are produced between commit and deployment

Why the software supply chain became the attack surface

The threat is not theoretical, and it is not shrinking. Sonatype's tenth annual State of the Software Supply Chain report, published in January 2026, found more than 454,000 new malicious open-source packages during 2025, pushing the cumulative total of known and blocked malware past 1.233 million packages - a 75% year-on-year increase in open-source malware. Over the same period, developers pulled 9.8 trillion open-source downloads across the four largest registries, up 67% (Sonatype, 2026). The two numbers together are the whole story: consumption is exploding, and attackers have industrialised the practice of poisoning the well rather than picking a lock.

The failure mode is distinct from a classic vulnerability. A CVE in a library is an accident you can patch; a malicious package is a deliberate payload that ran inside your build the moment a developer typed install. Typosquatting, dependency confusion, and compromised maintainer accounts all reach production through the same trusted pipe you use every day. That is why the industry stopped talking about "vulnerable dependencies" and started talking about supply chain integrity: the question is no longer only "does this component have a known flaw" but "do I actually know what is in my software, and can I prove how it was built."

What an SBOM is - and what it does not tell you

A Software Bill of Materials (SBOM) answers the first half of that question. It is a formal, machine-readable inventory of every component in a software product - libraries, packages, versions, licenses, and metadata - typically expressed in one of the two dominant formats, SPDX or CycloneDX. When a new critical vulnerability lands in a widely used library, the organisations that can answer "are we affected, and where" within hours are the ones holding current SBOMs. The ones grepping through repositories by hand are still answering that question days later, which in an incident is the same as not answering it.

The trap is treating an SBOM as a compliance artifact rather than an operational one. A "paper SBOM" generated once at release and filed away is nearly worthless, because your dependency graph and the vulnerabilities in it change daily. An SBOM is only useful if it is regenerated on every build and continuously matched against vulnerability and exploitability data. And it has a hard limit: an SBOM tells you what is in the box, not how the box was assembled. It cannot tell you whether the build itself was tampered with - whether the artifact in your registry is actually the artifact your source produced. That gap is what the next control exists to close.

SBOM vs SLSA: proving how the software was built

SLSA - Supply-chain Levels for Software Artifacts, pronounced "salsa" - is a vendor-neutral framework, now stewarded through the OpenSSF, that addresses build integrity rather than component inventory. Where an SBOM is a list, SLSA is a chain of custody. Its core mechanism is provenance: verifiable, tamper-evident metadata that records how an artifact was built, from which source, by which builder, so a consumer can confirm the binary in production genuinely came from the reviewed source and an untampered pipeline (SLSA, OpenSSF).

SLSA is structured as progressive build levels rather than a single bar to clear:

Build L1 - provenance exists: the build process generates a record of how the artifact was produced. Basic, but it makes tampering detectable in principle.
Build L2 - provenance is signed and generated by a hosted build service, so it cannot be trivially forged on a developer laptop.
Build L3 - the build platform is hardened so that provenance is unforgeable and the build runs in an isolated, non-falsifiable environment. This is the level that meaningfully defends against a compromised build system.

The practical reading for a delivery lead: SBOM and SLSA are complementary, not competing. The SBOM tells you and your auditors what shipped; SLSA provenance lets a consumer verify that what shipped was built the way you claim. Mature programmes generate both from the same pipeline, on every release, and treat a missing or unsigned provenance the way they treat a failing test - as a release blocker, not a warning.

What the EU Cyber Resilience Act requires - and by when

For Benelux teams, the reason this is now a roadmap item rather than a research topic is the EU Cyber Resilience Act (CRA). It applies to virtually any "product with digital elements" placed on the EU market - hardware and software - and it turns several of the practices above from good hygiene into legal obligation. The CRA entered into force on 10 December 2024, and its timeline is staged (European Commission):

11 September 2026 - the reporting obligations begin. Manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs, with a 24-hour early warning and a 72-hour follow-up.
11 December 2027 - the main obligations apply in full: secure-by-design requirements, vulnerability handling across the support period, conformity assessment, CE marking, and the duty to provide security updates.

The SBOM is written into that regime. Under the CRA, manufacturers must create and maintain a software bill of materials covering, at minimum, the top-level dependencies of the product, in a commonly used machine-readable format such as SPDX, CycloneDX, or SWID. It does not have to be published, but it must sit in the product's technical documentation and be handed to market surveillance authorities on request (Anchore, EU CRA SBOM overview). If your product touches the EU market, "we could produce an SBOM if asked" is no longer a defensible position; the machinery has to already exist and run continuously, because vulnerability reporting on a 24-hour clock is impossible without it.

How to build this into the pipeline instead of bolting it on

The teams that will absorb the CRA without drama are the ones treating supply chain security as pipeline plumbing, not a pre-audit scramble. Four moves do most of the work. First, generate the SBOM in CI on every build and store it as a first-class artifact alongside the binary, so inventory is a byproduct of shipping rather than a separate project. Second, enforce curation at the front door: automated policy that blocks dependencies which are suspiciously new, unmaintained, or carry incompatible licenses stops a large share of malicious-package attacks before they ever enter a build. Third, emit signed build provenance and verify it at deploy time, climbing toward SLSA Build L3 on the pipelines that matter most. Fourth, wire SBOM data to exploitability context - VEX and reachability - so your team spends its hours on the vulnerabilities that are actually reachable in your product, not on a wall of undifferentiated "high" scores.

None of this is exotic tooling anymore; the frameworks are mature and the formats are standardised. What it requires is the same discipline that separates elite delivery from the rest - encoding the control once, in the platform, so every team inherits it rather than reinventing it. The CRA has simply put a date on when that discipline stops being optional. September 2026 is the first of those dates, and it is closer than a typical platform migration takes to land.