Auditing projects for package vulnerabilities during restore

[JonDouglas]

Introduction to an auditing experience at package restore time where known vulnerabilities will be reported.

This proposal introduces new MSBuild warnings and output to the NuGet restore operation.

Rendered Spec

Please 👍 or 👎 this comment to help us with the direction of this feature & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.

Thank You 🎉

[mattzink]

We use Nexus repo manager and Artifactory as local Nuget.org package mirrors, so it would be great if there was a way in the nuget.config file to specify that Nuget.org is used only for vulnerability lookup, not for package hosting.

[loic-sharma]

What's the value in reporting severities with 0 hits? Would it be better to exclude those instead?

Suggested change

	Found 2 vulnerabilities (0 low, 1 moderate, 0 high, 1 critical) in 2 package(s)
	Found 2 vulnerabilities (1 moderate, 1 critical) in 2 package(s)

[JonDouglas]

Good idea, let's keep this open for discussion!

[CamiloTerevinto]

This sounds very interesting, thanks @JonDouglas. I have a few comments:

• CLI switches to run/skip auditing

It's quite common for an entire build to be run twice (feature branch and dev/main branch) for a change in environments with CI/CD. I think that for this to be useful, we should have an easy way of telling dotnet restore to run or skip the audit (for example, run the audit on the PR build, skip it in the dev build).

• Fail on X level

It would be useful to have a way to make dotnet restore exit as failure when a package with a particular vulnerability level is found (such as treating NU1904 as error instead of warning).
However, this might be doable already through something like <WarningsAsErrors>NU1904</WarningsAsErrors>.

[nkolev92]

CLI switches to run/skip auditing

Any CLI switch basically doubles as an MSBuild property. We're proposing MSBuild properties for opting into auditing, so that automatically makes it available as a CLI switch. Example: dotnet restore -p:NuGetAudit=disable

[zivkan]

@JonDouglas FYI, I moved the vulnerability summary output on command line restores under "Future Possibilities" for two reasons. 1. So we can get a V1 of this feature out sooner. 2. I don't believe this proposal has been specced out well. I have a bunch of questions if we want to implement it.

For example, in the sample output, if there are non-vulerability warnings or errors, where in the output do they go? Before the vulnerability summary, or below with the sample vulerability warnings? If before, should vulerability warnings/errors be output twice, once between the summary once after?

What's the expected order of output when restoring a solution with many projects? Wait until all projects finish restoring, and then output all their summaries? Or output project summaries as each project finishes restoring, even if it means that the vulnerability summary for that project will be somewhere much earlier in the restore log?

When restoring a solution where the same package version is in multiple projects, should we de-duplicate the output?

Anyway, as I said, I think we can take this on in the future if we still think it's useful. Let's get a V1 of the feature done without it, and see how we and customers feel about it.

[nkolev92]

I think some details, like the ones about the handling of multiple vulnerability for a package can still be in the main part as that's likely going to be done.

[JonDouglas]

Let's see what this shapes to be while working to answer the unknown. Thanks for being so thorough with questions to be answered.

[nkolev92]

Great updates @zivkan

[nkolev92]

I think some details, like the ones about the handling of multiple vulnerability for a package can still be in the main part as that's likely going to be done.

[JonDouglas]

We have approval from @nkolev92, but @zivkan did you want to approve before merge?