CI/CD Pipeline Attacks

What it is

CI/CD pipeline attacks target automated build, test, and deployment systems. These systems often hold credentials or influence production artifacts, making them a powerful trust boundary. A workflow that safely processes ordinary code can become dangerous if untrusted contributions or third-party actions receive deployment permissions.

How it works

An attacker modifies a build script, compromises a runner or action, or steals a pipeline secret. Code executed during a build can inspect available credentials and alter outputs. Persistent runners can retain malicious changes between jobs, while broad deployment tokens can extend compromise into production.

How people get tricked

A routine dependency, pull request, or workflow update is reviewed only for product changes. Teams forget that tests and installation hooks execute code too. Approval of a build is not automatically approval of every privileged action it can perform.

Example scenario

An untrusted contribution triggers a workflow with production secrets. Its build step can access those secrets even though the contribution has not been accepted into the protected branch.

Warning signs

• Unexpected workflow changes or secret use outside approved deployments.
• Unexplained runner state or outbound requests during builds.
• Released artifacts differ from reviewed source or expected provenance.

If it happens to you

Pause affected deployments, revoke exposed credentials, and inspect runners and produced artifacts. Rebuild releases in a clean trusted environment and assess production changes. Restoring the workflow file alone does not establish that earlier artifacts or stolen tokens are safe.