Ask five questions in order: do we run the affected product, is it exposed, is it being exploited, is a fix available, and who owns the system. Written down, the answers sort any advisory into act now, schedule or close within about ten minutes.
The five questions
| Step | Question | Where to look |
|---|---|---|
| 1 | Do we run the affected product and version? | Your inventory or SBOM |
| 2 | Is it reachable by an attacker? | Network diagrams, asset exposure, whether the vulnerable feature is on |
| 3 | Is it exploited? | The CISA Known Exploited Vulnerabilities catalog, the vendor advisory |
| 4 | Is there a fix or a mitigation? | The vendor advisory, distribution notice or Security Tracker |
| 5 | Who owns it and when is their next window? | Your service catalog |
Each question can end the process. If the answer to question one is no, stop and write down why.
Step by step
- Read the headline and affected versions only. Do not read the whole advisory yet.
- Search your inventory. If you have no inventory, say so in the ticket, because that gap is the finding.
- Check exposure. A kernel or shared library may matter on every host, while a daemon matters only where it runs.
- Check the KEV catalog. CISA adds an entry only with a CVE ID, reliable evidence of active exploitation and clear remediation guidance, so a match is a strong signal.
- Find the fix in the vendor's own wording. For Debian or Red Hat packages, a fixed package version is the vendor's string, not the upstream number, because both backport fixes.
- Assign an owner and a date. A ticket with no date is a wish.
The outcomes
- Act now: present, exposed, exploited or no safe wait. Notify the owner and decision makers. Pilot the fix the same day.
- Schedule: present, a fix exists, no exploitation evidence. Add to the next change window and set a due date.
- Mitigate: present, no fix yet. Apply the vendor's workaround or reduce exposure, and recheck daily.
- Close with a note: not present, or not reachable. Record the check and the date.
Keep a paper trail
For each advisory, store the advisory link, the date, who decided, the answers to the five questions and the next review date. Auditors and customers ask for this. It is also how a new teammate learns your reasoning.
Common mistakes
- Reading the severity first. Severity is useful, but it comes after presence and exposure.
- Treating a scanner hit as proof. Verify against vendor data.
- Forgetting revisions. Advisories change after release. Oracle's own page shows revision numbers on its updates, and GitHub says it does not notify when vulnerabilities are updated, so set a recheck date on anything open.
See also our guide on the first hour after security news.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how checking whether code is reachable removes findings from the pile, which is question two in action.
Safeguard offers SBOM and dependency scanning plus reachability analysis, which help answer questions one and two quickly. Try a free scan.
Quick check
Should I read the severity score first?
Start with whether you run the product and whether it is exposed. Severity helps rank items that pass those checks.
What if I have no inventory?
Record that in the ticket and begin one. Without it, step one takes hours instead of minutes.
Sources
- CISA, Known Exploited Vulnerabilities
- Debian, Security FAQ
- Red Hat, Backporting security fixes
- Oracle, Security Alerts and Critical Patch Updates
- GitHub Docs, Configuring notifications for Dependabot alerts
Last reviewed: 19 October 2026.
