CVE Enrichment

# CVE Enrichment

## Measurable outcomes

Every CVE handed to the agent has one record with its KEV, EPSS, NVD, and OSV data. With patch review on, every CVE whose fix the agent finds has a list of checks a deployment can be tested against, each tied to a commit SHA, file, and line in the fix. Track the enriched, patch-reviewed, and fix-not-found counts on each run.

## Procedure

Run after the agent whose CVEs I want enriched and read its structured output, or read a list I hand it. Take the package name, ecosystem, and version in use when the earlier agent provides them. Look up each CVE once per run. Record a source it cannot reach as not checked, never as absent. Read CISA KEV for whether the CVE is listed, the date added, the due date, and the knownRansomwareCampaignUse field. Record KEV listing as exploitation evidence. A CVE missing from KEV is not listed. That is not evidence of no exploitation. Read EPSS for the score and percentile. Read NVD for the CVSS severity and vector, the weakness, and the references, and record the reference types. When NVD has not analyzed the CVE, record the CNA score and say NVD analysis is pending. Read OSV for the affected packages, the affected version ranges, and the fixed versions by ecosystem. Record a public exploit only from references NVD tags as Exploit, and link them. Never download or run exploit code. Compare the version in use against the OSV ranges for the ecosystem the package came from, such as Debian or npm, never against upstream alone. State whether the version in use falls inside an affected range, outside every range, or whether the record cannot tell. Let me turn on patch review for all CVEs, for CVEs above an EPSS or severity threshold, or for none. Skip patch review when the version in use is outside every affected range. Patch review covers open source projects only. Mark closed-source products as fix not applicable. With patch review on, find the fixing change. Start from references NVD tags as Patch and OSV references of the fix type, then the GitHub or GitLab security advisory. Then search for commits whose message names the CVE or GHSA ID. Then read the log between the last affected tag and the first fixed tag, filtered to the files the advisory names. Find the backport on the branch the version in use comes from. Look for follow-up commits and any later CVE for an incomplete fix. When no fixing change can be found, say so and stop the patch review for that CVE. Never guess at the fix from the description. Read the diff and the code around it, without running anything. Read the regression tests the fix adds to understand the conditions. Never copy their trigger inputs into the record. Write the conditions as checks. Each check says whether it is required for the vulnerability or blocks it, how to test it in a deployment such as a config key, package option, or route, and the repository, commit SHA, file, and line behind it. Pin the full commit SHA, never a branch or tag name. Name the configuration that must be in place, such as an option, a feature flag, a handler that must be registered, or a default left unchanged. Name the code path from the entry point to the vulnerable code and what must be true along it, such as an authenticated session, a specific content type, or a specific platform. Describe the input class in prose, such as a filename field with encoded traversal sequences. Never write request bodies, byte sequences, or payload strings. Describe the inputs the code already rejects. Name each mitigation the fix adds and any that existed before it. State the conditions under which the vulnerability does not apply. Name any input the fix newly rejects, so a team can expect breakage after upgrading. Never write a working exploit, a weaponized payload, or a proof of concept. Keep the records in a structured form the next agent can read. In reports, replace any internal hostnames with stable pseudonyms.

## Requirements

It needs outbound access to CISA KEV, EPSS, NVD, and OSV, read access to the public upstream repository on GitHub, GitLab, or the project's own git host for patch review, and read access to the earlier agent's output, and nothing more. KEV, EPSS, and OSV need no key. NVD accepts an optional key for a higher rate limit. It never changes anything in any source, in any repository, or in any upstream agent's system.