Direct-only NuGet audit vs scheduled vulnerability listing for CI noise control

Coverage and Signal Differences

The primary difference between direct-only auditing and scheduled listing is the actionability of the failure. Direct-only auditing identifies vulnerabilities in packages explicitly listed in your project file, meaning the remediation is a simple version bump in the .csproj or packages.config.

Transitive Risk Coverage

• Direct-only Audit: Completely ignores vulnerabilities in transitive dependencies unless they are also explicitly referenced as direct dependencies. If a direct dependency pulls in a vulnerable transitive package, the build will not fail, creating a coverage gap for risks that cannot be fixed without updating the parent package.
• Scheduled Listing: Provides full visibility into the entire dependency graph. It captures newly added transitive risks that a direct audit misses, but because these risks often require an upstream maintainer to release a fix, they frequently generate "noise" in CI.

Maintenance of NuGetAuditSuppressions

In direct mode, NuGetAuditSuppressions maintenance is generally lower-volume but higher-stakes. Since you are only suppressing direct risks, each entry represents a conscious decision to accept a risk for a package you explicitly chose to include. Over time, this maintains a higher signal-to-noise ratio compared to full audits, where suppressions often accumulate for transitive packages that the developer cannot realistically update.

Combining Approaches without Duplication

You can combine both strategies by decoupling Build Enforcement from Security Reporting. This prevents duplicate alerts from blocking the pipeline while ensuring visibility.

1. CI Pipeline (Blocking): Set NuGetAuditMode to direct. This ensures that any new direct vulnerability breaks the build immediately, forcing an actionable fix.
2. Scheduled Job (Non-Blocking): Run a separate, scheduled pipeline (e.g., nightly) using dotnet list package --vulnerable. Pipe this output to a security dashboard or a notification channel rather than failing the build.

Because the CI build only triggers on direct risks and the scheduled job is a reporting mechanism, you avoid "double-failing" a build for the same advisory. The scheduled report serves as the source of truth for transitive risks that require monitoring or upstream pressure.

Verification

To verify the current state of your dependencies and identify the gap between these two methods, run the following command in your project root:

dotnet list package --vulnerable

Compare this full list against the warnings generated during a build with NuGetAuditMode=direct to see exactly which transitive risks are being silenced in your CI pipeline.