Vulnerability management

Verify that the deployed build is affected

Record the component, deployed version, configuration and authoritative advisory. Check package provenance as well. A vendor may have backported a fix without changing to the upstream version number, so the banner alone is not sufficient evidence that the software is unpatched.

Connect the result to an asset owner, exposure path and business dependency. If ownership or reachability is still unknown, keep it as unresolved work. An inconclusive scan does not mean the finding has been demonstrated not to apply.

The same library can require different priorities

In this fictional example, a public request-processing service and an isolated test tool use the same vulnerable library. The service sends untrusted input through the affected function. The test tool’s configuration does not use that function. The team prioritizes the public path and records the evidence behind both decisions.

Now suppose an authoritative advisory reports exploitation of the vulnerability. A dated EPSS snapshot shows probability 0.02 and percentile 0.90. These are invented values: a 2% forecast probability and the 90th percentile, not a 90% probability of compromise. The public service is confirmed affected and reachable, so the team acts despite the low forecast. It retains the advisory and schedules a retest. The advisory does not establish that this service was compromised; that would require local evidence.

If a patch is not ready, a temporary control may reduce exposure. Check that it interrupts the relevant path and give it an owner and expiry. Keep the status accurate: the control limits access to the software, but it has not patched the software.

Keep exploitation evidence separate from the forecast

A known-exploited catalog records exploitation in the wild. It does not determine whether this deployment is affected or compromised. Save the source, date checked and advisory details. The catalog’s inclusion date is not the date exploitation first occurred. If an entry is absent, record that it was not listed in the checked snapshot; do not turn that absence into evidence that no exploitation occurred.

EPSS forecasts observed exploitation activity in the wild over the next 30 days. Its probability estimates likelihood, while its percentile ranks the vulnerability among those scored. Record both with the score date. Keep an unavailable value distinct from zero. The forecast does not evaluate the exposure, consequences or controls of this particular deployment.

References: CISA Known Exploited Vulnerabilities Catalog: official data mirror, FIRST: EPSS Frequently Asked Questions.

Confirm that the fix is actually running

After the change, verify the deployed artifact or package and repeat the original safe test or inspection. Include dependent nodes, containers and replicas. A successful update on one instance does not establish that the remaining instances stopped running the old version.

If restarts or a phased rollout remain outstanding, keep the finding open for that population. Record failures and exceptions separately rather than averaging them into a successful deployment percentage. Test essential business behavior as well, so the remediation can remain in place.

Check what a lower finding count means

Measure time to assign an owner, time exposed after a verified finding, overdue exceptions and repeated defect classes. Explain the denominator and exclusions. A declining scanner count could mean remediation, asset retirement, a change in scan scope or lost coverage. Investigate which explanation applies before treating the count as improvement.