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