A solo developer can defer findings that sit in development-only dependencies, in code your application never calls, or in features you have switched off, provided nothing on the exploited-in-the-wild list is involved and each deferral is written down with a date. Ignoring without a note is neglect.
Why ignoring is a skill, not a failure
Scanners report everything that matches an advisory. They cannot know how your application uses a package. If you treat every line as equal, you will burn out before you reach the item that matters. The aim is to spend your limited hours on the findings that could hurt you.
Four categories you can usually defer
| Category | Why it can wait | What to record |
|---|---|---|
| Development-only dependency | It is not installed in production | Package, advisory ID, "dev scope" |
| Unreachable code path | Your code never calls the vulnerable function | The reason you believe that |
| Disabled or unused feature | The affected component is off | The config that turns it off |
| No fix exists yet | You cannot upgrade today | Revisit date and any mitigation |
GitHub treats the first case as a built-in idea. Its auto-triage presets include "Dismiss low impact issues for development-scoped dependencies", which is on by default for public repositories and can be enabled for private ones. You can also filter alerts with scope:development to see them together.
npm lets you leave dev dependencies out of an audit with the omit=dev option, which also removes them from the payload sent for the audit.
Four things you should not ignore
- Anything that appears in the CISA Known Exploited Vulnerabilities catalog and affects a package you run.
- Anything in a component that handles untrusted input from the internet, such as a web framework or an image parser.
- Leaked credentials. Rotate them. Do not file them away.
- Findings you do not understand yet. "I do not know" is a reason to look, not to dismiss.
A caution about dev dependencies
Dev-only does not always mean harmless. Build tools run on your machine and in your CI with access to tokens and source code. A malicious or compromised build-time package can do real damage even though it never ships. So deferral is fine for a low-impact advisory in a dev tool, and not fine for anything suggesting malware or code execution in a tool you run with secrets.
Write the deferral down
Use the dismissal reason and comment field in your alert tool, or one line in a notes file: package, advisory, reason, revisit date. Review the list when you do your weekly routine. Dismissals that are never reviewed turn into blind spots.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Can I ignore every low severity finding?
Not automatically. Severity is one input. A low score in an internet-facing parser can matter more than a high score in a dev tool. Check exploitation status and exposure first.
How long should a deferral last?
Pick a short window such as four weeks, then re-check. Facts change when a fix ships or exploitation starts.
Safeguard reachability analysis is built for this question, showing whether vulnerable code is actually called, and a free scan is available at gold.safeguard.sh/scan.
Sources
- GitHub Docs, about Dependabot auto-triage rules
- GitHub Docs, viewing and updating Dependabot alerts
- npm Docs, npm audit
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
