Most vulnerability programs do not fail because they lack data. They fail because the data arrives raw. A scanner reports a plugin ID, a title, a severity grade and maybe a CVE reference, and then it stops. The analyst is left to answer the questions that actually matter. What weakness class does this represent? Which attacker technique does it enable? Has the security team already written guidance for it? Is the vendor severity even trustworthy in this environment? Every one of those questions is a manual lookup, and at scale those lookups become the bottleneck that keeps findings sitting in a queue.
Vulnerability intelligence enrichment is the discipline of attaching that missing context automatically, before a human ever opens the finding. Done well, it turns a bare scanner record into a decision-ready item. Done poorly, it adds another field nobody trusts. This guide walks through how enrichment should work inside a vulnerability management platform, using PMAP as the worked example. It covers the reusable template library, the Smart Match engine that links findings to templates, deterministic plugin key matching, MITRE ATT&CK mapping, the role of CVE, CWE and CVSS, the canonical taxonomy that ties everything together, the difference between internal finding definitions and external templates, and the bilingual remediation knowledge base that gives owners something to act on.
If you want the full process view of how a finding moves from intake to closed, start with our pillar on the vulnerability management lifecycle. This article zooms into one layer of that lifecycle. It is the enrichment layer that sits between intake and triage and determines how fast everything downstream can move.
Why Raw Findings Are Not Enough for Triage
A triage decision is a comparison. The analyst weighs the severity of a finding against the exposure of the affected asset, the likelihood that the weakness is reachable, and the effort required to fix it. Every part of that comparison needs context, and a raw scanner finding supplies almost none of it.
Consider what a typical imported finding actually contains. There is a title, which varies in wording from one scanner to the next. There is a severity grade, which the vendor assigned according to its own model. There may be a CVE identifier, and there is usually a scanner-specific plugin identifier such as a Nessus plugin ID or a Qualys QID. What is missing is everything that converts that record into a judgment. There is no statement of the weakness class in CWE terms. There is no link to the attacker techniques the weakness enables. There is no canonical description that reads the same regardless of which tool produced the finding. There is no remediation guidance that the team has already vetted. Without those, the analyst rebuilds the same context by hand for every finding, and two analysts looking at the same vulnerability will often produce different write-ups.
This is the gap that enrichment closes. In PMAP, enrichment is anchored to a platform-level template library that carries the scanner-agnostic definition of a known vulnerability class. A template holds the CVE and CWE identifiers, the CVSS scoring, the MITRE ATT&CK techniques, multi-language descriptions and canonical remediation guidance for that class in one place. When a finding is linked to a template, that context flows onto the finding. The analyst stops doing research and starts making decisions.
The second reason raw findings fall short is consistency. A vulnerability class that appears across hundreds of assets should be described once and described the same way everywhere. When each finding carries its own free-text description copied from whichever scanner reported it, the program loses the ability to group, count and report coherently. Enrichment that draws from a shared library gives every instance of the same weakness the same canonical language, which is the precondition for meaningful taxonomy analytics later.
The Vulnerability Template Library
At the center of PMAP enrichment is the vulnerability template library, the domain the platform calls VulnDB. A vulnerability template is a reusable, scanner-agnostic definition of a known vulnerability class. It is authored centrally by security content authors and then matched automatically against incoming findings from any scanner, whether that is Tenable, Qualys, Rapid7, a DAST tool, a SAST tool or an SCA scanner.
Each template is a structured record rather than a free-text note. It carries a set of identity fields, a set of content fields, a classification block, taxonomy arrays, vulnerability identifiers and the matching keys that let the engine connect findings to it. Templates support full create, read, update and delete management, and the platform enforces a duplicate-name guard so that two active templates cannot share the same name. When an author tries to create a template whose name already exists among the active templates, the platform rejects it with a conflict response rather than silently producing a second copy. That guard matters because the library is the single source of truth for a vulnerability class, and a split into two near-identical templates would fragment every match and every report that depends on it.
Templates are platform-global. They are not scoped to any single tenant, which means the same curated knowledge base serves every company and subsidiary that the platform manages. A holding that runs many subsidiaries does not maintain a separate library per subsidiary. The content authors maintain one library, and the enrichment it produces is consistent across the entire estate.
Each template also carries an active flag. Setting a template inactive removes it from match results and from the default library view without deleting it. This soft-disable is the safe way to retire a template that no longer reflects how the team describes a vulnerability, because the historical findings that were enriched from it remain intact while the template stops influencing new matches.
The library is browsable and filterable. Authors and analysts can filter by severity, by CVE identifier, by CWE identifier, by tag and by free-text search across the name and description. When a free-text search is present, the library switches from its default chronological ordering to a relevance ranking that surfaces exact name matches first, then prefix matches, then substring matches, then everything else. That ranking is the same Tenable-style relevance ordering used across the platform, so the search behaves the way analysts already expect.
Smart Match: Auto-Linking Findings to Templates
A library only helps if findings reach the right template without manual searching. That is the job of Smart Match, the engine that links an incoming finding to the best template in the library. Smart Match accepts the finding title, any CVE identifiers and any scanner plugin keys, then runs a prioritized pipeline and returns ranked candidates for the analyst to confirm.
The pipeline runs in four stages, in strict priority order. The first stage is CVE exact match. If the finding carries one or more CVE identifiers and a template carries any of the same identifiers in its CVE array, that template matches with full confidence. The second stage is plugin key match. If the finding carries scanner plugin keys such as a Nessus plugin ID or a Qualys QID, and a template carries any of the same keys in its external match keys, that template matches with high confidence. The third stage is fuzzy title match. When neither identifier-based stage produces a result, the engine compares the finding title against template names using trigram similarity and returns templates above a similarity threshold, with the similarity score itself becoming the confidence value. The fourth and final stage is the manual fallback. When nothing else matches, the engine returns the most recently updated active templates at low confidence, so the analyst always has somewhere to start rather than an empty screen.
This ordering is deliberate. Identifier-based matching is deterministic and trustworthy, so it runs first and wins. Title similarity is heuristic and noisier, so it only runs when the deterministic stages come up empty. The fallback exists so the analyst is never stranded. The engine deduplicates across stages, which means a template that already matched on CVE in the first stage is not added again by a later stage, and the candidate list stays clean.
The best match is always the highest-priority candidate the pipeline found, presented first in the list. The engine requires at least one of title, CVE identifiers or plugin keys to run at all, because matching on nothing would be meaningless, and it rejects a request that supplies none of them. The default candidate limit is small and the maximum is bounded, so the analyst sees a focused shortlist rather than a wall of weak guesses.
Once the analyst selects a template, auto-fill takes over. The platform returns the ready-to-apply subset of the template and injects it into the finding. The analyst reviews the proposed values before they are applied rather than having them silently overwrite the finding, which keeps a human in the loop for the moment that matters while removing the manual research that came before it. You can see how this engine is packaged in the VulnDB Smart Match datasheet.
Confidence Scoring and Match Methods
Every Smart Match candidate carries two pieces of metadata that tell the analyst how to read it. The first is a confidence value on a scale from zero to one. The second is a match reason that names the stage which produced the candidate. Together they make the engine transparent rather than a black box.
The confidence values follow the stages. A CVE exact match returns the highest confidence because an identifier overlap is unambiguous. A plugin key match returns high confidence because scanner plugin identifiers are stable and specific. A fuzzy title match returns confidence equal to the trigram similarity score, so a near-identical title scores higher than a loose one and the number itself communicates how close the match is. The manual fallback returns low confidence because it is a starting point rather than a real match.
This transparency changes how analysts work. A high-confidence identifier match can be accepted quickly because the evidence is deterministic. A mid-confidence fuzzy match invites a quick read of the title before confirming. A low-confidence fallback signals that the library may not yet have a template for this class, which is itself useful information because it tells the content authors where a gap exists. The match reason makes the why visible, so the analyst is never guessing about how the engine arrived at a suggestion.
Plugin Key Matching for Deterministic Links
CVE-based matching is powerful, but a large share of scanner findings either carry no CVE or carry a scanner-specific detection that maps to a plugin rather than to a single published CVE. This is where plugin key matching earns its place as a distinct, deterministic stage.
Every scanner ships its own detection identifiers. Tenable Nessus uses plugin IDs. Qualys uses QIDs. Other tools use their own equivalents. These identifiers are stable across scans and specific to a single detection, which makes them ideal join keys. PMAP templates carry an external match keys array precisely for this purpose. A content author who knows that a particular Nessus plugin and a particular Qualys QID both detect the same underlying weakness records both keys on the same template. From then on, any finding produced by either scanner links to that single template through its plugin key, regardless of how the two scanners worded their titles.
This delivers two benefits at once. The first is deterministic enrichment. A plugin key match does not depend on title wording or fuzzy similarity, so it produces the same result every time and carries high confidence. The second is cross-scanner unification at the knowledge layer. Because one template can hold the plugin keys of several scanners, findings from different vendors that describe the same weakness all converge on the same canonical definition. That convergence is what lets the program describe a vulnerability once and report on it consistently no matter which tool found it.
Plugin key matching also reduces the load on the fuzzy stage. The more detections a template captures through explicit keys, the fewer findings fall through to title similarity, where the results are noisier. A well-maintained external match keys array is therefore one of the highest-leverage investments a content author can make, because each key added converts a class of future findings from heuristic matching to deterministic matching.
Mapping Findings to MITRE ATT&CK
Severity tells you how bad a vulnerability is in isolation. It does not tell you what an attacker would do with it. That second question is the one that connects a vulnerability program to the way real adversaries operate, and the answer comes from the MITRE ATT&CK framework.
PMAP provides a canonical reference table of ATT&CK Enterprise techniques and sub-techniques, seeded from a curated catalogue of ATT&CK Enterprise version 14. This is a read-oriented reference service. The techniques live in their own table and are exposed as a searchable, filterable surface that the rest of the platform draws on. Analysts can search techniques by their identifier, such as a technique numbered in the T1500 range, or by name, and they can filter by tactic such as initial access or privilege escalation. Techniques that span more than one tactic appear once and carry every tactic they belong to, so a technique like Valid Accounts surfaces correctly whether the analyst is looking through the lens of initial access, persistence, privilege escalation or defense evasion. Sub-techniques carry a reference to their parent technique, which lets the platform present a hierarchical navigator rather than a flat list. Every technique also carries its canonical ATT&CK URL, so an analyst can deep-link straight into the framework documentation for the full description.
There are two paths by which a finding gets its ATT&CK techniques. The first is direct tagging. An analyst working a finding selects the relevant techniques from the picker and they are stored on the finding. The second, and the one that scales, is backfill from a template. Vulnerability templates carry their own ATT&CK technique array. When a template is applied to a finding and the finding does not yet have any techniques of its own, the template’s techniques are backfilled onto the finding automatically. This is the enrichment pattern doing exactly what it should. The mapping work is done once, on the template, by a content author who understands the weakness class, and it then propagates to every finding that links to that template without each analyst repeating the analysis.
The payoff arrives at the reporting and prioritization layer. When findings carry ATT&CK techniques, the program can render coverage heatmaps that show which tactics and techniques the discovered vulnerabilities enable. That view reframes a list of findings as a picture of attacker capability, which is the language that resonates with leadership and with red and blue teams alike. For the standalone definition of the framework itself, see our cluster article on what MITRE ATT&CK is.
CVE, CWE and CVSS in Context
Three standards carry most of the identity and severity weight in vulnerability data, and a template library is where they come together. PMAP templates store all three as first-class fields rather than as text buried in a description.
A CVE identifier names a specific, publicly disclosed vulnerability. Templates carry a CVE array because a single vulnerability class can encompass several related CVEs, and because the CVE array is the highest-priority Smart Match key. Storing CVE identifiers as a structured array also makes the whole library queryable by CVE, so an author or analyst can find every template that touches a given vulnerability in one filter.
A CWE identifier names the underlying weakness class, such as a category of injection or a class of improper access control. CWE answers a different question than CVE. CVE says which vulnerability this is. CWE says what kind of mistake it represents. Templates carry a CWE array, and the library can be filtered by CWE, which lets a team look at its findings through the lens of weakness categories rather than individual disclosures. That weakness-class view is what makes systemic patterns visible, because a recurring CWE across many assets points to a root cause that a single CVE-level fix would never reveal.
CVSS supplies the severity grade. PMAP templates store both the CVSS vector string and the numeric CVSS score, so a matched finding gains standards-aligned severity context rather than only the grade a single scanner assigned. The vector matters as much as the score, because it records the assumptions behind the number, such as the attack vector and the impact dimensions. Keeping the vector alongside the score means the severity is auditable rather than a bare digit.
The reason these three belong together on a template is that triage needs all three at once. CVSS frames how severe, CVE frames which one and CWE frames what kind. A finding enriched with all three is a finding the analyst can reason about without leaving the platform. For a deeper standalone treatment of how these standards interact, our cluster article on CVSS, CWE and CVE in vulnerability management goes further than this section.
Canonical Taxonomy: Effects, Root Causes, Remediation
Identifiers and scores describe a vulnerability from the outside. A canonical taxonomy describes it from the inside, in the program’s own structured vocabulary, and that internal vocabulary is what makes findings groupable and analyzable beyond the level of individual CVEs.
PMAP templates carry several taxonomy arrays. There is an effects array that names what the vulnerability does, a root causes array that names why it exists, a remediation techniques array that names the families of fixes that apply, and a tags array for free-form grouping by technology, vendor or any custom dimension. These arrays align every template with the platform’s canonical finding taxonomy, which means a finding enriched from a template inherits a structured classification rather than a paragraph of prose.
This is where enrichment pays off twice. The first payoff is at triage, where a structured effect and root cause tell the analyst at a glance what they are dealing with. The second payoff is at analytics, where taxonomy turns a heap of findings into a set of measurable categories. A program that classifies its findings by root cause can see which root causes recur most often, which is the input to a prevention strategy rather than a perpetual cleanup. A program that classifies by remediation technique can see where a single class of fix would close many findings at once, which is the input to efficient remediation campaigns. None of that is possible when each finding carries only its scanner’s free text. It becomes possible the moment findings inherit a shared taxonomy from the template library.
The taxonomy also travels through the finding lifecycle. Because the arrays live on the template and flow to the finding at link time, every instance of a vulnerability class carries the same effects, root causes and remediation techniques. That consistency is what lets the reporting layer compute taxonomy distributions and taxonomy-based mean time to remediate, because the categories actually mean the same thing across every finding that uses them.
Internal Finding Definitions vs External Templates
PMAP maintains two libraries of vulnerability templates, and the distinction between them is deliberate and important. One is the external reference library, VulnDB, described throughout this article. The other is the internal finding definition library, and knowing when each one applies is part of running enrichment well.
The external VulnDB library is the scanner-agnostic, platform-global reference. Its templates carry CVE and CWE identifiers, CVSS scoring, ATT&CK techniques and canonical descriptions for known vulnerability classes, and they are matched automatically against incoming scanner findings. This is the library the Smart Match engine draws on.
The internal finding definition library is a writable, company-scoped library that the security team authors and owns itself. A finding definition captures the canonical title, severity, taxonomy, CVE identifiers, CVSS scoring and remediation guidance for a vulnerability class exactly as the organization defines it, tailored to the team’s own pentest methodology and remediation standards. Where VulnDB reflects the external world of published advisories, finding definitions reflect the team’s internal vocabulary and its way of describing the vulnerabilities it discovers, including findings that come from manual testing rather than from a scanner.
The two libraries connect rather than compete. A finding definition can carry an optional link to a corresponding VulnDB template, which lets the team cross-reference its internal description against the external reference. And the finding definition library has its own auto-link behavior. When a finding is created with a title that matches an existing definition, the platform links it to that definition automatically using a case-insensitive, whitespace-trimmed comparison, creating a new definition if none matches. At link time the finding inherits the definition’s taxonomy arrays, the same effects, root causes and remediation techniques pattern that VulnDB uses, so manual findings gain structured classification just as scanner findings do.
Each finding definition also tracks an occurrence count, computed live as the number of findings currently referencing it. That count is a quiet but powerful signal. A definition with a high occurrence count names a vulnerability class the team encounters repeatedly, which flags it as a candidate for a standing remediation pattern or a prevention control. The two libraries together give the program both an external lens, grounded in CVE, CWE and CVSS, and an internal lens, grounded in how the team actually works.
A Bilingual Remediation Solution Library
Enrichment that explains a vulnerability is useful. Enrichment that also explains the fix is what actually moves a finding toward closed. That is the role of the solution library, PMAP’s remediation knowledge base.
A solution is a remediation record that describes how to fix a class of vulnerability. Like the VulnDB templates, solutions are platform-global rather than tenant-scoped, so a remediation that one team writes becomes available knowledge across the estate. Each solution is keyed for lookup. It carries a CVE array, so it can be found by exact CVE match, and a related CWE array, so it can be found by weakness category. It carries free-form tags for grouping by technology or vendor, and it records a maximum CVSS value that captures the highest severity associated with the remediation, which lets the most severe fixes surface first.
The content itself is bilingual. Each solution carries separate Turkish and English rich-text fields alongside a shared summary description, which means a remediation owner reads the guidance in the language they work in rather than translating on the fly. That bilingual structure is a practical recognition that security teams and the engineers they hand findings to do not all work in the same language, and remediation guidance only helps if the person doing the work can read it directly.
Solutions connect to the rest of the enrichment graph through an optional link to a VulnDB template. When a solution is linked to a template, the template’s resolved name is returned on every read of the solution, so the relationship is visible rather than implicit. This is the chain that makes enrichment actionable end to end. A finding links to a template, the template carries the identifiers and taxonomy, and a solution linked to that template carries the vetted fix. The remediation owner arrives at a finding and finds not just a description of the problem but the team’s approved answer to it.
The platform also exposes a dedicated solutions browser built for the moment of selection. The browser returns an enriched view ordered by severity, with the highest-CVSS solutions first, and it shows how many templates each solution is linked to. That ordering is purpose-built for remediation work, because when an owner is choosing a fix to apply, the most severe and most reused solutions are the ones they want at the top. You can read more about how this remediation knowledge connects to the rest of the platform in the VulnDB Smart Match datasheet.
How PMAP Turns Findings Into Decisions
Step back from the individual mechanisms and a single pattern emerges. Every part of PMAP enrichment exists to move work upstream, from the analyst’s queue to the content author’s library, and from repeated manual research to a one-time authoring effort that propagates automatically.
The flow runs like this. A scanner imports a finding carrying a title, maybe a CVE, and a plugin key. Smart Match takes those inputs and runs its four-stage pipeline, preferring deterministic CVE and plugin key matches over fuzzy title similarity, and presents a ranked, confidence-scored shortlist. The analyst confirms a match, and auto-fill injects the template’s context onto the finding. With that single confirmation, the finding gains its CVE and CWE identifiers, its CVSS vector and score, its MITRE ATT&CK techniques, its canonical effects, root causes and remediation techniques, and a path to the vetted remediation in the solution library. For findings that come from manual testing rather than scanners, the internal finding definition library does the same job, auto-linking by title and inheriting taxonomy so that manual work is enriched as consistently as scanner work.
What the analyst is left with is not a research task but a decision. The context that used to take a dozen browser tabs to assemble is already on the finding, attached the same way every time, drawn from a library the team controls. The severity is auditable because the CVSS vector is preserved. The weakness class is explicit because CWE is a structured field. The attacker relevance is visible because ATT&CK techniques are mapped. The fix is reachable because a bilingual solution is linked. That is what it means for enrichment to actually help triage. It does not add fields for their own sake. It removes the manual lookups that stand between a raw finding and a confident decision, and it does so consistently across every scanner, every tenant and every analyst.
The deeper point is that enrichment is the multiplier on everything else in the lifecycle. A program with strong enrichment triages faster, reports more coherently, and remediates more efficiently, because every downstream activity inherits the structured context that enrichment attached at the start. That is why the enrichment layer deserves the same care as the scanning and the reporting around it, and why a curated template library, a transparent match engine and a vetted remediation knowledge base are not nice-to-haves but the foundation that makes the rest of the program move.
Ready to see it in practice? Explore the VulnDB Smart Match datasheet and enrich your findings before your team ever opens the triage queue.
Frequently Asked Questions
What is vulnerability intelligence enrichment?
Vulnerability intelligence enrichment is the practice of automatically attaching context to a raw scanner finding so that an analyst can triage it without manual research. In PMAP that context comes from a reusable template library and includes CVE and CWE identifiers, CVSS scoring, MITRE ATT&CK techniques, a canonical taxonomy of effects and root causes, and a path to vetted remediation guidance. The goal is to turn a bare finding into a decision-ready item before a human opens it.
How does Smart Match link a finding to a template?
Smart Match runs a four-stage pipeline in strict priority order. It first looks for a CVE exact match between the finding and a template, then a plugin key match using scanner identifiers such as Nessus plugin IDs or Qualys QIDs, then a fuzzy title match using trigram similarity, and finally a manual fallback that returns the most recently updated active templates. It deduplicates across stages and returns ranked candidates, each carrying a confidence value and a match reason, so the analyst can confirm the best match and apply the template’s context to the finding.
What is the difference between VulnDB templates and finding definitions?
VulnDB is the external, platform-global reference library of scanner-agnostic vulnerability templates carrying CVE, CWE, CVSS and ATT&CK data, matched automatically against incoming scanner findings. Finding definitions are an internal, company-scoped library that the security team authors itself to capture vulnerability classes in its own vocabulary, including findings from manual testing. A finding definition can optionally link to a VulnDB template for cross-reference, and both libraries inherit their taxonomy onto findings at link time.
How does PMAP map findings to MITRE ATT&CK?
PMAP maintains a canonical reference table of MITRE ATT&CK Enterprise techniques and sub-techniques that analysts can search and filter by tactic. A finding gets its techniques in two ways. An analyst can tag them directly from the picker, or they can be backfilled automatically when a VulnDB template is applied and the finding has no techniques yet. The technique mapping is authored once on the template and then propagates to every finding that links to it, which lets the program render ATT&CK coverage views without repeating the analysis per finding.
Why does PMAP store both the CVSS score and the CVSS vector?
The CVSS score is a single severity number, while the CVSS vector records the assumptions behind that number, such as the attack vector and the impact dimensions. Storing both means the severity grade on a matched finding is auditable rather than a bare digit. An analyst or auditor can read the vector to understand why the score is what it is, which is essential when severity drives prioritization and SLA timing.
What makes the remediation solution library actionable?
Solutions are bilingual remediation records, written in Turkish and English, that are keyed by CVE and CWE and can be linked to a VulnDB template. When a solution is linked to the template that a finding matched, the remediation owner arrives at the finding and finds not just a description of the problem but the team’s vetted fix. The dedicated solutions browser orders results by severity, surfacing the highest-CVSS and most-reused solutions first, which is exactly what an owner needs when choosing a remediation to apply.
Can plugin key matching unify findings from different scanners?
Yes. A single template can hold the plugin keys of several scanners in its external match keys array, such as a Nessus plugin ID and a Qualys QID that detect the same underlying weakness. Findings from either scanner then link to that one template through their plugin key, regardless of how each scanner worded its title. This is deterministic, high-confidence matching, and it converges different vendors’ findings onto a single canonical definition so the program can describe and report on a vulnerability consistently no matter which tool found it.
