NugetAudit is not consistent

[AlbertoMonteiro]

NuGet Product Used

dotnet.exe

Product Version

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.3068a692
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /home/alberto/.dotnet/sdk/9.0.100/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  8.0.100 [/home/alberto/.dotnet/sdk]
  8.0.404 [/home/alberto/.dotnet/sdk]
  9.0.100 [/home/alberto/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0 [/home/alberto/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.11 [/home/alberto/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [/home/alberto/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.0 [/home/alberto/.dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.11 [/home/alberto/.dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [/home/alberto/.dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/home/alberto/.dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Worked before?

Just noticed in .NET 9, didn't tried in other versions

Impact

It's more difficult to complete my work

Repro Steps & Context

The issue is the different behavior of NugetAudit configured in the .csproj file when executing a dotnet build or dotnet publish with the argument --self-contained true.

csproj config:

<NuGetAudit>true</NuGetAudit>
<NuGetAuditLevel>moderate</NuGetAuditLevel>
<NuGetAuditMode>all</NuGetAuditMode>

When the argument --self-contained is not used, the build completes successfully without any failures related to vulnerable packages.

Example:

Command:

dotnet build -c Release

Output

  Determining projects to restore...
  All projects are up-to-date for restore.
  sample -> /home/runner/work/NugetAuditRepro/NugetAuditRepro/bin/Release/net9.0/sample.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.63

However, when using the --self-contained parameter, the build returns messages regarding vulnerable packages.

Command:

dotnet build -c Release -r linux-x64 --self-contained true

Output

  Determining projects to restore...
/home/runner/work/NugetAuditRepro/NugetAuditRepro/sample.csproj : warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-5f2m-466j-3848
/home/runner/work/NugetAuditRepro/NugetAuditRepro/sample.csproj : warning NU1902: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-x5qj-9vmx-7g6g
/home/runner/work/NugetAuditRepro/NugetAuditRepro/sample.csproj : warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc
  Restored /home/runner/work/NugetAuditRepro/NugetAuditRepro/sample.csproj (in 2.01 sec).
/home/runner/work/NugetAuditRepro/NugetAuditRepro/sample.csproj : warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-5f2m-466j-3848
/home/runner/work/NugetAuditRepro/NugetAuditRepro/sample.csproj : warning NU1902: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-x5qj-9vmx-7g6g
/home/runner/work/NugetAuditRepro/NugetAuditRepro/sample.csproj : warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc
  sample -> /home/runner/work/NugetAuditRepro/NugetAuditRepro/bin/Release/net9.0/linux-x64/sample.dll

Build succeeded.

I've created that repo that does have the behavior: https://github.com/AlbertoMonteiro/NugetAuditRepro

I've created github action that does some combinations of dotnet build

https://github.com/AlbertoMonteiro/NugetAuditRepro/actions/runs/12075457777/job/33675284368

Verbose Logs

No response

[zivkan]

@AlbertoMonteiro If you'd like to discuss this furtner, please create an issue over at https://github.com/dotnet/sdk. GitHub only allows transfers of issues within the same org account, and NuGet/ is obviously not the same as dotnet/, so I can't transfer it.

NuGet reports only what it gets told about, and the .NET SDK changes NuGet's inputs depending on the command. You can verify this as NuGet saves the restore inputs in obj/{project_name}.nuget.dgspec.json.

For example, do the following commands:

1. clone your sample repo
2. dotnet restore
3. copy the obj/sample.csproj.nuget.dgspec.json file somewhere
4. run dotnet build -r linux-x64 (you can pass the other parameters from the example in the original post, but only the -r matters here)
5. diff the dgspec copy with the new file contents

Depending on the CLI arguments, you might see a new downloadDependencies section, but that's not relevant to the System.Private.Uri advisories. What is relevant is this:

+      },
+      "runtimes": {
+        "linux-x64": {
+          "#import": []
+        }

In other words, the .NET SDK wasn't previously telling NuGet about any RIDs, and now it is. One of the packages you're referencing has RID specific dependencies, and when the .NET SDK doesn't tell NuGet about any RIDs, NuGet doesn't resolve any RID package graphs, and therefore there's nothing more for NuGetAudit to check.

You can mitigate this by explicitly setting the <RuntimeIdentifiers> property in your project, and then the .NET SDK will tell NuGet when you do a "normal" dotnet restore, and then NuGet will detect and report the known vulnerabilities in the first restore. If you're developing on a Windows machine, and deploying on a Linux machine, you might need to set both win-x64;linux-x64 RIDs, not just Linux, so that you can run the app locally during debugging/testing.

[AlbertoMonteiro]

@zivkan for dotnet build, your suggestion to add the RuntimeIdentifiers works, but for other useful commands to know about vulnerable packages doesn't work, I've tried dotnet list package --vulnerable --include-transitive and dotnet nuget why sample.csproj Syste.Private.Uri.

Is there some other way to make those commands know about this vulnerability?

[zivkan]

For dotnet nuget why, we just finished the implementation and it will be available with the 9.0.200 SDK

• dotnet nuget why should check RID specific packages #13718

I couldn't find an issue for dotnet list package, so I just created one:

• dotnet list package should show RID specific packages #13978

Please add a 👍 reaction to it, as we use these upvotes as a signal to prioritize work

[AlbertoMonteiro]

Tyvm for you help, upvoted both linked issues!