How should you respond to a newly disclosed vulnerability?

When a new vulnerability is disclosed, answer three questions in order: do we run the affected software, is it being exploited, and can an attacker reach it in our setup. Those answers set the speed of your response. A severity score alone should not decide it.

What is the first hour for?

Scoping. You are not fixing anything yet. You are finding out whether you are in the blast radius.

Pull the affected product and version range from the vendor advisory or the CVE record. Search your software inventory for that product, including images, containers, transitive libraries and vendor appliances. If you have no inventory, this is the hour you learn the cost of that. NIST SP 800-40 Rev. 4 frames enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, and the first of those verbs depends on knowing what you have.

How do you tell if it is urgent?

Look for evidence of exploitation first. CISA maintains a Known Exploited Vulnerabilities (KEV) catalog. Under Binding Operational Directive 22-01, US federal agencies must remediate catalog entries within the timeframe CISA sets in the catalog. Private organizations are not bound by the directive, but many use the catalog as a priority list, since a listing means exploitation has been observed.

Next, look at likelihood. FIRST publishes the Exploit Prediction Scoring System (EPSS), which estimates the probability that a vulnerability will be exploited. It complements CVSS, which describes severity if exploited, not how likely that is.

Then ask about reach, which is local to you. Is the vulnerable component internet-facing? Is the vulnerable function actually called by your code? A flaw in a library function you never invoke is real but lower priority than the same flaw on an exposed edge service.

What does this look like in a constructed case?

A new flaw is announced in a popular image-processing library. A scan shows it is in 14 services. Three are public APIs that accept uploads and call the affected function. Eleven include the library as a dependency of a build tool and never call it at run time.

The response: patch or mitigate the three public services the same day, schedule the other eleven with normal dependency updates, and write down why. The reasoning is the artifact an auditor or customer will ask for later.

How to check or apply this

1. Confirm the advisory is real and read the affected versions. Use the vendor or CVE record, not a social media summary.
2. Search inventory for the component, direct and transitive, in code, containers and appliances.
3. Check KEV and exploitation reports. If it is listed, treat it as urgent.
4. Check EPSS and the CVSS vector for how it is reached: network, local, authentication needed.
5. Decide per asset: patch now, mitigate (disable the feature, restrict access, add a filter), or schedule.
6. Apply the fix or mitigation, then verify by rescanning, not by assuming the change took.
7. Record the decision, the owner and the date. Review mitigations when the real patch ships.
8. Watch for follow-ups. Initial advisories are often corrected, and bypasses of first patches appear.

Where does Safeguard fit?

Safeguard's dependency scanning and reachability analysis help with steps two and four: they find affected packages and show whether your code calls the vulnerable path. Autonomous remediation can open fix pull requests, and that is off by default. You still make the call on what ships.

What if no patch exists yet?

Mitigate. Restrict network access to the affected service, disable the vulnerable feature, put a filter in front of it, and raise monitoring on that asset. Set a review date so a temporary measure does not become permanent.

Quick check

Sources

• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 22-01
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• FIRST: Exploit Prediction Scoring System (EPSS)

Last reviewed: 18 October 2026.