Your SBOM won't save you: Closing the provenance gap in software security
"The industry has spent five years building better autopsies. Now it needs to start building gates."
There is a ritual in enterprise software security that has become so normalized we have stopped questioning it.
A breach occurs. A dependency audit is performed. A Software Bill of Materials is produced. Executives are briefed. A report is filed. The SBOM is updated. The cycle repeats.
Everyone feels busy. Nothing fundamentally changes.
This is not a criticism of SBOMs as a concept. SBOMs are necessary. The problem is what we have turned them into: a compliance artifact. A document that proves we looked, not one that proves we prevented.
And in 2026, that distinction is no longer academic. It is the difference between governance and theatre.
Autopsy vs. prevention
The foundational error in modern software supply chain regulation is temporal.
Every major framework from the US Executive Order 14028, the EU Cyber Resilience Act, DORA's ICT risk management requirements, and NIS2's supply chain obligations has been designed in response to incidents that had already occurred. SolarWinds. Log4Shell. XZ Utils. Each one a postmortem. Each regulation is a forensic tool retroactively dressed as a preventive one.
An SBOM tells you what components were in a system at the point of documentation. It does not tell you what components are running right now. It does not tell you which of those components has been silently tampered with between the last audit and this moment. It does not block anything. It does not enforce anything. It is, structurally, an autopsy report written before the patient has died and updated, occasionally, after.
The analogy that keeps returning: imagine regulating aviation safety by requiring airlines to publish a list of all parts used in their aircraft, updated quarterly. No mandatory pre-flight checks. No real-time sensor telemetry. No automatic ground stop if a critical system fails. Just the list. Published. Attested. Filed.
That is precisely what SBOM-centric compliance looks like from a systems engineering perspective.
The question is not whether the list is accurate. The question is: what happens between the list and the runtime?
The answer, in most production environments today, is: nothing deterministic.
The provenance gap no-one is talking about
Here is the specific technical problem that regulatory frameworks have consistently failed to address.
A dependency can be attested as safe at build time and compromised at runtime. This is not a theoretical edge case. It is the attack vector that produced the most significant supply chain breaches of the last decade. The XZ Utils backdoor was committed to a package repository that passed all static analysis checks. The malicious code was not in the SBOM it was introduced after the SBOM was generated, through a sophisticated social engineering campaign targeting the maintainer.
The SBOM was accurate. The system was compromised. Both statements were simultaneously true.
This gap between the point of attestation and the point of execution is the provenance gap. And current regulation does not close it. It audits around it.
Closing the provenance gap requires moving from documentation to enforcement. From lists to gates. From passive attestation to active, continuous verification that what was approved is what is running at the moment it runs, not at the moment it was packaged.
This is not a new idea in systems engineering. It is, however, a genuinely new idea in regulatory compliance architecture.
From passive lists to active gates: The meaning of Machine Law
The phrase "machine-readable regulation" has been circulating in policy circles for several years. It is typically understood to mean: regulation that can be parsed by software. Structured legal text. APIs for compliance data. Interoperable reporting formats.
This is useful. It is also insufficient.
Machine-readable regulation is still passive. It describes what should be true. It does not enforce what must happen. The enforcement still occurs through human audit cycles quarterly, annually, upon incident. The temporal gap remains.
Machine Law, in the architectural sense, means something different and more demanding: legal rules compiled into deterministic enforcement gates that execute at the point of action, not at the point of audit.
The distinction is operational, not just philosophical.
READ MORE: "Where risk and invisibility collide": Mapping Shadow AI in the enterprise
In a Machine Law architecture, a software component that is not in the approved, attested dependency graph cannot be loaded. Not "should not be." Cannot be. The gate is hardware-enforced, cryptographically sealed, and produces an immutable attestation record at the moment of attempted execution. There is no human approval step between the rule and the enforcement. There is no window between the audit and the control.
This is what Trusted Execution Environments, combined with deterministic policy engines, make possible at production scale today. AWS Nitro Enclaves. Intel SGX. Azure Confidential Computing. The hardware exists. The cryptographic primitives exist including post-quantum primitives like CRYSTALS-Kyber-1024, which ensure those attestation records remain legally defensible beyond the quantum threat horizon.
What has been missing is the governance architecture that connects hardware attestation to legal rule enforcement. That connection is the machine law layer.
The regulatory implication
If enforcement gates replace audit cycles as the primary compliance mechanism, the regulatory model inverts.
Currently, organizations demonstrate compliance by producing evidence that they were compliant at a prior point in time. Auditors review that evidence. Regulators accept or reject it. The latency between violation and detection is measured in months or years.
In a gate-enforced model, non-compliant actions are structurally impossible, not just prohibited. The evidence of compliance is continuous, cryptographically verifiable, and temporally precise. There is nothing to audit after the fact, because the fact cannot occur without a valid compliance gate having been passed.
READ MORE: From beerware to the chicken dance: The world's weirdest open source licenses
This is not a marginal improvement in governance efficiency. It is a category change in what "compliance" means.
For regulators, this raises a genuinely difficult question: if enforcement is automated, deterministic, and hardware-backed, what is the role of the regulatory body? The answer, and this is where machine law becomes genuinely interesting from a legal theory perspective, is that the regulatory body's role shifts from enforcement to rule authorship and gate specification. From auditor to legislator-compiler.
The regulation becomes the code. The code becomes the gate. The gate becomes the audit trail.
Why SBOMs still matter
None of this means SBOMs are worthless. They are the input layer of a properly designed supply chain enforcement architecture. You cannot build a dependency allowlist without knowing what your dependencies are. You cannot specify a gate policy without a provenance model. The SBOM is the precondition, not the solution.
The failure is treating the precondition as the destination.
The industry has spent five years building better autopsies. The next five years need to be spent building gates.
The components exist. The regulatory pressure is building CRA, DORA, NIS2, US EO 14028 all point in this direction, even if none of them articulate the architectural conclusion clearly.
READ MORE: "It's undermining system reliability": Why AI workslop is the new technical debt
The question is whether the industry moves to gate-based enforcement before the next SolarWinds or after it.
History suggests: after.
The architecture exists to change that trajectory. The decision to use it is not a technical one. It is a governance one.
© 2026 Andrew McCandless & Rami Cherri. The authors retain full copyright and intellectual property rights to this text and its underlying concepts. Licensed to Machine Media Ltd for publication.
