Security Patching .NET Core Applications & Libraries

Every once in a while, a security problem comes up that needs patching. We couldn’t find a clear and concise Microsoft document that describes that process, so we asked Barry directly.

We thought it might be useful to document our conversation here.

Regardless what you are building, you ultimately have two types of dependencies:

  1. Functionality that is part of the .NET runtime/SDK
  2. Functionality you reference via a Nuget package. This might be a Microsoft package that is not part of the shared runtime (e.g. the OpenID Connect authentication handler) or a 3rd party package (e.g. IdentityModel)

It depends a little bit on your scenario what the best practices are. Let’s have a look.

Library Authors

You are shipping the output of dotnet pack to your customers – in our case IdentityServer.

For category 1 there is nothing you need to do. It is the job of the host to provide a security patched .NET runtime. The advice to give to your customers would be to install the patched runtime and delete any older version(s) of the runtime.

See here for a tool that helps with deleting old and outdated versions of the .NET runtime/SDK.

For category 2 it is a bit more subtle. Generally speaking, you should always reference the base version of a Nuget package – e.g., in IdentityServer we always reference the 3.1.0 and the 5.0.0 version of the OpenID Connect handler. Let the consumer of your library decide on the exact version they want to use.

That is UNLESS you want to force the consumer to update their dependencies to a certain minimum level e.g., because there is a known vulnerability that has been fixed in a subsequent patch.

You then would update your own package with a patch version and publish again. Encourage your customers to update.

Application Authors

You are shipping the output of dotnet publish to your customers – in our case PolicyServer.

The story is a little different here. If you are publishing for the shared framework (IOW not self-contained) the advice for category 1 is the same as above. The customer/consumer of your application should patch their installation of the .NET runtime.

If you are publishing self-contained, you must patch your .NET runtime + SDK and re-publish your product. Then notify your customers that they should update their installation of your product.

For Nuget dependencies the story is also a little different. Here you are in full control of your dependency graph, and it is recommended you always use the latest patch versions of your dependencies.

Build Servers

One last recommendation. Make sure you use the latest and greatest build tools and runtimes on your build servers.

Sometimes it takes a couple of days after patch Tuesday before an updates SDK or runtime is pre-installed on a build agent. My advice would be to always install the latest SDK manually during build and in addition use global.json to specify your minimum required SDK with a roll-forward policy.

This way you won’t end up with an outdated .NET by accident (but rather get an error during build).

HTH – and thanks to Barry for answering my questions.

PS: Here is additional information for container scenarios (thanks John).