GitHub Actions is one of the most popular CI tools in use today. If you need or want to use it for business, though, there are a lot of choices to make that have huge implications to the information security and compliance posture of your organization. These questions get harder with more users and projects, moving faster and not prioritizing security. Some of these questions include:

- What sort of code and dependencies are in a GitHub Action?
- How can those get exploited?
- What information can I know about what my users are up to?
- My users requested that we allow the use of an Action out of the open-source marketplace, but how do we evaluate the security of it?
- Is it safer to host all of my own build machines?

This talk leverages Natalie's experience in building and running large implementations of GitHub Actions in a regulated environment to provide guidance at this intersection of developer enablement and secure, scalable development. In this talk, we'll dive deep into what an Action really is, what goes into an Action out of the marketplace, and how each of the three types of Action can be exploited with a demonstration. With each exploit, a few control strategies will be discussed to counter it.

Build system integrity is about more than _just_ the code in your build pipeline. Once what an Action is is well understood, Natalie will cover how to handle secrets securely at every stage of your CI/CD pipeline and go over common mistakes she sees users make - authenticating into multiple repositories, handling temporary credentials or long-lived service accounts safely, integrating with other secret stores, and scaling with OpenID Connect. Handling secrets in a safe way is critical to maintaining supply chain security (and keeping a sane bill with your cloud provider of choice).

Next, the talk will spend some time outlining how to think through when (or if) to host your own compute or use GitHub's hosted runners for any particular job. The security of using GitHub's hosted compute is examined, followed by key infrastructure decisions and guidelines for hosting your own runners. With each choice, Natalie will highlight strategies to maximize the traceability and minimize the "blast radius" should a runner or build pipeline become compromised - providing the critical information of Who did What When and Where (and Why!) for incident response.

Most importantly, the talk ends on how to build a human-friendly process to govern the ungovernable. It's (usually) not acceptable to "just allow everything for everyone", but the opposite end of that spectrum is building an unwieldy and lengthy approval process. This desire to make sure everyone has their say can instead increase your shadow IT inventory in your build and production infrastructure. Having built this at a large heavily-regulated company, scaled it to thousands of users, and then advised many other companies in the same situation, Natalie recaps her lessons learned in how to evaluate a requested Action by a user. This means setting clear expectations, written evaluation guidelines, and tactical advice on how to add it to your company's pipeline for better, faster, and more secure software.