Yes, with limits. NuGet Audit supports packages.config projects from NuGet 6.10, which ships with Visual Studio 2022 17.10. The audit mode setting does not apply to them, and MSBuild controls such as NoWarn and TreatWarningsAsErrors are not supported for packages.config projects.
When each form of audit arrived
| NuGet | .NET SDK | Visual Studio 2022 | Feature |
|---|---|---|---|
| 5.9 | .NET 5 SDK 5.0.200 | Not applicable | dotnet list package with the vulnerable option |
| 6.8 | .NET 8 SDK 8.0.100 | 17.8 | NuGetAudit for PackageReference |
| 6.10 | Not applicable | 17.10 | NuGetAudit for packages.config |
| 6.11 | .NET 8 SDK 8.0.400 | 17.11 | NuGetAuditSuppress for PackageReference |
| 6.12 | .NET 9 SDK 9.0.100 | 17.12 | Audit sources, and suppress for packages.config |
| 7.0 | .NET 10 SDK 10.0.100 | Visual Studio 2026 | Audit mode default changes for .NET 10 |
What you get on packages.config
Audit runs as part of restore and checks your packages against vulnerability information from your audit sources. The data behind nuget.org's vulnerability list comes from the GitHub Advisory Database.
The Microsoft documentation lists these differences for packages.config:
- The audit mode setting (direct or all) is not applicable.
- NoWarn, TreatWarningsAsErrors and similar severity properties are not supported.
- Suppression with NuGetAuditSuppress works from Visual Studio 17.12 and NuGet 6.12.
Compare that with a PackageReference project, where audit mode defaults to direct, and to all when the project targets net10.0 or higher.
What to do if you cannot migrate yet
- Run audit in Visual Studio 17.10 or later so restore reports warnings.
- Add a scan to CI that reads your packages.config files, so you are not relying on developer machines.
- Track the migration to PackageReference as a security task, since it unlocks audit mode, warning controls and central package management.
- Do not suppress an advisory without recording why. The documentation calls suppression a last resort, because it hides the advisory for every project that shares it.
The command line view
dotnet list package --vulnerable --include-transitive
The documentation notes that transitive packages are not included by default, so add the include option.
Migration is the real fix
Moving to PackageReference takes work, but it brings the full set of audit controls and lets you manage versions in one place. Plan it by project, starting with the ones that ship to customers, and keep a short list of which projects still use packages.config so the gap stays visible.
Quick check
Which warning codes does audit raise?
NU1901 for low, NU1902 for moderate, NU1903 for high and NU1904 for critical severity, plus NU1900 when vulnerability data cannot be fetched.
Does a clean audit mean my packages are safe?
It means no known advisory matched at that moment. The database changes, so the Microsoft docs advise checking regularly and in CI.
Safeguard's SBOM and dependency scanning can run in CI alongside the restore audit, and continuous monitoring rechecks as new advisories are published. Start with the free scan.
Sources
Last reviewed: 19 October 2026.
