 Welcome, everyone. How are people feeling? Do you want a little stretch? Yes. Yes? We'll do a stretch? All right, everyone. If you're able and you want to join in, stand up. We're going to do the open source stretch. This will be great. So reach up for all your open source hopes and dreams. Now we'll go down. We'll reach down to the grassroots. Come back up. Arms up. We're going to sway in the winds of change. And now reach your arms out. We're going to shake the money tree. We need that funding. Put your arms on your hips. We'll lean right to avoid account takeovers. We'll lean left to avoid maintain a burnout. And now we'll lean all around to avoid unsecure ecosystems. Welcome, everyone. Good job. Thanks for stretching with me. I appreciate it. So yeah, welcome to securing the NPM ecosystem. Really thankful to be here today. Thanks so much, the organizers, for having me. I'm excited to talk to you all about this. I did want to start with some acknowledgments. Namely, Miles Borenz, who's on parental leave. He actually gave a talk. He picked this topic first, and I realized he gave a very similar talk before, so he let me use the slides. If you did see this talk before, don't worry. I added my own fun jokes, so you will still be entertained. But I also added a few other things. We've had some new releases since Miles was giving this talk. And to all those faces on the right-hand side, these are the people who actually did the work. I was a bunch of different teams from NPM, Security, Ospo, DevRel, the new packages security team. It's really exciting work that they're all doing. I wanted to share with you what they've done. Hi, I'm Abby. I did want to introduce myself a little bit. I lead GitHub's open source maintainer programs. I like this photo. I was trying to find a photo of me and my grandmother, my Lola, without my little brother stealing the scene, but this is the best I could find. I started my career actually in cancer research. I was writing web apps for scientists. And my grandmother, my Lola here, she had passed away from cancer. So this idea that I was helping other people, I was writing software that actually helped other researchers find discoveries and find curies was really meaningful for me. So that was really what got me into open source. Just seeing that the code that I was writing was being used around the world, that other people were making discoveries. And since then, I've spent my career just helping people do open source well from Mozilla and now at GitHub. And I'm really excited to be somewhere where I can actually help maintainers. So many of you are on GitHub. So happy to be there. I'm also joined the OpenJS board. Hello, OpenJS table this year. And it's been such a pleasure to work with you all and just understand this ecosystem more. So here's what we're going to talk about today. So first, a little bit of, like, why focus on security. How did we get here? That slide's weird. I'm going to look on this side. Then we're going to talk about 2FA enforcement and how GitHub really approached this in this maintainer first way. Because we are the stewards of the NPM ecosystem. So we want to do this in a way that helps security but also made lives easier for maintainers and just help the whole ecosystem overall. Next, there were some new releases this week. I'm really excited at the timing of this talk. So I'm going to talk to you about granular access tokens and Code Explorer, which both were released like two days ago. So you get hot off the press info there. And then finally, Sigstore and more, I'm excited about the future of NPM and some future work and some investments that we're making. So that first section, why focus on security. Oh, yeah. I was deciding whether or not to leave this in. I was like, is this a serious conference or a fun conference? I wasn't sure. But I realized it was kind of serious but needed a bit more fun. So here's a quote from Lady Gaga from New York. Trust is like a mirror. You can fix it if it's broken. But you can still see the crack if that mother of hers reflection. And to focus on here, I did want to focus on the positive. You can fix it. But also you want to prevent these cracks from happening. This maybe wasn't the best quote to include, but I thought adding some levity. But really the point I wanted to make there is that open source is built on trust. Like I'm trusting these open source maintainers who built the software that I'm running. I'm trusting the people I'm collaborating with. Trust is a really essential part of open source. So we need to be helping build up that trust however way we can. So at GitHub, like we are the stewards of the NPM registry we are really aiming to be good stewards. We want to help this ecosystem grow. We want to be able to make things secure but then also make things easy for maintainers. So it's a nice balance that we have to walk. So NPM is a critical tool in the open source software supply chain. NPM, yeah, I learned this style recently. The JavaScript community downloads over 2 billion packages from NPM a month, which is a time. Do people here use NPM? Yeah. We're in the JavaScript track, so I do expect so. So this is really a central for the JavaScript ecosystem. But there are some threats. So a big one that we've seen is account takeovers. This is where high impact packages, well, the credentials for an account gets taken by someone and they use it to publish malware. So looking at last year, there were a couple weeks where there were a lot of account takeovers in a short span of time. So it started in October 22nd. UA Parsard was hijacked and that has 1200 dependents and 7.5 million weekly downloads. So a lot of people are using this and downloading it. Someone got the credentials and then they were publishing malware with it and it affected a ton of people. And GitHub was able to take this down after about nine hours. So same day, but a lot of people were affected by this. A few weeks later, COLA was hijacked, which only has 166 dependents. It's a bit lower on the dependency tree, but it does have nine million weekly downloads. So still a ton of people affected by this. But we were able to remove that in 30 minutes, which is great. And then less than two hours, probably about two hours later, RC was hijacked and that has 1300 dependents and 13 million weekly downloads. And that was taken care of in 15 minutes. So you can see we got a lot better going through this. So looking at what we learned from this, first is that these improved process policies and notifications worked. So after that UA parser, we're on high alert. So we added a few things. We already had malware scanning, but we added better notifications, especially for high impact packages, where they had over a million downloads or over 500 dependents. So that helped a lot. We had better policies in place and better processes. So internally, all hands were on deck when this happened. So we were ready to do that, to take care of that. So you can see going from nine hours to 15 minutes, it really worked there. Next, we saw a pattern of account takeovers. All of these accounts had stolen passwords. So we saw that strong 2FA may have stopped this. And then finally, we saw that we really needed to stop these attacks to build trust. People lose trust every time there's a dent in the armor. So doing what we can to really build up that ecosystem and make sure that people are comfortable using NPM was really important. So we'll talk about how NPM really enforced 2FA in a maintainer-friendly way. So the plan actually started not with enforcing 2FA, but with better login verification. So for accounts that didn't have 2FA enabled, making sure that there was login verification through a one-time password for new sessions. Next, there was also mandatory 2FA for high-impact package maintainers. I'll explain how we did that in a way that still was nice and friendly for maintainers. And then finally, there's a few things in this one, but just making it easier and nicer to be using 2FA. So improved 2FA experience and better account recovery, because if you have 2FA, I'm sure... I don't know, actually, I've been locked out of my 2FA accounts before, and it's always very stressful for me. But more people using 2FA, more people need to go through the account recovery process. So I'm going to walk through these things. First with login verification. If you have a non-2FA protected account, you were emailed a one-time password. So again, this is not 2FA, but it did add an extra layer of security that wasn't there before. And it's great for email verification. So this made sure that you actually had, yeah, access to that email for that account. And we started enrolling that about a year ago, like shortly after the account takeovers from that previous graph, and March 1st that was introduced for all accounts. So that's there now. And again, it's because improving security is a trade-off between usability and security. So this was a nice way to just level up beef-up security for everyone across the board without adding too much friction. And then next for the 2FA enforcement, we really wanted to focus on those account takeovers. So the enforcement was only for creating new sessions. So if you were logging in from somewhere new. So we encouraged 2FA for publishing, but it wasn't enforced as part of this campaign because we were really thinking about those account takeovers. There was a phased rollout, so we could learn from this. So we started with a smaller set of maintainers and then grew that larger and iterated on it as we went. And we really kept that maintainer first approach. We didn't want to disrupt everyone's workflow. That's always annoying, and then, yeah, you don't want that. So existing access tokens continue to work. And publishing until 2FA is enabled, new sessions couldn't be created. So they were kind of in limbo if they were a high-impact maintainer. They could still sort of publish, but they couldn't do anything new like change their password or anything. All right, so here's a little update on 2FA adoption as of yesterday. So for the top 500 maintainers, 88% of them have 2FA enabled. The top 100 maintainers, 91% have them enabled. And then for just the general high-impact maintainers, which, again, that's over a million downloads a month and over 500... Oh, no, it was a week, a week. And over 500 dependents, 79% have those enabled. So we see this ticking upwards. It keeps increasing. And we don't expect this to be 100% because, again, we're trying to be nice around how we're setting this... having this adoption happen. And most of the ones that haven't adopted yet, a lot of those are, like, inactive accounts. So it's working, 2FA is coming along, even though we're very gentle about it. And then this improved experience around 2FA, so that improved 2FA experience and account recovery. The big one was using WebAuthn. So this way before, 2FA was only your phone with those timed tokens, which always really stressed me out. I could see it, like, counting down, and it's like, oh, am I going to get the number in time? Then I wouldn't, and I'd be so frustrated. But now, you can use Ubiquit, you can use your finger, your pass, your fingerprint, probably not your actual finger. You could use a whole bunch of things. So this was a great improvement in 2FA. Next, better 2FA management. You can manage multiple keys. You can replace your Authenticator app without disabling 2FA, which is great. And you can also view and regenerate your recovery codes. I'm that person who never remembers where I save my recovery code. They're just all in my downloads file. Please actually put them in something like one password. I'm learning, but I... Yeah, I just have that downloads folder that's just full of files from the end of time. Who knows what's in there? But this way you can regenerate them. It's great. And then another big investment was 2FA for orgs. So this way you can enforce 2FA for your org members if you are an org admin. And you can audit to see who has 2FA enabled within your org. So we don't publish who has 2FA enabled on their public profile, because that would just be a huge sign and it's like, take over my account. But this way we thought org owners should have that information so that they can enforce that so that they can trust their community. And then for that improved account recovery. So if you did get locked out, they added new playbooks that were reviewed by account security experts, and they added consistent processes across all account recovery. I thought this was interesting. They're really inspired by the DMV to have a point system to measure, like, how many factors of identity you have and, like, is this enough trust that's, like, similar to 2FA? So if you had, like, email verification and you linked your GitHub and Twitter, it's like, okay, this is probably who they say they are. We'll let them have their account. And before, it was just, like, text boxes where you put your GitHub and your Twitter, but now you can actually verify them. And then we automated a lot of that. So if you make an account recovery request, it'll automatically walk you through the process of verifying your email, verifying your GitHub, your Twitter, so that when you get to that agent they can just, like, use that point system, like the DMV, and say, like, oh, yes, this person is who it is. Whereas before, there was a lot more back and forth, like, can you tell me your GitHub? Can you tell me these things? So that's been great. And then new releases this week. These are a couple things I'm very excited about. Oh, I'm going so fast. That's okay. Well, I have more time for questions. First is granular access tokens. So that's the public beta it's now. It happened a couple days ago. So you can create access tokens that limit the access. So you can limit it by package, by scope, by organization. You can also set expiration dates up to a year. And you can also limit it to an IP range. And an interesting thing I thought I was reading the blog post. Orgoners can now automate more org management. You couldn't do that before with the tokens that were generated, but with these new tokens you can. So super helpful. And there's a lovely animation walking you through what that looks like. So you can use these new access tokens. Next is Code Explorer. Because, yeah, we wanted you to be able to view the contents of a package without having to actually download it, run NPM install. So this way from NPM portal, this used to be a paid feature, but now for free everyone can just go to that tab. And then you can view the folder structure. You can click through to an actual file. And then it has syntax highlighting for JavaScript, TypeScript, a bunch of other things. And, yeah, it's a nice way so you can actually verify this before doing other things. But wouldn't it be great if there was a way to automate all that or to automate the verification, which is some of the new stuff that people are working on. Sigstore plus more, I called it, because I liked how it rhymed. It's some future plans and investments. So first, Sigstore announced general availability about a bit over a month ago in October. So this is the new technology for signing, verifying, and protecting software supply chains. And I'm really excited about this because the first thing people do when you're securing your build, you usually sign it, and then you have to keep hold of this token and keep it a secret. You have to rotate it, and did you generate it properly? It's a lot of work. I see some nods. So there hasn't been a wide adoption of the Sigstore. If you're building on a Cloud CICD provider that supports the OpenID Connect tokens, it can do keyless signing for you, which is great so you don't have to keep hold of that key, and then it stores things like the repository this came from, the commit that this is actually coming from, and the build instructions. So right now in an NPM... Oh, that's the next part. So it stores a lot of these things. And GitHub's really partnering with OpenSSF on this and helping with the Sigstore. We're also working with other CICD Cloud providers just because we want other people to adopt this. We want this to be part of the ecosystem. So here's a proposal and this will probably go into public beta. The plan is Q1 2023. So next few months or so. This way when you're looking at... Right now when you're looking at a registry... Sorry. Yeah, this is the part that's the least. It's exciting stuff but it's very technical. So right now if you're on NPM, you're looking at a package you can optionally add a repository that it will go to, but it's optional and it doesn't say which commit it goes to. But this way you can link the packages to a source in the build. So if you're building on a Cloud CS CD and you use Sigstore then yes, this will be added. So this will be optional if you want to opt into this. But this will really help with the provenance. So this is a good first step for that end-to-end supply chain security. So excited to see that happening. This is a screenshot of a request for comment that was out. It is closed now, but you can go and look at the proposal. You can read all the comments from the community and it's exciting stuff. So let's wrap us up. So what's next? This is a slide from Myles again. So the team is really thinking in three different areas. First is that core security improvements. How are we going to be securing what we're doing at NPM. Next is the customer requirements. And then the big thing I want to talk about is innovation. I think that's where we're talking about Sigstore. But how can we be making NPM useful for JavaScript five years from now and not just from today, not just being reactive to things like account takeovers, but really forward thinking. And I'm excited that we have a package of security team that's really thinking about this and a lot of people working on this. So to close us off, thank you so much. We have 12 whole minutes for questions and comments. And yeah, you can find me online. I'm Abby Cabs with GitHub and Twitter. And yeah, thanks for your time, everyone. Sorry. Oh, so like the account takeovers? We're talking about like, yeah. Well, that's what like two factor and so the question was like, how did we mitigate the account takeovers? All of these, all of this work was to help mitigate that so that stolen credentials couldn't be used to publish malware. So first was increasing our processes so we'd be more responsive to an account takeover. So that was the one thing that's how we saw those times go way down and just making sure like all hands were on deck if something like that happened, especially to a popular package. And the next was trying to make sure that doesn't happen again. So if we go back to Lady Gaga at the beginning, so the next part was really like making sure we didn't have cracks in the first place rather than trying to patch them up. So this was beefing up the security for logins. And then I think the six store stuff would be more for later, like if it did happen being able to track the provenance and understand why this happened. Did that explain? Ooh, can we publish the security score? I am not a security expert. I probably should have said that at the beginning of this. And also I'm not always the biggest fan of scores. It could be hard to balance those what goes into that and the factors that goes into that. But I'm sure someone could create a score. I don't know if someone here has any ideas. That's great. I don't know if everyone heard that, but OpenSSF has security score cards so you can integrate that with GitHub. Yes, I probably should have said that at the very beginning. I'm not a security expert. I'm sharing what a lot of work was done on NPM and security. You can ask me about maintenance questions also if we want to chat. Anything? Yeah. Yeah, so we're not going to say which ones don't have 2FA enabled. I think that would not be good. What is interesting is the high impact maintainers they make up, I wrote this down on one of my notes. I forgot to say it. I think they make up 93% of the traffic of the downloads on NPM. So we are really pushing on those 500 top maintainers to get adoption. Visibly, I think we're going to continue pushing for 2FA there. But then things like the six-store integration I think will help a lot. Yes. Thanks. Anything else? Yeah, yeah. Yeah, so that's part of the Webathon that was implemented there. So yeah, you can use different forms of multi-factor authentication depending on where you are. Yes. Anything else? I went super fast so you can ask me all the questions you want. But with that I think we'll call it. Thank you all so much. Yeah, I had a great time. Feel free to find me after this.