`dotnet add package` should fail vulnerable packages

[richlander]

I'm installing this package: https://www.nuget.org/packages/System.Formats.Asn1/8.0.0. My expectation is that (A) the vulnerability should be reported with this command, and (B) the addition should be failed by default (should require --force to actually add).

C:\Users\rlander\dotnet8proj>dotnet --version
9.0.100-rc.1.24452.12

C:\Users\rlander\dotnet8proj>type dotnet8proj.csproj | findstr TargetFramework
    <TargetFramework>net8.0</TargetFramework>

C:\Users\rlander\dotnet8proj>dotnet add package System.Formats.Asn1 --version 8.0.0

Build succeeded in 0.9s
info : X.509 certificate chain validation will use the default trust store selected by .NET for code signing.
info : X.509 certificate chain validation will use the default trust store selected by .NET for timestamping.
info : Adding PackageReference for package 'System.Formats.Asn1' into project 'C:\Users\rlander\dotnet8proj\dotnet8proj.csproj'.
info : Restoring packages for C:\Users\rlander\dotnet8proj\dotnet8proj.csproj...
info :   GET https://api.nuget.org/v3-flatcontainer/system.formats.asn1/index.json
info :   OK https://api.nuget.org/v3-flatcontainer/system.formats.asn1/index.json 75ms
info :   GET https://api.nuget.org/v3-flatcontainer/system.formats.asn1/8.0.0/system.formats.asn1.8.0.0.nupkg
info :   OK https://api.nuget.org/v3-flatcontainer/system.formats.asn1/8.0.0/system.formats.asn1.8.0.0.nupkg 32ms
info : Installed System.Formats.Asn1 8.0.0 from https://api.nuget.org/v3/index.json to C:\Users\rlander\.nuget\packages\system.formats.asn1\8.0.0 with content hash AJukBuLoe3QeAF+mfaRKQb2dgyrvt340iMBHYv+VdBzCUM06IxGlvl0o/uPOS7lHnXPN6u8fFRHSHudx5aTi8w==.
info :   GET https://api.nuget.org/v3/vulnerabilities/index.json
info :   OK https://api.nuget.org/v3/vulnerabilities/index.json 14ms
info :   GET https://api.nuget.org/v3-vulnerabilities/2024.10.02.05.41.40/vulnerability.base.json
info :   GET https://api.nuget.org/v3-vulnerabilities/2024.10.02.05.41.40/2024.10.06.11.41.54/vulnerability.update.json
info :   OK https://api.nuget.org/v3-vulnerabilities/2024.10.02.05.41.40/vulnerability.base.json 33ms
info :   OK https://api.nuget.org/v3-vulnerabilities/2024.10.02.05.41.40/2024.10.06.11.41.54/vulnerability.update.json 48ms
warn : NU1903: Package 'System.Formats.Asn1' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-447r-wph3-92pm
info : Package 'System.Formats.Asn1' is compatible with all the specified frameworks in project 'C:\Users\rlander\dotnet8proj\dotnet8proj.csproj'.
info : PackageReference for package 'System.Formats.Asn1' version '8.0.0' added to file 'C:\Users\rlander\dotnet8proj\dotnet8proj.csproj'.
info : Writing assets file to disk. Path: C:\Users\rlander\dotnet8proj\obj\project.assets.json
log  : Restored C:\Users\rlander\dotnet8proj\dotnet8proj.csproj (in 1.32 sec).

C:\Users\rlander\dotnet8proj>dotnet restore
Restore succeeded with 1 warning(s) in 0.7s
    C:\Users\rlander\dotnet8proj\dotnet8proj.csproj : warning NU1903: Package 'System.Formats.Asn1' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-447r-wph3-92pm

Build succeeded with 1 warning(s) in 0.9s

dotnet add package clearly has access to vulnerability data but doesn't act on it. It seems like we would "shift left" with the report on having just added a vulnerable dependency. Is there a reason why not?

[richlander]

I see that I missed the warn. The NuGet console output is objectively way too verbose and not purpose-built for the experience.

Stating the obvious, the audit output should be uniform across commands.

[baronfel]

I'm working on a draft for guidelines about how the dotnet CLI should respect CLI common options, and the specific actionable thing here is that many nuget CLI commands do not respect verbosity and/or do not log in a way that unifies with the rest of the .NET SDK. I'd love an output pass that took inspiration from Terminal Logger and provided a more polished experience.

[aortiz-msft]

Closing in lieu of dotnet/sdk#43938

[richlander]

@aortiz-msft I changed the title to make it more specific.

[JonDouglas]

Our approach is to warn by default and fail when explicitly configured.

This could be implemented through a configurable option like a "strict mode" that enforces stricter security policies.

The tool's role is to inform, not to act on its own. Decisions remain in the hands of the user, and no actions are taken without their explicit consent.

[richlander]

I understand that policy, however, it feels incompatible with "secure by default". It also doesn't help that the warning is effectively hidden.

and no actions are taken without their explicit consent.

This is the lack of taking an action. It feels different to me.