I have scanned for vulnerable NuGet packages using dotnet list package --vulnerable --include-transitive. I get the following:
Project `MyProject` has the following vulnerable packages [net6.0]: Transitive Package Resolved Severity Advisory URL> System.Net.Http 4.3.0 High https://github.com/advisories/GHSA-7jgj-8wvc-jh57As you can see, I am using .NET 6. When inspecting my packages.lock.json, I see that System.Net.Http 4.3.0 is depended on by NETStandard.Library 1.6.1. When reading the information posted at the advisory URL, it says that only certain .NET Core 1.x and 2.x runtimes are vulnerable. Again, I am using .NET 6, so I expect this vulnerability doesn't apply to me.
I am confused about how to handle this.
I would very much like to not be notified about the vulnerability if it's not relevant to me. IMHO dotnet list package should handle this automatically, taking into account the target framework, but that's another issue. In any case, this is done as part of a CI build, so false positives are annoying. I don't want to be spammed with warnings or build errors due to stuff that's not relevant to me.
I could install the most recent version of System.Net.Http as a direct dependency, but with potentially hundreds of transitive packages, that is a solution that won't scale: I don't want to keep hundreds of packages up to date, and there is as far as I know no easy way to then automatically remove these "directly installed transitive dependencies" if my other dependencies change in a way that makes them obsolete. I'd particularly prefer to avoid all of this since I don't seem to be affected.
My preferred solution might be to go to the authors of the packages that depend on the vulnerable package and tell them to update, but firstly, that won't really scale for the same reason as above (and would delay my getting the patch, particularly if the transitive dependency is several steps removed from me, and/or if one of the steps is not actively maintained), and secondly, this package is only referenced by NETStandard.Library, which is not your normal NuGet package.
How should I handle this (both specifically this example, and the general issue) in a way that maintains security best practices (notably, fixes vulnerabilities) and does not add a nightmarish maintenance burden?