How should teams govern their internal mappings to ATT&CK and CVE?

How to Govern Internal ATT&CK and CVE Mappings

Internal mappings work best when treated as shared security metadata, not as one team’s private taxonomy. The catalogue should define who can add or change mappings, which evidence is required, how version baselines are tracked, and how internal technique IDs stay linked to public identifiers so reporting remains stable across detection engineering, threat intel, red or purple team, and GRC.

A useful governance model separates the content of a mapping from the process that approves it. That distinction matters because ATT&CK techniques and CVEs evolve at different speeds, and the mapping only stays trustworthy if the organisation can show why a link exists, when it was last reviewed, and which downstream reports depend on it.

Crosswalks are the practical control point. A well-governed crosswalk keeps internal technique names, ATT&CK procedure references, and CVE identifiers aligned without forcing every team to speak the same operational language. When that alignment is missing, analysts can still do the work, but executives, auditors, and incident responders lose consistency when they compare assessments over time.

For ATT&CK, the catalogue should capture the technique version used at the time of mapping, the rationale for any local extension, and whether the internal ID represents a direct technique match, a parent technique, or a more specific detection pattern. That prevents later confusion when a technique is renamed, split, or retired in the external matrix and avoids accidental overstatement of coverage.

For CVEs, the same discipline should record the exact identifier, the affected asset class, and whether the mapping is based on confirmed exposure, likely exposure, or a watchlist condition. Teams should resist the temptation to collapse all known vulnerabilities into a single “badness” bucket, because the operational meaning of a CVE varies depending on whether it is exploitable, present, mitigated, or only relevant to a dependency chain.

Good governance also defines review cadence. ATT&CK mappings often need periodic refresh after framework releases, while CVE mappings need review when affected products change, compensating controls land, or a vulnerability’s exploitability becomes clearer. The catalogue should be able to show both the last approval and the next review point, so stale mappings are visible rather than buried in spreadsheets.

Risk and Threat Considerations

Internal mappings become risky when they drift from the public identifiers they are meant to represent. A stale ATT&CK crosswalk can make detection coverage look broader than it is, while an inaccurate CVE mapping can distort remediation priority and create false confidence about what is actually exposed.

Failure mechanism: version drift, undocumented local extensions, and inconsistent ownership can break the traceability between internal IDs and public references, so reports no longer mean the same thing across teams or over time.

Impact: leaders may fund the wrong detections, miss material gaps, or misstate exposure in assurance and incident reporting, especially when the same internal label is reused for different external meanings.

Practitioner Guidance

What to verify: every internal mapping should have a named owner, a source reference, a version baseline, and a rule for when it must be revalidated. If any one of those elements is missing, treat the mapping as draft metadata rather than trusted control evidence.

Decision rule: approve local extensions only when the team can explain why the public identifier is too coarse for operational use and how the extension will still roll up cleanly to ATT&CK or CVE in reporting. If that roll-up is not possible, the extension is probably a new field, not a mapping.

What good looks like: detection engineering can use local IDs for daily work, threat intel can enrich them, red or purple team can test them, and GRC can still produce a stable crosswalked report without manual translation at the end of every cycle.

Practitioner takeaway: treat mappings as governed reference data, not analyst shorthand, because the real control is not the label itself but the organisation’s ability to preserve meaning as frameworks and vulnerabilities change.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?