Vulnerability finding CVE and EPSS enrichment
attach upstream advisory references to every finding on one record

The canonical reference that ties a finding to the upstream advisory ecosystem. Without a CVE on the record, the finding cannot be matched against the CISA KEV catalog, the FIRST EPSS feed, vendor PSIRT bulletins, the NVD entry, or the upstream proof-of-concept landscape. Capturing the CVE at intake (or marking explicitly that no CVE applies for custom application findings) is the first enrichment step and the one most often skipped because the scanner output already feels complete.

The intrinsic technical severity of the vulnerability under different operating contexts. The base vector answers "how bad if exploited"; the temporal vector layers exploit code maturity and remediation level signals over time; the environmental vector recalibrates the score for the deployed estate by adjusting CIA requirements and modified attack vector or scope. SecPortal stamps the full vector on every finding so the residual severity is auditable rather than narrative.

The FIRST Exploit Prediction Scoring System estimate of the probability the CVE will be exploited in the wild over the next thirty days, paired with the percentile that places the CVE in the population of all scored CVEs. EPSS updates daily. The enrichment step records both the probability and the percentile against the finding so the queue can sort by either and so the audit can verify the priority decision was based on a fresh value rather than a snapshot pulled at import.

Whether the underlying CVE sits in the CISA Known Exploited Vulnerabilities catalog at the time of the latest catalog refresh. KEV is the strongest single signal a finding can carry because it records observed exploitation rather than predicted exploitation. KEV status is recorded as a boolean, the date the CVE was added to KEV, the BOD 22-01 remediation deadline if applicable, and the catalog vendor and product fields so the audit trail reads as a fact rather than as a claim.

The Common Weakness Enumeration category the finding maps to. CWE classification feeds clustering across findings, secure-code training content, framework control mapping (OWASP Top 10, OWASP ASVS, NIST SP 800-53 SI controls, ISO 27001 Annex A 8.28), and the root-cause view leadership reads when asked which weakness families dominate the backlog. CWE is captured at intake against the 300+ remediation templates and at import against the source tool mapping.

The vendor PSIRT bulletin, the official patch reference, the workaround instruction, the vendor severity rating, and the fixed-in version. The vendor reference is what the remediation owner reads when deciding whether to upgrade, patch, or apply the workaround, and what the audit reads when asking how the team verified the upstream advice. Generic claims that "the vendor recommends an upgrade" without naming the bulletin are the most common path from a defensible remediation to a finding the audit cannot defend.

The scanner output lands with a severity and the workflow stops at intake. Six months later the team is sorting the backlog by a CVSS number that bears no relationship to the CVE, the KEV catalog, the EPSS percentile, or the vendor advice. The fix is making CVE capture and upstream enrichment a queue-entry signal so every finding lands with the full set of external references the priority decision actually needs.

A team integrates an EPSS pull at the moment of intake and then forgets to schedule the refresh. EPSS is updated daily and a stale percentile from three months ago can be wrong by tens of points. The fix is recording the EPSS refresh cadence on the engagement and scheduling a recurring reconciliation job so the live value on the finding reflects the live FIRST feed rather than the snapshot.

The team checks KEV only when a scan produces a new finding. A non-KEV finding from yesterday becomes a KEV finding tomorrow when CISA updates the catalog, and the queue keeps reading the stale tag. The fix is running KEV reconciliation on a separate cadence keyed off the catalog refresh rather than off the scan cycle, so catalog-side additions promote existing findings without waiting for the next scan.

Custom application findings, configuration findings, weak header findings, and most pentest writeups do not carry a CVE. The pipeline treats the absence as a no-op and these findings end up in the queue without any external enrichment. The fix is making the no-CVE state explicit, recording why the CVE is not applicable, and enriching against CWE, OWASP, and asset context so the queue ordering is still defensible.

A single finding can reference multiple CVEs (a vulnerable dependency where several versions share a chain of CVEs, a misconfiguration that maps to multiple advisories). The pipeline reads only the first identifier and the rest are lost. The fix is recording every CVE on the finding, taking the highest EPSS percentile across the list as the priority signal, and citing the source CVE explicitly so the rationale is reproducible.

A standalone risk-based vulnerability management analytics layer sits on top of the scanner data and produces a prioritised list in a dashboard. The remediation team works from a different system that does not see the enrichment, so the queue ordering and the dashboard ordering drift apart within a quarter. The fix is making CVE, CVSS, EPSS, KEV, CWE, and vendor references first-class fields on the finding record so the same trail the queue runs on is the trail the audit reads.

Whether the workflow accepts findings without a CVE identifier, and what the explicit treatment is for findings that cannot carry a CVE. The policy lists the source classes where CVE is mandatory (external scanning, code scanning SCA, bulk import from CVE-keyed tools) and the source classes where CVE is optional but the no-CVE state is recorded explicitly (manual pentest, configuration review, custom application logic).

How often the platform refreshes EPSS percentile and probability against the live finding inventory. EPSS is updated daily by FIRST; a defensible policy reconciles at least weekly, more often for tier-zero assets and KEV-listed findings. The cadence is recorded on the engagement so the audit verifies the priority decision was based on a current value rather than a months-old snapshot.

The triggers that re-run KEV reconciliation against the open queue. Standard triggers are the daily catalog refresh, every new finding at intake, and any explicit operator request. The policy lists the trigger ladder so the audit can verify the queue is reading a current KEV state rather than the state at the moment of the last scan.

The named vendor PSIRT feeds the workspace tracks (Microsoft Security Update Guide, Oracle Critical Patch Updates, Cisco PSIRT, Red Hat Security Advisories, Atlassian Security Advisories, and others relevant to the deployed estate). The list is part of the engagement record so the audit can verify the programme is reading the advisory landscape that matches the technology footprint.

The rule for when the workspace-calibrated CVSS overrides the source-tool severity and when the conflict is escalated to an enrichment-conflict triage. Common patterns are: workspace overrides for environmental adjustments, source severity preserved as a comparison field, conflicts above a delta threshold (say, two severity bands) trigger explicit calibration. The rule lives on the engagement record so the decision is reproducible.

The events that force a finding back through the enrichment pipeline: a new EPSS percentile crossing a policy threshold, a new KEV listing for the underlying CVE, a new vendor advisory updating the recommended fix, a CVE being assigned to an existing custom finding after public disclosure. Trigger-driven re-enrichment keeps the queue accurate between scheduled reviews rather than waiting for the next cycle.

Enrichment depends on vulnerability finding intake landing a CVE identifier and the source-tool severity on the record, on bulk finding import preserving the original tool metadata, on scanner result triage validating false positives before enrichment effort is spent, and on threat intelligence driven prioritisation ingesting structured CTI signals (KEV additions, EPSS shifts, CERT advisories, vendor PSIRT bulletins) alongside the enrichment values.

The enriched record feeds vulnerability prioritisation because the priority logic reads CVE, EPSS, KEV, and CWE as inputs. It feeds vulnerability SLA management because KEV listing and EPSS uplift modify the SLA tier. It feeds vulnerability acceptance and exception management because residual risk decisions cite the enriched values. AI report generation produces the leadership and audit narratives from the same enriched record.

Every CVE-bearing finding carries CVE, CVSS calibration, EPSS, KEV status, CWE, and vendor advisory references on its own record. The priority decision is not an output of a separate analytics tool; it is a property of the finding the queue inherits at all times.

The EPSS and KEV refresh cadence is recorded on the engagement, the last reconciliation timestamp lands on the finding, and the stale-enrichment queue surfaces records that need a re-pull. Nobody assumes the values are current; the workflow proves they are.

Source severity and workspace severity sit side by side on the record. Disagreements land on the enrichment-conflict queue with an explicit calibration decision, the prior severity, the calibrated severity, and the rationale. The audit reads the calibration as deliberate rather than as a quiet overwrite.

The KEV coverage view, the EPSS top-percentile view, the stale-enrichment queue, the enrichment-conflict queue, the CWE distribution view, and the activity log export all derive from the live record. Nobody assembles the enrichment evidence at the end of the quarter from a spreadsheet; the activity log is the trail and the AI report is the narrative.