Why Short-Lived Credentials Beat Rotating Secrets After a CI Breach

After the October 2026 GhostAction campaign, the standard advice was to rotate every exposed secret. That is correct and necessary, but if rotation is your whole strategy you will be doing it again after the next compromise. The deeper fix is to change what a stolen workflow can take in the first place. A credential that expires in an hour and never sits in a file is a poor prize for an attacker who has already read your repository.

The Problem With Long-Lived Secrets

Most CI pipelines run on stored secrets: a cloud access key, a registry password, a deployment token, saved once and reused for years. This model has two failures that GhostAction exploited directly.

First, a long-lived secret is valuable for as long as it exists, which is usually far longer than anyone intends. The same token that deploys your app today will still work months after it leaks, giving an attacker a wide window. Second, a stored secret has to live somewhere a workflow can read it, and as how a GitHub ActionsGitHub Actions🛡️GitHub's built-in automation and CI/CD platform. It runs workflows defined in YAML files under a repository's .github/workflows directory, and those jobs can read the repository's stored secrets and reach the network. workflow can reach every secret in your pipeline explains, anything a workflow can read, a malicious workflow can exfiltrate. Rotation shortens the window after you detect a leak, but detection is the hard part, and the clock only starts when you notice.

What Short-Lived, Identity-Based Credentials Change

The alternative is to stop storing cloud credentials in your CI system at all and let the workflow prove its identity instead. With OpenID Connect, a workflow presents a short-lived, cryptographically verifiable token describing what it is, which repository and branch it runs in, and which event triggered it. Your cloud provider validates that token against a trust policy you define and hands back temporary credentials that expire in minutes.

Nothing durable is stored. There is no access key in a settings page for an attacker to steal, and the temporary credential a workflow does hold is useless by the time it reaches an exfiltration server and a human looks at it. Just as important, the trust policy can be scoped so that only a specific repository on a specific branch can assume a given role, so a malicious workflow pushed into a fork or a feature branch cannot mint production credentials even if it runs.

This does not cover everything. Some third-party services still require a stored API key, and those should be minimised, scoped as tightly as the service allows, and rotated on a schedule. But moving the high-value cloud and deployment credentials to short-lived identity removes the targets that matter most.

Approval Gates and Egress Control

Identity is the foundation; two more controls limit the damage when something still goes wrong.

Approval gates decide what is allowed to run. In the August-to-September 2026 GhostAction wave, GitHub held most malicious runs for manual approval and blunted the campaign. You can build the same friction deliberately: require review before workflows execute on changes from outside collaborators, protect the branches that deploy, and treat a change to a workflow file as a sensitive diff that a human signs off on, the same way you would review a change to authentication code.

Egress control decides where a runner can talk. A build job rarely needs to reach arbitrary addresses on the internet, yet by default it can, which is how stolen secrets leave. Restricting outbound traffic to an allowlist of the registries and services a pipeline genuinely uses means that even a successful credential grab has nowhere to send its loot. The October campaign's bare-IP, plain-HTTP exfiltration would have hit a wall against a default-deny egress policy.

Building the Plan

You cannot convert an entire organisation overnight, so sequence the work. Start by inventorying which pipelines hold the most dangerous standing credentials, typically cloud and deployment access, and migrate those to OpenID Connect first. In parallel, turn on push protection and secret scanningSecret Scanning🛡️An automated check that searches code and commit history for credential-shaped strings. Push protection extends it by blocking commits that contain a detected secret before they reach the repository. so new secrets stop accumulating, which pairs with the cleanup described in how to find and remove secrets hidden in your git history.

Then add the guardrails: branch protection and approval requirements on the workflows that ship code, and an egress allowlist on the runners that handle anything sensitive. Finally, write down the revocation-first incident steps so that when a token does leak, you kill it at the source before you spend hours rewriting history.

The Shift in Mindset

Rotation treats each leak as an event to clean up. Short-lived credentials treat leaks as inevitable and make them cheap. The goal is a pipeline where a compromised workflow walks away with a credential that has already expired, cannot be used from where the attacker is, and could not reach the internet to be sent in the first place. GhostAction succeeded against repositories full of durable, broadly scoped, readable secrets. The way to not be the next victim is to stop keeping any.