NuGet - Step 3

[JakobL-MSFT]

I’m not seeing any supply chain defence in here ‘ just randomly load some stuff from an dns which we hope hasn’t been hacked and install it’.

there are real attacks out there targeting this sort of mechanism.

Nuget (or rather .net) has some support for sig checking so you end up just hoping that the signing key hasn’t been compromised.

@rodwiddowson . Great point. For this specific example we are just drafting a way to build test samples, but it'd be nice to apply 'best practice' and who knows if the repo here gets copied for production. And this is a bit of a new world, so please tell me more? Would you be able to share an example of right way to do this or documentation?

References I was able to find (not quite sure how they fit in, but looks relevant):

• https://learn.microsoft.com/en-us/nuget/concepts/security-best-practices
• https://learn.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-verify <-- This looks interesting. Perhaps a call to NuGet -Verify on the packages we consume.
• https://learn.microsoft.com/en-us/nuget/reference/packages-config <-- Looks like this file cannot tie public signatures to packages.

[rodwiddowson]

@jacoble-ms I was hoping to learn from you!

My exposure to this stuff is much more in the Java world where we have built an entire tooling [1] to check not only the jars (dlls) that we ship but also the jars which are used to build the projects. Over time we have built a bunch of keystores based on unilateral trust where each key has been reviewed.

The learning process has been quite terrifying as you realize what an “open goal” this is, so I am a very quick to leap on people to make sure they have thought about it. Here is an example of an attack (but there are easier ones [2]

I saw this go by because as well as the Java stuff I have been doing File Systems for Windows for a long time (pre NT4) so I lurk on the driver-samples repo...

Anyway here’s all I know: I ran into the nuget problem when trying to build an installer using the nuget packages for Wix. I eventually ended up with a nuget.config which looks like this [3]. AIUI this ties us to one particular key (which no one has claimed ownership for yet btw) because we don’t really trust commercial PKIX.

I wrote up a PR for the WiX Guys which they didn’t want but it describes what I did and why and where I found the info. You can see it here [4]

I hope some of this helps. If you learn anything more please share it.

[1] https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/3269918721/Supply+Chain+Defence+for+the+Shibboleth+Java+Products [2] https://blog.oversecured.com/Introducing-MavenGate-a-supply-chain-attack-method-for-Java-and-Android-applications [3] https://git.shibboleth.net/view/?p=java-idp-jetty-base.git;a=blob;f=src/main/wix/nuget.config;h=0d2de2a5d690b09643984200708da9925aa8b56c;hb=29f8ed9994e64e51b56ad551900a598cb33e9b98 [4] https://github.com/rodwiddowson/wix-web/blob/master/src/Docusaurus/docs/tools/msbuild.md#defending-your-supply-chain