Triage False-Positive Dependency Alerts

A dependency alert can be wrong for the artifact you deploy, but a matching package name is not enough to decide either way. The advisory may refer to another ecosystem, an affected version range, a different distribution, or a code path that is not present. OSV data can help identify affected versions. OWASP recommends dependency inventory and assessment. Use both to build a documented applicability decision.

Applicability matrix

Compare normalized package identity and exact resolved version to the advisory. Do not use a manifest range when the lockfile pins a different release. Check whether the package is present in the deployed artifact; a development-only dependency may still affect the build pipeline even if absent from production. If several copies are installed, examine each one.

Close only with evidence

For a claimed false positive, record the decisive mismatch: wrong ecosystem, version outside the affected range, package not in the relevant artifact, or a documented condition that cannot occur. A test for an unreachable code path should use an owned environment and should state its limits. If applicability is uncertain, leave the alert open for investigation rather than force a binary closure.

Keep the advisory ID, source date, artifact digest, dependency path, test result, reviewer, and recheck trigger. New deployments or advisory updates can invalidate an old decision. If the alert is valid but temporarily accepted, use a time-limited risk exception instead of the false-positive label. That distinction keeps dashboards honest and gives responders a useful history when the same package appears again. Reopen the decision if the advisory expands its affected range or the application changes its dependency graph.