CVE Enrichment: Turning Raw CVE Data Into Action

CVE enrichment is not the act of adding more fields. It is the work of turning separate, attributed claims into a decision an owner can defend and verify.

A raw CVE Record can identify a vulnerability and describe affected products. NVD may add product applicability, weakness labels, and severity analysis. CISA can add exploitation and SSVC data. A vendor can publish the fixed build. None of those sources knows whether one package is installed, loaded, reachable, or protected in your environment.

Weak enrichment flattens all of that into one row and calls it intelligence. Useful enrichment keeps each claim tied to its source and time, resolves conflicts by field, adds observed system state, and names the action that closes the case. That distinction is the whole job.

What is CVE enrichment?

CVE enrichment is the addition of structured information that helps a consumer understand and act on a CVE Record. Common fields include affected products and versions, CPE names, package identifiers, CWE classifications, CVSS vectors, exploitation status, exploit probability, references, remediation terms, and source metadata.

Start with identity. The CVE Program publishes the record and its state. A CNA supplies the description, affected scope, and references it can support. Authorized Data Publishers can add separate containers. NVD ingests the record and adds its own analysis. The CVEs and vulnerability intelligence pillar guide explains how those publishers fit together.

Enrichment becomes actionable only after public claims meet local observations. The useful output is not “CVE-2021-44228 has a high score.” It is “this customer portal loads an affected Log4j Core build, accepts internet input, has no effective block, and needs this supported update with this rollback and verification test.”

Current ranking guides usually stop at aggregation or generated explanation. They collect CVSS, EPSS, KEV, weakness, exploit, and affected version fields, then present a better summary. That helps a reader, but it does not define how to handle a disputed range, stale asset observation, missing package identity, or failed repair. The opportunity is not a longer record. It is a shorter path to a supported decision.

Which layers belong in a CVE enrichment record?

Use five layers. Identity contains the CVE ID, record state, publisher, publication time, and revision time. Affected scope contains vendor, product, package identifier, version logic, configuration, and fixed build. Threat and impact contains severity vectors, known exploitation, probability, weakness, and decision models.

Local proof records the observed package, file, process, feature, route, privilege, controls, business service, and owner. Owned action contains the exact fix or mitigation, approval, deadline, test, rollback, and fresh proof required to close. The first three layers describe public knowledge. The last two turn it into work.

Why does source provenance matter?

Different publishers can make different claims for sound reasons. A CNA may know the private product design. A Linux vendor may know a vulnerable function was removed or a fix was backported. NVD may map the upstream product to CPE. CISA may confirm attack use. Keeping one winner and deleting the others destroys the reasoning an operator needs.

The federal audit of NVD shows why blind flattening is risky. The May 2026 Department of Commerce Inspector General report found that severity scoring and CPE applicability consumed an estimated 80 percent of NVD enrichment time. In the auditors' internal test, independent evaluators produced consistent severity scores only 12 percent of the time. A score without its vector, source, and assumptions hides material judgment.

As of August 2025, the same report found that nearly 80 percent of CVE Program participants already included severity scores in submissions. NIST changed policy in April 2026 so it would no longer routinely create a separate score when one already exists. Consumers must display who scored the case. “NVD score” is no longer a safe label for every number returned through NVD.

What changed in CVE enrichment during the last year?

CVE Record Format 5.2.0 was released on October 29, 2025. The official CVE schema release added optional Package URL support inside affected product objects and tightened validation for unexpected properties. It also warns that a PURL in a CVE Record must not include a version because the version belongs in the record's version field. That detail matters to parsers and matchers.

NVD made another large change on June 17, 2026. It added CISA SSVC data and CVE affected data to feeds and API responses, touching about 95 percent of existing vulnerabilities. Its August 26 update replaced repeated affected JSON in history entries with direct GitHub links. The NVD deployment notices tell consumers to expect larger current records and a different history payload.

These developments expose a basic design rule. An enrichment pipeline must tolerate new containers, attribute each provider, validate against the record's declared schema version, and retain change events. Hard coded assumptions about one publisher or one payload shape will age badly.

How do you inspect official CVE and NVD data?

Pull the official CVE record and the NVD view separately. The first command reads the CVE Program's public JSON repository. The second uses the official NVD 2.0 API. Both commands were tested on August 30, 2026.

curl -fsSL \
  'https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2021/44xxx/CVE-2021-44228.json' \
  | jq '{
      schema: .dataVersion,
      id: .cveMetadata.cveId,
      state: .cveMetadata.state,
      cna: .containers.cna.providerMetadata.shortName,
      adp_count: ((.containers.adp // []) | length),
      affected_count: ((.containers.cna.affected // []) | length)
    }'

curl -fsSL \
  'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' \
  | jq '.vulnerabilities[0].cve | {
      id, sourceIdentifier, status: .vulnStatus,
      score_sources: ((.metrics // {}) | keys),
      cisa_added: (.cisaExploitAdd // null),
      affected: (.affected // []),
      configuration_sets: ((.configurations // []) | length)
    }'

The output for Log4Shell showed one CNA affected collection, two ADP containers in the CVE Record, and separate NVD fields for CVSS, SSVC, CISA action data, affected data, and 20 configuration sets. That is not one truth object. It is a set of claims with different publishers and purposes.

What does CVE enrichment look like in a real case?

Log4Shell is useful because the public record is rich and the local question is still easy to get wrong. The CNA affected data describes changes across multiple Log4j Core release lines. NVD adds numerous configuration sets and severity sources. CISA added the case to KEV on December 10, 2021 and supplies a required action. None of those facts tells you whether a shaded JAR inside one application image contains the affected code.

An enrichment pipeline should first preserve the CNA range exactly, including each change from affected to unaffected. It should store NVD configurations as NVD claims, not rewrite the CNA object. The KEV date and action belong in threat evidence. References need tags and publishers so a vendor advisory is distinguishable from an article or exploit repository.

Local proof comes next. Search deployed artifacts, package manifests, images, and running process classpaths. Record the hash and location of each candidate. Check whether the application accepts attacker controlled input on a reachable route and whether a mitigation changes that path. The decision can differ by instance even when every instance shares one CVE ID.

Finally, write the work in terms the owner can execute: affected artifact, service, supported target version, test command, restart condition, rollback, and the query that will confirm the old artifact disappeared. Enrichment earned its cost when the owner does not need to rediscover those facts.

How should CVE enrichment resolve conflicts?

Set authority by field. Use the CVE Program for record identity and state. Prefer the responsible vendor for supported product versions, fixed builds, and backports. Use CISA KEV for its exploitation determination. Use FIRST for dated EPSS probability. Keep NVD analysis as attributed enrichment. Then store the local conclusion as a separate record.

Do not overwrite. If the CNA says versions before 4.2 are affected and a distribution vendor says its 4.1 package contains a backported fix, preserve both. Confirm the exact distribution build and vendor advisory. The conclusion can be not affected for that package while the broader upstream range remains true.

CISA's public Vulnrichment repository demonstrates the Authorized Data Publisher model: additional SSVC, CVSS, CWE, and reference information lives in a distinct container. That separation is a feature. Copy it in your internal data model.

What does manual enrichment cost?

Use a hypothetical monthly batch of 2,400 new CVEs. If an analyst spends eight minutes finding sources, checking affected versions, and writing a short note for each one, the batch consumes 19,200 minutes, or 320 hours. Four analysts working 160 hours each have 640 hours of monthly capacity. The first pass takes half of it before a single local asset is checked.

The answer is not to generate 2,400 confident summaries. Automate collection, normalization, source labeling, schema checks, and obvious joins. Spend human time on conflicts, high impact unknowns, repair safety, and sampled quality checks. Measure how often conclusions reverse after better evidence arrives.

How do you measure CVE enrichment quality?

Completeness alone is a bad metric. A system can fill every field with weak inference. Measure attribution, freshness, supported matches, conflict age, unknown age, and decision reversals. Sample the cases labeled not affected because false closure is the expensive error. Also sample urgent cases to find wasted repair work.

Track handoff time by stage. Publication to ingestion measures collection. Ingestion to normalized claims measures parser health. Claims to supported local status measures product matching and telemetry. Supported status to owner measures routing. Owner to fresh closure proof measures execution. One mean time number hides which system is failing.

A practical weekly review takes 15 affected cases, 15 not affected cases, and the ten oldest unknowns. Recheck sources, product rules, endpoint observations, action terms, and closure proof. If two of 15 not affected cases lack current evidence, the problem is not a two case exception. It is a 13 percent error signal in the most dangerous decision class.

What should an enrichment contract require?

• Every claim stores publisher, source URL, retrieval time, and effective time.
• Raw records remain available beside normalized fields and parser version.
• Missing data stays null and receives an evidence state.
• Conflicting values remain visible until a field specific rule resolves them.
• Local matches include the observed product, version, package, runtime, and route.
• Actions include exact change, owner, deadline, test, rollback, and closure query.

Deep endpoint context with AI driven analysis can perform many of these joins and draft a repair command. Artemes uses that approach. The output is useful only when the operator can see what was observed, which public claims supported the decision, and how a fresh observation will prove the result.

Frequently asked questions about CVE enrichment

Is CVE enrichment the same as vulnerability intelligence?

Enrichment supplies and organizes claims around a CVE. Vulnerability intelligence uses those claims with local context to support a decision. Enrichment is an input, not the finished product.

Which CVE enrichment source is authoritative?

Authority depends on the field. No source owns every question. Keep identity, affected versions, severity, exploitation, probability, remediation, and local state attributed separately.

Should AI fill missing CVE fields?

AI can suggest a classification or summarize evidence, but inferred content must be labeled and kept separate from publisher claims. Never convert a guess into a vendor affected range or confirmed exploit status.

How often should enriched records refresh?

Process source revisions at least daily and faster during active incidents. Reevaluate local decisions whenever affected ranges, exploit evidence, fixes, or observed asset state changes.

The executive takeaway

Take one high priority CVE and ask your platform to show every claim, publisher, timestamp, conflict rule, local observation, repair action, and closure test. If the answer is one blended row, you do not have enrichment you can audit. You have a summary. Fix the data model first.