Read an alert in five checks: which package and version, which version fixes it, whether it is exploited in the wild, whether your code reaches the vulnerable function, and whether it ships to customers. Then pick fix, defer or dismiss and write one sentence of reason.
Minute one: what and where
Note the package name, your installed version, and whether it is a direct or indirect dependency. If indirect, find the path that pulls it in. GitHub's documentation says the dependency graph can show the transitive path for a dependency, which tells you which top level package to upgrade.
Minute two: the fixed version
Find the first version that fixes the problem. If the fix needs a major version jump, note that the upgrade may need real testing. If no fixed version exists, note that now, because your options change to mitigation or replacement.
Minute three: exploitation evidence
Check whether the CVE is on the CISA exploited catalog. CISA strongly recommends that all organizations prioritize remediation of listed vulnerabilities, so a match changes the urgency.
If it is not listed, look at its EPSS score. FIRST describes EPSS as a daily estimate between 0 and 1 of the probability a CVE will be exploited in the next 30 days. A high value is a reason to hurry. A low value is not a reason to ignore it.
Minute four: reachability
Ask whether your code calls the vulnerable function, or whether the vulnerable setting is on. Read the advisory text for the affected function, then search your code, or use reachability analysis to check the call graph. If the package is only in a test dependency, say so.
Minute five: decide
| Evidence | Decision |
|---|---|
| Exploited, shipped, reachable | Fix now |
| Reachable, not exploited, fix exists | Fix this month |
| Not reachable, fix exists | Fix in routine update |
| Not reachable, no fix | Defer, review in 30 days |
| Not in shipped code | Dismiss with reason |
Write the reason
One sentence is enough. For example: Not reachable, the vulnerable parser is never called, reviewed on the nineteenth. That sentence is what stops the same alert being re debated next month and what you show a reviewer.
What can mislead you
- A severity score alone. Severity measures potential impact, not likelihood or your exposure.
- A fixed version that is not yet released for your ecosystem. Check availability.
- An indirect dependency you cannot upgrade directly. Look for a parent update.
- A scanner that matches on name only. Check the advisory's affected range.
When to stop and ask
If you cannot decide in five minutes, mark it fix this month and ask the owner. Do not leave it undecided. For the batch version of this method, see triage your first scan in an afternoon.
Safeguard shows exploitability and reachability alongside each finding. A free scan at https://gold.safeguard.sh/scan lets you try the five minutes on your own alerts.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What if the alert is in a dependency of a dependency?
Find which top level package pulls it in and check whether a newer version of that package fixes it.
Is a high EPSS score enough to fix now?
It is a strong reason to prioritize, but check reachability first. A high score on code you never call is lower urgency than an exploited, reachable issue.
Sources
- GitHub Docs, Dependency graph
- CISA, Known Exploited Vulnerabilities
- FIRST, Exploit Prediction Scoring System
Last reviewed: 19 October 2026.
