 I'd like to thank my colleagues for making this much more awkward. OK, so we're here to talk about creating a secure open source project on GitHub. And so if you're here, and if you're attending, you're probably wondering why my slides aren't advancing. And you might be thinking, hey, I have this cool thing. I'd like to open source it on GitHub. And I listened to the talk this morning, and then I started thinking about, oh, oh, crap. Well, how do I make sure that this thing is actually secure so people don't start harassing me about some issues that I'm causing? Not only the security of maybe all the other little NPM libraries or other, depending upon what language I'm writing and bring them in, but the code of myself. What am I writing? Am I actually doing this in a way that people are going to get angry at me with? And inevitably, a vulnerability might occur. So how do I respond when that happens? How do I make sure that I set up my repository in a way that I don't invite people to start creating zero days by opening up an issue and disclosing to the world how insecure my project is? And then lastly, you might be thinking, well, hey, how do I make it easy for people to contribute and do the right thing in my project? Because I don't want to be the one poor person who's got to maintain this thing long term if it gets really popular. I want to invite others in to do this with me. All right, so if you have those kinds of questions, you're in the right space. If not, you know, I won't be offended. I've given talks and had lots of people walk out on me before. My name's Phil. I'm with GitHub. I've been around at GitHub a while. I'm serving as our field CTO for places linked by the Darien Gap. I'm a bit of a geography nerd, so basically continents ending in America. I jokingly refer to my title as being the chief nerd on the revenue team. But when I'm not shilling for GitHub or talking about open source practices, you can usually find me in Minnesota hanging out in my kitchen, making food with my kids, baking bread, and it's wintertime now, so I'm excited to be out skiing very small hills since we don't have mountains within a thousand miles of where I live. All right, but I did mention I'm on the revenue team, so this is a bit of a sales pitch, and I am encouraging you all to spend exactly that much money on your open source projects. We make a lot of things available to you for free because we wanna make sure that open source is secure and robust and viable for everybody. And if you like it a lot, maybe you'll pay us some money for your private code too. That's the end of the sales pitch. All right, so carrying on. What we're gonna go through here and talk about from a high level are, how do I go about securing the dependencies in my open source project? How do I go about securing the code in my open source project? What happens when that vulnerability is reported? And then lastly, make it nice for people. If you had a chance to hear my colleague, Sarah, talk this morning, she could go ahead and do a little bit more depth that I'm gonna go to on the first two bullet points. So if you heard that, this will be a review. If not, this is your first intro to it. So let's talk about securing dependencies. And most people are not writing their software from scratch. You're pulling in some dependencies from somewhere because we wanna keep our code as dry as possible. And open source vulnerabilities are still a problem. A couple of years ago, this statistic was at 90 plus days for a meantime to update based upon a vulnerability in an open source package. We are down to about 28. So yay us, but it could still be a lot better. So what should we do? Well, if you have an open source project on GitHub, you can take advantage of a free, again, the sales pitch here. We're making tons of money. Capability for your repository known as Dependabot. Dependabot will do three different things for you if you want it to. And we're gonna go through right now and just demo how to do those. So slide right over here at this direction. This is a repository we're gonna be working with. It's a fork of node goat. If you're not familiar with node goat, it is a deliberately insecure node web application used to test a lot of the oh lost common vulnerabilities, which we're gonna see pop up all over the place as we go through this process. All right, so I am an administrator here. This is my open source repository. It's public. You could go harass me right now on it if you want to until I delete it after the end of this presentation. I'm gonna click on settings. And over there on the left hand side, as I scroll on down, there is a code security and analysis. Little place to click on. Let's go ahead and do that. And when I look at this right now, you'll see first and foremost, we have this thing called the dependency graph. And because this is a public repository, it is enabled by default. So what is the dependency graph, you might ask? Well, GitHub goes and crawls through every single public repository, as well as any private repositories that have opted in. And we take a look at your package manifest for your package manager. We then create a graph. So we know everything that you depend upon. We know everything that depends upon you. Why do we do that? Well, when a new vulnerability comes out, we can immediately figure out who's using this package and start sending them the alerts that we're gonna start opting into here. So this first little button right here, Depend About Alerts, just lets me know when I'm depending upon an insecure package. Just kind of that little helpful thing, hey, you might wanna do something about this. That can be helpful enough in itself. I'm gonna click on the second one right here. And what the second button is gonna do is it's gonna start not only alerting me, but it's gonna open up pull requests to bump me to the lowest secure version of the package. The key word there being lowest secure, not a lot of people wanna buy that first model year vehicle. Not a lot of people wanna test drive the next major release of a particular package. So that sounds pretty safe to me. I'm gonna need to turn on that first one because it was cascaded, we're gonna click Enable. The third one down here, if I wanted to go ahead and click on it, would also create those same pull requests every time there's a new version that comes out. So if I wanna be kept up to date and at least alert, hey, there's a new version, we can create that pull request. If I've got CI tied to my project, which we'll cover here in a little bit, it'll start kicking up those CI jobs, making sure your build's not breaking. And then it'll allow you to opt in to that new and updated version of the dependency when you want to. Okay, so this sometimes works and it sometimes doesn't. So we're gonna see if I need to fall back on my cooking show demo skills here. So we're gonna go ahead and click on the security tab again. Nothing quite yet. All right, so before this demo, I went ahead and ran all these processes again. These alerts usually pop up in 30 seconds to two minutes. We're getting closer to the two minutes here. You'll notice here on the left-hand side, we have some Dependabot alerts that came in. And as I had mentioned, this is a deliberately insecure application just to highlight the capabilities of any sort of security tooling, but these are the alerts. And if I go take a look at the pull requests, we can see that we have a number of pull requests that Dependabot has opened up for me to start fixing all of these particular vulnerabilities that I am now depending upon in my packages. So when we open this up, particular one up, Dependabot will tell us a little bit about what's going on, will show any release notes associated with the package. It's also going to show what commits are in there and then run any of the other checks that I have in place. Again, nice helpful way to keep up to date. So Dependabot users patch their dependencies on average 13 days faster. That's 13 fewer days. You have to worry about somebody knocking on your door saying your open source project is insecure. If you're using this package in production, that's 13 fewer days, you have to worry about that. All right, so even though we're pulling in all these dependencies and probably 90% of the code is just other people's open source code, we're still writing custom code on top. So it's worth talking a little bit about fixing the human error problem. That could be a nickname for me when it comes to some of my code, but 83% or so from what we've seen in our data the 521 sample vulnerabilities are caused by the human error problem. So it's important to scan the code that we're running. And again, going back to that free mantra from earlier, you can use GitHub's code scanning tools that we provide free of charge for any of your open source projects. You can integrate with other free or commercial scanners that are out there to have the same unified experience and build that whole thing directly in the pull request. So what's that look like? Let's switch back over to my deliberately insecure repository over here and set something up. So I'm gonna go ahead, I'm gonna click on settings here again or actually I'll click on security. And you'll notice over here, this is what I get for having the cooking show version and the non cooking show version, there we go. All right, so under security we've set up our dependent bot alerts. Now I'm gonna click on this little button that says set up code scanning. All right, so we don't have any code scanning set up here in this repository yet. Let's click configure code scanning tool. And it's gonna give me a list of a lot of different code scanning tools that are out there. Some of them are free. So if you have Terraform in your project, you might wanna use TFSEC or if you've got containers, you might wanna use Trivi. We're gonna go ahead and use this code QL analysis one and I'm gonna click configure right here. What this is gonna do is it's gonna create a GitHub actions workflow for me and it's gonna run the code scan directly in actions. If you're using an interpreted language, you can just go ahead and click start commit and commit that file directly into the repository. If you're using a compiled language, you're gonna, it's gonna attempt to auto build it. If you've got some particular arguments that you need to supply to the compiler, you can do that right here within this workflow file or if you've got another CI tool, we can kinda integrate this process directly with that CI tool and have it still work. Okay, so this does a couple of things. It's gonna kick off a build. It's gonna run the analysis. We're gonna switch back over to the cake that I can pull out of the oven and if we go into the security tab here, we can see that we have a bunch of code scanning alerts and those code scanning alerts are all coming in from the built in GitHub code scanner. Yeah, this one's looking pretty bad. Again, deliberately insecure. Okay, so this is just a nice bit to understand kind of where am I at? But as contributions are coming in from people you don't know, maybe it's a colleague, maybe it's some random person you've never met halfway around the world, we wanna make sure that those commits and those proposals to the code base are as secure as possible and we can build that experience directly into the pull request. So I've got another project over here that I wanna highlight just what that experience looks like and I've got two open pull requests. Some shady developer called P. Hollerin is trying to add a search capability to this particular Java application and all sorts of checks are passing but there's this big old red one right here that the code scanning is failing. Again, we can build these PR checks directly into these open source repositories and I as a person contributing to this repository need to go ahead and make sure that all these checks are passing before you're gonna accept my proposal in. So go click on details. I get some helpful information about what's going on. This is query built from user-controlled sources AKA SQL injection and it'll let me know exactly what's going on. I can take a look at all the paths through the application, get a lot of data, get a lot of data, get some ideas to fix it. That allows the contributor to then go ahead and update their pull request. We can see here this one has the same failing check from before. This one I went ahead and implemented the correct way to manage this data in Java which was to use a prepared statement to not pass it directly to the database. So that all looks good. Now everything's all green and we can be merged. So we can use this technology and these code scanning patterns to make sure that the proposal coming in from our community are as secure as possible and the nice thing is we don't have to be the humans telling potential contributors, hey, your code's bad. We can let the bots do that for us and we can be the nice helpful people that help those contributors get their code into a good state and not the person who arbitrates your code is thinks you really should be fixing it. I prefer to let the bots do all the shaming for me. So what do we find? Really across wherever GitHub Advanced Security GitHub code scanning is used, 74% of code scanning findings are fixed in the pull request before they're ever merged to the mainline branch. Again, a significant improvement over what we see in a lot of other workflows. All right, two, you did your best. You made sure your dependencies are secure with the pendabot. You made sure that you're running code scanning on your repository, but new novel vulnerabilities are discovered. We find new things we didn't know about before. Somebody found one in your repository in your project. Crap, what do I do? That's where we wanna make sure that we have a process in place to prevent the accidental disclosure of a zero day. We wanna have a defined path for reporting and we wanna have a way to have you as a project maintainer securely collaborate with whatever security researcher helpful passerby opened up that particular problem to work on a fix in private before you start alerting the world that hey, I've got a problem, but don't worry, I already have a patch. So let's figure out how to do that. The first thing we wanna do is we wanna establish a security policy. And a security policy is basically something that shows up when a developer is interacting with your repository. Go back this way. And they may be going to VS code and they're clicking on a new issue and they see this report a security vulnerability bit right here and I need to go and I need to view the policy so that I know exactly the right and correct and responsible way to disclose what I believe to be a security issue with this project. So the way that I do that in GitHub is I'm gonna go to my settings again, go down to code security analysis and as I continue scrolling on down, whoops, oh, this is again, sorry, wrong one, settings, code security analysis right over that go. So we're gonna do this the other way. We're gonna go into security, we're gonna establish a security policy, set up a security policy right here, click start setup and it's gonna create a markdown file that it's gonna populate into our repository and then as soon as we start with that security policy setup, you can put in the details here, we're gonna automatically start suggesting to people throughout the UI, is this a security issue via the security policy? Open up a security issue, view the security policy. The reason you saw me bouncing back and forth is we kind of have some secret GitHub stuff we're working on with a couple of projects right now that you'll be able to opt into soon where we automate that process for you a little bit more and that's what something we're calling private vulnerability reporting. So if I go ahead and click here and enable that, what we're gonna do is automatically create a new issue type for reporting directly into GitHub so that we can collect a little bit more information in a formal form. The Electron project is already using that so if I go over here to issues and click on new issue and then go down to report a security vulnerability, you're gonna see a slightly different experience here where I can get a little bit more customized bit, get a little bit more information in, you'll see some of this stuff rolling out here pretty soon and I wanted to give a chance to show a little bit of both what are happening. So now that's great, we have a security policy. We're pretty much ready to go but somebody reports in an issue and we need to start working on it to fix it. So that brings us back to the need to ultimately open up a draft of security advisory. We need to start getting ready to alert our community that we have a known security issue and we need to do that in a formalized way. So again, as an administrator, right here on the security tab, I can go ahead and click this view security advisories just to the right hand side over here. I don't have any security advisories for this one right now but a user has responsibly reported something that I need to start working on. So I'm gonna go ahead and click new draft security advisory and I'm gonna start filling in some details with one hand here so this could be interesting. So stuffs bad but not that bad. Okay, we're gonna go ahead and request a CVE ID later. GitHub is a CVE numbering authority and you can request a CVE be issued for this project directly by GitHub. We're gonna go ahead and just drop some placeholder text in here. Didn't know if I'd have one hand or two, I clearly only have one. This is an ecosystem, this is an other. The package name is gonna be foo. Our affected versions are 1.1, that should not be in there and then patch version is 1.2. Okay, severity, unknown pending selection, we're gonna go low and then we can go ahead and create a draft security advisory. This has not been released to the public yet. This is for me to continue working on preparing this with others in my community, with any of the security researchers that have reported in and then as I scroll on down here, there's a new button that shows up and this says collaborate on a patch in private. We need to have a way to work with others, trusted people in our community or the researchers who reported it to work on a fix so that that fix can be rolled out immediately when we release this notification of vulnerability. So I'm gonna click on that button and what that's gonna do is that's gonna create a temporary private fork. It is temporary, it is private. If you were to dig under the covers, it's technically not a fork, but it's a repository where I can then start individually adding people to it right here to collaborate on a patch. This is that particular repository. I can go use the temporary private fork that exists to start adding collaborators to it one-on-one. When we get done, when we're ready to ultimately release a CVE to the world, there's that request CVE down here and we can request the CVE, click the button, we'll get the CVE. Once we get that, we can go ahead and publish the advisory out, notify our community that, hey, there's a problem, it's bad, but not that bad and we've got a fix ready for you. And of course, if this is an open source project, which it is, and it's a part of the security, excuse me, part of the dependabot and therefore part of our dependency graph, we automatically know all of your users that are using this particular one and we can start directly sending them not only those notifications through dependabot, but if they have opted in, dependabot can start opening up those pull requests for them. So, we've now covered, let's make sure our dependencies are secure, let's make sure that the code we write is secure and let's make sure we've got our bases covered for when we're proven to not be as secure as we thought we were because of some new discovery. A little bit on the side, just to toot our own horn a bit, we've issued a lot of CVEs already in 2022. We are the, I believe, the second largest total CVE issuer, but of security vendors we've issued far more, largely due to the fact that the open source projects are already out there on GitHub. All right, so the last thing I wanna cover is how to make your project a little bit more friendly because one of the best ways to encourage and make sure that our projects are secure is that more people are using them. The more eyes on the code, the more people there are spotting it, the more people there are to potentially raise security issues and the quicker we can get them patched. This is the same reason why encryption algorithms are public and the keys are private. So, I want to contribute to this project as an individual, but how do I get started? What do I do? What do you need from me as a contributor? How can I help? What are the norms that this community operates under and how do I make sure I follow them? And how do I install this thing and actually get it running? So, with that I wanna highlight just a few things that GitHub offers. The first is a contributing.md document. And so if you create a contributing.md document and you drop it in one of three magic locations in your repository, either the root, the docs folder, or the .github folder, what we're gonna do is every time somebody goes to create a new issue, we're gonna show them a little modal right at the top. This is, hey, welcome to Electron Electron or hey, welcome to my project if they have not contributed before already. Hey, if you've got an idea, you might wanna go read our contributing guidelines. And that's where you can spell out basically how you want to interact with your community and your project. What are the ways that you expect people to contribute? What are your documentation standards? What are your norms within the community? If you want to, you can translate it into multiple languages and the languages at the top. And it again just sets those rules of the road so that people know how to behave within your project. The next thing that I wanna highlight are some issue and pull request templates. You saw me back over here in GitHub a little bit earlier in a repository. So we'll just pick one VS code. And when I go to issues and I see that, hey, maybe I should review their contributing guidelines. That sounds like a good idea. Then I decide to open up an issue. There are a couple of standard issues that they've set up that are ready to go that are asking me for the information that the community needs in order to triage whatever I'm reporting and start working with me. Those are all defined, whoops. Those are all defined in your repo and can be configured right in your settings page. Just go to repository settings, scroll on down. Once issues are enabled, you can click set up templates and set up the markdown documents for your repository directly in the interface. Another useful thing, if you create a label called good first issue and you start applying that label to issues and pull requests across your project, we're gonna highlight that for you. So again, relying on VS code. When I come to VS code, I can see here not only are they inviting me to read the contributing guidelines, but it looks like they've collected some good first issues for me. So I'm gonna click on that. It's gonna take me directly to a contribution page and it's gonna highlight how can I get started and how can I start contributing in a meaningful way to this project without necessarily having a ton of knowledge about the project. Again, all you gotta do is create that good first issue, start applying it to your issues and pull requests and we'll start highlighting that information for you. Okay. Couple other interesting things to highlight. Maybe you wanna make a quick change or your community wants to make a quick change and they don't have a full development environment at their hands. In browser, they can just hit the dot key and then we're gonna launch VS code in github.dev and you're gonna have a full VS code environment, edit it or ready for them to just start editing your file that they can commit in. But you might need a little bit more than that. You might need access to a terminal to run some shell commands. Maybe you need to actually interact with this application. And for that, we have something called github code spaces. Github code spaces are a hosted developer environment. Come with VS code, they'll run any Linux application you want to. You can write your code in the in browser VS code or if you wanna connect to it from your local VS code or you wanna SSH into it and use Vim or Emacs or whatever you can do that. The nice thing about a github code space is we can define that entire environment as code. What packages are needed? What are the install scripts? What else has to happen in order to actually package this application up and make it run in a uniform environment? Now I as a contributor don't need to worry about installing all my dependencies somewhere or worrying about conflicting with something else on my machine. I can go ahead and launch that in a code space. And because again I said everything is free and without a price here, we do provide 120 core hours per month per user on github.com to go and contribute to open source projects. The minimum core machine is two cores so technically it's 60 hours of free programming or far fewer if you wanna start running a huge GPU machine but we'll give you the opportunity to do that. All right, so that's code spaces. The last thing I wanna point out is actions. We went through and you saw me run some of those code scanning jobs in actions. Actions is a general purpose automation tool. You can do your builds, your tests, your deploys, whatever else you expect to from there and have that built into github. But what makes it unique is there are a lot of ready to use workflows from the community that are already out there. So we at github support some of these building blocks confusingly also called actions that we provide up to the community. The Azure, the AWS, the GCP, the Hashicore teams all write their own actions to integrate their products directly with github. And then the community has written 10,000 plus interesting useful ways to automate work. Whether you're an open source maintainer and you wanna do issue maintenance with an action that goes through and checks things on a scheduled basis. Or you wanna have just a simple little thing that welcomes people to your project and it says, hey, I'm glad you're here. The humans will be with you in one to three days but enjoy this cat gift. They're already out there ready to use. And again, because I said everything's free for any open source organization, we're gonna give you 2,000 minutes a month to run your automations, run your builds, perform your code scans to make sure that you have the most secure open source project possible. So with that, I just wanna say thanks for coming on out. I have not been keeping an eye on the time. Looks like I might have about two to three minutes for questions if there are any. And if not, thanks for coming on out and enjoy the rest of the conference. Bueller? Please burn our server time. That's all I'm asking. Thank you. Thank you very much. We're glad that you're getting these. Are you using them on personal projects or open source? Are you using them on personal projects and on your work? Wonderful. I just met her, she has not been paid but please come see me about getting a T-shirt or something for saying that. I'm not kidding about that either.