search

NuGet / Home

Repo for NuGet Client issues
Other
1.49k stars 250 forks source link

`dotnet list packages` should not report false positives for assemblies in `shared` directory #13405

Open richlander opened 4 months ago

richlander commented 4 months ago

A user reported false positives vulnerability findings of .NET product CVEs using dotnet list package --vulnerable --include-transitive.

https://github.com/dotnet/sdk/issues/30659#issuecomment-2072429833

This behavior should be improved for .NET 8+ (8.0.1xx, 8.0.4xx, 9.0.1xx).

dotnet-policy-service[bot] commented 4 months ago

@richlander Issue is missing Type label, remember to add a Type label

nkolev92 commented 4 months ago

There's no assembly scanning, but rather package scanning here. As long as a package is in the graph, NuGet will report vulnerabilities on it.

A way to minimize this is https://github.com/NuGet/Home/issues/7344, and it's something we're planning to explore, but the degree to which it'd help that scenario is going to be dependent on what packages brought it in.

richlander commented 4 months ago

@agocke -- you've been talking to vulnerability scanners. What is your guidance to them to avoid false positives like this?

richlander commented 4 months ago

We need to come up with designs that work well for all vulnerability scanners. The .NET CLI should have the best implementation and it should be a good reference implementation for others. If the proposal does that, great.

nkolev92 commented 4 months ago

I think if we eliminate things at the root (restore time), all other commands and components benefit. (restore pruning them means list package gets them, means they probably don't end up in deps.json). The challenge is that we can only eliminate certain packages. Deny listing/pruning 1000s of package ids won't scale and it probably bleeds too much of the framework implementation into NuGet.

I haven't look at this particular example, to know if a more minimal approach would solve it.

richlander commented 4 months ago

I think if we eliminate things at the root (restore time), all other commands and components benefit. (

That sounds good / makes sense.

We now have a fair bit of experience with false positives. This should give us a sense of how likely it is for users to run into this scenario and how many of our packages can contribute to this problem.