Fix first the vulnerabilities that are reachable in your code, sit in internet facing parts of your app, and have a patched version available. Defer dev only packages and flaws your code never calls. A short, ordered list that gets done beats a long one that does not.
Why order matters
A volunteer team has a few hours a month. A scan might return dozens of findings, most of them in indirect dependencies nobody chose. Treating them all as urgent leads to burnout, then to ignoring the list.
The goal is to cut real risk per hour of effort.
Four questions
- Is it reachable? Does your application actually call the vulnerable code path? Reachability analysis answers this. A flaw in a function you never use is a lower priority than one on a route every visitor hits.
- Is it exposed? Is the package part of the public website or API, or a build tool that only runs on a laptop?
- Is a fix available? If a patched version exists, the work is an upgrade. If not, look for a workaround or a replacement.
- How bad is it? Use the advisory's severity as one input, not the only one.
A simple triage table
| Reachable | Exposed | Fix available | Action |
|---|---|---|---|
| Yes | Yes | Yes | Do this week |
| Yes | Yes | No | Mitigate, watch for a patch |
| Yes | No | Yes | Do this month |
| No | Yes | Yes | Schedule with routine upgrades |
| No | No | Any | Note and review later |
Work in small batches
Pick the top three items for the month. Upgrade one at a time, run your tests and click through the site. If you have no tests, write one for the most important path first, such as the donation form.
Keep a log of what you fixed and what you deferred, with a reason and a review date. That record helps new volunteers and answers funders who ask how you manage vulnerabilities.
Handle the ones you cannot fix
Sometimes a library has no patch, or an upgrade breaks things. Options include removing the feature, replacing the library, limiting access to the vulnerable component, or accepting the risk for a defined time. Write down who accepted it and when it will be reviewed.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop out of the urgent list once reachability is considered.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is available but off by default, and every category starts on Manual, so a person approves each change. For setting up alerts on GitHub, see turning on dependency alerts for a volunteer repo.
Quick check
Should we ignore low severity findings?
Not forever. Defer them, record the decision and revisit at your next routine upgrade.
What if we cannot tell if a flaw is reachable?
Treat it as reachable if the package handles input from outside, and upgrade when a safe version exists.
Last reviewed: 19 October 2026.
