MITRE ATLAS, the MIT AI Risk Repository, CVE for AI and threat-modelling an AI system

Why this matters

Lesson 7 covered the OWASP lists, which tell you what commonly goes wrong in AI applications. They do not tell you how a real adversary moves through an AI system from first contact to impact, what risks exist beyond security, how a specific flaw in a specific component is tracked, or how to work out which risks matter for the system on your desk. Four further resources cover those gaps, and each answers a different question.

MITRE ATLAS describes adversary behaviour against AI systems. The MIT AI Risk Repository catalogues AI risk in the broadest sense. The CVE AI Working Group is part of the effort to record vulnerabilities in AI systems the way the industry already records software vulnerabilities. And a threat-modelling framework is the method that pulls all of them together for one system.

A security professional needs all four because they are used at different moments: ATLAS when planning detection or red-team work, the repository when a risk assessment needs to be complete, CVE when a component needs patching, and a threat model whenever a design changes. Scenario questions in this objective usually describe a task and ask which resource fits it, so knowing what each is for matters more than memorising its contents.

The lesson

MITRE ATLAS as ATT&CK's counterpart for AI: tactics, techniques and case studies

ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a knowledge base maintained by MITRE of adversary tactics and techniques against AI systems, deliberately modelled on MITRE ATT&CK. Anyone who has used ATT&CK already knows how to read it.

• Tactics are the adversary's goals at each stage: the "why" of a step. Many are shared with ATT&CK, such as reconnaissance, initial access, persistence, exfiltration and impact. ATLAS adds tactics with no ATT&CK equivalent, covering how an adversary gains access to a model and how they prepare an attack against it, for instance by building a proxy model to craft inputs offline.
• Techniques are the "how": specific ways of achieving a tactic, such as prompt injection, poisoning training data, evading a classifier with crafted input, or extracting a model through its interface. Each technique has an identifier, and ATLAS techniques carry an AML prefix that distinguishes them from ATT&CK's.
• Mitigations link techniques to the controls that address them.
• Case studies document real-world attacks and red-team exercises against AI systems, mapped step by step to tactics and techniques.

The case studies are what make ATLAS more than a taxonomy. They show that attacks on AI systems combine AI-specific techniques with entirely ordinary ones: many chains start with conventional reconnaissance and initial access, and become AI-specific only at a later step. That matters to a defender, because it means most of the existing detection estate still applies, and the AI-specific techniques are the few new detections that have to be built.

Use ATLAS the way ATT&CK is used: to map a threat actor's likely path through your system, to check which techniques your monitoring would see, to plan a red-team exercise, and to describe an incident in shared terms.

The MIT AI Risk Repository, and using it to find risks nobody on the team thought of

The MIT AI Risk Repository is a living database of AI risks, compiled from a large number of published frameworks, taxonomies and research papers, and updated as new ones appear. Its value is breadth: rather than any single author's view of AI risk, it gathers many, and records where each risk came from.

It organises risks two ways:

• A causal taxonomy, which classifies each risk by how it arises: whether it is caused by a human or by the AI system, whether intentionally or not, and whether it arises before or after deployment.
• A domain taxonomy, which groups risks by subject: areas such as privacy and security, misinformation, malicious use, discrimination and toxicity, and failures and limitations of the AI system itself.

The practical use is as a completeness check. A security team threat-modelling a new HR assistant will naturally list prompt injection and data leakage. Filtering the repository by the relevant domains and by "unintentional, post-deployment" surfaces risks the team was never going to think of: staff over-trusting answers about their entitlements, unequal quality of answers across groups of employees, or a gradual loss of the human expertise the assistant replaced. Several of those land with the governance and responsible-AI owners in lessons 30 and 31 rather than with security, and that is exactly the point: the repository widens a risk assessment beyond the security team's instincts.

What it is not: a list of attack techniques, a control catalogue or a vulnerability feed. A question about how an adversary operates points to ATLAS; a question about making a risk register complete points here.

The CVE AI Working Group, and how a vulnerability in an AI component gets an identifier

The Common Vulnerabilities and Exposures (CVE) Program gives publicly disclosed vulnerabilities a unique identifier, so that a vendor advisory, a scanner finding and a patch can all refer to the same flaw. AI components already receive CVE identifiers by the ordinary route, because much of the AI stack is ordinary software: model-serving frameworks, inference servers, orchestration libraries, notebook environments and the libraries that load model files.

The ordinary route is unchanged for those. A researcher reports the flaw to a CVE Numbering Authority (CNA) whose scope covers the product, usually the vendor itself, or to a CNA of last resort when no vendor CNA exists. The CNA assigns the identifier and publishes a record describing the affected product and versions. The weakness behind it is classified with Common Weakness Enumeration (CWE), and severity scoring is a separate step.

The harder questions are the ones the CVE AI Working Group exists to address. The CVE Program set it up to work through how vulnerabilities in AI systems are identified and recorded, where the existing rules fit awkwardly:

• What is the affected product when the flaw is in a model's behaviour: the weights, the hosted service, the application around it, or the training data?
• Is a model that can be talked into misbehaving vulnerable, or behaving as designed with insufficient guardrails?
• How is a flaw recorded when it is probabilistic, reproducing on some attempts and not others?

Do not expect the exam to test the group's conclusions; know what it is for. The practical lesson for a defender is that CVE only helps if you know what you are running. A software inventory that lists the inference server and libraries, and ideally the models and datasets too, is what lets a new CVE be matched to your estate in hours rather than weeks.

Applying a threat-modelling framework to a system that includes a model

None of the resources above is a method. A threat-modelling framework supplies one: a repeatable way to describe a system, find threats against it and decide what to do about them. The familiar frameworks work for AI systems with one adjustment, which is to draw the model and its data flows as first-class elements.

Take an HR assistant: employees ask questions, the application retrieves policy documents from a vector store, sends them with the question to a hosted model, and can email a summary to the employee.

1. Draw the data flow diagram with the AI-specific elements explicit: the model endpoint, the vector store, the ingestion pipeline that fills it, the system prompt, the email tool, and the logs.
2. Mark the trust boundaries. The usual ones remain (browser to application, application to the provider). The AI-specific boundary is the one inside the prompt: retrieved content and user text cross from data into the model's instruction stream. That crossing is where indirect prompt injection lives, and it appears on no network diagram.
3. Apply a threat-finding method to each element. STRIDE works well: spoofing of the user to the retrieval layer, tampering with documents in the ingestion pipeline, repudiation of an email the assistant sent, information disclosure through retrieval that ignores the reader's permissions, denial of service through unbounded requests, and elevation of privilege when injected text drives the email tool. LINDDUN adds a privacy lens, PASTA a risk-centred and attacker-focused process, and attack trees suit a single high-value goal such as "exfiltrate salary data".
4. Enrich with the catalogues. Map each threat to its OWASP entry and its ATLAS technique, which gives shared language and points to known mitigations. Then check the MIT repository for risks outside security's usual view.
5. Decide and record. For each threat: mitigate, accept, transfer or avoid, with an owner, and revisit whenever the system gains a new data source or a new tool.

The examinable point is the second step. A threat model of an AI system that draws only network trust boundaries misses the one boundary that makes it an AI system.

Choosing the right resource for the scenario a question describes

The resources overlap at the edges, but each has a home question:

• How does an adversary attack systems like ours, and would we detect it? MITRE ATLAS, its techniques and its case studies.
• What should a design review of our LLM application check? The OWASP LLM Top 10.
• What can go wrong in our model training and inference pipeline? The OWASP ML Security Top 10.
• Is our AI risk assessment complete, including non-security risks? The MIT AI Risk Repository.
• Is this inference server affected by a published vulnerability, and how are AI flaws recorded? CVE, and the CVE AI Working Group for the second half.
• What threats does this specific system face, and what will we do about each? A threat-modelling framework, fed by all of the above.

Organisation-wide AI risk management, as opposed to a single system, is the territory of the NIST AI Risk Management Framework in lesson 32.

A scenario typically gives away its answer in the verb. "Map", "emulate" or "detect" an adversary points to ATLAS. "Review" a design points to OWASP. "Identify all risks" points to the repository. "Track" or "patch" a flaw points to CVE. "Analyse a new system" points to a threat-modelling framework.