Prioritize a KEV match with local deployment evidence
Connect a CISA known-exploitation record to the exact advisory and deployed component. Record exposure, uncertainty, mitigation, and accountable remediation.
A Known Exploited Vulnerabilities match is a reason to accelerate triage, not evidence that your application has been compromised. Match the catalog identifier to the advisory, then match the advisory to a deployed component. Keep those steps distinct so a broad product-name match does not become an unsupported incident claim.
CISA publishes an official KEV data mirror. Use a dated catalog copy and preserve the exact entry used in the decision. This guide defines an internal triage card; it does not interpret contractual or regulatory deadlines.
Build the matching evidence chain
Start with the release inventory and current deployment identity. Check package ecosystem, affected versions, and any vendor-specific patches before deciding which services need action.
| Triage field | Required evidence | Do not infer |
|---|---|---|
| Catalog match | Exact vulnerability identifier and catalog date | A similar product name is enough |
| Component match | Installed version and advisory range | Every release contains the affected code |
| Deployment | Running artifact and service owner | A source repository is production inventory |
| Exposure | Relevant entry point and configuration | Internet exposure is the only possible path |
| Action | Fix, mitigation, owner, and decision time | A catalog entry proves local compromise |
If the inventory is incomplete, make resolving that gap an urgent task rather than labeling the service unaffected.
Choose the immediate defensive action
Review the maintainer's corrective release and mitigation advice. Determine whether disabling a feature or restricting access can reduce exposure while a verified upgrade is prepared. Record the effect and limits of any temporary control.
Do not run an exploit against an external service to confirm a catalog match. Use code, configuration, version evidence, and approved test fixtures. If local signs of compromise exist, handle them through the organization's incident process rather than treating the dependency ticket as a complete investigation.
Close with deployed evidence
After remediation, verify the artifact actually running on each affected service. A merged lockfile update does not prove that an old container or background worker was replaced. Check remaining duplicate package occurrences and retained release versions.
Save the catalog date, advisory reference, deployed versions before and after, and any unresolved exposure. Recheck temporary mitigations on their expiry date. The decision should explain why action was prioritized and what changed locally, without converting a known-exploitation signal into an invented customer finding or a guarantee that the rest of the service is unaffected.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.
Sources
- CISA: Official KEV data mirrorAccessed