What should teams do when a build runner may have exposed secrets?

When a build runner may have exposed secrets, what is the right response?

Teams should treat the event as a credential exposure, not a normal infrastructure rebuild. A compromised runner can leak the secrets it could read, sign, or publish with, so the response has to focus on revocation, rotation, rebuild from trusted images, and scope review. The key question is not whether the host “looks clean,” but which identities and artefacts may already be affected.

What needs to be revoked, rebuilt, and reissued

The runner itself is only part of the blast radius. Any secret reachable from that host, including CI tokens, API keys, signing credentials, and deployment credentials, should be considered exposed until proven otherwise. Where the runner could publish or sign artefacts, the identities behind those actions need to be rotated as well, because compromise of the host may imply compromise of the trust chain it used.

That response should start from the assumption that the attacker may have copied material silently rather than altering the build. Rebuilding the runner from a known-good base removes persistence, but it does not undo secret exposure. If the build system uses long-lived credentials, revoke them first, then reissue only what is still needed under tighter scope and shorter lifetime.

How to decide whether the same identity can still be trusted elsewhere

After containment, teams should review whether the same identity can reach other workflows, environments, or repositories. That matters because a single compromised runner identity often has lateral reach through reused tokens, shared secrets, or broad pipeline permissions. If the same credential can access multiple jobs or environments, treat that as an opportunity to reduce blast radius, not just a cleanup task.

A practical review asks three things: what the runner could read, what it could publish, and what it could impersonate. If the answer includes signing, release, or deployment authority, the identity should be narrowed or replaced rather than simply reinstalled. This is especially important when the runner is ephemeral in name only but still backed by durable secrets or shared trust material.

Risk and Threat Considerations

A build runner with exposed secrets creates two linked risks: disclosure of credentials and abuse of the pipeline trust path. Attackers often value CI and build systems because they can reveal source code secrets, deployment tokens, package-signing material, or environment credentials that unlock other systems.

Failure mechanism: The host may have been used to read mounted secrets, environment variables, cached credentials, or signing material before any alert fired. If those secrets are long-lived or reused across workflows, one exposed runner can become a pivot into additional build jobs, registries, cloud resources, or release channels.

Impact: The result can be unauthorized deployments, poisoned artefacts, leaked source or production access, and a wider trust failure in the software supply chain. Rebuild alone does not address that exposure, because the sensitive action is usually credential use, not host corruption.

Practitioner Guidance

What to prioritise: Revoke credentials before rebuilding the runner if the host could access signing, publishing, or deployment secrets. If the same identity also serves other workflows, assume those pathways are in scope until you have proven otherwise.

What to verify: Confirm which secrets were mounted, cached, or injected into the runner, and whether any of them had permission to create artefacts, publish releases, or reach production systems. A “clean” rebuild is not enough if the credential set remains unchanged.

What good looks like: The runner comes back from a known-good image, only short-lived credentials are reissued, and the affected identity is no longer broadly reusable across jobs or environments.

Practitioner takeaway: Treat the incident as a blast-radius question, not a host-replacement exercise, because the real control objective is to remove any identity that could still be used to move from the runner into the rest of the delivery chain.

Related resources from NHI Mgmt Group

• What should security teams do about secrets hidden in SharePoint?
• How should teams handle secrets that have no obvious owner?
• Why do exposed secrets in artifacts and build outputs create outsized risk for software delivery teams?
• How should security teams prioritise NHI remediation in cloud environments?