About XBOW
XBOW is an autonomous offensive security platform, founded in 2024. We’ve disrupted traditional penetration testing by training AI to continuously discover exploitable vulnerabilities in web applications. We run intelligent, scalable attack simulations inside customer environments.
About the Author
I'm the security engineer responsible for XBOW's internal security program. My scope covers infrastructure security, static and dynamic code scanning, CI/CD security, image and container security, and product, application, and AI security.
The Challenge
This is actually the third company where I've brought StepSecurity in to secure our CI/CD, after onboarding the product at two previous roles. Across all three, the underlying problem has been the same: CI/CD environments are complex and difficult to secure, especially when workflows can be edited or extended by many contributors.
There's a constant balancing act between restricting engineering access on GitHub and keeping teams productive. If you lock things down too aggressively, engineers can't do their jobs. If you don't, those same workflows become a prime target for supply chain attacks. As a security company, that gap is unacceptable for XBOW.
The bigger issue is that CNAPP tools fall short on CI/CD. They tend to stop at misconfiguration checks and don't give you any meaningful look at what's happening at runtime. I hadn't seen a tool that surfaced GitHub Actions runtime behavior, outbound network activity, and the potential for abuse, until StepSecurity.
Across my previous roles and during evaluations at XBOW, we'd looked at CI/CD security modules inside CNAPP platforms and several open source options. None of them delivered full visibility into CI/CD network behavior. They could flag a misconfigured workflow, but they couldn't tell us what a runner was actually doing once a job was executing. StepSecurity is unique in what it provides here.
Solution & Adoption
In a previous role, I was doing internal red teaming and pentesting against our own infrastructure. I targeted our self-hosted runners to make a clear point to the infra team that we had zero visibility into compromise. I leaned on a piece of public security research from the prior year showing how running a code review step after terraform plan could be turned into RCE on the runner. The exercise landed, and the infra team agreed we needed real visibility.
While researching the space, I came across the StepSecurity research team's work on the tj-actions incident. After receiving a demo and conducting a PoC, it was clear to me that the technology would fill an important gap for us, and it filled it well.
The research side of StepSecurity is particularly strong. The StepSecurity team consistently discovers new supply chain attacks and is informative about how those attacks impact customers in real time. When something is unfolding in the wild, they tell us, and they tell us specifically whether our environment is affected, sometimes via Harden Runner telemetry catching calls to a known C2 domain from a vulnerable workflow run. This has helped us proactively prevent multiple potential security incidents.
The features that mattered most for us were:
- Network monitoring on runners and the visibility that comes with it
- Deep visibility into CI activity overall
- Ease of rollout across the CI estate, especially the automated PRs to harden workflows at scale
- Developer laptop dependency monitoring, which gives us an inventory of malicious npm packages reaching engineering laptops
That last piece has been particularly valuable as MDMs often don't provide that level of supply chain visibility on developer endpoints.
Results and Impact
We know what's happening on our CI. We have visibility into network calls, malicious activity, a full inventory of our CI footprint, and laptop-level supply chain monitoring on top of that. As a security engineer, I genuinely don't worry about CI/CD the way I used to, because I know StepSecurity is watching it.
The clearest result is that we have not had a single supply chain or CI-related incident lead to a compromise of our environment. Effectively that's 100% of in-scope incidents prevented and a meaningful reduction in our overall risk surface. We've also wired StepSecurity alerts into our SIEM, which lets us trigger incidents through incident.io when an event warrants it.
We've automated a lot of what used to be manual triage and integrated StepSecurity directly into our incident response process, which has cut response time considerably. It's now a standard part of our vulnerability management workflow, and because the alerts are tuned, it doesn't generate extra noise or extra work for the security team.
As a security company, CI/CD and supply chain attacks are an unacceptable risk. Our team understands our attack surface and knows how to harden it. We now rely on StepSecurity’s threat research team to continuously identify emerging threats, helping us to proactively prevent potential security incidents.
.png)
