About Circle
Circle is a global financial technology firm and the issuer of USDC, the world's largest regulated, dollar-backed stablecoin, along with EURC. USDC and EURC are issued by regulated affiliates of Circle; see Circle's list of regulatory authorizations available at circle.com/legal/licenses. Our stablecoins are used by developers, businesses, and financial institutions worldwide to move money on public blockchains, settling an enormous volume of value, so the integrity of everything in our software supply chain is a first-order concern, not an afterthought. Circle's Technical Operations team owns our CI/CD platform and the security controls around our software supply chain, including our GitHub Actions runner fleet.
The challenge
Every CI job spins up, pulls in third-party GitHub Actions and dependencies from public registries, and makes outbound network calls before disappearing. A single tampered action can propagate quickly and attempt to exfiltrate secrets from CI, so as a regulated stablecoin issuer we hold our build pipeline to a high bar: verifiable, runtime guardrails rather than trust and after-the-fact review.
What we tried before
We relied on native GitHub Actions controls plus our own conventions, action pinning, permission scoping, and code review. Those are a strong baseline, but by design they're static, they don't give you runtime visibility or enforcement while a build is actually executing. We wanted that real-time layer, managed centrally as code, which is where StepSecurity came in.
How we found StepSecurity
StepSecurity came onto our radar during the industry response to the tj-actions/changed-files compromise: StepSecurity published the definitive technical analysis of the attack and offered hardened, drop-in replacements for the affected actions, which is how many teams first encountered them. That credibility led us to evaluate their broader platform, and it helped that Harden-Runner is already trusted by thousands of open-source projects, including Kubernetes.
Why we chose StepSecurity
Building and maintaining an equivalent in-house wasn't viable. Of the options we evaluated, StepSecurity was the only one we found that did both: runtime, network-level monitoring of our CI runners and a hardened set of supply-chain best practices built directly into the GitHub Actions lifecycle, backed by threat intelligence they continuously ship across their whole customer base. It also fit our environment cleanly: they gave us a hands-on proof of concept up front, worked directly with our engineers on the self-hosted-runner path, and the agent dropped into our existing setup with no workflow changes, with an audit-then-enforce model that let us learn a safe baseline before turning on blocking.
The capabilities that mattered most
Harden-Runner runtime monitoring — EDR-style visibility into outbound network calls, file writes, and process execution in every CI job, with the ability to baseline in audit mode and then block anything off-baseline in enforcement mode.
Software supply-chain governance — workflow policies for allowed vs. compromised actions, pinning actions to immutable commit SHAs, and a minimum security score for any third-party action before it can run.
Automated remediation PRs — Renovate-style pull requests that pin actions and reduce over-broad permissions for us, plus StepSecurity-maintained hardened forks of popular actions.
Policy-as-code and central visibility — allowlists and action policies managed in version control and reviewed like the rest of our infrastructure, with org-wide dashboards and Slack/email alerting.
Zero build-time overhead and clean integration with our existing stack (GitHub App, Okta SSO, Slack).
The impact
We moved from trust-based CI security to enforced, runtime guardrails. We now have visibility into what every workflow connects to and pulls in; unexpected egress is blocked, and unapproved or known-compromised actions and packages are stopped before they run. Managing all of it as code keeps our posture consistent across the org and easy to audit, and exceptions are quick to grant through a reviewed allowlist. We've also used StepSecurity to lock down our fast-growing set of AI-driven CI workflows, steering them onto isolated, zero-standing-permission runners.
Measurable results
Zero measurable impact on build or test times. We ran Harden-Runner in audit mode for over a month and confirmed no increase in PR or build times before enabling enforcement, so engineers saw no slowdown.
Faster supply-chain incident response. When a compromised package or action makes news, StepSecurity's org-wide inventory and runtime data let us answer "is it running anywhere in our pipelines?" in minutes instead of chasing it across teams and repositories, so our mean time to respond has improved noticeably.
Off-baseline egress blocked at the runner. Harden-Runner measures every build against a learned network baseline and blocks unexpected outbound connections, the same credential- and secret-exfiltration behavior seen in recent npm and GitHub Action supply-chain attacks, so anything off-baseline is stopped before it can leave CI.
Supply-chain campaigns caught early. StepSecurity gives us real-time intelligence on major npm/PyPI/GitHub Action supply-chain campaigns, often several a month, and its cooldown and compromised-package PR checks prevent affected package versions from being merged.
Full runtime visibility into CI egress. Every outbound connection our build jobs make is now captured in one place, measured against a per-workflow baseline and kept over time. We had this signal before, but it was scattered and hard to search; now it is centralized and easy to act on.
How our workflow changed
For most engineers, StepSecurity runs silently in the background, it only surfaces when there's a genuine security event or a workflow change that needs attention, so day-to-day work is unchanged. Behind the scenes, our security model shifted from reactive to preventative: issues now show up as a clear, actionable PR check before merge instead of as an incident later. On our side, managing action and network policies as code means changes are reviewed and version-controlled, and we have a single place to see action usage and detections across the whole org. StepSecurity has also been very responsive to feature requests, which has let us tailor enforcement to how we actually work.
In summary
"StepSecurity was the only platform that gave us both network-level runtime monitoring and supply-chain hardening built into GitHub Actions, and it closed that gap with zero impact on our developers."
– Circle's Technical Operations team
.png)



