Executive Order 14028 pushed agencies, contractors, and enterprises to invest in SBOMs, signing, and provenance. Three years later, you've got transparency into your software composition. You know what packages you're running. You can verify who built them.
But here's what you still don't know: what that code will actually do when it executes.
What Changed
The software supply chain security model hit a wall. We built systems to answer "what's in this software?" and "who made it?" We didn't build systems to answer "what can this software do to my environment?"
University of Toronto researchers demonstrated an AI-powered worm capable of adapting its attack strategy. The June 2026 AI executive order on cybersecurity reflects federal concern about this shift. AI agents can now generate, modify, and deploy code faster than your review process can catch it.
Your SBOM tells you the ingredients. It doesn't tell you if those ingredients will exfiltrate your database at 3 AM.
Key Findings
Identity verification doesn't equal safety verification. You can cryptographically prove that Package X came from Developer Y at Company Z. That signature confirms origin. It says nothing about whether Package X will spawn a reverse shell or quietly modify your authentication logic. The trust model assumes that verified identity equals safe behavior. That assumption breaks when:
- Compromised credentials sign malicious code
- Legitimate maintainers introduce vulnerabilities
- AI agents generate subtly flawed implementations
SBOMs document composition, not capability. Your SBOM lists every component down to transitive dependencies. It's a manifest, not a threat model. When an attacker compromises a widely-used logging library, your SBOM tells you you're affected. It doesn't tell you that the compromised version is attempting network connections to infrastructure you've never authorized. You learn that during incident response, not during deployment.
Provenance tracks the build, not the runtime. You can verify that your container was built from a specific commit in a specific CI pipeline. That provenance chain proves the build wasn't tampered with. It doesn't prove that the resulting binary won't attempt privilege escalation or data exfiltration when you run it. The gap between "built correctly" and "behaves safely" is where modern attacks live.
AI-generated code moves faster than review cycles. Your team reviews pull requests. You run static analysis. You check for known vulnerabilities. AI agents can generate thousands of code variations per hour, each subtly different, each potentially introducing new behavior. Your review process was built for human-paced changes. It's not built for machine-speed iteration where the code you reviewed at 9 AM is already three generations old by lunch.
Current controls focus on the supply chain, not the execution boundary. Zero Trust principles transformed how you think about network access and identity verification. You verify every request, regardless of source. But your software execution model still assumes "if it passed the build checks, it's safe to run." That's implicit trust at the most critical boundary.
What This Means for Your Team
You need to shift from asking "where did this code come from?" to "what is this code attempting to do?"
This isn't about abandoning SBOMs or provenance. Those controls remain necessary. They're just not sufficient. You need a second layer that monitors and constrains software behavior at runtime, regardless of how well-documented or properly-signed it is.
The practical implication: your security architecture needs to treat software execution as an untrusted boundary, similar to how you treat network perimeters and user authentication. Every binary, every script, every container should operate within defined behavioral constraints. When code attempts actions outside those constraints, you need detection and response mechanisms that don't depend on having seen that exact pattern before.
Action Items by Priority
Start with runtime behavioral baselines. Map what your critical applications actually do during normal operation: which files they access, which network connections they initiate, which system calls they make. Use eBPF, system call tracing, or runtime application self-protection (RASP) tools to build these baselines. You can't detect anomalous behavior until you know what normal looks like. Focus on your highest-risk applications first, anything that processes customer data or has elevated privileges.
Implement least-privilege execution policies. Configure your container runtime to enforce strict capability sets. Use seccomp profiles to limit available system calls. Apply AppArmor or SELinux policies that define exactly what each process can access. If your application doesn't need to make outbound network connections, don't grant that capability. If it doesn't need to write to specific directories, enforce read-only mounts. These controls limit what malicious code can accomplish, even if it passes all your pre-deployment checks.
Add behavioral monitoring to your CI/CD pipeline. Before deploying to production, run your builds in instrumented sandbox environments that capture behavioral telemetry. Compare this behavior against your established baselines. Flag any new network destinations, unexpected file access patterns, or unusual resource consumption. This gives you a chance to investigate anomalies before they reach production. Integrate this step between your existing security scans and your deployment approval.
Build incident response playbooks for behavioral anomalies. Your current playbooks probably focus on known vulnerabilities and signature-based detections. Add procedures for investigating unexpected runtime behavior: what to do when a container attempts network connections you didn't authorize, how to respond when a process escalates privileges without a code change, who to notify when behavioral monitoring flags an anomaly. Practice these scenarios. The first time you see AI-generated malicious code, you won't have time to figure out your response process.
Evaluate runtime security platforms. Look for tools that provide visibility into application behavior and can enforce runtime policies. Falco for Kubernetes environments. Tracee for eBPF-based monitoring. Commercial RASP solutions if you need vendor support. The specific tool matters less than establishing the capability to observe and constrain runtime behavior. Start with visibility, then gradually add enforcement as you refine your policies.
