Why SBOMs, signing, and provenance still don’t tell you if software is safe

We have made real progress in software supply chain security, improving visibility into software components, authenticity and build integrity. Much of this progress traces back to Executive Order 14028, which pushed agencies, contractors and enterprises to invest in SBOMs, signing and provenance.

All of that matters, but it is not enough.

The current software trust model still stops short of the question that determines risk at execution: What is this code capable of doing if it runs?

This blind spot is becoming harder to ignore as AI changes the speed, scale and variability of malicious software. University of Toronto research demonstrated an AI-powered worm capable of adapting its attack strategy as it moves through a network. Unlike traditional worms that exploit a fixed vulnerability, this prototype can reason through new attack paths and tailor its behavior to different systems.

The June 2026 AI executive order on cybersecurity reflects federal concern. But the issue is broader than policy: traditional trust models are insufficient when AI generates, modifies and deploys code faster than human review can keep up.

We can no longer trust software based primarily on what it is, where it came from or whether it resembles something seen before.

Visibility is not trust

SBOMs answer an important question: What is inside this software?

Organizations cannot manage dependencies, open-source exposure or known vulnerable components if they do not know what is inside a build.
But composition is not behavior.

A package can have a clean dependency tree and still perform dangerous actions. An application can include expected libraries and still attempt credential access, persistence, lateral movement, file modification or data exfiltration.

SBOMs help security teams understand ingredients, but they do not predict what software will do once it executes. Context matters. File deletion may be legitimate in a disk cleanup utility and catastrophic in an office macro. Credential access is expected in a password manager, but not in a package dependency.

That is the limitation of composition-based trust: knowing what software contains does not tell you what it can do once it runs.

Authentic does not mean safe

Signing and provenance answer different questions. Can we verify who published this software? Can we confirm where it came from? Can we determine whether the build followed expected steps?

Those controls improve integrity, accountability, compliance and auditability. But authenticity is not the same as trustworthiness.

Signed software can still behave maliciously. A trusted vendor update can be compromised. A legitimate build process can produce an artifact that violates enterprise policy. An AI coding agent can generate code that functions correctly while introducing unintended security consequences.

Most security programs still assume that if software is signed, came through an approved pipeline or originated from a known repository, it is safe. That may be reasonable as a first filter, but it is a dangerous final decision.

This approach made sense when software changed slowly and malicious code had recognizable indicators. AI is now generating, modifying and deploying code at unprecedented speed. Validating where software came from does not tell us whether it should run.

The missing fourth pillar

Government supply chain security frameworks have helped formalize essential controls around software origin, integrity and build process. What they have not fully addressed is behavior.

Software supply chain security must now answer four questions: What is inside the software? Can we trust where it came from? How was it built? What can it do?

The fourth question increasingly determines security outcomes because software inherits the privileges of the user, workload, service account or automation context that launches it. Once code executes, it can access data, modify systems, communicate externally, establish persistence, disable controls or move laterally.

Traditional malware defense often makes that decision after execution begins by collecting telemetry, generating alerts and enforcing containment. Those capabilities remain necessary, but AI makes the timing problem worse. When attackers can instantly generate variants and alter payloads, the observable surface of malware becomes unstable.

Waiting for recognizable signatures, known indicators or post-execution alerts to make trust decisions is too late.

Moving from software identity to software behavior

The next step is adding behavioral verification to existing software supply chain controls. A stronger model evaluates behavior before execution wherever possible, especially for high-risk artifacts such as third-party packages, installers, scripts, containers, CI/CD outputs and AI-generated code.

The practical question should change from “Do we recognize this?” to “Is this behavior authorized?” That requires assessing actions such as privilege escalation, persistence, credential access and unexpected network communication in context.

Years ago, Zero Trust changed security by rejecting implicit trust in networks, devices and identities. The same principle now needs to apply to software execution. No artifact should be trusted solely because of its origin, signature or reputation.

In a Zero Trust for Code model, trust is not inherited from supply chain evidence alone. Those controls remain foundational, but they do not answer the final execution question.

Most enterprises can answer what is inside software, where it came from and how it was built better than they could five years ago. The harder question is determining what it can do once it runs.