Natalie Somersall
bringing secure containers to the Feds @ a meme company
Denver, Colorado, United States
Actions
Natalie is a principal solutions engineer at Chainguard serving the public sector market. She spent years designing, building, and leading complex systems in regulated environments at a major systems integrator, but has also taken her career in many other directions - including detours into project management, systems engineering, and teaching.
She’s passionate about diversity in technology and empowering engineers to build better.
Area of Expertise
Topics
Whodunnit - git repository mysteries
With all the recent focus on software supply chain security, let's look at the very far left of this process - how does git know who did what, when, where, and why?
It seems straightforward to assume that you have all of this information in a git repository, but that's probably not the case. In this talk, Natalie will walk through how to determine the answers to each of these questions, edge cases and technical gotchas to watch out for, and why each are important to your company's security posture.
**Who?** will walk through identity and commit signing in git. This seemingly simple information turns out to be quite hard to reliably determine. We'll review setting your user identity in git and how/if that links to an external identity provider or your repository hosting service, how that identity interacts with signature verification, the common methods of git commit signing, and what the future of signature verification looks like for git. The walkthrough shows how each of these can leave a gap for auditors and how to address these with reasonable certainty.
**What?** answers, but then finds more questions, to what files changed at each point in time, how force pushing or history rewrites change this, and how to view these trends in bulk. It has become common to rewrite history to remove large files or secrets, but how effective is this in practice? What gaps does it leave in your reporting process to understand what files have changed?
**When?** considers time management in git - local versus universal, when it matters, and looking at how often a file changes through the lens of reporting to someone who doesn't know what git is.
**Where?** walks through several "where" questions - the confusing ways that `git checkout` can do different things to different files based on context, leveraging `CODEOWNERS` to provide ownership to teams over parts of a repository, and where git stores credentials. We'll look at what types of controls these credentials may bypass by looking deeply into the dozen or so types of credentials in GitHub and what they can do. Lastly, we'll consider the places `git` can do things automatically with hooks - hooks that run locally or remotely, how to leverage them responsibly, and what they realistically can do for governance.
**Why?** will consider documenting code changes over time. It's difficult to understand why a change occurred without this context and impossible to go back in time to ask yourself why. This section will cover structuring commit messages, then how to enforce these across projects by force and by cultural convention. Zooming out a little more, we'll talk about merge strategies and how they intersect with trying to prove changes over time. It ends on why and how to add additional insights to this history using an Architecture Decision Record to document major decisions, and why not to use Issues or Pull/Merge Requests for these records.
**No really, why?** ends on the existential questions of what it means to write software in a regulated environment, or pulling entirely unregulated software in. It's possible to do this quickly, reliably, and securely - we just need to know `git` inside and out.
Threat modeling the GitHub Actions ecosystem
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.
Getting Started with DevSecOps in a Regulated Environment
Natalie has worked with a great number of teams within system integrators as they've integrated security into their software engineering processes. Given the opportunity to work with such a diverse group of teams, she's found a couple of common traits in teams that thrive in delivering secure software in a regulated environment.
BSides Boulder 2024 Sessionize Event
BSides Boulder 2023 Sessionize Event
DevSecOps Days Rockies - Virtual Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top