We’ve made real progress in software supply chain security, improving software component visibility, authenticity and build integrity. Much of this progress stems from Executive Order 14028, which pushed agencies, contractors and companies to invest in SBOMs, underwriting and provenance.
All of this is important, but it is not enough.
The current software trust model still faces the question that determines execution risk: What can this code do when it runs?
This blind spot is becoming increasingly difficult to ignore as AI changes the speed, scale and variability of malicious software. Research from the University of Toronto has shown that an AI-powered worm is able to adjust its attack strategy as it moves through a network. Unlike traditional worms that exploit a fixed vulnerability, this prototype can think of new attack paths and adapt its behavior to different systems.
The AI Implementing Ordinance on Cybersecurity from June 2026 reflects the federal government’s concerns. But the problem goes beyond politics: 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 just based on what it is, where it comes from, or whether it resembles something we’ve seen before.
Table of Contents
Visibility is not trust
SBOMs answer an important question: What is included in this software?
Organizations cannot manage dependencies, open source disclosure, or known vulnerable components if they do not know what is included in a build.
But composition is not behavior.
A package can have a clean dependency tree and still perform dangerous actions. An application can contain expected libraries and still attempt credential access, persistence, page movement, file modification, or data exfiltration.
SBOMs help security teams understand the components, but they do not predict what the software will do when it runs. The context is important. Deleting files can be legitimate in a disk cleanup utility and disastrous in an Office macro. Access to credentials is expected in a password manager, but not in a package dependency.
That’s the limitation of composition-based trust: if you know what software contains, you don’t know what it can do when it runs.
Authentic does not mean safe
Signing and provenance answer different questions. Can we check who published this software? Can we confirm where it came from? Can we determine if the build followed the expected steps?
These controls improve integrity, accountability, compliance and auditability. But authenticity is not the same as trustworthiness.
Signed software can still behave maliciously. An update from a trusted provider may be at risk. A legitimate build process can produce an artifact that violates company policy. An AI coding agent can generate code that works properly while introducing unintended security consequences.
Most security programs still assume that software is safe if it is signed, came through an approved pipeline, or comes from a known repository. This may be sensible as a first filter, but it is a dangerous final decision.
This approach made sense when software was slowly changing and malicious code had detectable indicators. AI now generates, modifies and deploys code at unprecedented speeds. Checking where the software comes from doesn’t tell us whether it should be run.
The missing fourth pillar
Government supply chain security frameworks have helped formalize key controls around software provenance, integrity and build process. What they haven’t fully addressed is behavior.
The security of the software supply chain must now answer four questions: What is in the software? Can we trust where it comes from? How was it built? What can it do?
The fourth question increasingly determines security outcomes as software inherits the permissions of the user, workload, service account, or automation context that launches it. Once code is running, it can access data, change systems, communicate externally, establish persistence, disable controls, or move laterally.
Traditional malware defense often makes this decision only after execution begins, by collecting telemetry, generating alerts, and enforcing containment. These capabilities remain necessary, but AI exacerbates the timing problem. If attackers can instantly generate variants and modify payloads, the visible surface of the malware becomes unstable.
It is too late to wait for recognizable signatures, known indicators, or post-execution alerts to make trust decisions.
Transition from software identity to software behavior
The next step is to add behavioral verification to existing software supply chain controls. A stronger model evaluates behavior before execution when possible, especially for high-risk artifacts such as packages, installers, scripts, containers, CI/CD output, and third-party AI-generated code.
The practical question should shift from “Do we recognize this?” change. to “Is this behavior permissible?” This requires evaluating actions such as privilege escalation, persistence, access to credentials, and unexpected network communications in context.
Years ago, Zero Trust transformed security by rejecting implicit trust in networks, devices, and identities. The same principle must now also apply to software execution. No artifact should be trusted solely based on its provenance, signature, or reputation.
In a zero trust for code model, trust is not inherited solely through evidence in the supply chain. These controls remain fundamental, but do not answer the ultimate question of execution.
Most companies are better able to answer what is in the software, where it comes from and how it was developed than they were five years ago. The harder question is figuring out what it can do when it runs.
https://www.helpnetsecurity.com/2026/07/13/sbom-zero-trust-for-code/
