The SBOM Just Became a Liability With a Date on It

The SBOM Just Became a Liability With a Date on It

When a best practice becomes a product requirement, it stops being a security artifact and starts being a financial one. The question now is whether the document you are obligated to produce is true.

The EU Cyber Resilience Act is moving the software bill of materials from a best practice to a product security requirement, with the law’s full application arriving in December 2027.

If your company ships software into the EU, the character of one of your obligations just changed. The software bill of materials you used to produce because it was responsible is becoming one you are legally required to produce because a regulator says so.

That is not a procedural change. It moves the bill of materials off the security team’s task list and onto the company’s books, and most organizations have not adjusted to what that means.

A best practice and a requirement are not the same liability

Every CFO understands that an unmanaged liability is a governance failure. Open source software is the largest unmanaged liability in most enterprise technology environments, and in most organizations it has never appeared on any ledger the board reviews.

For years, the SBOM was the closest thing we had to putting that liability on the books. It was a best practice, which meant skipping it was a gap. A gap is something you can choose to close on your own timeline.

That is over. ENISA’s 2026 data shows SBOM adoption is climbing through tooling and automation, but supplier transparency, completeness, data quality, and internal expertise remain real gaps.

Read those two facts together. The requirement is arriving on a fixed date, and most organizations cannot yet produce a complete and accurate version of the document the requirement demands.

The consequence no one has priced in

An incomplete SBOM, before it is a legal requirement, is just an operational gap. You know your visibility is partial, you are working on it, and no one is keeping score.

An incomplete SBOM, after it is a legal requirement, is something else entirely. It is a dated, documented record of exactly what you did not know about your own software, produced under obligation, and signed.

That is not partial credit. In financial terms, it is the difference between an unbooked exposure and a disclosed misstatement. The first is a risk you are managing. The second is a finding.

The supplier lesson hiding in the AI headlines

The AI headlines carry a second lesson worth pricing. Anthropic suspended access to two of its models, and companies that had built production systems on them learned that access to a dependency you do not control can be cut off suddenly.

A CFO has a name for depending on a supplier you cannot substitute or control. It is concentration risk, and we price it deliberately in every other part of the business.

We have not been pricing it in the software supply chain. Every ungoverned open source component running in production is the same bet: that a dependency you did not vet, from a source you do not control, will keep behaving the way you assumed it would. The model shutdown is a clean illustration of what happens when that assumption breaks, and open source carries the same exposure at far greater scale.

The accountability is personal now

The reason this belongs at the executive table and not below it is that the regulatory environment has made it an executive matter.

EU CRA vulnerability reporting obligations begin arriving in 2026 and apply in full from December 2027, across products already on the market. SSDF is already a federal contracting condition. EO 14028 SBOM expectations that many treated as aspirational.

The accountability for a software supply chain failure now sits with named people, with personal exposure, not with a diffuse function somewhere below the waterline. That is the structural change. The documentation of a defensible decision, made before something went wrong, is the new minimum standard.

“We have an SBOM” is becoming the new “we have a scanner,” which has always been load-bearing corporate for “we have a document that suggests we know what is in our software.” The regulator is about to test whether the document is true.

From an unbooked exposure to a disclosed, dated obligation.

What a defensible posture looks like

The organizations that will not be scrambling in 2027 are the ones treating the SBOM as a byproduct of governance rather than a manual audit they assemble after the fact.

That is the approach we take at ActiveState. Components are built from source, scored for real-world risk across the full dependency tree, and shipped with a signed SLSA Level 3 attestation and a complete SBOM, so the document the regulator wants is generated by the way the software is sourced, not reconstructed under deadline.

The point is not the tooling. The point is that the bill of materials is accurate because the governance is real, and remediation runs on a contractual SLA rather than a backlog.

The requirement is no longer whether you can describe your software supply chain. It is whether the description you are now legally obligated to produce is true.

A best practice you skip is a gap you can close. A regulated requirement you cannot meet is a finding with your name on it.