Remediation priority (vulnerability triaging) traditionally focuses on Software Bill of Materials (SBOMs) and Vulnerability Exploitability eXchange (VEX) statements provided with the software and supplemented by CVSS scores. That is not enough in today’s environment.
SBOMs list the components within the software. They emanated from Executive Order 14028 designed to reduce supply chain attacks. VEX statements emerged soon afterward to indicate whether any known vulnerabilities are exploitable. The separate CVSS score is used as a severity indicator for vulnerability remediation priority. It’s not working – supply chain attacks continue.
A major cause is a growing lack of context around exploitation. In the AI Age, the effect of exploitation may differ depending on which stage of an AI lifecycle in which it occurs. Lack of context reduces the effectiveness of remediation priority, while the expansion of AI software will magnify the problem. Supply chain attacks will continue to grow.
(Understanding ‘context’ is essential for understanding anything and everything in life. We perceive things – in this case data – but those things are meaningless in isolation. It is the surrounding, often invisible, context in which we see things that gives them any meaning. For another and different example of the importance of context, again involving AI, see the effect of bad AI context on AI decision-making.)
Devashri Datta is an independent researcher and security architect (specializing in DevSecOps automation, software supply chain security, and governance of large-scale vulnerability and compliance systems) has a solution. This solution comprises two new elements in the triage process: a safety relevance interpretation layer (SRIL) to provide context, and an extension (known as AIVEX) to the CycloneDX VEX to make the context machine readable.
SRIL provides context, and AIVEX transforms the context into a CycloneDX‑compatible schema suitable for use within the organization’s existing tooling.
Datta’s article explaining SRIL (Moving Beyond Severity Scores: A VEX-Driven Interpretation Layer for Software Supply Chain Governance) will be published by ISACA on July 1. Today, she sat down with SecurityWeek to discuss the failure of existing SBOM/VEX/CVSS, and the manner in which AIVEX/SRIL can change things.
A growing concern
AI can transform a data threat against systems into a physical threat against people – it is increasingly and autonomously driving physical robots.
If a firm has two CVSS scores — a CVSS 9.8 critical remote code execution flaw in a back-office analytics dashboard and a moderate CVSS 5.2 input-validation bug in the sensor-fusion module of an autonomous delivery robot operating in a public warehouse — current logic dictates patching the former first. But the latter could possibly harm or even kill innocent members of the public. The existing triage logic of using SBOMs, VEX and CVSS scores does not provide this context.
As software-driven autonomous robots increasingly pervade our physical world, context becomes ever more important. “But VEX stops short of safety context,” explained Datta. “It can tell you a vulnerability is not exploitable; but it cannot tell you that if it were exploitable, the consequence would be a vehicle losing steering control at highway speed.”
The commercial consequence of an autonomous robot causing death because of a software vulnerability that could have been fixed but wasn’t fixed would probably be bankruptcy.
This is the anomalous consequence of relying on CVSS scores: AI turns low threat into very high risk.
The AI Attack Surface
The inability of CVSS to indicate context is a growing concern and has reduced the CVSS value for DevSecOps engineers. Today, with the rise of AI and autonomous robots, a new solution is urgent. But context within AI software is complicated because AI’s attack surface is not the same as a traditional software attack surface.
“An AI system, particularly an agentic one capable of taking actions in the real world, has attack surfaces distributed across training data, model weights, inference pipeline, tool integrations, and deployment infrastructure,” explained Datta. “A compromise at any stage can alter behavior in ways that are difficult to detect and harder to attribute.”
She tackles this problem through the combination of SRIL and AIVEX.
SRIL
SRIL is not just a vague idea. “Flexera has adopted this and is shipping the version to customers next week; similarly, Anchore is working on it and will ship it in the next version,” she explained.
So, what is it? “SRIL is a structured annotation layer designed to sit above existing vulnerability data, enriching CVSS scores and VEX statements with four dimensions of context that safety-critical environments need but current standards do not provide,” she continued.
The four dimensions are:
- Safety domain classification (does the vulnerable component operate within a safety-critical function such as a sensor in an autonomous vehicle);
- Lifecycle stage mapping (the attack surface differs between different stages of an AI – training data integrity has a different level of risk than inference-time input validation);
- Consequence severity modifier (independent of the CVSS score, what is the real-world consequence if this vulnerability is exploited?)
- Exploitability in context (does the deployment environment, threat actor model, and asset exposure change the exploitability calculation in ways the base VEX statement does not capture?).
In combination, said Datta, “These dimensions allow security teams to generate a safety-adjusted priority – a triage score that reflects not just how severe a vulnerability is in isolation, but how much it matters in the specific operational context where affected software is deployed.”
This is a manual effort required from the DevSecOps team, but one that is fully justified by the potential blast radius of an unpatched low-severity AI vulnerability causing robotic third party harm.
AIVEX
The SRIL data is consumed and processed by the AIVEX. It generates context-rich decisions (such as ‘remediate now’, ‘defer’, or ‘monitor’ in machine readable format.
“The AI Vulnerability Exploitability eXchange is a proposed extension to the CycloneDX VEX schema. It makes SRIL machine-readable in structured fields for model provenance, inference-time attack surface classification, safety domain annotation, and AI lifecycle stage. It is designed to integrate with existing SBOM tooling rather than replace it,” explained Datta. “The CycloneDX working group has it under active consideration.”
VEX tells you whether a CVE is exploitable in a given product configuration. “AIVEX asks the question that comes afterward,” she continued. “If the vulnerable component is an AI model acting as an agent in the real world, what does exploitation actually mean? That’s a different problem class, and the industry doesn’t have a standard for it yet.”
AI compliance benefits
More realistic triaging is not the only benefit provided by SRIL/AIVEX. It also benefits increasingly arduous AI regulatory compliance. “A life cycle-based interpretation model improves traceability and auditability without introducing new compliance burdens. The US National Institute of Standards and Technology (NIST) Secure Software Development Framework promotes risk-informed decisions,” she explains in the paper being published on July 1.
“This model operationalizes that guidance by clarifying how SBOM and VEX data feed into real-world governance decisions. Importantly, the model does not redefine these standards; it helps organizations apply them consistently.”
She goes further, anticipating future international regulation convergence. The EU AI Act is in force, but full enforcement of its most demanding aspects for AI embedded in regulated products (conformity assessment, risk management, logging, human oversight) will only begin in August of this year.
Meanwhile, she explained, “NIST’s AI Risk Management Framework similarly emphasizes governance processes that account for operational context and real-world impact of AI system failures, not merely technical severity. Sector-specific guidance from FDA (medical devices), CISA (critical infrastructure), and the Department of Transportation (autonomous vehicles) is independently converging on the same need: a structured mechanism to connect vulnerability data to safety consequence.”
Such increasingly arduous regulations make demands without telling DevSecOps how to comply with those demands. “SBOMs tell you what components you have. VEX tells you whether they’re exploitable. But SRIL asks the question that regulators actually care about: if exploited, does it matter to a patient, a power grid or a passenger?”
Related: Are SBOMs Failing? Supply Chain Attacks Rise as Security Teams Struggle With SBOM Data
Related: SBOM Pioneer Allan Friedman Joins NetRise to Advance Supply Chain Visibility
Related: AI and Cybersecurity – Everything You Wanted to Know, But Were Afraid to Ask
Related: The Wild West of Agentic AI – An Attack Surface CISOs Can’t Afford to Ignore
