We've already got a way to patch zero days at the system level even if you use local NuGets. Fear not! This exists today, in fact.

How is this possible?

It is enabled for .Net 4.5.1 as explained here : http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-...

Will patches be installed on servers that have never run the application but have it deployed, such as DR servers?

The mechanism describes seems to imply they won't as Microsoft Update won't know the vulnerable assembly is sitting on the machine waiting for a failover.

Same applies if I have an old build of an application which I push; it'll be vulnerable until Windows Update kicks in to patch it.

If they are using semantic versioning, like they say that they will be transitioning to, a developer of a package could specific a major and minor version of .NET, and the latest patch version would be automatically grabbed.

This would allow updating a package's .NET Core dependency, as long as it's a functionality or security patch, without breaking anything inside of the application. Just speculation though :)

It's per-package semantic versioning, not one big version for .NET Core. So you could have an app which has dependencies all over the place - old versions of some packages, new versions of others. Say you have application A, uses System.Foo version 3.4; then you have application B which uses System.Foo version 3.9. They're both old apps, the current version of System.Foo is 3.12. Now we find a security hole in System.Foo going back to version 2.3. MS is going to patch and release updated versions of every one of them, in case some application is still using 2.3?

Apparently, the answer is yes: http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-...

It's not much different from the situation with statically linking C, is it? This argument was the exact one MS used over a decade ago explaining why they couldn't ship a linker for .NET. (And 3rd parties, including MS employees, stepped up to fix it.)

On the flip side, there's been few (none?) exploits involving remote code execution, except for loading code from untrusted sources. The other large ones that come to mind were a few ASP.NET security bypass issues.

So it's not like, say, someone statically linking JPEG reading code that allows code injection. It could be, as nothing stops unsafe code being published, but it's far less of an issue with managed code than MS has made it out to be.

It's also no different than the state with many bin-deployed libraries Microsoft has shipped for .NET in the past. But this is a radical change to the way .NET developers have to think about their dependencies on the .NET platform.

"Critical security fixes must be deployed quickly and holistically in order to be effective. We are fully committed to making security fixes as we always have for .NET."

So they apparently have some approach for this, but didn't really say what it is. It'll be interesting to see how this works - some form of machine-wide assembly redirects, perhaps?

I believe that they already have a solution and have already used it[1].

> This is the first release from Microsoft that uses Security Updates for .NET NuGet Libraries Support. This feature enables Microsoft to update app-deployed .NET NuGet libraries, for machines with the .NET Framework 4.5.1 or later version installed. This security bulletin was released on 10/14/2014 as part of the monthly “patch Tuesday”.

[1]: http://blogs.msdn.com/b/dotnet/archive/2014/10/28/asp-net-mv...

I hear that they still plan to have a mechanism for patching zero-day vulnerabilities. Don't know how exactly, but a slide in one of Hanselman's talks mentioned it.