Why CVEs will not help with AI Models
The security industry as a whole has spent decades building robust frameworks for identifying, tracking, and remediating software vulnerabilities. At the heart of this system lies the CVE program (Common Vulnerabilities and Exposures), a method to catalog security flaws that has become synonymous with vulnerability management. With AI models now, we face an uncomfortable truth: the CVE framework fundamentally cannot address the security challenges posed by machine learning systems. This is not a minor limitation that can be patched with incremental improvements. The mismatch runs deep, rooted in foundational differences between how traditional software and AI models operate, fail, and expose risk.
The CVE Framework: Built for a Different Era
To understand why CVEs fail for AI models, it’s important to understand what they were designed to handle. The CVE system excels at cataloging vulnerabilities in traditional software because it makes several core assumptions:
Vulnerabilities exist in source code or binaries with deterministic behavior.
A vulnerability can be precisely located and described.
Versions can be clearly identified and compared.
Fixes can be deployed as patches without fundamentally altering the software's purpose.
The vulnerability is reproducible across identical deployments.
How AI Models Break These Assumptions
AI models, particularly large language models and deep neural networks, operate under entirely different principles that violate every assumption the CVE framework relies upon.
The Non-Deterministic Problem
Traditional software follows deterministic execution paths. Given the same input and state, the output is predictable and reproducible. This is fundamental to how we identify and verify vulnerabilities.
AI models are non-deterministic by design. The same prompt to GPT-4/GPT-5 can yield different responses even with identical model weights, depending on sampling parameters, system prompts, or subtle environmental factors. A vulnerability like prompt injection might succeed in one inference run and fail in another, even against the same model version, let alone different models
How do you assign a CVE to a vulnerability that only manifests probabilistically?
Vulnerabilities in Weights and Biasis, Not Code
CVEs point out flaws in code. But AI model vulnerabilities often reside in trained weights & biases, the billions of parameters that define model behavior. These weights are not human-readable code. They are the emergent product of training on massive datasets.
Example: Consider a backdoor embedded in a model through data poisoning. The malicious behavior exists in the weight matrices, not in any trainable code. There is no line number to point to, no function call to patch. The vulnerability is distributed across millions of parameters in ways we cannot precisely locate or understand. Traditional static analysis tools are useless here. You cannot grep for a backdoor in a 175-billion-parameter model.
Data Poisoning: Vulnerabilities Before Deployment
In traditional software, vulnerabilities arise from implementation errors made during development. The timeline is clear: code is written, bugs are introduced, the software ships, and vulnerabilities are discovered.
AI models introduce a new attack surface: the training data itself. An attacker who can poison training data can embed vulnerabilities before the model even exists in its final form. These vulnerabilities emerge during training, not during traditional development.
How do you version control a vulnerability that exists in your training corpus? Do you issue a CVE for a dataset? Against which vendor? The organization that collected the data, the one that preprocessed it, or the one that trained the model?
The Retraining Problem
When a CVE is issued for traditional software, the response is clear: apply the patch. Patching is relatively cheap, fast, and doesn't fundamentally alter the software's functionality.
AI models cannot be patched in this sense. If a vulnerability is discovered in a trained model, your options are limited and expensive:
Retrain the entire model (costs millions of dollars for large models)
Fine-tune to mitigate the issue (may not fully address the vulnerability and can introduce new problems)
Implement runtime guardrails (defensive measures that don't fix the underlying issue)
Deploy a different model entirely (requires extensive validation and integration work)
None of these maps to the traditional patch distribution and verification process that CVEs were designed to support.
Context-Dependent Vulnerabilities
A SQL injection vulnerability in a web application is exploitable regardless of whether that application manages a shopping cart or a hospital database. The vulnerability exists in the code, independent of the deployment context.
AI model vulnerabilities are often highly context-dependent. A prompt injection attack that works when a model has internet access might fail in an air-gapped environment. A jailbreak that succeeds with one system prompt might be completely ineffective with another.
This context sensitivity means that a vulnerability in an AI model might not actually pose a risk in many deployment scenarios. How do you scope a CVE when the exploitability depends on integration patterns, system prompts, and available tools or plugins?
Emergent Vulnerabilities and Jailbreaks
Traditional vulnerabilities are often implementation bugs, mistakes/misconfigurations made by devs. AI model vulnerabilities frequently arise from emergent properties of the model itself.
Jailbreak techniques that bypass safety guardrails are not bugs in any traditional sense. They exploit the fundamental way language models process and generate text. There is no code to fix. The "vulnerability" is an inherent property of how the model represents and manipulates information.
When security researchers discover a new jailbreak technique that works across multiple models from different vendors, what exactly gets the CVE? The technique itself? Each susceptible model? The underlying transformer architecture?
The Versioning Nightmare
CVEs rely on precise version identification. "This vulnerability affects versions 2.3.0 through 2.5.7" is a clear, actionable statement.
AI models have versions, but they are not comparable in the same way. A model might be updated with:
Different training data
Modified architectures
New fine-tuning
Changed inference parameters
Updated system prompts or safety layers
Two versions of GPT-4 might be dramatically different in their vulnerability profile, even if they share the same version number. Conversely, different models might share identical vulnerabilities because they were trained on similar data or use similar architectures.
The linear versioning model that CVEs depend on does not reflect the reality of AI model development and deployment.
What We Actually Need
The failure of CVEs to address AI model security is not just a theoretical concern. As AI systems become critical infrastructure, we need frameworks that actually work for this new attack surface.
These are some approaches that could work:
Model Cards and Transparency Artifacts
Rather than cataloging discrete vulnerabilities, we need comprehensive transparency about how models were trained, what data they were exposed to, and what risks they might carry. Model cards, datasheets for datasets, and similar documentation provide context that CVEs cannot capture.
Behavioral Testing Frameworks
Instead of identifying specific vulnerabilities, we need standardized tests for adversarial robustness, prompt injection and filtering resistance, bias, and safety. These tests should be run continuously, and results should be publicly available.
Supply Chain Security for ML
Just as we track software dependencies, we need frameworks for tracking data provenance, model lineage, and the full ML supply chain. This addresses risks that CVEs were never designed to handle.
Capability-Based Risk Assessment
Rather than cataloging vulnerabilities, we should assess and disclose model capabilities that could be misused. This shifts focus from specific exploits to potential for harm.
Continuous Evaluation Pipelines
AI model security cannot be a point-in-time assessment. It would need continuous evaluation frameworks that monitor model behavior in production and detect degradation or emergent risks.
Conclusion
The CVE framework represents decades of wisdom in vulnerability management. It has been instrumental in making traditional software more secure. But we must withstand the temptation to force AI models into this existing framework simply because it is familiar. AI models present fundamentally different security challenges that require fundamentally different solutions. Trying to wedge them into the CVE system will end up giving us a false sense of security while missing the actual risks.
As a security industry, it is crucial to experiment, iterate, and build new standards that actually address how AI models fail and how they can be exploited. This work is pressing as AI systems are already deployed in critical applications, and our vulnerability management processes are still stuck in the traditional software era.
