.png)
Introduction
Chainguard is building the safe source for open source. This requires sourcing the latest version of open source software across myriad repositories and interacting with it via GitHub Actions. Leveraging GitHub Actions securely at scale is not an easy task and this is especially true when the input can directly affect the output (with said open source software being included in the final product). Outside of this, all supporting code must be tested, validated, and deployed and Actions is the ubiquitous method for doing this.
Chainguard’s approach to security is to lead by example and not check boxes for the sake of having checked the box. StepSecurity provides a secure foundation for using GitHub Actions at scale and accomplishes this in several ways – including automation and comprehensive visibility.
Gotchas
GitHub Actions is easy to get started with, but by GitHub's own admission, it can be difficult to use securely, consistently. In fact, there are four separate blog posts just from GitHub’s Security Lab around using Actions securely.
While StepSecurity does not automatically cover or provide direct control over all of these vectors, a lot of the important foundational configuration is covered (more on this later).
Additionally, the StepSecurity platform provides a list of controls for Workflow best practices (not leaking secrets in logs, risky third-party actions, using OIDC when interacting with CSPs, etc.). These controls, while hard to automate, offer a concrete starting point for targeting which Workflows to update.
Without StepSecurity, Chainguard would spend much longer reviewing each distinct Workflow and comparing against a known, secure baseline. Even “secure” Workflows may not satisfy a best-practice or control and without the visibility provided by StepSecurity, the chances of noticing a vulnerable Workflow are slim.
Least Privilege
Chainguard is a strong proponent of least privilege (or “minimalism”). An entire blog post exists documenting this philosophy: https://www.chainguard.dev/unchained/the-principle-of-minimalism
StepSecurity applies the principle of least privilege for GitHub Actions in three different ways:
- Minimal GitHub Token permission recommendations
- Limiting network egress
- Disabling `sudo` in Workflows
Perhaps the most important of these three is the first item. By default, the GitHub token has read/write permissions to every scope except for `id-token` and `metadata` (which is `read` at most). This means any Workflow in a repository can leverage the default token to perform arbitrary modifications or destructive actions to repository contents if the token is not already set to be restrictive at the enterprise, organization, or repository level and is then left unconfigured in a Workflow.
StepSecurity makes this easy by automatically suggesting the minimum permissions required to run a Workflow successfully: https://www.stepsecurity.io/blog/determine-minimum-github-token-permissions-using-ebpf-with-stepsecurity-harden-runner
StepSecurity continuously profiles the network egress and file events of a Workflow to build up a baseline of expected behavior. Even without any additional configuration, StepSecurity is providing insight into how a Workflow operates on a routine basis.
For network egress, StepSecurity will automatically suggest the correct, minimal endpoints to allow for a Workflow while blocking everything else (this can always be run in audit mode, as well). The same principle applies for file events and StepSecurity also offers an explicit configuration item to entirely disable `sudo` on a GitHub-hosted runner to prevent any privileged access while a Workflow is running.
These three items go a long way in minimizing the attack surface of a given Workflow. With StepSecurity, Chainguard can apply the principle of minimalism to a critical subset of the production footprint where code is continuously modified, pushed, and introduced into other production systems.
Visibility
Visibility is a key component when running hundreds of Workflows on a daily basis. As mentioned above, StepSecurity is constantly monitoring the average baseline behavior of any given Workflow and alerts when anomalous network or file activity occurs. This level of visibility is not available with out-of-the-box Actions and parsing Workflows for leaked secrets is essentially impossible, especially when dozens or hundreds of Workflow runs are happening on any given day.
StepSecurity automatically alerts on anomalous behavior and will explicitly call out problematic endpoints, file write events, or possible secret leaks that show up during a Workflow run. Centralizing these alerts (and having control over the signal-to-noise ratio) adds confidence around running hundreds or even thousands of Workflows at scale. In fact, it was this functionality that made StepSecurity aware of the compromised `tj-actions/changed-files` Action .
StepSecurity gives Chainguard an alternative to engineering a high-overhead approach to collecting runner behavior (likely involving self-hosted runners with another eBPF solution and log collection capabilities). StepSecurity provides all of this with just three lines of YAML to begin with.
Easy Button
StepSecurity offers an “easy button” for bootstrapping Workflows in a repository called “Orchestrate Security”. This option covers *nine* distinct components that, while not a universal fit for all use cases, provides a very solid starting point for nearly every facet of a repository security’s posture: https://docs.stepsecurity.io/orchestrate-security
Instead of manually updating Workflows and writing out net-new YAML, this option can be used time and time again to apply consistent, automated best-practices. Setting minimal token permissions and pinning Action and container image digests is something that is usually tedious and time-consuming, but with StepSecurity this is just a click away.
Perhaps the most important item in the aforementioned list is pinning Action digests to SHAs. When leveraging mutable tags, any Workflows that run will automatically pull whatever digest the tag points to. This is an easy way to pull in compromised or back-doored Actions as seen in the 2025/03/14 `tj-actions/changed files` breach.
Lights, Camera, Maintain Action
Most organizations will leverage third-party Actions. Actions fall into the supply chain security bucket and it is never readily apparent as to what is happening when a new tag for an Action is released. Tags are mutable and without StepSecurity (or other automation), pinning Actions to digests is toilsome. Even so, some Actions are not secure by default or become unmaintained and accrue vulnerabilities.
StepSecurity again helps out here by offering a curated list of forked and maintained Actions. Whether this is offering a maintained version of a popular upstream Action or manually re-writing the logic of the Action to patch gaps or vulnerabilities, StepSecurity provides solid building blocks to make Workflows even more secure.
With this feature, each maintained Action is a simple drop-in replacement that will work without any additional configuration and Chainguard has benefited from this across several Actions.
Conclusion
StepSecurity is a must-have for any GitHub project or organization. While knowing the ins and outs of GitHub Actions is certainly enlightening and interesting, its inner workings are not necessarily the core competencies of security teams or organizations.
To effectively scale and use GitHub Actions, organizations need a straightforward and consistent approach to security and StepSecurity provides the knowledge and tooling to do this. GitHub should be treated as a production system and StepSecurity provides the confidence needed to run this particular production system at scale. By default, GitHub Audit logs can be shipped to a SIEM, but without visibility and controls at the layer where a majority of the action is happening, it’s very easy to miss context while also exposing any stored in a repository to unnecessary risk.
StepSecurity enables Chainguard to save a large amount of time on GitHub Actions security, improve its visibility into Workflows, and be even more secure where it matters most.
