NuGet Audit: Deciding Build Policy for Vulnerability Warnings

NuGet Audit runs during restore and reports known‑vulnerability findings as MSBuild warnings (NU1901–NU1904). Teams want to reduce notification noise while still ensuring critical issues surface. The default behavior is fail‑open: when a feed cannot provide advisory data, the restore emits an informational warning instead of failing, so silence does not guarantee safety.

NuGet offers no per‑warning override or deduplication. Tunable aspects are NuGetAuditLevel (minimum severity) and NuGetAuditMode (all or direct dependencies). A global TreatWarningsAsErrors converts every audit warning into a build failure, often increasing disruption rather than reducing noise. Private feeds may not expose vulnerability data, so audit coverage can vary, complicating alert policy.

The unresolved decision is how to structure alert ownership and build policy. Teams must choose whether to treat all audit warnings as errors, selectively filter transitive findings, or rely on external pipeline notifications. Without native deduplication or per‑warning control, trade‑offs between noise reduction and security visibility remain unclear.

1. What criteria should guide whether audit warnings are treated as errors in CI pipelines?
2. How can teams effectively filter or deduplicate transitive vulnerability warnings while retaining critical alerts?
3. Should alerting for NuGet audit warnings be handled entirely by external pipelines, or is there a need to extend NuGet’s native behavior?