Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add .NET 9 breaking change about NuGetAuditMode changed default #43569

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: "Breaking change: 'dotnet restore' produces security vulnerability warnings for transitive packages"
description: Learn about a breaking change in the .NET 9 SDK where 'dotnet restore' produces security vulnerability warnings for transitive packages by default.
---
# 'dotnet restore' produces security vulnerability warnings for transitive packages

The [`dotnet restore` command](../../../tools/dotnet-restore.md), which restores the dependencies and tools of a project, now produces security vulnerability warnings for transitive packages by default.

## Previous behavior

In [.NET 8, we introduced NuGetAudit](../8.0/dotnet-restore-audit.md), which emits warnings for packages with known security vulnerabilities.
It was possible to change the `NuGetAuditMode` property to include all packages, but the default was to report only direct package references.

## New behavior

`NuGetAuditMode` now defaults to `all`, if it has not been explicitly set.
This means that transitive packages (dependencies of packages your project directly references) with known vulnerabilities will now cause warnings to be reported.
If your project treats errors as warnings, this can cause restore failures.

## Version introduced

.NET 9 Preview 6

## Type of breaking change

This change is a [behavioral change](../../categories.md#behavioral-change).

## Reason for change

Packages with known vulnerabilities might cause your app to be exploitable, even if your project does not directly reference or use the vulnerable package.
New features in .NET 9 also make it easier to investigate the package graph, and suppress advisories that are not relevant to how your app uses the vulnerable package.

## Recommended action

- To explicitly reduce the probability of this breaking your build due to warnings, you can consider your usage of `<TreatWarningsAsErrors>` and use `<WarningsNotAsErrors>NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors>` to ensure known security vulnerabilities are still allowed in your environment.

- Use tools, such as `dotnet nuget why`, to find the top-level package that caused the transitive package with the known vulnerability to be included, and try to upgrade it to see if the transitive vulnerability goes away. If not, promote the transitive package to a top-level package by adding a `PackageReference` for it, and upgrade it to a newer version.

- If you want to suppress a specific advisory, you can add `<NuGetAuditSuppress Include="url" />` within an `<ItemGroup>`, where `url` is the URL reported in NuGet's warning message.

- If you want to only be warned of direct package references with known vulnerabilities, you can set `<NuGetAuditMode>` to `direct`.

## See also

- [Audit for security vulnerabilities (`dotnet restore`)](../../../tools/dotnet-restore.md#audit-for-security-vulnerabilities)
- [Auditing package dependencies for security vulnerabilities](/nuget/concepts/auditing-packages)
- [NuGetAudit 2.0: Elevating Security and Trust in Package Management](https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The blog seems to contain some information that the docs do not.
We should move all the content from the blog to some docs and reference those.

I recall someone else asking this as well, maybe we can create a tracking issue for that if there isn't one already.

Loading