Dotnet list package --vulnerable uses AuditSources

[Nigusu-Allehu]

Bug

Fixes:

Description

Design Spec: https://github.com/NuGet/Home/blob/dev/accepted/2024/Dotnet-list-package-vulnerable-uses-auditsources.md

I had the following PR, but I could not reopen it after rebasing : #6206

This PR updates dotnet list package --vulnerable to use user configured <AuditSources>.

Currently, the command only looks into <PackageSources> to load vulnerability data. However, with the introduction of NuGet Audit, other commands now support <AuditSources> to specify vulnerability data sources. This PR makes sure dotnet list package --vulnerable is also up to date and supports <AuditSources>

In order to do a manual test, I specified a package that has only one vulnerability data source. That source is only specified as an Audit source. This is what running dotnet list package --vulnerable results in before and after this PR

Before

After

PR Checklist

• Meaningful title, helpful description and a linked NuGet/Home issue
• Added tests
• Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc. Update doc: dotnet list package --vulnerable uses AuditSources Home#14021

[nkolev92]

Can we use resources for this?

[Nigusu-Allehu]

could you please elaborate what you meant by resources?

[nkolev92]

A file like the following: https://github.com/NuGet/NuGet.Client/tree/dev/test/NuGet.Core.Tests/NuGet.Commands.Test/compiler/resources instead of hard coding everything within the test.

[nkolev92]

Similar feedback on the reability of the tests, consider whether these are needed or if there's a better way to priming all this data.

Does the project structure really matter?

[Nigusu-Allehu]

Thanks for the feedback. I have cleaned up the tests to make them more readable. Please let me know if you have more suggestions

[nkolev92]

This return seems like a bug.
When we use vulnerability from audit sources, we return and we don't print packages later one.

This should probably be an if/else.

btw, if I'm right and this is a bug, it'd be great to ensure we have a test that would've caught this scenario.

[Nigusu-Allehu]

The code at

NuGet.Client/src/NuGet.Core/NuGet.CommandLine.XPlat/Commands/PackageReferenceCommands/ListPackage/ListPackageCommandRunner.cs

Line 140 in fa6bd36

bool printPackages = FilterPackages(frameworks, listPackageArgs);

is responsible for filtering out packages that should not be printed.

For example, when using --vulnerable, it removes packages that do not have any reported vulnerabilities.

However, the actual printing occurs at a higher level in the execution flow:

NuGet.Client/src/NuGet.Core/NuGet.CommandLine.XPlat/Commands/PackageReferenceCommands/ListPackage/ListPackageCommandRunner.cs

Line 40 in fa6bd36

reportRenderer.Render(reportModel);

In the new implementation, when retrieving vulnerabilities from AuditSources, only vulnerable packages are added. As a result, there's no need to execute additional filtering logic to remove non-vulnerable packages.

Thus, the printPackages check is redundant because GetVulnerabilitiesFromAuditSourcesAsync only adds vulnerable packages.

[nkolev92]

A file like the following: https://github.com/NuGet/NuGet.Client/tree/dev/test/NuGet.Core.Tests/NuGet.Commands.Test/compiler/resources instead of hard coding everything within the test.