CVSS, EPSS, and KEV: build a vulnerability decision record
Four fictional findings show how to record a remediation decision without treating a severity score or exploitation forecast as the whole answer.
AI-assisted article. Sources and examples follow our editorial policy.
A remediation ticket should explain why the team chose its action. A severity label alone leaves too much for the next person to reconstruct. They still need to know whether the product is present, whether the affected feature is exposed, what evidence supports the assessment, and who will revisit it.
CVSS, EPSS, and the Known Exploited Vulnerabilities (KEV) catalog contribute different information to prioritization. A useful decision record keeps those inputs separate, then connects them to the actual system. This article develops a worksheet using fictional findings. The examples demonstrate reasoning and documentation; they are not recommendations for any real vulnerability or organization.
Give each signal its own field
FIRST’s CVSS FAQ describes CVSS as a technical severity assessment and explains why complementary prioritization methods remain useful. Record the score, version, vector, and scoring source together. A number without those details is difficult to compare or explain.
EPSS estimates the probability that a published vulnerability will be exploited in the wild during the next 30 days. Its percentile describes relative position among scored vulnerabilities. Neither value describes the probability of compromise for a particular server. FIRST’s EPSS FAQ explicitly separates that forecast from an organization’s environment and consequences.
CISA’s KEV catalog records vulnerabilities with evidence of exploitation in the wild. Its purpose is described in CISA’s catalog announcement. Record the relevant entry and its dates when you use it. An absence from the catalog is not evidence that exploitation cannot occur.
These distinctions should remain visible in a product interface or customer-facing report. A single proprietary priority can be useful for sorting, but the reader needs access to the evidence behind it.
Start with a record someone else can inspect
The following worksheet is an editorial and operational suggestion. Its fields are deliberately more specific than “risk accepted.” Adapt ownership and review timing to your process.
| Field | What to record | Question it answers |
|---|---|---|
| Finding and artifact | Vulnerability identifier, product version, deployed artifact | What exactly are we assessing? |
| Severity | Score, vector, version, source | What technical impact was assessed? |
| Exploitation evidence | Forecast with date, catalog evidence, other supported observations | What do we know about exploitation? |
| Local exposure | Entry point, affected feature, access prerequisites | How could this apply here? |
| Consequence | Data, service, or dependency that could be affected | Why does this system matter? |
| Decision | Action, accountable owner, target date | What will happen next? |
| Reconsideration | New evidence or change that reopens the decision | When does the reasoning expire? |
Keep evidence references close to the fields they support. A link to a scanner report should identify its run or snapshot. An assertion about a disabled feature should reference the configuration reviewed. A reviewer should be able to tell which statements are observations and which remain assumptions.
Work through four fictional findings
Assume a small software company is reviewing four findings. The labels below do not represent actual CVEs. No numerical score is needed to demonstrate the decisions.
| Finding | Evidence available | Example decision | Reconsideration trigger |
|---|---|---|---|
| Public gateway | Affected release confirmed; relevant feature exposed; exploitation documented by a trusted source | Incident-response owner assesses exposure and applies the vendor’s supported remediation | New compromise evidence or changed vendor instructions |
| Internal build tool | Severe potential impact; current forecast comparatively low; tool processes untrusted contributions | Engineering owner investigates the contribution path and plans remediation | Evidence of exploitation or a change in who can submit jobs |
| Retired service | Scanner still reports the host; deployment inventory says it was removed | Infrastructure owner resolves the inventory conflict before closing the finding | Any running instance or unresolved ownership record |
| Optional parser | Component present; team believes affected parser is disabled; supporting evidence incomplete | Product owner verifies the build and configuration; finding remains unresolved | Verification result or a new deployment configuration |
The internal build tool deserves attention because its inputs matter. Calling it internal does not explain which users or external contributions reach it. The low forecast is a dated observation, not a substitute for examining that path.
The retired service illustrates a different problem. A score cannot resolve conflicting inventory. Closing the ticket requires evidence about the asset, followed by correction of the system that produced the stale result.
For the parser, “we do not use it” is only a starting hypothesis. The reviewer needs enough information to connect the product build to the affected code and relevant execution paths. The existing SBOM guide explains the inventory side of that work.
Make an exception readable
A temporary exception should preserve the action being deferred and the reason. Consider this fictional entry:
The gateway owner will apply the supported update during the approved maintenance window. Until then, operations will maintain the documented access restriction and verify it after configuration changes. The exception expires at the scheduled change review. Any evidence of exploitation involving this deployment triggers an immediate incident assessment.
This example still requires real evidence before use. The restriction must exist, somebody must verify it, and the maintenance window must be approved. The wording cannot make those conditions true.
Separate an operational constraint from a technical conclusion. “The update needs a maintenance window” explains scheduling. It does not establish that the system is unaffected. Similarly, a compensating control needs an owner and a known scope before it can support a decision.
Preserve uncertainty through handoffs
When an analyst hands a finding to engineering, the ticket should distinguish confirmed facts from questions. A short section headed “Still to verify” is often enough: whether the vulnerable component ships in the current artifact, whether an endpoint reaches it, or whether an emergency change has already been applied.
Set a next action for each unresolved question. “Investigate” leaves the recipient to discover the missing information. “Confirm whether the production image includes the parser and attach the artifact digest” gives them a bounded task.
The open-source security overview provides broader context for dependency decisions. For publication, use the same discipline: preserve the source date and environmental assumptions when turning an internal assessment into an article. A technical content review should check those claims against the evidence before the prose is approved.
At the next review, retain the previous decision and append the new evidence. That history explains whether the system changed, the assessment improved, or the original assumption was wrong.