A raw vulnerability finding tells you what is broken. It does not tell you what an attacker would do with it. That gap is where most prioritization stalls. A finding with a high CVSS score and a finding tied to a known intrusion path can read the same on a sortable list, yet they carry very different operational weight. MITRE ATT&CK closes that gap. It gives every finding a vocabulary for the adversary behavior it enables, so triage can reason about exploitation paths instead of severity numbers alone.
This guide is about the methodology of mapping vulnerabilities to MITRE ATT&CK. It is vendor-agnostic by intent. The steps here apply whether you tag findings by hand, inherit techniques from a template library, or build coverage views on top of the result. Where it helps to ground the methodology in a concrete behavior, the examples reference how PMAP stores and resolves ATT&CK data, because a working implementation makes the abstract steps easier to follow. For a deeper view of how ATT&CK fits into broader enrichment, the vulnerability intelligence enrichment pillar sets the wider context.
If you want a plain definition of the framework first, the companion piece on what MITRE ATT&CK is covers the basics. This article assumes you already know what ATT&CK is and want a repeatable way to apply it.
Why Map Vulnerabilities to ATT&CK at All
Severity scoring answers a narrow question. It estimates how damaging a vulnerability could be if exploited, in isolation, against a generic target. It says nothing about whether the vulnerability sits on a path an attacker actually uses, whether your environment exposes that path, or whether a detection already covers the behavior downstream.
ATT&CK reframes the question. Instead of asking how bad a vulnerability is, it asks what an adversary gains by exploiting it. A remote code execution flaw on an internet-facing service is not just a high score. It is an enabler for Initial Access. A credential-handling weakness is not just a medium. It can feed Valid Accounts and the lateral movement that follows. Once a finding carries that behavioral label, triage stops being a sort on a number and starts being a conversation about exploitation paths.
This is the core of threat-informed defense. You prioritize the findings that advance an attacker through your environment, not the findings that happen to score highest in a vacuum. Three benefits follow directly.
First, prioritization gains context. Two findings with identical severity can be separated by the tactics they enable. A finding tied to Privilege Escalation on a domain controller outranks an equally scored finding tied to a low-value isolated host.
Second, coverage becomes visible. When findings carry technique tags, you can group them by tactic and see where exploitable weaknesses cluster. A heatmap built from mapped findings shows which stages of the attack lifecycle your open vulnerabilities expose, which is a question raw severity counts cannot answer.
Third, the conversation with detection and red teams gets a shared language. ATT&CK is the lingua franca of adversary behavior. When a vulnerability finding and a detection rule both reference T1190, the handoff between remediation and monitoring is unambiguous.
The mapping itself is the price of admission. It has to be deliberate, consistent, and current, or the coverage views built on top of it mislead. The rest of this guide is the methodology for doing it well.
A Quick Orientation to ATT&CK Structure
Before the workflow, a short orientation on how the framework is shaped, because the structure dictates how you map.
ATT&CK is organized as a matrix. The columns are tactics, the adversary’s goals, ordered roughly along the attack lifecycle: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, and the rest. The cells under each tactic are techniques, the methods adversaries use to achieve those goals. The Enterprise matrix is the one most relevant to vulnerability management, since it covers the platforms where scanned assets live. PMAP’s reference catalog is built on ATT&CK Enterprise v14, with roughly 180 techniques organized across 12 tactics.
Two structural facts matter for mapping accuracy. Techniques have a parent and child relationship, and some techniques live under more than one tactic. Both are covered next, because both are easy to get wrong.
Techniques, Sub-Techniques and the Parent Chain
ATT&CK techniques are not flat. Many techniques have sub-techniques that describe a more specific variant of the same behavior. Phishing is the technique. Spearphishing Attachment is a sub-technique under it. The IDs make the relationship visible: the parent carries an ID like T1566, and its sub-techniques append a suffix, so T1566.001 is a child of T1566.
PMAP models this directly. Each sub-technique record carries a parent_id field that references its parent technique, so T1566.001 points back to T1566. A boolean flag marks whether a record is a sub-technique, derived from the ID shape. That parent chain is what lets a navigator view roll sub-techniques up under their parents instead of scattering them, and it is what lets you reason about whether a tag should sit at the general level or the specific one.
The practical takeaway: a sub-technique is more precise, but precision is only useful when the evidence supports it. If you know the vulnerability enables a phishing attachment specifically, tag the sub-technique. If you only know it enables phishing in general, the parent technique is the honest choice. Mapping accuracy is about matching the tag to what the finding actually demonstrates.
Techniques That Span Multiple Tactics
The second structural wrinkle: a single technique can serve more than one adversary goal. Valid Accounts, T1078, is the classic example. Stolen or default credentials can grant Initial Access, then provide Persistence, then enable Privilege Escalation, then support Defense Evasion. The same technique appears under four tactics.
PMAP represents this honestly. A multi-tactic technique is stored as a single record that carries an array of tactic IDs and an array of tactic names, not duplicated once per tactic. T1078 is one row with all four tactics attached. When you filter the catalog by any one of those tactics, the row matches, because the filter checks whether the requested tactic is present anywhere in the technique’s tactic array.
This has a direct consequence for coverage math, covered in detail later. A multi-tactic technique tagged on a finding contributes that finding to every tactic it spans. Treat that as a feature, not a bug. It reflects the reality that some weaknesses are useful to an attacker at several stages of an intrusion.
A Step-by-Step Mapping Methodology
With the structure understood, here is the repeatable workflow. The methodology has three steps: identify the exploitation path, select the right technique or sub-technique, and tag the finding. Each step has a discipline that keeps the result consistent across analysts and over time.
The workflow assumes you have a reference catalog to map against, seeded from an authoritative source. In PMAP that catalog is searchable and filterable, which is what makes step two practical rather than a memory exercise.
Step 1, Identify the Exploitation Path
Start with the finding, not the framework. Read what the vulnerability actually allows. Does it let an unauthenticated attacker reach the service? Does it grant code execution? Does it expose credentials, escalate a session, or weaken a control that defenders rely on?
Translate that into a tactic, the adversary’s goal. This is the coarse-grained decision and it anchors everything after it. An exploitable service on the network edge points to Initial Access. A flaw that lets a low-privilege process gain higher rights points to Privilege Escalation. A weakness that lets an attacker disable logging or bypass a guardrail points to Defense Evasion.
Tactics in ATT&CK have stable slugs, machine-readable identifiers like initial-access and privilege-escalation. PMAP uses those slugs as the filter key for narrowing the catalog, which is why naming the tactic first is the efficient move. Once you know the goal, you have a much smaller set of techniques to consider.
A useful discipline here is to write the exploitation path as a short sentence before you reach for a technique ID. “This lets an external attacker run code on the web tier” is a sentence that maps cleanly to a tactic and then to a technique. “High CVSS, internet-facing” is not. The sentence forces you to reason about adversary behavior, which is the entire point of the exercise.
Step 2, Select the Right Technique or Sub-Technique
With a tactic in hand, narrow to the specific technique. This is where a searchable catalog earns its place. In PMAP you search techniques two ways, and both matter for accuracy.
You can search by ID when you already know it, typing T1190 to confirm the exact record. You can search by name when you are reasoning from behavior, typing “exploit public-facing” to surface candidates. Under the hood the search is a case-insensitive substring match against both the technique ID and the technique name, so a partial term still returns the relevant records. You can also constrain the list to a single tactic, which pairs naturally with the tactic you named in step one. When you supply both a search term and a tactic filter, the catalog applies them together and returns only techniques that satisfy both.
Now make the parent-versus-sub-technique decision deliberately. The rule from the structure section applies: tag the most specific technique your evidence supports, and no more specific than that. If the finding clearly enables Exploit Public-Facing Application, tag T1190. If it enables a specific phishing variant and you have the evidence to say which, tag the sub-technique. When the evidence only supports the general behavior, the parent technique is the correct, honest tag. Over-tagging at the sub-technique level when you cannot justify the specificity produces coverage views that look precise and are actually wrong.
Resist the temptation to attach every technique that feels related. A focused set of accurate tags is far more useful than a long list of loosely associated ones. Each tag should answer the question “does this finding genuinely enable this behavior?” with a yes.
Step 3, Tag the Finding
The final step is to attach the selected technique IDs to the finding. In PMAP, every finding carries a mitre_technique_ids field, stored as a text array. That array shape is deliberate and it encodes an important truth: one finding can enable more than one technique. A single vulnerability might support both an initial access technique and a follow-on execution technique, and the array holds both, for example ["T1190", "T1059"].
The values are technique ID strings that reference the canonical catalog. Keeping the tags as references to a seeded catalog, rather than free-floating labels, is what makes the downstream coverage views trustworthy. Every ID resolves back to a real technique record with its name, tactics, and canonical ATT&CK URL.
There is a second path to tagging that scales better than manual entry. When a vulnerability template carries ATT&CK techniques, those techniques flow onto the finding automatically. In PMAP, applying a VulnDB Smart Match template backfills the template’s mitre_technique_ids onto the finding when the finding’s own array is empty. The methodology is identical, the labor moves to the template once and is reused on every matching finding after that. For the product-side mechanics of how that mapping lands on individual findings, the companion guide on mapping findings to MITRE ATT&CK walks the operational flow.
Manual tagging and template-driven tagging are not in tension. Templates carry the high-confidence, well-understood mappings that repeat across many assets. Manual tagging handles the one-off and the novel. A mature program uses both, with the template library absorbing more of the load over time.
Building Coverage From Mapped Findings
Mapping is the input. Coverage is the payoff. Once findings carry technique tags that reference a real catalog, you can group them and see the shape of your exposure.
The natural grouping is by tactic. Pull the open findings, resolve their technique IDs to full technique records, and group those techniques by the tactics they belong to. The result is a tactic-by-tactic view of where your exploitable weaknesses sit along the attack lifecycle. PMAP supports this with a navigator-style, tactic-grouped view of techniques, the same shape the public MITRE ATT&CK Navigator popularized, built from your own findings rather than a generic matrix.
This is where the structure facts from earlier pay off. Recall that a multi-tactic technique carries all of its tactics. When you group by tactic, a finding tagged with Valid Accounts contributes to every tactic that technique spans. That is correct behavior. The finding genuinely exposes the organization at each of those stages, so it should appear in each column of the coverage view. If you flattened multi-tactic techniques to a single tactic, you would understate your exposure at the others.
A coverage view answers questions a flat severity list cannot. Where do my open vulnerabilities cluster, at the entry stages or the post-compromise stages? Which tactics am I most exposed at right now? If I close this batch of findings, which column of the matrix goes quiet? Those are prioritization questions framed in adversary terms, and they are only answerable because the mapping was done consistently underneath.
To make coverage views reliable at scale, the platform needs to resolve large sets of technique IDs back to full records efficiently. PMAP exposes a bulk resolution path that other parts of the system, finding enrichment and report rendering among them, use to turn a finding’s technique array into named, tactic-aware technique objects. The reporting layer never has to render a raw ID, and the coverage math always works from resolved records.
Keeping the Catalogue Current
A mapping methodology is only as good as the catalog it maps against. ATT&CK evolves. Techniques are added, renamed, deprecated, and reorganized across versions. If your reference table drifts away from the version your analysts reason about, the tags they apply slowly lose meaning.
The discipline here is to treat the catalog as managed reference data, not a one-time import. PMAP seeds its catalog from a curated, in-process copy of ATT&CK Enterprise v14, and the seeding operation is built to be re-run safely. Each technique is upserted, meaning the operation inserts new techniques and updates existing ones in place, using an on-conflict-do-update strategy keyed on the technique ID. Re-running the seed against an already populated table is harmless. It refreshes the records without creating duplicates and without losing data.
That idempotence is what makes catalog maintenance a non-event. When the reference data needs to advance, you re-seed, and the existing tags on findings keep resolving because the IDs they reference are stable. Technique IDs are the durable anchor. Names and descriptions can be refreshed underneath them without breaking a single finding’s mapping.
Pin the version explicitly in your own program documentation. Knowing that your findings are mapped against Enterprise v14, and not some unstated mixture of versions, is what lets an auditor or a new analyst trust the coverage views. A clearly versioned catalog is the difference between a mapping that compounds in value and one that quietly rots.
Common Mapping Mistakes and How to Avoid Them
The methodology is simple to state and easy to undermine in practice. A handful of mistakes recur often enough to call out, each with a direct countermeasure.
The first is tagging from severity instead of behavior. An analyst sees a critical finding, feels it deserves a technique, and reaches for whatever ID looks plausible. The fix is the discipline from step one. Write the exploitation path as a sentence before you choose a technique. If you cannot describe the adversary behavior the finding enables, you are not ready to tag it.
The second is over-specifying sub-techniques. Sub-techniques look more rigorous, so analysts gravitate to them even when the evidence only supports the parent. The result is a coverage view that claims precision it has not earned. The fix is to tag the most specific technique the evidence supports and stop there. When in doubt, the parent technique is the honest choice.
The third is free-form tag drift. Because PMAP stores technique IDs as a flexible text array, the schema itself does not stop an analyst from typing an ID that does not exist in the catalog, or a stale ID from an older version. The array is permissive by design, which keeps the system fast and simple, and it puts the burden of correctness on process. The countermeasure is to always tag from the searchable catalog rather than from memory. If the ID does not appear in the technique picker, it does not belong on the finding. Periodically reconcile finding tags against the seeded catalog so drift is caught early.
The fourth is mishandling multi-tactic techniques in coverage reporting. Analysts sometimes try to assign a multi-tactic technique to a single tactic to keep a heatmap tidy. That defeats the purpose. The technique spans multiple tactics because the weakness is useful at multiple stages. Let it contribute to every tactic it carries, and read the resulting coverage as the more accurate picture it is.
The fifth is inconsistency between analysts. Two people mapping the same class of finding to different techniques makes the coverage view noise rather than signal. The fix is shared convention, encoded where possible. This is the strongest argument for template-driven tagging. When the high-frequency mappings live in the template library, every matching finding inherits the same technique set, and analyst-to-analyst variance disappears for the common cases. Reserve manual judgment for the genuinely novel findings.
Avoid these five and the methodology holds. The mapping stays accurate, the coverage views stay trustworthy, and triage keeps reasoning in adversary terms instead of drifting back to a severity sort.
Frequently Asked Questions
What ATT&CK version should I map against?
Map against a single, explicitly named version rather than an unstated mixture. PMAP’s reference catalog is built on MITRE ATT&CK Enterprise v14, with roughly 180 techniques across 12 tactics. Pinning the version in your program documentation is what lets analysts and auditors trust that every finding’s tags reference the same technique definitions. When you advance to a newer version, re-seed the catalog so the whole program moves together rather than mapping against a moving target.
Should I tag a technique or a sub-technique?
Tag the most specific technique your evidence supports, and no more specific than that. ATT&CK sub-techniques describe a precise variant of a parent technique, and PMAP models the relationship with a parent_id field, so T1566.001 references T1566. If the finding clearly enables the specific variant, tag the sub-technique. If you only know the general behavior, the parent technique is the honest choice. Over-tagging at the sub-technique level produces coverage views that look precise but are not.
Can one finding carry multiple ATT&CK techniques?
Yes. In PMAP a finding’s techniques live in a mitre_technique_ids text array, so a single finding can enable several techniques at once, for example an initial access technique and a follow-on execution technique stored together. Use that capacity deliberately. Attach the techniques the finding genuinely enables, not every technique that feels loosely related. A focused, accurate set of tags is more useful than a long, speculative one.
How do multi-tactic techniques affect coverage views?
A multi-tactic technique contributes its finding to every tactic it spans. T1078 Valid Accounts, for example, is stored as a single record carrying all of its tactics, and PMAP filters match the record on any one of them. When you group findings by tactic to build a coverage view, a finding tagged with a multi-tactic technique appears under each relevant tactic. That is correct. The weakness genuinely exposes the organization at multiple stages of the attack lifecycle, so the coverage view should reflect exposure at each one.
Where do the technique tags actually live on a finding?
They live in a dedicated mitre_technique_ids field on the finding, stored as a text array of technique ID strings. Those strings reference the seeded MITRE ATT&CK catalog, so each ID resolves back to a full technique record with its name, tactics, and canonical ATT&CK URL. Keeping the tags as references to a managed catalog, rather than free-floating labels, is what makes the downstream coverage and reporting views trustworthy.
How does template-driven tagging relate to manual mapping?
They follow the same methodology, the labor just moves. In PMAP, a VulnDB Smart Match template can carry ATT&CK techniques, and applying that template to a finding backfills the techniques onto the finding when its array is empty. The high-confidence mappings that repeat across many assets live in the template once and are reused everywhere they match. Manual tagging then handles the one-off and the novel. A mature program uses both, with the template library absorbing more of the load over time.
Can I avoid tagging the same finding type differently across analysts?
Encode the convention rather than relying on memory. The strongest control is template-driven tagging: when the high-frequency mappings live in the template library, every matching finding inherits the same technique set, and analyst-to-analyst variance disappears for the common cases. For the findings that still need manual judgment, always tag from the searchable catalog rather than from recall, and periodically reconcile finding tags against the seeded catalog so drift is caught early.
SEO summary (Turkish): Bu yazi MITRE ATT&CK eslemenin metodoloji acisini sahiplenir. Birincil keyword “mitre attack vulnerability” H1, ilk paragraf ve FAQ icine dogal yerlesti. Ikincil keyword’ler (ATT&CK Enterprise v14, technique/sub-technique hierarchy, tactic coverage, mapping methodology) ilgili bolumlerde gecti. Ic linkler: ust pillar P1-06 vulnerability-intelligence-enrichment, cluster P2-20 mapping-findings-to-mitre-attack, P7-04 what-is-mitre-attack, datasheet vulndb-smart-match-templates. Dis otorite: attack.mitre.org ve ATT&CK Navigator. Tum teknik iddialar wiki/domains/mitre.md ile teyitli; v14 ve ~180 teknik/12 taktik niteliksel verildi.
