 All right, off we go. Hi, everyone. My name is Billy Lynch. And today, we're going to be talking about things you can do to start securing your source repositories. So a little bit about myself. I'm a software engineer over at ChainGuard. I'm a maintainer for a few open source projects, like TectonChains and a six-door Git sign. And I've worked on a bunch of different source provider code in a different lifetime at Google, so Google Code, class source repositories. So yeah, so what can you do to take quick actions to help secure your repos? So number one, enable two-factor authorization. Being able to protect your account is critical. So enabling Google Authenticator, backing it by a UB key, protecting your identity is super important because that sort of is what gives you access to all the different resources, whether that's code repository, CI, artifacts, stuff like that. So locking that down is super, super important. If you haven't seen it yet, GitHub actually put out a blog post a couple of months ago, or I forget when. But they're going to start rolling out requiring two-factor auth for your accounts. I personally think that's a great thing, but I think it's also good to start rolling that out proactively and also in other source providers as well. Number two, protected branches. So this can mean a few different things. This is supported across a bunch of different source providers, so here's GitHub and GitLab right here. So the main things we're looking for here is two-party review, so making sure that there's a second pair of eyes on your code. One, because code reviews are just always good, but also in the event that someone's account is compromised, having that other check and balance there of someone else just saying, hey, this looks good, also can help secure repos, stuff like that. And you can also use this to say, hey, run these security checks, run the CI, things like that. Number three, we heard before about dependabots. So this is also critical. So I don't know how many projects I've seen, active community, stuff like that, but if you run a scan or something on them, you detect all these CVEs, and most of the time, they've actually already been solved and fixed upstream, but the dependencies haven't trickled their way down to the underlying projects. So using things like dependabot, things like renovate bot to help automate these workflows so you don't have to think about, hey, where is the latest dependency? When do I have to check these? Being able to automate those flows will make you and your project much safer for that. Four, I'm a bit biased here because I work on a project called Git Sign. Signing your commits. So there's a few different ways you can sign your commits. So traditionally, it's been GPG. In recent time, there's also been SSH and X5 and 9 that's been added, and the project I work on, Git Sign, is part of the six-door project, which is using your identity, like your Google or your GitHub identity, to sign your commits. This is super important. Like there's been a big focus on signing artifacts, release artifacts, OCI images, but not so much on Git commits, and that's a little weird because these are the things that we're putting into our CI pipelines. These are the things we're using for GitOps workflows. We're using Manifests to plane them to our Kubernetes clusters. So we should be using the same level of rigor for signing and verification for our source that we're also using for our binaries. So being able to start signing your commits is the great first step here. And then finally, using scope credentials. So really just taking an audit of your repository. Can you get away with a read-only token? Can you scope a token down to just a particular repository? Can you go a step further? There's been a lot of effort for CI providers for OIDC credentials. So these ephemeral credentials that you don't have to store and protect and bind them to particular repos. The more you can reduce that down in the event that you are compromised because it's more of a when, not an if. The lower, the less scope you're making yourself vulnerable to in the long run. And I just wanna make a special shout out for open source, open SSF scorecards. So there's a talk later today, recommend checking out. Scorecards is meant to be a tool to help you automate to do some of these checks for your repositories, to check for two-factor auth, to check for protected branches. And Naveen and Brian are giving a talk later today that would definitely be interesting. Cool, that's all I had, let me talk. If you wanna talk more, happy to hand it around after this, but thank you.