Use both, for different jobs. NuGet Audit runs automatically on restore and gives developers and CI an immediate warning. The dotnet list package command with the vulnerable option produces an on demand report, including transitive packages and JSON output, that suits scheduled reviews and evidence.
Side by side
| Question | NuGet Audit | List package, vulnerable |
|---|---|---|
| When does it run? | Every restore | When you run the command |
| Output | Warnings NU1901 to NU1904 in the build log | A report by project and framework |
| Transitive packages | Controlled by NuGetAuditMode | Only with the include transitive option |
| Machine readable | Build log | JSON with the format option |
| Can fail the build | Yes, with WarningsAsErrors | Only if you script it |
| Needs | NuGet 6.8 and the .NET 8 SDK for PackageReference | .NET 5 SDK 5.0.200 and later |
Dates in the right column come from Microsoft's feature availability table. The vulnerable option uses your audit sources from .NET SDK 9.0.300.
What the report is good for
dotnet list package --vulnerable --include-transitive --format json > report.json
Microsoft notes that transitive packages are not included by default, so add the option. The JSON output is useful for storing with a release, diffing week to week, or feeding another tool. The vulnerable option cannot be combined with deprecated or outdated in the same run.
What audit on restore is good for
It catches problems at the moment a developer adds or updates a package, and again on every CI restore. Because it is a warning with a code, you can promote chosen severities to errors and keep the rest advisory.
A setup that uses both
- Enable NuGet Audit at the repository level, with mode set to all.
- In ordinary CI builds, leave audit warnings non blocking.
- In a dedicated audit pipeline, turn NU1903 and NU1904 into errors.
- Schedule the list command nightly with JSON output and store the artifact.
- Review changes in the report, and open tickets for new findings.
- Prove audit ran by comparing audited and project counts in a solution targets file.
Shared limits
Both use advisory data from your audit sources, which for nuget.org comes from the GitHub Advisory Database. Both tell you a known issue exists in a version. Neither tells you whether your code reaches the vulnerable function, nor whether a fix is safe to apply. Also note the metadata lookup caveat for list package: package source mapping does not apply, so package IDs go to every configured source.
Try it yourself
Click through it at your own pace, or open it full screen. Compare a single finding view with the aggregate report view.
Safeguard combines dependency scanning, reachability analysis and fix pull requests in one workflow, and a free scan shows how it reads a NuGet project.
Quick check
Do I need dotnet list package if NuGet Audit is on?
Not strictly, but the report gives a stored, machine readable record that restore warnings do not.
Does the list command include transitive packages by default?
No. Add the include transitive option.
Sources
- Auditing package dependencies for security vulnerabilities, Microsoft Learn
- dotnet package list command, Microsoft Learn
- Package Source Mapping, Microsoft Learn
Last reviewed: 19 October 2026.
