At a glance
- Gained full runtime visibility across the software delivery pipeline, from GitHub Actions runners to developer machines
- Deployed Harden-Runner to bring runtime visibility and network-level protection to previously black-box CI/CD runners
- Deployed Dev Machine Guard across all developer machines to extend that same monitoring to where code starts its life
- Cut compromised-package investigations from hours to minutes across pipelines and laptops
- Replaced a homegrown static-analysis tool with continuous, runtime coverage of the whole build and development environment
- Reduced triage time for security events, with the runtime data the team needs already at hand
About Contrast Security and my role
Contrast Security is the leader in Application Detection and Response. Our technology protects the software of some of the biggest corporations and government entities in the world. No other product can do what we do, which is to block attacks at runtime.
As Senior Director of Product Security at Contrast, my job is to ensure our products, tools, and services are secure. My team does a little bit of everything in the application security space: from security engineering to incident response, to threat modeling. It's a busy life, but very fun and rewarding.
The challenge: Limited visibility into GitHub Actions runners and developer machines
Our biggest pain point was the lack of runtime visibility in the ephemeral VMs that run CI/CD for our software. When a build kicks off on a GitHub-hosted runner, that machine spins up, executes code, including third-party actions and dependencies, makes outbound network calls, and disappears. We had no view into the running processes or outbound network traffic on those machines.
And the problem doesn't stop at CI/CD. The same blind spot exists on developer machines, where packages are installed, and code runs long before it ever reaches a pipeline. When news of a compromised open-source package breaks, the hardest question to answer quickly is: is that package running anywhere in our environment, in our pipelines or on our developers' local machines? Without runtime visibility across both, answering that question during an incident is slow and painful.
StepSecurity bridged that gap.
What we tried before
We had a homegrown tool that did static analysis of third-party GitHub Actions, but that was just barely scratching the surface of what we really needed, which was runtime visibility into GitHub runners and the rest of the development environment. Static analysis tells you what a workflow declares it will do; it tells you nothing about what actually happens at runtime.
How we found StepSecurity
Through our CISO, Dave Lindner, who came across the Harden-Runner open-source project on GitHub.
Why we chose StepSecurity
Three things: functionality, breadth of coverage, and cost. StepSecurity was the only solution that gave us runtime visibility across the whole software development and delivery pipeline, from the developer's laptop to the ephemeral CI/CD runner, rather than just one slice of it.
The capabilities that mattered most
Two capabilities stood out, and together they gave us coverage across the entire build and development environment.
Harden-Runner was the first. It gave us the runtime visibility and network-level protection we had been missing on our GitHub Actions runners, surfacing the running processes and outbound network traffic that were previously invisible to us. For the first time, our CI/CD pipelines stopped being a black box.
Dev Machine Guard completed the picture. It extends that same runtime visibility to where code actually starts its life: our developers' local machines. We've deployed it across devices, so our monitoring no longer ends at the pipeline. It follows the software all the way back to the laptops where our engineers build it every day. That end-to-end coverage, from developer machine to ephemeral runner, is what set StepSecurity apart.
The impact
We went from having no line of sight into our build environment to continuous runtime visibility across our GitHub runners, and, with Dev Machine Guard, the same visibility across our entire fleet of developer machines. Our biggest blind spot is now one of our most closely watched surfaces.
Dev Machine Guard has also transformed our incident response. Whenever news of a compromised package is made public, we can quickly see if that package is running anywhere within our pipelines and local machines. It's the difference between hours of uncertainty and a clear answer. What used to be a scramble across teams is now a quick lookup.
Measurable results
Reduced triage time for security events. When a supply chain incident hits the news, we no longer spend hours or days manually chasing down whether we're affected. We can answer that question across our pipelines and all developer machines in minutes.
How our workflow changed
The team now starts from data instead of guesswork. Investigations that once meant chasing answers across teams begin with the runtime evidence already in hand, so security is embedded in how we build and ship rather than bolted on after the fact.
In summary
“StepSecurity gave us visibility into a part of the software delivery process that had previously been difficult to observe. We can now investigate potential supply chain incidents across both our CI/CD runners and developer machines using runtime evidence instead of chasing answers across multiple teams.”
— Naomi Buckwalter, Senior Director of Product Security, Contrast Security
