 of snacks and beverages and continue the conversation. So our next speakers, I would like to welcome to the podium Jeff Mendoza and Steven August. Oh, well, Steven, the man of mystery, was not able to join us. So we have Naveen Srinivasan here, speaking on behalf of our friend Steven. Jeff is an engineer at Google's open source security team. He's focused on supply chain security and securing Google's GitHub repositories. I'll let Naveen introduce himself, because Steven didn't give us a bio either. So please, Jeff and Naveen, take it away. We would love to hear more. Test, test. All right. Thank you, everyone, for joining. And thanks for the introduction, Scrope. Today, we're going to talk about automated techniques for measuring trustworthiness of open source code and communities. And that's a mouthful. And so I'm going to start it off, and then Naveen's going to cover some bit, and then we'll switch back to me. Naveen, why don't you go ahead and introduce yourself? Hi. Obviously, what Crow and Jeff mentioned, I'm not Steven. I'm taking over for Stevens, because Steven couldn't make it, because of flight delays. I'm going to try my best to cover up for things. And if this is next in this last hour, I prepared for this talk. That's a quick update of what it is. I'm Naveen Srinivasan. I'm one of the maintainers of the Scorecard Security Project. And I work for EndoLabs, which is a supply chain security startup. Thanks. Yeah. Yeah, and one of the benefits of having your conference in your hotel is you can get here really quickly in the morning, but you can also go to your room after lunch for NAP. So thank you, everyone, for not doing that and coming here, because I could use a NAP right now. So before we talk about automated ways to judge security and trustworthiness, we should talk about the previous techniques or before automation. And that is the OpenSSF Best Practices Badge. So this was kind of a precursor to some of the automated tools that were developed to judge trustworthiness. And it was formerly known as CII Best Practices Badge. I think it predates OpenSSF. So it has, and since it's not an automated tool, it's not something you run, it's text. You go and you look and you see what are the requirements to meet these best practices. And it's a lot of text, and it's a really great resource for an authoritative place where you can say, these are the practices that we recommend. This is something that is secure. And you can go and see what you need to do to meet those requirements. And then if you attest to meet them, then you get the badge. And one other thing about the badge is it has full coverage because it's not limited by things that can be automated. And as you'll see with the automation techniques later, of course, there are limitations to what you can build inside of a tool. So getting on to the first tool, we're going to talk about Scorecard. And Naveen, as the maintainer of Scorecard, he's going to go over that. Thanks, Jeff. Scorecard is an OpenSSF project. And it's an automated tool to help analyze most of the security issues that an open source project could have. Scorecard is developed by, within the OpenSSF, with cross-country organizations like GitHub, Google, IBM, and all these organizations. There are multiple maintainers. I'm one of the maintainers among that. What does Scorecard do, tries to do? Scorecard tries to identify the good practices as well as the bad practices. Scorecard attempts to detect if the good practices are followed. Example, do projects do continuous testing, fuzzing? Why is this critical? Because that reduces the number of bugs in the source code. The next thing is it looks for, does it do projects, update their dependencies? Is it important so that you patch your vulnerabilities? Does it have safe configuration settings? Something like code protection, which I will be doing another talk tomorrow, which we will demonstrate how that can, if you don't have that setting enable, how malicious developers can push source code into that? It also looks at web configuration settings, like is it authenticated? Like I mentioned, not just good practices, even bad practices. Things like, do you have a bus factor of one that isn't maintained by only one developer? If it is, then there's a higher risk of, if that one developer had something happen to him, then who's going to maintain that project? Looks for your secrets accessible to pull requests. I'll demonstrate, as it goes on the talk, of why it can be a problem. It also looks at how the attacker can circumvent your permissions and bypass code reviews. Things like that. Primarily, what are the use keys of using Scorecard? You can do it for your own projects, as well as for your dependencies. Improve the security practice of your own project, as well as your dependencies. It can identify if your dependencies are being maintained. Are there any vulnerabilities in your project and your dependencies? I'm going to skip that. I want to go to this, specifically, because how do you install Scorecard? How do you run Scorecard? The easiest way to run Scorecard is using Docker Run. That's the easiest way. To run this, one of the critical things that you need is a GitHub token, because Scorecard primarily utilizes GitHub token to use the GitHub APIs. That's something you need that. And using this, there's a Docker container to run that, and you point it to a repository. It runs all the default, all the checks that needs to run. When it runs, what does it come back with? It comes back with certain warnings, the good and the bad. Like I mentioned, it's going to come back and say, what are the things that it could identify as not working? Like in this example, it's going to indicate a project exposes secret to pull requests. The next one is how somebody, how an attacker can change the permissions of the workflow. That's critical, especially on the supply chain security, because if somebody can change your permission, that means they can take away your code. And then this last one, how your dependencies are not being pinned with hash, so that what you depend on can be changed, and that could cause problems, and which I will be demonstrating in the, I apologize, not today, but in tomorrow's talk. Now coming back to how Scorecard being utilized. If you're using any Go project, the official package.dev.go.dev now provides a link to every project as to what is the score of each one of these things, which provides a link. Another classic example is Depst.dev. Depst.dev, people who don't know, Depst.dev essentially takes all your dependencies and showcases on any project what are the dependencies and what others depend on you. Based on that, and also along with that, the Depst.dev also utilize shows Scorecard scores for each one of your, each one of those projects and how they stand, where they stand on each one of these checks. And what you see on the right side is all the checks of Scorecards, checks. You can utilize Scorecard for your own projects. I showed, just now I showed prior to this how to utilize Scorecard using Cli. Scorecard also has an action, a GitHub action that you can install, and it'll run for your project, your GitHub project, and figure out what are the best practices, what are the things that are failing on. The action runs on two different settings. One is a cron job that keeps running on a cron. Another one is whenever there's a push to your repository. And all the results are stored within your GitHub code scanning. So essentially you'd be able to go and look at what is the state of each one of these things. Here's an example of how these results would be shown. It's not shown to every, every one of the country. It's only shown to the contributors and the administrators what are things that are going wrong. The example, these are the ways it shows critical, high, low vulnerabilities in any one of these things. That's about it. Thanks. All right, so we've learned the automated techniques to judge the security posture of other projects. And so I hope you wouldn't want to use those for your dependencies that you're using or dependencies that you may be evaluating to bring into your project and depend on them. And then we've learned how to run scorecard on your own projects, because if you want other people to use your project, you want to have a good score. But now you might be thinking, now how do I take these best practices and high security posture and apply it to my projects at scale and across and with enforcement or with continuous checking? So that's where we bring into All-Star. So if scorecard gives you a good score, you can use All-Star to make yourself an All-Star of your scorecard score. So we'll go over what is All-Star? So it is a GitHub app that continuously checks for your, those security best practices on all of your repositories, as many as they install it on. It can raise alerts like GitHub issues or it can actually just fix those settings that are, if they are settings on your GitHub repositories based on what you decide. So again, you decide what policies to enable. And it's also extends a little bit past scorecard where scorecard is a tool that is objective. The best practices come down from our best practices working group of OpenSSF. All-Star is a little bit more tweakable where you can decide for yourself, what do I wanna enforce on my own GitHub repositories and set those settings up with your own configuration. So again here, you send GitHub app, you go, how do I use it? You go, you click install and you install it on your organizations. It has access to read the contents and settings of all your repositories, creates issues. Again, set settings, if there's anything that needs to be configured and they can actually, you can use it not just on public but on private GitHub repositories as well. So here's, the configuration is all YAML files that go in a special GitHub repo in your organization. And you can turn on and off, again, all of those best practices. These are all really analogous to the scorecard checks that we saw that Navin covered. You can turn all those on and off and decide what you want the enforcement action to be and then which repos you want to be enforced as well. So just to give you an example, Anne earlier today covered your security MD, how you should have a security policy. All-Star and scorecard can check for that but you may only wanna do that on your public repositories because your private repositories don't need that. So you can configure the All-Star settings to only alert for each policy like which type of repository you want it to check. And again, here's some of those example policies. A big one right now is branch protection. So GitHub has quite good settings for letting you enforce that on certain branches only commits go in through pull requests with certain reviews. And it's, we wanna apply that at scale on all of our repositories. So All-Star can put that on for whatever settings you pick and then make sure that it stays on. When you, for the policies that don't have a setting that we can just go and set and fix for you, these are the alerts that it raises currently. So if you have, again, a thousand GitHub repositories and you have owners of each one, you can give each repository owner an alert via a GitHub issue that they need to go and fix something like remove a binary artifact or set up a security MD. And that's just a real quick overview of All-Star. Just to wrap up, both projects here in the OpenSSF, PR is welcome, but if actually that's kind of a joke, you know, just join the community. Join us on GitHub, create issues, we're on Slack, OpenSSF Slack and mailing lists and we have our bi-weekly meeting. Any questions? Yes? Yeah. So Scorecard, oh yeah, I'll repeat the question. So the question was, what about places that you host your repositories that are not GitHub? Scorecard works on Git repositories. It checks all of its settings there, but a few of the settings that Scorecard checks are GitHub-specific and then All-Star right now is a GitHub app. So all of the code is connected to GitHub, but the project is, the intention of the project is to be policy-based for all these settings. So if that could be applied to GitLab or anywhere else that has range protection settings or other settings that need to be checked, that would make sense for the project as well. It's not for me, but it's, again, part of the project. So if anybody wants to work with me, I wanna work with them. Do what? Yeah, yeah, talk to me afterwards and Brian. Adding to that specifically, Scorecard has a setting that you can run on local Git repositories, but it's not gonna cover all the checks, but it covers certain checks. Scorecard has a, you can utilize to run on local repositories that like what Jeff mentioned. All right, well thanks to everybody. No, there's a question. So like you're just talking about the alerts and you wanna stop the alerts. Yeah, so the config is set up where either the organization owner can be the gatekeeper and allow things to be turned on or off or accepted, or the organization owner can allow the repo itself to opt itself out by setting a file in its own repo. So it's flexible based on how the person installing All-Star on the org can decide what they want to allow or disallow. No, it does not need one. It does not even. Obviously, right, that's the whole idea. So you don't need to, you can run it on, you don't need that. You don't need that. Yep, you don't need to. You don't even need, yeah, you don't, it does not go, it does all the checks locally, so it does not need any get-about token. David? We, the scorecard has contact at GitLab and we are working on efforts to not be specific to get up. Did I say that correctly? Okay, just wanna make sure that. Any other questions, comments? Okay, all right, thank you very much. Thank you. Appreciate it.