{"id":56236,"date":"2024-07-17T12:37:50","date_gmt":"2024-07-17T19:37:50","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=3234"},"modified":"2024-07-17T12:37:50","modified_gmt":"2024-07-17T19:37:50","slug":"nugetaudit-2-0-elevating-security-and-trust-in-package-management","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/nugetaudit-2-0-elevating-security-and-trust-in-package-management\/","title":{"rendered":"NuGetAudit 2.0: Elevating Security and Trust in Package Management"},"content":{"rendered":"

Introduction<\/h2>\n

In November 2023 (NuGet 6.8, Visual Studio 17.8, .NET SDK 8.0.100), we released NuGet Audit<\/a>. NuGet Audit provides warnings during restore when a package with a known vulnerability is used by a project. More information about NuGet Audit, including detailed configuration options can be found on our learn website<\/a>. New features are still being added, so if you haven\u2019t read the docs recently, consider having another look, or check our release notes<\/a>, to see if new features that may help you have been added.<\/p>\n

Here is a quick summary of available settings that will be available in NuGet 6.12, Visual Studio 17.12, .NET SDK 9.0.100.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Setting<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
NuGetAudit (property)<\/td>\nEnable or disable NuGetAudit<\/td>\n<\/tr>\n
NuGetAuditMode (property)<\/td>\nReport only direct packages with known vulnerabilities, or report both directory and transitive packages with known vulnerabilities.<\/td>\n<\/tr>\n
NuGetAuditLevel (property)<\/td>\nSelects the minimum vulnerability severity level to report on.<\/td>\n<\/tr>\n
NuGetAuditSuppress (item)<\/td>\nDon\u2019t warn about specific advisory URLs.<\/td>\n<\/tr>\n
WarningsNotAsErrors (property)<\/td>\nThis is not NuGet Audit specific, but if your project uses TreatWarningsAsErrors<\/code>, consider adding NU1901<\/code>, NU1902<\/code>, NU1903<\/code>, and NU1904<\/code> to this list to avoid newly disclosed package vulnerabilities from causing restore and build failures.<\/td>\n<\/tr>\n
auditSources (nuget.config)<\/td>\nIf no audit sources are provided, NuGet will use package sources to download the vulnerability database to use for auditing. NuGet.config’s auditSources<\/code> will allow you to use nuget.org (or another source’s) vulnerability database, without it being a package source.<\/td>\n<\/tr>\n
SdkAnalysisLevel (property)<\/td>\nThe .NET 9.0.100 SDK introduced this SDK analysis level concept, which multiple .NET SDK and NuGet features use to change default values<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u2139\ufe0f Note: In response to developers’ feedback to ensure builds continuity when updating to .NET SDK 9, we have reverted the default value of NuGetAuditMode to direct<\/code> in Visual Studio 17.12.3 and .NET 9.0.101.<\/p>\n

What it looks like<\/h3>\n

On command line restores, NuGet Audit’s warnings will appear like any other MSBuild warning or error:<\/p>\n

\n

D:\\src\\test\\vulnTest\\ClassLib1\\ClassLib1.csproj : warning NU1903: Package ‘Newtonsoft.Json’ 9.0.1 has a known high severity vulnerability, https:\/\/github.com\/advisories\/GHSA-5crp-9r3c-p9vr [D:\\src\\test\\vulnTest\\vulnTest.sln]<\/p>\n<\/blockquote>\n

In Visual Studio, these warnings will appear in the Error List window<\/p>\n

\"VS<\/a><\/p>\n

Solution Explorer will show a yellow bar warning you at least one project has a package with a known vulnerability. There is a clickable link to take you to NuGet’s Package Manager UI (PM UI) for the solution. Note:<\/strong> Currently PM UI at the solution level does not show transitive packages, only direct packages.<\/p>\n

Additionally, projects using the newer SDK style projects will have a Dependencies node under the project, and any warnings related to a specific package displayed under the package itself. Projects using the older non-SDK style format will have a references node, rather than dependencies, and will not show additional information about package specific warnings or have overlay icons.<\/p>\n

\"Visual<\/a><\/p>\n

Recommended way to resolve warnings<\/h2>\n

Getting a warning about packages with known vulnerabilities is only part of the process. Once discovered, action needs to be taken to remove the potential vulnerability from your solution.<\/p>\n

The easiest case is when a package you reference directly has the known vulnerability, in which case you update the version to another version that fixes the vulnerability. If no newer version exists, you can try to contact the package owner, but you may need to look for an alternative package and stop using the one with a known vulnerability. See our documentation on auditing package dependencies for more tips on remediation<\/a><\/p>\n

However, often a vulnerability will be in a transitive dependency, and the solution is not so obvious. Our recommendation is to prefer updates to packages \u201cclosest\u201d to your direct references<\/strong>. Though, there\u2019s nothing wrong with just upgrading the package with known vulnerability either.<\/p>\n

For example, say your project references package A. Package A has a dependency on package B, which in turn has a dependency on package C. In this example, we’ll consider that package C version 1.0.0 has a known vulnerability, fixed in version 2.0.0. Our recommendation is to first try upgrading package A<\/strong>. If that doesn\u2019t resolve the audit warning, then try upgrading package B<\/strong>. If that doesn\u2019t resolve the audit warning, then upgrade C directly<\/strong>.<\/p>\n

How to upgrade transitive packages<\/h3>\n

In order to upgrade a transitive package to a higher version, you need to add it as a direct package reference<\/strong>. Our docs have more information about NuGet’s dependency resolution algorithm<\/a>.<\/p>\n

Using Central Package Management<\/a> with the transitive pinning setting<\/a>, CPM can automate this for you, with the added benefit that when you upgrade your direct package reference and the transitive package is no longer needed, it automatically disappears from your project\u2019s package graph. However, note that CPM with transitive pinning will still cause packages to become dependencies if you pack your project into your own package to share with others, even if your project doesn\u2019t directly call APIs on that package.<\/p>\n

Suppressing specific advisories<\/h3>\n

Sometimes you might determine after a security review that your software is not at sufficient risk for a particular advisory. For example, several serialization libraries in the past had security advisories where there’s a Denial of Service (DoS) risk when an attacker can craft an input that has deep object nesting leading to a stack overflow. Usually, this can be mitigated by telling the serializer to limit the maximum allowed nesting depth. Therefore, if your software is already mitigating the package’s security risk, you might choose to suppress the specific advisory.<\/p>\n

To do so, edit the project file with a text or XML editor, and add a NuGetAuditSuppress<\/code> element within an ItemGroup<\/code>.<\/p>\n

<Project Sdk=\"Microsoft.NET.Sdk\">\n  <!--  other parts of the project left out of this example -->\n  <ItemGroup>\n    <NuGetAuditSuppress Include=\"https:\/\/github.com\/advisories\/GHSA-6qmf-mmc7-6c2p\" \/>\n  <\/ItemGroup>\n<\/Project>\n<\/code><\/pre>\n
You can put these MSBuild items in a Directory.Build.props file<\/a> if you wish to define it in one place but apply to all projects in subdirectories. However, you may also wish to consider only putting it in specific projects that you have done a security review on, to minimize risk that a different project in the solution takes the same dependency and starts using the library in an insecure way.<\/p>\n
However, we strongly encourage<\/em><\/strong> you to upgrade packages to versions without known vulnerabilities, rather than suppressing the advisory.<\/p>\n
How to find transitive package path<\/h2>\n
There are several ways to find the package path. Which method you prefer depends on what tools you normally use during your development.<\/p>\n
dotnet nuget why<\/h3>\n
On the command line, dotnet nuget why<\/code><\/a> was added to the .NET SDK 8.0.400 and the .NET 9 preview 6 SDK. Pass it a project file and package id, and it will show you why the package is in your package graph, even through project references.<\/p>\n
\"Image<\/a><\/p>\n
Like the rest of the dotnet<\/code> CLI, it directly only supports SDK style projects. If you have a Visual Studio project that doesn’t work with the .NET SDK, you can restore your project with Visual Studio or MSBuild. NuGet creates a file named project.assets.json<\/code> in the project’s obj\/<\/code> directory (technically, using the MSBuild property MSBuildProjectExtensionsPath<\/code>). Using an up-to-date version of VS 2022, you can also use msbuild -getProperty:ProjectAssetsFile<\/code> to find the path to the assets file. Finally, starting from the .NET 9 preview 7 SDK, you will be able to pass dotnet nuget why<\/code> the assets file as a substitute for the project file. For example, dotnet nuget why path\\to\\project.assets.json System.Text.RegularExpressions<\/code>. \u00a0<\/p>\n
VS solution explorer<\/h3>\n
SDK style projects also provide the full package graph under the project\u2019s Dependency node. It\u2019s also searchable!<\/p>\n
First, expand search options and enable \u201csearch external files\u201d.<\/p>\n
\"Image<\/a><\/p>\n
Then you can search the package name, and it will show you all instances under each project’s Dependencies node.<\/p>\n
\"Image<\/a><\/p>\n
Visual Studio NuGet Package Manager UI<\/h3>\n
When you look at the Installed tab in Visual Studio\u2019s package manager UI, when the project uses PackageReference<\/code> for package management, it will show both direct and transitive packages. Currently this only happens when you manage packages for a project, not for the solution, although we’re working to improve this.<\/p>\n
If you mouse hover of a package in the package list, the tooltip will include the name of one direct package that has caused that transitive package to be included in the project.<\/p>\n
\"Image<\/a><\/p>\n
Looking at the assets file manually<\/h3>\n
All of the above experiences are based on reading NuGet\u2019s assets file, so if none of them work for you, you can always look at the assets file directly to find the same information. The assets file should not be considered a stable format, so we do not recommend building tools that read the file. We already have upcoming feature plans which need to introduce breaking changes in the json schema, though we will change the version number at the top of the file. But this is not a problem when viewing and searching the file manually.<\/p>\n
Generally, the assets file can be found in the obj\/project.assets.json<\/code> under your project\u2019s directory, but if you use the .NET SDK\u2019s artifacts output layout, or otherwise change the default layout, you can also find the location by running the following command on a command prompt:<\/p>\n
dotnet msbuild -getProperty:ProjectAssetsFile\n<\/code><\/pre>\n
If your project is non-SDK style, you may get an error about an import that can’t be found. In this case, open Visual Studio\u2019s Developer Command Prompt, and remove the dotnet<\/code> from the command line, to use Visual Studio\u2019s MSBuild.exe<\/code> directly.<\/p>\n
Use a text editor to search for the package id that has a known vulnerability, look through potentially multiple search results, and you\u2019ll be able to find which packages list that package as a dependency. Repeat with the other packages until you find the information you\u2019re looking for, perhaps the package your project directly references. Here’s an example showing that Newtonsoft.Json<\/code>, and a few other packages, are dependencies of the package NuGet.Packaging<\/code>:<\/p>\n
      \"NuGet.Packaging\/5.11.3\": {\n        \"type\": \"package\",\n        \"dependencies\": {\n          \"Newtonsoft.Json\": \"9.0.1\",\n          \"NuGet.Configuration\": \"5.11.3\",\n          \"NuGet.Versioning\": \"5.11.3\",\n          \"System.Security.Cryptography.Cng\": \"5.0.0\",\n          \"System.Security.Cryptography.Pkcs\": \"5.0.0\"\n        },\n<\/code><\/pre>\n
Notes on specific packages<\/h2>\n
System.Net.Http and System.Text.RegularExpressions<\/h3>\n
These packages are from .NET Core 1.x, and made redundant since .NET Core 2.0. Since all supported .NET platforms also support .NET Standard 2.0, we do not recommend using versions of .NET Standard below 2.0<\/a>. If your project directly references either of these packages (or any other System.* package version 4.*), you can remove the package reference, as the assembly is built into the target framework\u2019s reference assemblies. If your project is getting these packages transitively, follow our previous guidance in preferring to upgrade packages closer to your project. Hopefully there\u2019s a newer version of the package that no longer uses .NET Standard 1.x or these packages.<\/p>\n
Runtime packages<\/h3>\n
If you look at some of the .NET platform\u2019s security advisories, for example GHSA-hhc7-x9w4-cw47<\/a>, or GHSA-7fcr-8qw6-92fr<\/a>, you can see the packages affected all start with Microsoft.NetCore.App.Runtime.*<\/code> or Microsoft.AspNetCore.App.Runtime.*<\/code>. These packages are not referenced directly by your project but are instead implicitly added by the .NET SDK itself. In order to stop using vulnerable versions of these packages you must upgrade to a newer version of the .NET SDK<\/strong>.<\/p>\n
Upcoming improvements<\/h2>\n
Work on improving the experience detecting and managing packages with known vulnerabilities hasn\u2019t stopped. Here are some upcoming features we\u2019re working on. You can search our GitHub issues for issues labeled with NuGetAudit<\/a> to see existing ideas and bug reports. If you have an idea and can\u2019t find an existing issue to upvote, you can create a new feature request there.<\/p>\n
PM UI improvements<\/h3>\n
Currently Visual Studio\u2019s NuGet Package Manager UI only shows transitive packages that are dependencies of packages that the project references directly. But it does not show packages that only come in via project references. This will be changed.<\/p>\n
Additionally, when you mouse hover over a transitive package, it shows which direct package reference has caused the transitive package to be included in the project. If a transitive package is brought in by multiple top level packages, only one of the top level packages will be reported. We\u2019re going to improve this so that more information is available, since non-SDK style projects don\u2019t have the Solution Explorer view that SDK style project have.<\/p>\n
Supplied By Platform<\/h3>\n
NuGet and the .NET SDK team are working on a feature named Supplied By Platform<\/a>, which will allow the .NET SDK to inform NuGet which packages are now part of the .NET reference assemblies. This will allow NuGet to automatically cull those packages from the restore graph. This means that not only will packages like System.Net.Http and System.Text.RegularExpressions automatically be removed and prevent NuGet Audit warnings, but restore performance will improve because any package that lists NETStandard.Library as a dependency<\/a> (typically version 1.6.1), will have tens of packages removed from the graph, meaning fewer packages to download and recursively check for their own dependencies.<\/p>\n
dotnet nuget audit fix<\/h3>\n
We also want to provide a way to automatically resolve all your project\u2019s known vulnerabilities by running a single command<\/a>. It will implement the recommended approach described above, analyzing the package graph and testing upgrades find which combination of upgrades removes all packages with known vulnerabilities. Like any automated tool, it won\u2019t be perfect for all scenarios. For example, if a package with a known vulnerability only has fixes in package versions with breaking changes, the fix to resolve known vulnerabilities may leave your project failing to build. But we believe that it will be a good and quick solution for most developers.<\/p>\n
Warnings and errors disappearing from Visual Studio’s Error List<\/h3>\n
We’re aware of an issue where non-SDK style projects (Visual Studio’s new project wizard calls them “.NET Framework” projects) will have NuGet warnings disappear from the error list after one or two builds<\/a>. We’re investigating what is clearing the error list, and what NuGet needs to do to retain its warnings. A command line restore (msbuild -t:restore<\/code>) will always display warnings until this is resolved.<\/p>\n
Summary<\/h2>\n
We covered upcoming changes to NuGet Audit, detailing how to identify and resolve vulnerabilities in your NuGet packages. You learned how to set severity levels, suppress specific advisories, and use new tools to manage vulnerabilities and maintain security. Stay tuned for future enhancements to simplify vulnerability management and be sure to view the docs<\/a> for up-to-date information.<\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction In November 2023 (NuGet 6.8, Visual Studio 17.8, .NET SDK 8.0.100), we released NuGet Audit. NuGet Audit provides warnings during restore when a package with a known vulnerability is used by a project. More information about NuGet Audit, including detailed configuration options can be found on our learn website. New features are still being […]<\/p>\n","protected":false},"author":146987,"featured_media":56281,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7933,7874,326],"tags":[8016,8024,123,7982],"class_list":["post-56236","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-feature-announcement","category-nuget","category-security","tag-audit","tag-nuget-audit","tag-security","tag-transitive-dependencies"],"acf":[],"blog_post_summary":"
Introduction In November 2023 (NuGet 6.8, Visual Studio 17.8, .NET SDK 8.0.100), we released NuGet Audit. NuGet Audit provides warnings during restore when a package with a known vulnerability is used by a project. More information about NuGet Audit, including detailed configuration options can be found on our learn website. New features are still being […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/56236","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/146987"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=56236"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/56236\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/56281"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=56236"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=56236"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=56236"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}