Enhancing CVE Records with Cause-Oriented Threat Intelligence

Context: MITRE and NIST — CVE & NVD

The Common Vulnerabilities and Exposures (CVE) program is operated by the MITRE Corporation, funded by CISA/DHS. MITRE assigns unique CVE identifiers and manages the official list. Separately, the National Vulnerability Database (NVD), maintained by NIST, imports all CVEs and enriches them with CVSS scores, CWE classifications, and CPE data.

In summary: MITRE creates the core CVE entries, NIST builds the NVD by enhancing them with detailed analysis. Both are essential — and both stop short of saying anything about the cause of the vulnerability or the shape of an attack that exploits it.

Abstract

CVE records tell us what is vulnerable, but not how attacks unfold, when they move, where they cross trust boundaries, or why the underlying weakness exists. We propose enriching CVE records with TLCTC v2.1's cause-oriented threat clusters, attack velocity (Δt), topology operators (domain / transit / intra-system boundaries), and Data Risk Event tags — bridging the gap between vulnerability management and strategic risk management. This blog post summarizes the core idea; the full proposal is on GitHub.

The problem: what CVE records are missing

A typical CVE entry gives us affected software, a vulnerability description, a CVSS score, and references. But it lacks four dimensions critical for strategic defense:

The proposal: a tlctc_extended section for CVE records

We propose adding an optional, backward-compatible tlctc_extended JSON section to CVE records. It includes:

• Generic vulnerability mapping — which root weakness category the CVE exploits
• TLCTC cluster classification with R-* rule justification (e.g., R-ROLE, R-CRED, R-EXEC, R-INTRA)
• Attack path examples with v2.1 operators: velocity (→[Δt=...]), domain boundaries (||[ctx][@A→@B]||), transit (⇒), intra-system boundaries (|[type][@A→@B]|), and unresolved-step markers (?, …)
• Data Risk Event tags separating cause from outcome (+ [DRE: C, I, A])
• Vertical stack / role analysis clarifying server/client roles per R-ROLE
• NIST CSF 2.0 mapping across all six functions (GV, ID, PR, DE, RS, RC)

Minimal v2.1 schema sketch

"tlctc_extended": {
  "generic_vulnerability": "Code imperfection in server-side software",
  "cluster": "#2",
  "sub_cluster": "TLCTC-02.20",         // core function vector
  "r_rule_justification": ["R-ROLE", "R-EXEC", "R-INTRA-7"],
  "attack_path": {
    "steps": [
      {
        "step_id": "s1",
        "cluster": "#2",
        "intra_system_boundaries": [
          { "type": "privilege", "from": "@local_user", "to": "@SYSTEM" }
        ],
        "outcomes": ["C", "I", "A"]
      }
    ],
    "textual": "#2 |[privilege][@local_user→@SYSTEM]| + [DRE: C, I, A]"
  },
  "velocity_class": "VC-4",
  "nist_csf_2_0": ["PR.PS-02", "DE.CM-09", "ID.RA-08"],
  "attck_techniques": ["T1068"]
}

The intra_system_boundaries array, the textual path, and the velocity class are all v2.1 additions — and they are precisely the dimensions CVSS and CWE cannot encode.

Quick example: before and after (corrected)

Take CVE-2025-21333 — Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege, CVSS 7.8 High. The original version of this post mapped the bug to #3 Exploiting Client. That was wrong, and it's worth saying so plainly. The first correction was only half right, so here is the second.

Here is the comparison with the corrected mapping and v2.1 operators:

CVE-2025-21333 — Windows Hyper-V NT Kernel
Integration VSP Elevation of Privilege
CVSS 7.8 HIGH

CVE-2025-21333
├── CWE-122 (Heap-based Buffer Overflow)
│   └── Generic Vulnerability:
│       Code imperfection in server-side software (kernel handler)
│       └── #2 / TLCTC-02.20 (Exploiting Server,
│           core-function vector)
│           [R-ROLE: kernel-side syscall handler,
│            handling a caller-supplied DACL]
│           ├── ATT&CK T1068 (Exploitation for Privilege Escalation)
│           ├── NIST CSF 2.0: PR.PS-02 (software maintenance),
│           │                DE.CM-09 (computing hardware/software monitoring)
│           ├── Attack Path:
│           │   #2 |[privilege][@local_user→@SYSTEM]|
│           │   + [DRE: C, I, A]
│           └── Velocity Class: VC-4 (architectural controls required)
└── CVSS 3.1: 7.8 HIGH

Now the record encodes the four dimensions:

• How: #2 — server-side memory-safety flaw in a syscall handler; data-only under R-EXEC, so #7 is recorded only if a payload is later executed
• When: VC-4 — the overflow-to-SYSTEM transition completes in milliseconds; human response is structurally impossible
• Why: "Code imperfection in server-side software" — the generic vulnerability behind every #2
• Where: |[privilege][@local_user→@SYSTEM]| — a host-local elevation into kernel context; the sandbox feature is a precondition for the vulnerable callback, not the attacker's vantage point

From proposal to practice

This proposal is no longer hypothetical. The companion post CVE-2026-35414: A 15-Year-Old Comma in OpenSSH applies exactly this enrichment structure to a current, high-impact CVE. It demonstrates:

• How to separate the CVE focus (a single cluster — the root cause) from the attack path (a sequence with velocity and boundaries)
• How R-CRED distinguishes credential application (#4) from credential lifecycle issues, and why this CVE has a #4 step but is not a #4 CVE
• How to use the v2.1 domain boundary operator ||[auth][@External→@OpenSSH-sshd]|| to make the trust crossing explicit
• How to handle CVSS divergence (NVD 8.1 vs CNA 4.2) without letting it pollute the cluster classification

That post is the published worked example of this proposal — read together, the two pieces show the spec and the practice.

What this enables

• Eliminates ambiguity: R-* rules replace vague "RCE" or "EoP" labels with precise cluster classification and citable justification.
• Velocity-informed control selection: VC-4 transitions require architecture, not analysts; VC-2 transitions allow human triage. Defenders learn this from the record itself.
• Cause/outcome separation: Clusters identify how the attack works; DRE tags capture what happens — the conflation that makes "ransomware" a category instead of a sequence is gone.
• Topology made explicit (v2.1): Domain, transit, and intra-system boundaries surface where trust changes hands — the dimension CVSS metrics cannot reach.
• Dual-audience notation: #2 for the boardroom, TLCTC-02.20 for SIEM correlation by vector class.
• Cross-framework alignment: Maps cleanly to ATT&CK, CWE, NIST CSF 2.0, STIX/TAXII, and IEC 62443 zone-conduit models.

Full proposal on GitHub

This post is a summary. The complete proposal — including the full enhanced JSON example, all R-* classification rules through R-INTRA and R-TRANSIT, velocity class definitions, semantic guardrails SG-1 through SG-7, implementation roadmap, framework alignment details, and FAQ — is maintained on GitHub.

We welcome contributions, feedback, and discussion via GitHub Issues. Whether you're a CNA, a security tool vendor, a SOC analyst, or a standards body representative — the proposal is designed to complement (not replace) existing CVE infrastructure while adding the strategic dimensions the community needs.