Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
“Authenticity is useful evidence, but it isn’t proof of safety.”
—Jeff Williams
You need to know more than just what’s inside the software; you need to understand what the software does or has the potential to do, said Denis Calderone, a principal and CTO of Suzu Labs. “The Axios attacker never modified a single line of library code. The SBOM was clean. The package was signed. The provenance was legitimate. And it still dropped a [remote-access Trojan] on every machine that pulled it,” he said.
“An SBOM is an ingredient list, not a safety test.”
—Denis Calderone
Jasmine Noel, Senior Product Marketing Manager at ReversingLabs, said applications and their dependencies often start multiple background processes to function properly — but there are hidden capabilities that can pass through.
“The problem with that is those same background processes can mask hidden capabilities designed by malicious actors to activate only under specific circumstances, increasing the difficulty for routine code reviews — even with AI assistance — to determine when software is doing something it is not supposed to do.”
—Jasmine Noel
Another challenge is that software (along with its hundreds of dependencies) will exhibit thousands of behaviors. So accurate behavior identification is only the first step. "Intelligence on malicious behaviors, behavior prevalence, toxic combinations of changes, and tracking behavior changes across versions are also crucial solution capabilities," Noel said.
CodeHunter’s Ammon wrote in his article that behavioral verification has to be added to software supply chain security 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,” he wrote.
We have learned not to place implicit trust in networks, devices, and identities, Ammon said, and that same zero-trust approach now applies to software execution. “No artifact should be trusted solely because of its origin, signature, or reputation,” he said.
“Trust is not inherited from supply chain evidence alone. Those controls remain foundational, but they do not answer the final execution question.”
—Ken Ammon
Zero trust forces the authorization question, Suzu Labs’ Calderone said. “Right now, if code comes from a trusted source and passes a signature check, it runs,” he said. “Zero trust for code means that’s not enough.”
“You evaluate what the code actually does — does it escalate privileges, does it make unexpected network calls, does it touch credentials? — and you make it then allow it to make decisions based on behavior, not just origin.”
—Denis Calderone
SAS’s Smith said that applying zero trust to code execution makes software safer by shifting the security focus from “who the software is” to “what the software does.”
“By replacing ‘trust by identity’ with ‘verification by behavior,’ we can better ensure that no process is granted implicit trust. Enforcing a least-privilege model on what a process can do helps block malicious actions regardless of where the software came from.”
—Brett Smith
When you stop trusting signatures and provenance, you eliminate the VIP pass that attackers exploit in supply chain attacks, Smith added.
He recommends that CISOs stop treating digital signatures as safety guarantees and move toward a binary authorization policy. The strategic goal is to shift KPIs from “How fast can we detect a breach?” to “How many unauthorized execution attempts did we prevent?” he said.
The idea of applying zero trust to code is interesting but not new, said Brian Jack, CISO of KnowBe4.
“Putting friction in place and requesting the user approve what’s happening has been around a long time and, if done well, can be a great security control enhancement.”
—Brian Jack
However, Jack noted, if done poorly, it will frustrate users with too many prompts for approval that could put the user into a default click-approve mode. “The other concern is [that] by offloading some of the responsibility to the user, how can you be sure that every user is operating off of the same baseline knowledge of what the software should and shouldn’t do?” he said.
Contrast Security’s Williams said zero trust for code is a sound principle, but it has had mixed results in the versions of it that have been tried over the years: the Java sandbox, SELinux, compartmented mode workstations, and others.
“They’ve struggled because the policies are cumbersome, difficult to maintain, and prone to breaking legitimate software. Developers need to do inherently dangerous things — access private data, modify databases, create files, launch processes, and open network connections. When security controls prevent legitimate work, they’re usually weakened or disabled.”
—Jeff Williams
A noted exception to that rule is mobile, where Apple and Google control the operating systems, app stores, and distribution model and are able to make permissions mandatory. “That kind of leverage doesn’t exist across software generally,” Williams said.
Agentic AI could make traditional permission models nearly intractable, Williams added.
“Everyone is talking about guardrails, but an agent may legitimately need to read data, write code, call APIs, send messages, execute commands, and take actions across many systems. When the potential range of behavior is almost everything, expressing everything that should be allowed and disallowed in advance becomes impossible.”
—Jeff Williams
Williams prescribed a layered strategy:
ReversingLabs’ Noel said one of the big misconceptions folks have is that the code has to be running for behavioral analysis to happen, making it a slow and arduous process.
“Analyzing a software binary can deliver a comprehensive SBOM, evaluate the behaviors of each embedded artifact (even images and files that are not supposed to have behaviors), and perform threat detection in a single pass that is much faster and more rigorous than traditional dynamic analysis.”
—Jasmine Noel
Gartner noted the blind spots with traditional AppSec in a recent report, "The Gartner CISO Playbook for Commercial Software Security." Alternatively, modern strategies should be based on software supply chain security tooling that evaluates “both the software components and the security of the development practices followed to create it,” the report notes.
To carry this out, Gartner identifies required security controls and processes for effectively managing commercial software risk:
The above security measures should provide the risk scoring CISOs need “to inform procurement decisions and determine appropriate implementation controls,” Gartner noted in its report.
The annual cybersecurity conference focused on frontier AI agents — and what they mean for cyber. Here are three key takeaways.
Researchers built a worm that reasons about hosts it infects, and the open-weight models powering it sit outside AI-provider safety controls.
While prompt injection and data disclosure remain concerns, excessive agency climbed the list — not surprising with recent security incidents.