A Clean SBOM Won't Stop a Dirty Transaction

Be clear about what the supply-chain security movement got right, because it got a great deal right. The attacks are real: compromised build systems, poisoned open-source dependencies, tampered artifacts riding trusted update channels into thousands of environments at once. The response has been genuinely good engineering. Finding the vulnerable dependency in the pull request instead of in production is cheaper, faster, and real. Context-aware scanning across source, dependencies, containers, and infrastructure-as-code genuinely cuts the noise that drowns security teams. Signed artifacts, attested provenance, and SBOMs genuinely harden the path from commit to deploy against classes of attack that used to be invisible. Policy-as-code gates in the pipeline genuinely stop bad builds from shipping.

None of what follows argues you should do less of this. The argument is about what this work can see — and about the one question it was never built to answer.

Strip away the tooling and the entire supply-chain stack answers a single question with increasing rigor: is this software what it claims to be, built from what we approved? That is a question about the identity and integrity of the artifact. The signature proves who produced it. The provenance attestation proves how, and from what, it was built. The SBOM proves what is inside it. The curated registry proves its ingredients passed inspection at the door. Each control strengthens the same chain of custody, and the chain is genuinely strong.

Follow that chain to its last link, though, and notice where it ends. The artifact-centric platforms — the ones that treat the release itself as the authoritative record, gate it immutably, and curate everything that feeds it — govern the delivery of software. The pipeline-policy platforms govern the same span from the other end: security policy expressed as code, enforced at the merge, the build, the deploy. Within that span the governance is real, and it deserves the credit it gets. But the span has a boundary, and the boundary is structural, not a roadmap gap: the moment the artifact is deployed, the writ ends. The running application's business actions — the payment it releases, the record it changes, the data it exports — answer to the application's own code paths and whatever standing entitlements it holds. Not to the pipeline that shipped it.

Provenance answers a who-question: who made this actor, through whose hands did it pass, was it altered on the way. That makes it an identity document — a passport with an unusually good tamper seal. And a passport, however rigorous, is not a permission slip. Border control that verifies every passport flawlessly still says nothing about what the visitor does once inside the country. The supply-chain stack has built world-class border control for software. What happens inside is outside its jurisdiction — by design, and often by explicit delegation to someone else's runtime tooling.

Consider an illustrative case — hypothetical by construction, because the point is architectural. A payments service is built through an exemplary pipeline: every dependency inventoried, no known-critical vulnerabilities, image signed, provenance attested and verified at deploy. It then releases a payment to a vendor bank account that changed yesterday, above the limit of the person who nominally approved it — because a code path permitted it, a service entitlement was broader than anyone remembered, and no policy stood between the intent and the act. Now run the incident review. What failed? Nothing in the supply chain. Every control functioned exactly as designed, because every control was pointed at a different question. The software was precisely what it claimed to be. The act was still unauthorized.

This is the shape of the incidents that actually reach regulators: not forged binaries, but legitimate software — steered sometimes by fraud, sometimes by misconfiguration, sometimes by an over-permissioned integration or an AI-generated instruction — executing business actions no policy ever sanctioned. Provenance tells you who made the actor. It cannot tell you whether the act was allowed.

The strongest objection comes from the most runtime-oriented corner of the category, and it deserves a straight answer. Admission control that refuses a workload failing policy is enforcement, not posture. Immutability enforcement that pins a running workload to the exact image you built — and blocks anything that deviates — is enforcement at execution time, full stop. If your estate has neither, that is a genuine gap these platforms genuinely close.

But be precise about the object of that enforcement. Admission control governs which software is allowed to run. Immutability enforcement governs that it stays unmodified while running. Both are statements about workload integrity — the actor's identity, extended into runtime. Neither is a statement about the actor's actions. A perfectly attested, drift-free, CVE-free workload remains fully capable of releasing the wrong payment, updating the wrong record, exporting the wrong dataset — through its own legitimate, unmodified code. Integrity of the actor is not governance of the action. Runtime enforcement of this kind extends the passport check to the moment of execution. It still never reads the transaction.

This is where Entroid's architecture aims at a different object — not a better pipeline, but governance of the act itself. ES is a Composable Process Fabric: business processes are composed from five primitives — Deterministic Workflows, Intelligence Orchestration, Atomic Agents, Functions, and Connectors — over a shared Semantic Ontology, on one runtime, with an immutable per-action audit trail. The security consequence is architectural, not aspirational: a process built this way is governed by construction, because the control lives on the executing action.

• Authorization is inline, not upstream. A Deterministic Workflow gate sits in the execution path of the action itself. A payment release is permission-checked and policy-evaluated at the moment it runs — and an unauthorized action is refused right there, regardless of how clean the binary that requested it was.
• Connectors are the only door out. By design, Connectors are the sole primitive that touches external systems. Every action that reaches a bank, an ERP, or a data store passes through a governed, permissioned interface — a choke point that exists in the architecture, not just in a diagram.
• Every action writes its own evidence. The audit record is emitted per action, immutably, as a property of the runtime: who or what acted, under which policy, with what approval.
• Humans are first-class, not bolted on. Atomic Agents make human-in-the-loop a native construct, so a high-stakes action can pause for a person before it commits — inside the same governed path, on the same audit trail.

None of this replaces the supply-chain stack, and ES does not pretend it does. ES's own DevSecOps module delivers scanned, signed, gated software to Kubernetes with AI guardrails — artifact discipline still matters — and ES runs over your existing estate through governed Connectors rather than assuming a green field. The claim is complementarity: the SBOM proves what the software is; the per-action audit proves what it was allowed to do, action by action.

Here is the question worth carrying into your next architecture review. For each materially risky business action your software can take — release a payment, change a customer record, export a regulated dataset — where does its authorization live at the moment of execution? If the honest answer is "in the application code, we hope," then your supply-chain investment, however excellent, is guarding a different door than the one the next incident will walk through.

An enterprise ultimately keeps two ledgers. One records what shipped: signatures, SBOMs, attestations — the identity of every actor. The other records what acted: every consequential business action and the authority under which it ran. The supply-chain stack has made the first ledger nearly unimpeachable. When the incident comes, the regulator reads the second — and in most enterprises today, the second ledger is whatever the application happened to log. That is the gap. Not a missing scanner. A missing object of governance.