 My name is Karan Nandwani. I'm a PM on the NuGet team. Today, we'll be looking at how you can secure a NuGet package ecosystem. In the recent past, there has been an increase in the number of supply chain attacks, and they have made the news. We have seen that there has been a propensity for using package managers as the mode of attack for some of these things. Today, let's recap some of these incidents and see what we can learn from them. So, Homebrew is a package manager that you can use to install software on Linux and Mac OS. There are many use cases here such as setting up a DevBox really quick with the essential tools that the new developer might need. Now, in this case, sometime last year, a security researcher was able to get access to the core Homebrew repositories. They had commit access to these repositories, which means they could have made a change, and that change would have flown to anybody that ran Homebrew update or recently installed Homebrew, and they would have gotten their malicious formulae. Now, the takeaway really here is that there was no way for the end user to protect themselves. So, really what we are asking is the tools that package manager should be able to detect if a package has been tampered and block installing such packages. In addition, there should be a way for package authors to stamp the identity on a package, and on the other end, for a package consumer to be able to validate this identity and confirm that this package truly came from who it says it came from. In a separate incident last year with NPM, the NPM account of the maintainer of a really popular package was compromised. The attacker went on to publish a malicious update that got into 4,500 accounts and got the credentials before it was taken down. Now, we should understand that this was not a fault on the NPMJS side. The attacker was able to get the password and username for the maintainer from a third-party leak and was able to reuse it to gain access to the maintainer's NPMJS account. So, the clear takeaway here is that username and password security is simply not enough. In a separate incident, an attacker uses a different vector to target package users. They published several packages that looked very similar to a very popular package which has over 2.5 million weekly downloads. These were all malicious packages that harvested environment variables from the victim's machine, and this attack went unnoticed for nearly two weeks. So, the key takeaway here is that popular repositories should be able to detect and block typosquadding attempts. In addition, there should be a way for users to define which publishers they really trust, and if a package does not meet that specification it should fail to install. Now, let's take a quick look at what does a typical NuGet workflow looks like and what are some of the best practices. So, let's say I have an awesome library that I want to share with the world, and the obvious next step there would be to create a NuGet package. The first best practice here would be to author sign it. Now, author signing it allows me to stamp my identity on the package, and on the consumption side, it allows the consumer to validate that this package really came from me. Next, I want to publish this package to, let's say, NuGet.org. Last year, we NuGet.org adopted MSA-based authentication which allows users to opt into 2FA. Now, setting up 2FA is really easy. It is literally three steps after you log into NuGet.org. Now, if you are an enterprise customer that uses Azure Active Directory to log in, you can ask your admin to enable 2FA and it's just that easy. As we have seen, enabling 2FA would have prevented several of these attacks that we looked at. The next step here really is to publish this package to NuGet.org. Now, when the package is being pushed to NuGet.org, we actively check if this package ID looks very similar to an existing package, and if it does, we block it from publishing at that point itself. After it passes that, and it does not look similar to an existing package, it undergoes several checks to see including virus scanning to ensure that this package is safe for consumption. Once it passes these checks, NuGet.org then signs it with its own repository signing cert. This way, you can be guaranteed that this package is truly coming from NuGet.org, even if you are using it through let's say, ADO using an upstream source or this package are rehosted on an internal feed, etc. Now, let's look, this was the publishing side of things. Let's see what we can do when you're consuming these packages. So, to begin, we have something called as client trust policies. This allows a package consumer to define policies that say I want to trust a package that has been authored by a certain author, or I only want to trust packages that come from a specific feed, let's say NuGet.org, and you can get more specific by saying only by these specific users or accounts. Let's take a look at a quick demo of how you can do this in your day-to-day flow. So, I have a solution that is NuGet.Cleaner. I've been working on this site project for a while now along with the new PM on the team, and I want to implement client trust policy. The first thing that I did here was add a new NuGet.config file, and this file is at the solution level. This is necessary to isolate the settings that I want to apply to this solution from the other solutions that I might have on my machine. So, the first thing I really want to do here is start validating signatures when the package is being installed. The way you would do that is by setting the signature validation mode to require. What this does is every time you install a NuGet package to any project in the solution, it will check that the package has a valid signature. Now, this happens at the time of a solution which means when the package is being extracted, it checks for this signature and then that point onwards that package assumed to be safe. Hence, it is a best practice to add a new global packages folder which is exclusive for the trusted packages that you want to use with the solution. The way you can do that is simply by using by adding a new key called global package folder and defining that folder. Now, let me quickly close the solution and reopen it so that the new config can take effect. All right. So, let's try to install some NuGet packages into this project. I'm going to try to install NuGet and sort of JSON and what do we have here? The package failed to install, although it has a valid signature. The reason for that is although we said we want to validate packages on the solution, but we did not really specify what packages or sources we trust. So, the next thing to do here is define NuGet as a trusted package source. The way you can do that is using the NuGet trusted signers command and you can say add a new trusted signer and say, NuGet at org and what this does is it'll go out to NuGet at org, figure out what is the right fingerprint for the packages that are signed by NuGet at org and insert in your config file. So, I'm going to once again reload my solution for the settings to take effect, and let's try to install that package again. As expected, this package now successfully gets installed. But what if you told me that I want to have more fine-grain control over which package owners on NuGet at org I trust? You can easily do that by specifying owners, and in this case, I'm going to say I trust James and K and I trust any package that is published by Microsoft. Awesome. So, let's reload our solution again, and we're going to try to install a bunch of more packages. So, I already installed Newton's out of Jason, I'm going to try to install this one for Microsoft. It should, since tells me license acceptance, goes through perfect. Now, what if I try to install a package which was say something like this, castle.core and as expected, it did not get installed because although it has a valid signature, it is not in our list of trusted signers. So, to summarize, client trust policies allows you, guarantees you package authenticity and integrity. That is, you're guaranteed that this package truly comes from who it says it comes from, and that the package has not been tampered with after it was created or published to NuGet at org. Now, in addition to client trust policies, you can also use lock file. What lock files do is they store the hash of the package content, and when a package is being restored, it validates this content hash against the package which is being restored. If the content hash does not match, it fails the restore and ensures that a bad package does not find its way into your NuGet dependency chain. To close the loop here, we have hosted a first-class and highly available symbol server on NuGet at org. This allows package owners to publish symbols using the new SnubKec format. The new SnubKec format uses a secure portable PDB for symbols. This also allows you to securely debug your NuGet packages. To make things easier, NuGet at org symbol server is listed as one of the default sources in Visual Studio. The added security here is that the DLLs in the NuGet have a checksum for the PDBs, which means that when you're debugging, the Visual Studio debugger will actually validate that this checksum matches and provides for a secure debugging experience. Now, let's take a sneak peek at what we have coming up in the next few releases. We will be integrating with GitHub token scanning service. What this means is, if you inadvertently checked in one of your NuGet at org API keys, within seconds, we will be able to detect that and disable that API key and also notify you. This will minimize the potential for malicious use of any API key that you might have leaked. Also, we are working on a new feature that helps you identify and flag vulnerable packages anywhere in your dependency graph. This includes any packages that you have taken, any packages, this includes your transit dependencies as well, and this will allow you to proactively update your dependencies to the ones that do not have these vulnerabilities and ship more secure code and applications to your customers. So for anything that we looked at today, you want to know more, go to AKMS slash secure NuGet, and we have links for everything there. That's all we have from the NuGet perspective. Thank you very much. All right. I'm excited to be here, Mika. Me too. So we have just come into frame because I was seeing some Spice Girls stuff over there, and they're like, hey Seth, the director's like, you need to go in there right now because you're not a very good singer when it comes to Spice Girls number one, and number two, you're kind of working and you're like, Seth, let's get in there. Yeah. Maybe do something. Yeah. All right. So what do we got here for a new post? Looks like we are done for today. Thank you so much for that. Thank you. The cool thing about NuGet, the cool thing about NuGet that I like is that it allows you to share code, but that's also the bad thing about NuGet. So it's good to have all of this infrastructure to make it a little safe. Do we got anything else in there? Yeah. Ryan actually is talking about securing NuGet packages that build super pumps about this session. Oh, so fantastic. So securing NuGet, like I said, the cool thing about NuGet is that you can share stuff, but that's also a bad thing about NuGet. Okay. So look, we are done in Studio A for today. Is that right? Yes. We are. Okay. So what we're going to do is we're going to now toss it over to Studio C. Yeah. So you can still ask questions on the.net.com hashtag, but I'm probably going to go home and have a dinner and then maybe go to sleep or something. Yeah. Take a nap, sink some more of Spice Girls. What we're going to do is we're going to have Jeff come in here because right now, come on over, dude. As he's coming, we're going to toss over to them. You had the party last night too, right? The after thing? We had the after party last night. Okay. Okay. Yeah. The after party party. Okay. And so were you wearing that? No. Okay. So now this time, we're going to have like an extra party. So it looks like you're muted right there. So why don't you talk into the small of my chest here? Hi, Seth. It's so good to see you. How are you, buddy? Over so that I'm not muted. Oh, now he's on. Am I on? Can you hear me now? Yeah. No, you were on before, but not with the mic. I see. We're professionals. So let's go show them where Studio C is. Let's go for a walk, Mika. All right, yeah, let's do it. So what we're going to do is we're going to go out here. I'll open the door for you because no one ever gets to see Channel 9 Studio the way I do. No. So this is Channel 9 Studio. Yeah. That was off. So let's come over here. Wait, come here. I want you to meet someone. Come here. Come here. Come here. Closer. Closer. This is Beth Massey. She is the one that did all of the work. We just stand around and look pretty. Here, look, speaking to this right here, tell... I love you all. Thank you so much. We had such a great event. And we adjusted the mic so that she could literally talk right into it. Right, do you see this? This was all planned by our wonderful studio people. So we're going to have you back up here. Let's come over here. Let's go for a walk. Let me show you all the buttons that they push. I'm going to try to push some buttons and if anything happens, just let me know. This is where all the buttons happen, right? This is the director here, Cameron, Cam Cam. Golnath tells us what to do and we do it mostly out of fear. So there is that. And so these buttons, she says, never to push, okay? This means that we're recording it, right? Come over here. So that way, at the end of 24 hours, all of this stuff, all of the hot little bits are going to be in your hands as well. So should we go back to studio C? Let's take a walk. Come on, let's come this way. I think it's about time. Let's come this way here. So you don't want to turn it back. Is that awkward for you? No, no, no. I got to come over here. So this is studio C. Obviously it says warning, anything in this room can be live stream. So we're going to go in here. So let's open it up. Here we go. Okay. Hello. Fantastic. Oh my goodness. This is now where the magic's going to happen afterwards. So why don't you come in here? Join us. Very good. Oh my gosh. So we're about to go live, live, 24 hours straight on Twitch, twitch.tv slash visual studio. If you're out there, if you're watching on Twitch, click that follow button. You want to follow along. You want to know what's happening because we've got lots more content after .NETCon for you. But we've got our crack team of hosts all throughout the day. You're going to see a bunch of folks hosting, showing content throughout the day, or every time zone. So they are telling me to wrap in my ear because I have a special earpiece that makes me get into really special places all the time. It's really fantastic. So we're going to wrap it up here with the .NETCon from Studio A. Oh, they tell me to keep talking. So Javier here is the other mastermind that you may not hear. Let me scoop down so you can talk into it. He does all of the website stuff and he brought up a beautiful dashboard. You're welcome. Hold on, let me get closer. You are welcome. Thank you. Thank you. So here's how technical we are. Look at this. Double keyboards. Two keyboards. Because I have to. This is a two keyboard show. It is a hunt. It's great. And there's more buttons over there. Look at all these buttons. There's buttons. Don't push this one. No, they told us that this will cause issues. It is not good. There's literally an X there that says don't push it. But I kind of want to push it. All right, no. So before we go, we'd like to say thank you for those that were with us in Studio A. We're going to turn it over to Studio C after a short little break but go to twitch.tvfrontslashvisualstudio to continue all of the joy and the fun. Make sure you tune in. See you there.