Why do CI/CD pipelines make secret theft easier for attackers?

Why CI/CD Pipelines Become High-Value Secret Targets

CI/CD systems concentrate the exact material attackers want: cloud keys, package tokens, deployment credentials, signing material, and environment variables. That concentration turns a build path into a credential warehouse. The risk is not only exposure during runtime, but also persistence in logs, artifacts, caches, and runner images, where secrets can be copied long after the original job finishes.

NHIMG’s The State of Secrets Sprawl 2025 shows how broad this problem already is in real environments, while NHIMG case research such as CI/CD pipeline exploitation case study and Reviewdog GitHub Action supply chain attack illustrate how a trusted automation step can become a harvesting point. In practice, many security teams encounter secret theft only after a pipeline compromise has already been used to pivot into production, rather than through intentional review of the build trust boundary.

Attackers prefer pipelines because they are already allowed to do sensitive work. The same automation that pulls code, installs dependencies, and deploys to cloud platforms can also reveal where secrets live and when they are injected. Once a workflow definition, action, plugin, or runner dependency is altered, secret exposure can happen without any interactive login at all.

How Attackers Turn Build Automation Into Secret Harvesting

Most pipelines expose secrets through trusted execution paths rather than direct misconfiguration alone. An attacker who can modify a workflow file, poison a dependency, compromise a self-hosted runner, or abuse a third-party action may gain access to the same variables and tokens the pipeline uses to perform legitimate releases. The main weakness is that traditional trust assumes the pipeline itself is safe once authenticated, even though the pipeline’s content and dependencies may be changing on every run.

Current guidance suggests treating pipeline identity, execution context, and secret access as separate decisions. That means applying least privilege to each job, issuing short-lived credentials only when a step truly needs them, and revoking them as soon as the task completes. Where possible, use workload identity rather than static secrets, because a cryptographic proof of what the runner or agent is can be safer than a reusable token that sits in a variable store. Frameworks such as the CISA cyber threat advisories and NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce the need for access restriction, auditability, and controlled credential handling.

• Store fewer long-lived secrets in pipeline variables and more in a central secrets manager with short TTLs.
• Separate build, test, and deploy identities so one compromised job cannot read every credential.
• Block secret output in logs, artifacts, and caches, since post-execution residue is a common leakage path.
• Review third-party actions, runner images, and plugin updates as supply chain dependencies, not just code utilities.

NHIMG’s Guide to the Secret Sprawl Challenge is useful here because it frames the practical problem as sprawl plus reuse, not just accidental leakage. These controls tend to break down when self-hosted runners are broadly privileged and persist across many builds, because one foothold can expose many unrelated secrets at once.

Where the Standard Answer Breaks Down in Real Pipelines

Tighter pipeline credential controls often increase delivery overhead, requiring organisations to balance release speed against containment. That tradeoff becomes sharper in mono-repos, GitOps deployments, ephemeral preview environments, and multi-account cloud setups, where a single release path may need access to several systems. There is no universal standard for this yet, but current guidance suggests minimising the number of secrets injected per job and preferring just-in-time access over static reuse.

One common exception is dependency on legacy tooling that cannot use federated workload identity, forcing teams to keep static tokens longer than they should. Another is heavily outsourced CI where multiple vendors, orchestrators, and shared runners blur responsibility for who can see secrets at runtime. In those cases, the most realistic improvement is not perfect elimination, but stronger segmentation, better audit trails, and rapid revocation if a job behaves unexpectedly. The broader pattern is documented across NHIMG research on the 52 NHI Breaches Analysis and the Shai Hulud npm malware campaign, both of which show how quickly trusted automation can become a secret extraction channel.

For threat modeling, pairing pipeline hardening with MITRE ATT&CK Enterprise Matrix helps map likely post-compromise actions, while the OWASP Non-Human Identity Top 10 remains the clearest reference for reducing secret sprawl in non-human workloads.

Related resources from NHI Mgmt Group

• Why do CI/CD pipelines create secret governance risk?
• Why do CI pipelines make secret exposure harder to control than service accounts?
• Who is accountable for OpenTofu secret handling in CI/CD pipelines?
• How do attackers turn a supply-chain incident into wider NHI compromise?