10

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-jh57

As 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?

cmeeren
  • 3,890
  • 2
  • 20
  • 50

1 Answers1

-2

In your example there is a package that references the System.Net.Http 4.3.0 version.

This causes your app to resolve 4.3.0. This means your project literally have that version installed. See your bin folder to confirm. In other words: it is relevant to you.

To avoid using this version all you need to do is install 4.3.4 as recommended by the advisory url. This means that the fix would be to add the required version on the .csproj eg.

<PackageReference Include="System.Net.Http" Version="4.3.4" />

This would cause your project to resolve a version with the fix, and you do not need to contact the authors of intermediary packages.

Aldracor
  • 2,133
  • 1
  • 19
  • 27
  • I already mention the solution you propose here as a non-workable solution. For clarity, I have updated the question with details about exactly why. Furthermore, the vulnerability is _not_ relevant since (as I mentioned) the vulnerability only exists for a combination of package version **and target framework** that I am not using. – cmeeren Apr 19 '22 at 12:20
  • @cmeeren not workable as it doesn't scale? Contacting authors is much more difficult and then you have to wait for a fix as well... Your argument doesn't make sense to me. It seems much easier to just add the affected packages and update them as and when necessary. Making assumptions from that short description isn't a good idea. see: https://www.nuget.org/packages/System.Net.Http/4.3.0 – Aldracor Sep 21 '22 at 11:42
  • 1
    As I mention, I agree - contacting authors is _also_ a solution that won't scale. I see both of these solutions as suboptimal for the reasons I describe in the question. It seems that there really isn't a solid solution to this issue, at least for now. – cmeeren Sep 22 '22 at 11:46