Back to Case Studies

How Checkmarx Brought Least-Privilege Enforcement to GitHub Actions at Enterprise Scale with StepSecurity

This case study is written by Udi Yehuda, VP of Platform Engineering and Global CISO at Checkmarx, based on Checkmarx's experience using StepSecurity at scale.

Table of Contents

At a glance

  • Implemented block-by-default network egress policies with narrowly-scoped allowlists across hundreds of repositories spanning multiple GitHub organizations
  • Deployed Harden-Runner to gain centralized control of, and historical visibility into, network egress on CI/CD runners
  • Identified 76 end-of-life third-party actions in use across 263 repositories, and blocked and replaced them using StepSecurity data and workflow run policies
  • Significantly reduced GitHub Actions sprawl and its associated risk by standardizing on StepSecurity-maintained actions
  • Converted recommended GitHub Actions security practices into enforced, enterprise-wide controls
  • Gave every engineering team a rapid feedback loop on pipeline security - as core to every pipeline as a set of unit tests

About Checkmarx and my role

I'm VP of Platform Engineering and Global CISO at Checkmarx - a dual-hat role covering both sides of the same problem.

As VP of Platform Engineering, I own the infrastructure, DevOps, and developer tooling that all of R&D builds and ships on. As Global CISO, I'm accountable for the security of the company itself: our products, our cloud, our supply chain, and our people.

Having both means I'm not writing policy and handing it to someone else - I own the pipelines where those controls actually get enforced. And as the CISO of a security company, I'm our own first customer: whatever we ship, I'm running it in my own environment before anyone else does.

The challenge: GitHub Actions' flexibility is also its biggest footgun

As heavy users of GitHub Actions and big fans of its flexibility, we were seeing an increasing need to mitigate some of the biggest footguns that flexibility brings with it. An action can be written to do anything!

We needed to establish a stronger set of guardrails than what GitHub currently offers. And those new security controls couldn't be a boutique, repo-by-repo effort - they would have to scale to hundreds of repositories across multiple organizations.

What we tried before

We evaluated other eBPF-based tools designed for use as CI/CD runner egress firewalls. These standalone options were not suitable for our scale, having neither the centralized control nor the historical visibility of StepSecurity's solution.

How we found StepSecurity

We had encountered StepSecurity's Harden-Runner in the wild before, in use by several open-source projects we keep tabs on. That, combined with an internal word-of-mouth recommendation, led us to do our initial evaluation.

Why we chose StepSecurity

The other solutions we evaluated broadly fell into one of two categories: too early in development for use in a production environment, or bundled with a suite of unrelated services.

We wanted a mature solution from a partner for whom CI/CD pipeline security is a core competency, not just an afterthought.

The capabilities that mattered most

The most important factor for us was the centralized control of, and visibility into, network egress on our runners.

This has enabled us to bring the principle of least privilege to our pipelines - implementing block-by-default network policies at scale, with narrowly-scoped allowlists defining exactly what each workflow is permitted to reach.

The impact

The adoption of these new security controls has greatly improved teams' visibility into what their pipelines are actually doing.

Even something as minor as a tool quietly adding on-by-default telemetry collection - the unexpected network traffic is immediately surfaced so we can decide how to act on it. Nothing leaves a runner without us knowing about it.

Measurable results

Using StepSecurity data and workflow run policies, we were able to identify 76 end-of-life third-party actions used across 263 repositories for blocking and replacement.

Coupled with a switch to StepSecurity-maintained actions, this has allowed us to significantly reduce action sprawl and its associated risk.

How our workflow changed

With StepSecurity now part of our CI/CD across the enterprise, individual teams have a rapid feedback loop helping ensure their GitHub Actions workflows adhere to recommended security practices. It's as core a part of every pipeline as a set of unit tests.

In summary

"StepSecurity has excelled at filling gaps in GitHub's native security feature set. It has enabled us to convert a set of recommended practices into enforced controls, and to do so at enterprise scale."

- Udi Yehuda, VP of Platform Engineering and Global CISO, Checkmarx

Explore More Case Studies