 All right, test, test. Can you hear me? Thanks, everyone, for coming. I'm Jeff Mendoza, and today I'm going to talk to you about that. You can read that. So first of all, I'm going to tell you a little bit about myself. I'm an engineer on Google's open source security team, and I work on securing Google's GitHub repositories. Also, I'm a contributor to the open source software foundation. That's that cool-looking goose with a shield. And I'm a co-chair of a working group with Amir here. And also, I contribute to the Allstar project, which I'm here to talk about. And of course, if you see me after this talk, feel free to approach me, ask questions if you want to learn more. OK, welcome, Ospoites. I think that's the term. If you all adjacent to Ospo or work on Ospo-like things, welcome here. I really appreciate all the work that you all do. I know Ospo works a lot on compliance, licensing legal requirements. That tends to be one of the first things. Or releasing your organization's IP, making sure that you don't release your secret sauce, developing processes and procedures there. And then potentially on open source and gestion, if you have a process that you want to make sure that this is relevant or good when you bring that in. So welcome and thank you for all the hard work. But here I talk a little bit about what we do in Ospo, but not why. And the real reason why is because we all love open source. And we believe we were rightfully so that developing software in the open is the best way to produce the best software. And then we go to our organizations and advocate for those benefits to the other people in our companies or in our groups. And thank you for that. And also, when doing that, we also sometimes have authority or administer our organization's open source presence in the community. Typically that might be our GitHub presence or wherever else we publish our code and write guidelines and policies for how to present and what rules we might need to have that presence. So again, we love open source. We advocate for it. We want to convince people that haven't been convinced yet. Hopefully those are getting fewer. But what's a nightmare scenario for that mission that we have in our organizations? A security incident related to open source. So if the big execs see that this is dangerous, maybe they're going to put a damper on and say, yeah, you shouldn't be releasing as much open source as you're doing or contributing or whatever we do. So for those of you not super plugged into the security community, this is a very basic diagram of what could happen to your organization. You produce a really cool open source project internally. Our project internally that you think would benefit from open source development and getting contributors outside your org. You open source it. A malicious actor puts in a back door, whether into the project directly or somewhere in your release pipeline. And then that project that's maybe used by your paying customers or your consumers is then ingested. And those people are compromised due to your open source project. So an example in March of last year, the PHP languages get hosting servers were compromised and attackers added a back door to PHP that enabled remote code execution. Fortunately, the commits were detected and reverted before it made it downstream to users in that case. What I'm describing here, as many of you may know, is a supply chain attack. And a really basic definition of a supply chain attack is a malicious compromise in a project that is then used to compromise downstream systems. And in here, for us Ozpolites, we're talking about our open source projects mostly. Of course, this is a buzzy thing right now. You've probably heard a lot about it. There's a co-located conference track happening right now. So yeah, it's the buzz right now. But in the past, open source has been safe from these supply chain attacks. Typically, open source security in the past was somebody made an accidental bug that's found to be an introduce a vulnerability that needs to be fixed and that fix needs to be pushed to downstream. But that's not the case any longer. Attackers are attacking open source deliberately to introduce bugs, introduce vulnerabilities. And that's on the rise. As you can see, the up and to the right chart here. So yeah. And then this other chart, you may have seen this yesterday morning. But these attacks are happening. And they're targeting open source. The recent CodeCov attack shows how supply chain be exploited. So CodeCov is something that happened. It was an attack not of the actual repository, but of the way the CI system that's attached to the repository. And then the resulting bits were compromised. OK. So jumping back to a little bit about me, I'm here giving you a talk about security. But I'm not a security researcher. I don't dig through code to find vulnerabilities. I don't do offensive security. I don't do penetration testing. But what I do like to do is look for the easy gains. And while I won't say that we don't need any more people doing those things I mentioned, they're far outpacing the rest of the industry. So the bleeding edge of security is not being adopted fast enough. And there's a huge amount of practices and posture and recommendations that aren't being used. So for me, as not a researcher, I want to say let's use those things that other smart people have already found and figure out how we can apply that to what we're doing in a way that makes it automatic and easy. And another kind of fact to state here is that GitHub is the place where most organizations put their open source software to get a lot of eyes on it, to get contributors that already know how to open PRs and to get more awareness. So we're putting all of our open source on GitHub. GitHub has security features built in that may not be fully used or they may not be able to be used at scale, at the kind of scale that big organizations have, the kind of scale that OSPOS manage. And so if we kind of put all those things together, we get to All-Star, which is what I want to talk about today. So I saw that we needed to make this security automatic. I saw that we do a lot of open source on GitHub. I saw that we needed security is serious. We want to avoid any kind of incidents. So what I created was this GitHub app, a tool, that administrators and of any open source repositories organizations on GitHub can use to improve the security posture of those organizations. And All-Star is a project under the open source security foundation. So we have a cool goose with a star. So just at a real high level, I'm going to dig in deeper into what it does at each point. But it's intended to be used by the GitHub administrator to maintain adherence to the security best practices across a lot of GitHub repositories. It's running in the background. It's not something you have to set up to run and continuously checking for if. Once you achieve some kind of security compliance that you don't have regressions, and then when it does find that, it raises an alert. That could be a GitHub issue or some other kind of configured action. And on some cases, it can actually go and just fix the setting for you in GitHub. And if you're familiar with GitHub apps, it's pretty easy. You go to the page and you click the big green button. So this is an instance that's operated by me under the open SSF. You can run your own instance. And I'll cover that later in the talk. So it's an open source project. You can either use the code or just click the green button. All right, so I've talked a bit about this gap in security posture between what we know and what we should do and what we're doing. But what are those things? What are the best practices? So in general, they kind of come in either something you should do or something you shouldn't do. So just a real generic list of continued testing to making sure your dependencies are up to date, making sure you have good review practices, and then things you don't do like making sure that you don't have CI permissions that let your tokens that are too broad, the principle of least privilege, that kind of thing. So goal of all star is to codify these practices into individual security policies. Something that as the administrator that's kind of setting a rule, you would say all of our repost should meet this policy and if they don't, it's out of compliance. And then as the administrator of all star, the app or the GitHub repository is you decide which policies to enable or disable and what specific settings you wanna have on those. So this is a graph, a diagram from Salsa that covers the entire world of supply chain attacks. It simplifies this a lot, but kind of covers the different points. And I wanted to cover which ones all star is looking at. It's mostly A and B here. So can the developer, is there any attack on getting unauthorized changes into your source control or is there a compromise to the permissions on your source control? It does help with CDNF a bit because some of those things like your CI system setup are files that are in your GitHub repository or that all star can look at and then tell you if you're doing the wrong thing there. But inherently it's not plugged into your CI CD system unless we can look at those files in your repository. So if you're concerned about the rest of the letters on this and you should be, check out the Salsa project and read more about how to make sure all of those things are secure. All right, so I'm gonna dive into the policies that all star supports specifically. And this can get a little dry because it's detailed but if you take anything away, know that these are the practices you should be doing whether or not you use all star on your GitHub repositories. So the first and the major thing that we wanna have turned on is branch protection. So branch protection is a set of GitHub settings that limit the users with write and push access's ability to push directly to those protected branches. At its most basic, it requires a pull request to merge code so you can't actually just push directly to the branch. But if you put the settings right, you can set the number of PR reviews required, dismissing approvals, et cetera. And if you have good branch protection settings, the goal is that you can protect from an attack with the stolen credentials of a single maintainer that has write or push access to that repository or that maintainer going rogue. So remember that a single administrator, if they are compromised, they could still have access because administrators can go and change any setting. So still follow the principle of least privilege there, try to limit the number of administrators on your GitHub repositories. And then with good branch protection, you can have more writers and not be worried of one of them being compromised. And like most security, if your project has better security than the project next to you, then the attacker will go to the project next to you. So if they have to compromise two different writers to get access to make an attack, then it's a lot that much harder. So yeah, we recommend setting up branch protection on any GitHub repository that you have where it's feasible. It's not feasible on single developer projects where you don't have anybody to approve reviews. So what can All-Star do for branch protection? You can tell it which branch to protect, to check. Normally it'll just check the default branch, but if you have release branches, you want it to check those two. It'll see that you have the specific settings set that are needed and then notify the repo or if it's out of compliance with the issue or All-Star can go and change the settings to be what you specify. Actually, raise the settings up. And again, like you might be thinking, why do I need All-Star to do that? But remember this scale here. Branch protection is a per repo, per branch setting and All-Star does that across all your repositories. The next policy I wanted to discuss that All-Star enforces is binary artifacts. You can say I don't want to have binary artifacts in any of my Git repositories. Binary artifacts are things that can't be reviewed. Somebody could try to merge a quote new version of this binary in that might be subverted and you wouldn't know. So in general, this is something you want to avoid unless you absolutely need it. So again, All-Star can go and check to see if you have anything there. You can list out binaries that are allowed that you in an ignore list and then it'll alert you if it finds any artifacts. Another policy is a security MD. So security MD is known as a security policy sorry for the naming confusion, but this file lets security researchers know how to responsibly and privately disclose vulnerabilities found on your project. So without it, a researcher might be forced to disclose a vulnerability publicly, leaving you with no time to actually produce a patch version for your consumers. So All-Star can check for the presence of this file in each GitHub repository or at the org level. So at the org level in your .github repository, you can put a security MD there and it'll apply to your whole GitHub organization. This is found in the security tab if you're not aware where it's got the orange there. If you click on that and then the security policy on the left, you can see the security policy for any GitHub repository. Therefore, and security researchers know how to know where to find this, but you as an organization want to make sure that you have this on everything. Another policy that All-Star can enforce is an outside collaborator policy. In GitHub, organization members and teams built inside of an organization can be given access to repositories like Read, Write, Admin. But also if you go directly to repository, non-organization members can be added and GitHub calls these outside collaborators. So All-Star can scan repositories for any outside collaborators with certain access, which you can figure. You can say I don't wanna have any outside collaborators with write access or you can say just admin. Like I wanna avoid admin, but outside collaborators with write is okay. And it'll also alert you if you have any of those. This pairs well with other automation that controls like who's a member of the organization because that's just the top level that you might have. So I've known a number of companies that have that kind of automation. So when somebody leaves the company, they remove them from the GitHub organization. And just another side note, there's another part of the outside collaborator policy called ownerless, which will alert you if there are no administrators. So this might be a worry if nobody in your organization owns the project and nobody's looking for alerts or issues or vulnerabilities. Another policy that All-Star can check for is dangerous workflow. So to understand this, we have to look at how like a CI CD system typically works and people use CI CD for two things. Here we have a left column and a right column and these things have vastly different trust levels. So on the same system, let's take the right column, you have a contributor, an unknown contributor making a PR, you wanna take that code and run tests, lint and coverage on it and produce results. But on the left column, you also have like a maintainer making a release tag and in that system you wanna build release artifacts and sign them and publish them to your storage account or your package manager. So one is highly sensitive and one you're running untrusted code and it's really easy to get the configuration of your CI CD wrong to like leak, have leakage between the two. So All-Star has some built-in detection for GitHub actions workflows. This is specifically about actions because again we're looking at those workflow files that are checked in to the repository. And I won't get into all the dangerous patterns here that like you might do, but essentially we have a bunch of reg-exes and look for different tags and settings to let you know if you're doing something that's probably causing that to happen, this vulnerability to happen. Again, if your CI CD is compromised, attackers can get access to push code directly to your repository. They often have right access to the repository or to push to your releases where you have your package managers and release artifacts. So something to worry about. The other thing All-Star can do is more checks from the sister project. We have security scorecards. I'm gonna talk about scorecards later in the talk, but scorecards and blunts checks that All-Star can check for as well. And then ideas. So please, you'll do GitHub, you'll think about security or policy or management. Tell me what we think we should add to All-Star to be able to check for at scale. So All-Star has access to the GitHub APIs and the repository contents. That's what we look for to decide if something's good or bad. And let us know your thoughts. One of the ideas is the contents check. If you wanna have a required Git pre-submit for everything that does something like credential scanning, I don't know. All-Star could check for the presence of that pre-submit. Same thing for GitHub action if you wanted to have a GitHub action that you want or a GitHub action that you don't want. Something like that could be a policy. Another one we're thinking of is we wanna make sure you have your dependency auto update bought present, like dependent bought, renovate bought, something like that. But please see the issues and drop your ideas. I'd appreciate to see them. Okay, so that's a pretty detailed look at all of the security policies that we can look for. What do we do when we find a repository that's out of compliance based on what you set up? Those are our, quote, enforcement actions. So the most basic one is to create a GitHub issue. And the important thing to know about the GitHub issue is that the people reading the issue aren't necessarily the person setting up All-Star, setting up the configuration, deciding what the requirements are. They're the maintainers of one of the projects in your organization. So they need to know what the violation is, exactly why it's important, whether the remediation steps to fix it, and links to more documentation. So that's kind of our goal with the issue. All-Star will open one issue per policy, per repo, and it will ping it every 24 hours if nobody responds or fixes it. Whenever the violation is fixed, since All-Star is scanning in the background, it'll see that it's fixed and just auto-close the issue for you that you don't have to close it. Next one is to fix. So let's fix, if the policy is something that can be fixed by All-Star, then let's have an action that will just do the fix for you. So right now it's just branch protection, because those are the settings. But any policy that we add that is a setting that can be flipped or switched, let's have an action that will go and All-Star can make the API call to GitHub to set that. Some of the other things like security MD, that's not easy to fix, like we'd have to make a PR, but we don't really know what you want to put in there. So that's something that you have to go and do yourself. So future ideas for actions, again it's a developing project looking for contributions. Right now I'm working on RPC action, which will make a GRPC call to an external system, which is meant to be then piped by you into your internal system if you have an internal bug tracker or something like that, if you wanted to build a plugin. Block is an idea of an action where if we were really confident in All-Star's detection and what we want to check for and what we want to enforce, and we could say basically if you're out of compliance, like stop allowing PRs to be merged or something like that, that would kind of be the most draconian as a policy administrator that you could set. So that would be easy to implement it, but we haven't really seen a need to do that yet. Email, like we could have it like issue where instead of creating issues, it can email somebody, the administrators, the maintainers of the project, but it needs design, like how do we know who to email and whatever, but if that's something that people think All-Star should do, definitely weigh in. Okay, so let's say you have All-Star set up, it's checking all your repositories for the things that you consider important, creating issues or whatever. Policy is not gonna be universally applicable to every project in your organization. So you'll need a way to allow users to opt out. So All-Star config either goes into an organization level repository, the dot All-Star repository, or it goes into the repos itself. You can put config in each individual repo. And there's another setting that the administrator can have, the override enabled, and that really allows you as the administrator to decide what level of review you want on exemptions. So if you set override allowed, then any repository might be able to put, you know, the owner of that repository can put a file in that repo to say, like, I wanna turn off or tweak the settings to All-Star. And that might be if you wanna have, if you trust everybody to follow, like, whatever policy that you have for exempting. However, if you wanna have, like, an approval process, you could say override disabled, and any change to All-Star config would need to go to the one dot All-Star repository and your organization, which you would manage and look at PRs and, you know, have some kind of way that you determine if it's okay to exempt this repository. Again, this is flexible at the security, at the policy level. So it's not just for All-Star. You can say, for this policy, repos can opt themselves out. And for that policy, I want it to be, I want all reviews to go through me. Okay, so getting into the more details on the install, I already showed you the big green button, you click it. We have a sample repository that's a quick start with all the config files. If you copy the quick start to your organization, then you will essentially just turn on All-Star with all the policies and overall, in all the default settings. And overall, it's the project's intention that the default settings and all the policies is the security, is our recommended security best practice. But of course, everything is tweakable. But before you do this on like a huge organization, you might get too many issues right away. So you might need to take a little bit more stepped approach. So for a large organization, you'll want to have steps. And I kind of recommend two prongs. One, look for teams in your organization that are interested in All-Star and trying it out and seeing if they will turn it on themselves. And two, start looking at the policies and seeing which one might be the easiest one to enable company-wide or organization-wide and doing that like one step at a time. So like branch protection is a hard one because I think it's probably the most important one, but it's maybe the least used right now, at least widely. So turning it on will probably make a lot of issues. But something like setting up an org-level security.md file and turning on that policy could be a really easy first step. So yeah, launch and iterate. And if you run into any problems, definitely let us know. So at Case Study, I'm doing this at Google right now. We have done that two prong approach. For example, the Flutter, Dart, Angular teams have turned it on all the policies on their organizations. And at the company-wide level, I've only turned on binary artifacts. So binary artifacts will check, again, the artifacts and create the issues. So we've had surveys and internal communication for people that have seen these issues because you can go to GitHub to search for issues and then see if we've got any feedback, tweak the issue text, that kind of stuff. And of course, all that's going into the public all-stars. So all of our efforts on making the issue text as good as we can. OK, so I mentioned about running an instance. So the one on the left, OpenSSF instance, that's the one that I run. I use OpenSSF infrastructure. So when you install a GitHub app, you're instantially giving the app, which is a private key and can access GitHub APIs. You're giving it access to your GitHub repositories. So the OpenSSF one is volunteer run. I'd recommend using it for public foundations or if you use GitHub primarily for public projects. But All-Star requires a good amount of permissions to accomplish all the things that it can do. So if you have a lot of private repos or you deploy your mission-critical infrastructure from GitHub, you'd probably want to look into running your own instance. We have documentation, the one link there, the operator MD. It's very simple. It's just a go binary. You run it with a few command line options. And that's it. OK, getting towards the end of the talk. So I wanted to give a quick shout out to the sister project that I mentioned before, security scorecards. Scorecards and All-Star share a lot of code behind the scenes because they both check for security best practices. The difference is scorecard is something you run on other projects, and it tells you a one in 10 score of the security posture of that project. As Poites, you might want to consider using scorecards in your organization's OSS ingestion process. And then we hope that demand for high scores and open source will improve the posture of other open sources well. Before you run scorecards on your ingestion or your dependencies, you do need to know what they are. So I think there's other talks about that in this track. Yeah, that's it. Thank you very much. Let us hit the issues and let us know what you think, ideas for policies, feature requests. What best practices are we missing? Questions? Up here? Yeah, you can run scorecards against your own repository. The question was, what should we do with scorecards? Can we run it on our own repositories? Yes. So that would be point in time. I want to see how am I doing. I would recommend that. And then when you're at the point where, OK, I want to keep everything up to date, then look at All Star. Question back here? So we're a bit odd. We don't use GitHub. We use GitLab. So can we use All Star on GitLab on our self-hosted GitLab? Yeah, great question. So All Star is a GitHub app that's based on the settings that GitHub provides and even the gaps that it doesn't let you set settings at an org level. So I think as a project, the mission and vision, supporting the same thing for GitLab makes sense to me. And I would totally be interested in getting that off the ground. But it would have to look at some of the things that are based on contents. That makes sense, like binary effects, security, MD. But things like the branch protection settings, like where does GitLab have those settings? And what is hard to do at an org level? Because if you can flip a switch and do everything for all your repos, you don't need All Star. But if you need to go to 1,000 repos and flip 1,000 switches and make sure they're all on all the time, then we need All Star. I think the question is, what do we want to do there as well? Go ahead. Yeah. Question? I'm back. I might have missed this. But when you said you were talking about adding new policies later on, what does the updating process look like for that as an organization owner? Do I need to do a combination of updating the app and then also updating my configuration for that? Or is there a way for me to subscribe to the best practices without an update? Great question. So the app, you're always using the latest app, because it's basically just plugged into the one that I'm running, essentially. Unless you're running your own instance, then you need to download code or get a new release. Each policy is in a separate file. So you just need to create the new file and put the config there to, say, turn it on. And with the default configuration, essentially be an almost an empty file. As far as announcements, I have an announce list where I would announce, like if you're not following the repo, I'll announce monthly that we have these new features that came out. You might want to check them out. OK. Would there ever be a way to subscribe to the recommended best practices without having to do anything and automatically get the new updates? Yeah, so I did just merge a feature that lets you point to another repo for config. So I plan to use that across multiple orgs that I control. So the quick start right now is to copy the template. We could have, which we don't have yet, is basically like the golden config. And then you could point to that. So the features there, the documentation, and the golden config is not there yet. But I want to add that. OK, cool. More questions? Nope. All right, well, that's about it. We're five minutes early for a coffee break. So get out there and get coffee for everybody else. Thank you.