Skip to content

For SOC analysts

A new CVE, an agent, and four questions

What to ask an AI agent about a CVE, and how to read the answer without being misled by it.

5 minute read

The lookup is slow. The reading is where mistakes happen.

A CVE lands in the queue. Before you decide anything you want three things: what the weakness is, which attacker behaviours it is associated with, and which of those you could already see. That is lookups across NVD, MITRE and the detection-rule repositories, and an agent can do them in seconds if it can show where each fact came from.

The risk is not that the agent is slow. It is that it flattens everything it finds into confident sentences, and a link someone inferred reads exactly like a link a vendor published.

The four questions

  1. What is it, and what weakness does it map to? (A lookup and one hop: the CVE and its CWE.)
  2. Which ATT&CK techniques does the graph associate with it, and who said so?
  3. For each technique, which detection rules exist, and which techniques have none?
  4. What does the graph not know? Every step that came back empty is part of the answer.

Reading the answer

Every link in a Lattice answer carries its source and a basis. Read it like this:

BasisWhat it meansHow to say it
declaredA source stated it (NVD, MITRE, a rule repository)."is" and name the source
inferredWe derived it through other links. It carries a confidence figure, which ranks guesses against each other. It is not a probability."likely" or "may", with the figure
gapThe step has no data, or the source is not published."the graph has nothing on this"

A worked example, with the awkward part left in

CVE-2024-10001 is a code injection flaw in GitHub Enterprise Server. Asked for the techniques it enables, the graph returns three: T1564.009 (Resource Forking), T1027.009 (Embedded Payloads) and T1027.006 (HTML Smuggling). All three links are inferred, at a confidence of 0.36. On our reading, none of the three obviously fits a server-side injection bug.

An agent that writes "this CVE enables Embedded Payloads" has said something no source said. An agent that writes "the graph weakly associates it with three defence-evasion techniques (inferred, 0.36), which does not obviously fit" has handed you the decision, which is where it belongs.

The detections are a different kind of fact. A Sigma rule for token obfuscation is declared against T1027.009, and an Elastic rule for suspicious HTML file creation against T1027.006, both at confidence 1. T1564.009 has no detection. The countermeasure step is marked source-not-published, and in the context view of the same CVE the known-exploited and advisory steps came back empty. Those gaps are worth as much as the hits.

What this does not do

  • It does not look at your systems. It cannot tell you whether you are affected, exploited or covered.
  • It does not rank what to fix first or decide what to do. It is reference material, and it can be wrong or out of date.
  • Inferred links are guesses. Treat them as leads.

Four prompts to start with

  • For CVE-2024-10001, which ATT&CK techniques does the graph associate with it? For each, say whether a source declared the link or it was inferred, and the confidence if inferred.
  • For technique T1059, which detection rules exist? Group them by the rule source and say which sub-techniques have none.
  • What does the graph NOT know about CVE-2024-10001? List every step that came back empty or unpublished.
  • For threat actor G0016, which techniques does it use, and for how many of those does the graph hold a detection? Say how many were cut off by the answer limit.

Where to go next