How to handle TRANSITIVE vulnerable/deprecated/outdated packages in the .NET ecosystem

[cmeeren]

Prevously asked with a somewhat different perspective on Stack Overflow without much activity. I opened #11786 to address part of the original question, but I am left with the general handling of transitive vulnerable/deprecated/outdated packages, so I am re-posting here in a slightly modified form.

I have scanned for vulnerable NuGet packages using dotnet list package --vulnerable --include-transitive. I am taking it for granted that transitive vulnerabilities are important to know about and, generally, to fix. Even transitive outdated packages may be important to know about, since there may be a fix for a bug you are potentially (transitively) impacted by.

My question is how to handle the result of vulnerable/deprecated/outdated transitive packages.

I have two questions:

1. How should we as package consumers handle vulnerable/deprecated/outdated transitive packages in a way that maintains security best practices (notably, fixes vulnerabilities), reduces bugs, and does not add a nightmarish maintenance burden?
2. How should we as package authors handle vulnerable/deprecated/outdated transitive packages with respect to dependency versions required by our package?

Thoughts on point 1:

I could install the most recent version of the packages as direct dependencies, 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.

My preferred solution might be to go to the authors of the packages that depend on the vulnerable/deprecated/outdated package and tell them to update, but 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).

In general, as a package consumer, given that NuGet resolves the lowest possible transitive dependencies, I'd like for all packages in my dependency graph to always be updated to require (i.e., be compiled and tested against) the latest version of transitive packages. The problem then disappears for me, as I simply update my direct dependencies and then get a completely up-to-date package graph. The only problem I can see is if there is a relevant bug introduced in the latest version of a transitive package. That could then effectively prevent me from updating to the latest version of my direct dependency, which could otherwise contain important fixes unrelated to the transitive package.

Thoughts on point 2

Given the last paragraph above, as a package author, in my own packages (Felicity, Facil, and Fling), I am currently always requiring the latest version of all dependencies. This is contrary to what I perceive to be best practices in the .NET ecosystem, which is to depend on the lowest package versions you can (at least the lowest version that is in practice – i.e., for the parts of the API you use – binary compatible with the latest version). I have yet to receive any complaints from users, though I am unsure of the significance of that fact since my packages are fairly niche.

[JonDouglas]

I wrote a doc about this here: https://docs.microsoft.com/en-us/nuget/concepts/security-best-practices

I plan to update more guidance as I gave a talk about this problem recently too.

The answer really sits in a "do what is in your control".

As a consumer, you can't do much but consume. You take patches when vulnerabilities are fixed and you educate yourself on the severity of the exploits to know how you should act(update, remove, replace).

As an author, you can update your dependencies to the last stable version known at time of publishing. This is typically a best practice in security to rid any deprecated/vulnerable packages.

As a good citizen of open source, asking libraries you consume as both a consumer and author to update certain dependencies helps the whole ecosystem shift left regularly and is appreciated by all.

[JonDouglas]

Sounds good. I just wanted to clarify after re-reading.

Sadly I don't have an answer for what is "a good balance". It sounds like you are already aware of these issues and doing the best you can. The answer to that question from one perspective is just moderation/middle path of these two extremes and what feels right to you. Not too early, not too late, but when it feels just right.

[cmeeren]

Thanks, I appreciate your perspective on this.

[swegele]

I think it would help if you could somehow identify packages that you made TOP LEVEL purely to deal with a transitive vulnerability. That way they would stand out somehow via filtering. So in future you could come back and determine which of those are still needed or which are no longer needed (because a 3rd party dependency updated their stuff).

Thoughts?

[KalleOlaviNiemitalo]

@swegele, doesn't Transitive pinning solve that already?

[swegele]

@swegele, doesn't Transitive pinning solve that already?

OK time to put on my learning hat...that looks promising! Thanks!!