Almost no software is written from scratch any more. A typical desktop application, web service, or embedded firmware image is assembled from hundreds or thousands of third-party components: open-source libraries, transitive dependencies you have never heard of, and their dependencies in turn. That is not carelessness; it is how modern engineering achieves the speed clients expect. But it means the security of what you ship depends on code you did not write and cannot see.

The last two years made the risk concrete. The XZ Utils backdoor of 2024 showed how a single patient contributor, trusted over years, could plant malicious code deep in infrastructure that countless systems quietly link against. In September 2025 the self-replicating Shai-Hulud worm on the npm registry compromised popular packages and redistributed itself automatically, and in early 2026 a hijack of the widely used axios package pushed a hidden remote-access trojan into developer machines and build pipelines. The pattern is clear: attacks that were once surgical are now automated and ecosystem-spanning, and the time from compromise to widespread impact has collapsed from years to days.

Provenance: knowing where your code came from

The common thread is provenance — being able to answer, with evidence, "where did this exact component come from, who built it, and has it changed since?" Most organisations cannot answer that today. When a vulnerability is disclosed in a common library, the first, expensive question is simply: are we affected? Without an accurate inventory, answering it means a frantic manual audit while the clock runs.

The SBOM: an ingredients label for software

A Software Bill of Materials (SBOM) is the answer to that question, prepared in advance. It is a machine-readable inventory of every component in a product, with versions and relationships — the software equivalent of an ingredients label. When the next headline vulnerability lands, an SBOM turns a multi-day investigation into a database query.

Two formats dominate, and they are converging in capability:

  • CycloneDX, maintained by OWASP, is security-first. It pairs naturally with vulnerability and exploitability data, and its 1.6 revision was ratified as the ECMA-424 standard, with 1.7 following as a second edition. It is the de facto default in security tooling.
  • SPDX, an ISO/IEC standard (5962), grew out of licence-compliance work and remains strong there. Its 3.0 revision reorganised the model into profiles — including first-class support for AI models and datasets.

For most teams the pragmatic answer is to generate both. Modern tooling produces them as a by-product of the build at little extra cost, so no one downstream can ask for the format you skipped.

Signing: proving the label is genuine

An inventory is only trustworthy if you can prove it — and the artifact it describes — has not been tampered with. This is where signing comes in. Sigstore has become the practical standard here. Its cosign tool signs artifacts and SBOMs; Fulcio issues short-lived certificates tied to an identity (for example, a specific CI workflow) rather than a long-lived key you must guard; and Rekor records every signing event in a public, tamper-evident transparency log.

The shift is subtle but important: instead of "prove you hold this secret key," the claim becomes "prove you are this identity, and here is the public record." Combined with SLSA build-provenance attestations — which vouch for how an artifact was built — this gives a verifiable chain from source to shipped binary. What used to be a multi-week project can now reach a meaningful assurance level in an afternoon using built-in support from common CI platforms.

Why this becomes a legal duty: the EU Cyber Resilience Act

Until recently, supply-chain hygiene was optional discipline. The EU Cyber Resilience Act (CRA) makes much of it a legal obligation for products with digital elements sold in the EU. The Act entered into force in December 2024 and applies in phases:

  • September 2026 — reporting obligations begin. Manufacturers must report actively exploited vulnerabilities and severe incidents on a strict clock: a 24-hour early warning, a 72-hour notification, and a final report within 14 days.
  • December 2027 — the main obligations apply: secure-by-design requirements, conformity assessment and CE marking, vulnerability handling, security updates across a defined support period, and SBOM generation.

The CRA requires an SBOM in a common machine-readable format covering at least the top-level dependencies. It need not be published, but it must sit in the technical documentation and be produced to market-surveillance authorities on request. Non-compliance carries penalties of up to €15 million or 2.5% of global annual turnover, whichever is higher. This reaches beyond EU manufacturers to anyone placing such products on the EU market.

What to do now

None of this needs to be a scramble. The sensible path is incremental: start generating SBOMs automatically in your build pipeline, sign your release artifacts, and keep the outputs as normal project records. Done this way, provenance stops being a compliance burden and becomes what it should be — knowing exactly what you ship, and being able to prove it. If you would like a second pair of eyes on your build pipeline before the 2026 and 2027 deadlines, that is precisely the kind of work I take on.