Read the maintainer's reasoning and test it against how you use the package. If it holds for your configuration, record that and close the finding with an accurate status. If it does not, say why in the issue and decide your own mitigation. A rejection is input, not a ruling on your risk.
Why the answer can differ
A maintainer assesses a library in general. You run it in a specific setting. Both can be right. A maintainer might say an issue needs an attacker to control a configuration file, which they consider out of scope. In your environment that file might be user supplied.
The reverse is also common. A scanner flags a record that the maintainer considers wrong, perhaps because the vulnerable code is not in the shipped artifact. In that case the maintainer is probably right and your finding is a false positive for you.
The CVE programme has a name for records that a supplier disputes. Our explainer on what disputed means on a CVE record shows how it appears in data.
Decision steps
- Quote the maintainer's reasoning in your own words. If you cannot restate it, you have not understood it.
- List the assumptions it relies on, such as "the attacker cannot set this option".
- Check each assumption against your deployment. Is that option reachable from untrusted input?
- Try to reproduce the issue with your real configuration, in a test environment.
- Choose an outcome from the table.
| Outcome | When | What to record |
|---|---|---|
| Accept the maintainer view | All assumptions hold for you | Reasoning, who reviewed, date |
| Mitigate locally | Assumptions fail, no fix coming | The control you added and a review date |
| Replace the package | Risk too high and no fix | Migration ticket and interim control |
| Ask for clarification | Reasoning unclear | Link to the public question |
Using Dependabot statuses honestly
If you use GitHub's alert dismissal, the available reasons include inaccurate, not_used and tolerable_risk. If the alert truly does not apply to you because of how you use the package, not_used or inaccurate fits and a comment should say why. If you are accepting a risk the maintainer does not think exists, that is still your decision and your comment should say it. See our post on choosing a dismissal reason.
How to push back politely
If you believe the maintainer is wrong, ask in public with facts: the version, a minimal reproduction and the impact you see. Avoid disclosing details of your own systems. Many projects have a security policy with a private route for new reports, so use that if the issue could be exploited broadly.
Do not argue on social media. It rarely changes a decision and can expose users before a fix exists.
Keep the evidence
An auditor or customer may later ask why a flagged package stayed. A short note with the maintainer's link, your assumption check and the decision date answers that in one reading.
Where Safeguard fits
Safeguard's reachability analysis gives you evidence about whether a flagged function is called, which helps test a maintainer's claim against your code. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Check how the demo separates a flagged package from an exploitable path.
Quick check
Can the maintainer be right and my scanner still flag it?
Yes. Scanners often match by version without knowing whether the vulnerable code is shipped or reachable.
Should I ignore the finding if the maintainer disagrees?
Only after you check their assumptions against your own use and write the decision down.
Sources
Last reviewed: 19 October 2026.
