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

[richlander]

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

dotnet/sdk#30659 (comment)

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

[dotnet-policy-service]

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

[nkolev92]

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 #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]

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

[richlander]

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]

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]

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.