Software supply-chain security acquired a standards stack and a regulatory regime in a short space of time, and both changed materially in the last two years. This chapter is the current state, with the specific corrections that make older material wrong.

• The current specification has two tracks, not one. A build track and a source track. Material describing only build levels is a version behind.
• There is no build level four. The original draft had a four-level model; every version since consolidated to three. Any chapter, slide or job posting citing ‘level 4’ is quoting a specification that was superseded years ago.
• Build level 1 is provenance that exists and is generated automatically. Level 2 adds that the hosted platform generates and signs it. Level 3 requires hardened builds — strong isolation between runs, and signing key material inaccessible to user-defined build steps.

Three things get treated as alternatives and are actually complementary layers:

• The attestation format is the envelope and the layout language — a signed statement that something is true about an artifact. It reached the highest maturity tier of its foundation in early 2025.
• The provenance framework is a set of requirements expressed in that envelope.
• The signing infrastructure is how the envelope gets signed — keyless, binding a signature to an identity from your CI platform, with the record written to a public transparency log. Its client tooling is now on a major version that defaults to a standardised bundle format and can verify attestations from several ecosystems with one tool, and the transparency log was rebuilt and reached general availability in late 2025.
• Adoption is now broad: package ecosystems for several major languages, a package manager, and model registries all sign this way.

Two operational caveats that surprise people at rollout. Keyless signing means you must be able to verify against the transparency log at consumption time — an availability dependency on a community-operated service. And your build identities become public, because the log is public. Neither is a reason not to do it; both are reasons to find out before rather than during.

Two formats dominate and they have different origins, which shows in what they carry.

• One was built for security first and carries a document-level vulnerability array, so a bill of materials can hold vulnerability and exploitability data inline. Its current version was adopted as a formal standard in late 2025 and is described as the last in its major line.
• The other was built for licence compliance first and added a security profile in its version 3 line. It has broader government and standards adoption.
• And the trap: when a requirement cites the ISO standard for the second format, it is naming version 2.2.1 — not version 3. Teams that upgraded to version 3 ‘for compliance’ may have moved out of the standard they were citing. Check what the requirement actually names.

This is the section most training material has not caught up with, and it reverses the 2021–2023 picture entirely.

• In Europe, obligations become binding in September 2026: manufacturers must notify authorities of actively exploited vulnerabilities and severe incidents in products with digital elements, through a central reporting platform. The full regime, including bill-of-materials obligations, conformity assessment and marking, applies from December 2027.
• In the United States the direction reversed. An early-2026 budget-office memorandum rescinded the previous form-based attestation mandates, characterising them as unproven and burdensome. Updated minimum-elements guidance for bills of materials was published by the security agencies — as guidance, not regulation.
• Net position: Europe is the binding regulator of software supply-chain security and the United States is not. American federal expectations now flow through contract terms and agency-specific requirements rather than a government-wide mandate.
• So a team building for compliance should build to the European regime. That sentence would have been wrong two years ago and it is the correct answer now.

The scale is worth stating because it makes the regulation legible rather than bureaucratic. Industry monitoring reported over 450,000 new malicious packages discovered in a single year, with the overwhelming majority in one ecosystem, and cumulative known-and-blocked totals well over a million.

Two named campaigns illustrate the shape of the problem: one compromised hundreds of packages within days by using each compromise to reach the next, and another generated over a hundred thousand malicious packages in a couple of days through automation. This is not a threat you can review your way out of — the volume defeats human inspection, which is exactly why the controls are structural: pinning, integrity hashes, namespace reservation, provenance verification and a proxy that blocks known-bad components before they enter the build.

The figures come from a vendor that sells products addressing this, so treat the framing accordingly — but the counts derive from registry monitoring and are the best public numbers available.