Ignore an advisory once you have confirmed it does not apply to how you use the package. Scope the suppression to that one advisory, write down why, name an owner and set a review date. Avoid blanket rules that hide whole severity bands, because they also hide the next real finding.
Definitions
Suppression. A recorded rule that removes a finding from reports.
Exception. A time limited acceptance of a finding you cannot fix yet.
False positive. A finding that does not apply, for example a wrong product match.
How the tools let you do it
| Tool | Mechanism | Scope |
|---|---|---|
| NuGet audit | NuGetAuditSuppress item with the advisory URL | One advisory, across packages that share it |
| pnpm audit | Ignore option by GHSA, or audit ignore in the workspace file | One advisory |
| yarn npm audit | Ignore option or the npmAuditIgnoreAdvisories setting | One advisory |
| Dependency-Check | Suppression XML files, local or by URL | Rules you define |
| composer audit | Ignore severity option | A severity band |
Microsoft notes that NuGet suppression hides the advisory completely, even for other packages that share it, and calls it a last resort. The composer severity option is broad by design, so be careful with it.
Steps
- Read the advisory. Identify the affected function, configuration or platform.
- Confirm your usage. Check call sites, config and runtime.
- Choose the narrowest rule that works. Prefer one advisory over a severity band.
- Write the entry with four fields: advisory id, reason, owner, review date.
- Commit the rule file, so changes go through review.
- Re-check at the review date, and on any major change to how the package is used.
- Remove the rule once the package is upgraded.
A simple record format
| Field | Example content |
|---|---|
| Advisory | GHSA identifier |
| Package and version | name and resolved version |
| Reason | The vulnerable feature is not enabled |
| Evidence | Link to config or code search |
| Owner | Named person |
| Review by | A date |
What not to do
- Suppress by severity because the list feels long.
- Leave entries without an owner.
- Keep a rule after the package changed.
- Treat a clean report as proof, when it may just be hiding items.
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the check and note what evidence would justify ignoring a finding.
Quick check
Is it fine to ignore low severity findings?
With a reason. Severity is one signal. Reachability and exposure matter too.
Who should approve a suppression?
The owner of the system, with security informed. Record the name and date.
Safeguard policies and gates let you set rules by severity and reachability, and every decision stays on record. A free scan shows how that looks.
Sources
- Microsoft Learn, Auditing package dependencies
- pnpm docs, pnpm audit
- Yarn docs, yarn npm audit
- Composer documentation, audit
- OWASP Dependency-Check CLI arguments
Last reviewed: 19 October 2026.
