NuGet Audit: Deciding Build Policy for Vulnerability Warnings

Question

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.

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

Tasadduq Burney · Answer

Answer the three questions directly Criteria for treating audit warnings as errors: Treat a warning as an error only when the vulnerability has a known fix, the warning severity meets or exceeds a chosen threshold (e.g., moderate), and the feed providing the advisory data is reliable. If any of these conditions is missing, keep the warning as a non‑fatal MSBuild warning to avoid breaking builds on incomplete data. Filtering or deduplicating transitive warnings: Limit analysis to direct dependencies by setting NuGetAuditMode=DirectOnly. For remaining direct‑dependency warnings, suppress specific low‑risk codes with NU1901;NU1904 and collect all warnings in a SARIF log (GenerateSarifOutput=true) for external deduplication and trend analysis. Alerting location: Keep NuGet Audit enabled locally for immediate feedback, but route the SARIF output to a pipeline step that uploads it to a code‑scanning tool (e.g., GitHub CodeQL, Azure DevOps Security). This provides centralized, deduplicated alerts without altering NuGet’s native behavior. Likely explanation vs. confirmed facts Likely explanation: Teams see noisy audit output because NuGet reports every known vulnerability as a warning, and there is no built‑in per‑warning override or deduplication. The default “fail‑open” behavior means a missing advisory feed only yields an informational warning, so silence does not guarantee safety. Confirmed facts (based on NuGet behavior): NuGetAuditLevel controls the minimum severity that produces a warning (values: none, low, moderate, high, critical). NuGetAuditMode can be set to All (default) or DirectOnly to limit analysis to directly referenced packages. MSBuild treats each audit finding as a warning with codes NU1901‑NU1904; there is no native way to convert only a subset of those warnings to errors. Setting TreatWarningsAsErrors=true converts **all** warnings (including audit) to errors, which often increases disruption. NuGet can emit SARIF logs when GenerateSarifOutput=true is present, enabling external aggregation and deduplication. Steps needed for this case Add a Directory.Build.props file (or modify the existing one) with the following properties: moderate DirectOnly true true In your CI pipeline, after the dotnet restore step, run: dotnet nuget locals all --clear # The SARIF file is written to the output directory, e.g., **/NuGetAudit.sarif** # Upload it to your code‑scanning tool: # gh codeql sarif upload -s NuGetAudit.sarif -r ${{ github.repository }} # or az devops security codeqa upload --sarif NuGetAudit.sarif Optionally, suppress known low‑risk transitive warnings that you have reviewed and accepted: NU1901;NU1902 Missing diagnostic detail If your internal or private feeds do **not** expose vulnerability advisories, the audit may produce no warnings even when a vulnerable package is present. Before finalizing the policy, confirm whether the feeds used in your build provide advisory data for the packages you consume.

NuGet Audit: Deciding Build Policy for Vulnerability Warnings

1 answer

Answer the three questions directly

Likely explanation vs. confirmed facts

Steps needed for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments