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.

[cmeeren]

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.

So, in terms of point 2 above, in my role as a package author, your suggestion is to always require the latest version of dependencies at the time of release?

What about what you mention about supply chain attacks in #11786 (comment)? Specifically:

It is best practice to regularly audit your dependencies and be on newer versions as time passes. While .NET may have a bias towards lowest applicable version, it puts you in a position where a future disclosed vulnerability may force you to update anyway. On the other end, updating always to the latest is subject to any active supply chain attacks.

Ideally you should be on a recent version or even the latest version that is pinned and doesn't automatically update.

As a package consumer, I always pin my package versions and update manually. I generally update all packages in all my applications at least once a week, and dependencies of all my own packages whenever I publish a new version for other reasons (or if the dependency update is important enough to warrant its own release). However, given your comment above, that could leave me open to supply chain attacks. How can I strike a good balance between wanting the latest bug/security patches, and not opening myself up to supply chain attacks? Is what I'm doing already a good balance?

[JonDouglas]

To clarify, when I refer to "latest" I mean in a pinned manner. The supply chain attack "could" happen if an account was taken over and a malicious actor published a new version with malicious code/behavior. I hope that helps clarify what I mean by "latest".

[cmeeren]

Sure, that was how I interpreted you. Were my remarks/questions not making sense in light of that interpretation?

[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.