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