Attacks shifting to CI/CD chains

Attacks Are Moving Up the Software Assembly Line Attackers used to spend most of their time breaking into individual servers. Now they are increasingly aiming at the systems that build and ship software in the first place: continuous integration and continuous delivery pipelines, source repositories, third-party build actions, and release infrastructure. Security agencies and open-source defenders have been warning for several years that these systems are attractive because one compromise can spread malicious code, steal secrets, or tamper with releases across many environments at once. (media.defense.gov) That shift changes the economics of an attack. Breaking into one production server might give access to one application. Breaking into a build pipeline can give access to source code, cloud credentials, signing keys, deployment workflows, and every downstream environment that trusts the pipeline’s output. The United States Cybersecurity and Infrastructure Security Agency and the National Security Agency said in their joint guidance that continuous integration and continuous delivery environments are a distinct attack surface and that compromises have been increasing over time. (media.defense.gov) To understand why this matters, it helps to think of modern software delivery as a factory line. Developers push code into a repository, automated jobs test it, package it, and deploy it, and other systems trust the result because it came from an approved workflow. If an attacker gets into that factory line, they do not need to break every product after it leaves the warehouse; they can alter the process that makes all of them. NIST describes these pipelines as flow processes that move software through build, test, package, and deploy stages as part of the software supply chain. (csrc.nist.gov) That is why the old mental model of “just harden the server” is no longer enough. Traditional host hardening still matters, but it does not cover the workflow file that can mint cloud credentials, the bot token that can rewrite a release tag, or the third-party action that runs inside a trusted build job. GitHub’s own security guidance now emphasizes least privilege for workflow tokens, careful handling of secrets, and scrutiny of third-party actions because the workflow itself has become a privileged control point. (docs.github.com) The warning is not theoretical. In March 2025, the widely used GitHub Action `tj-actions/changed-files` was compromised in a supply-chain attack tracked as CVE-2025-30066. CISA said the incident was potentially enabled by a related compromise of `reviewdog/action-setup@v1`, tracked as CVE-2025-30154, showing how one breached component in a development pipeline can feed the next. (cisa.gov) Researchers and maintainers described the 2025 incidents as a chained compromise rather than a single isolated event. According to the Open Source Security Foundation’s June 11, 2025 maintainer guide, attackers first gained write access in the `reviewdog` organization, pushed a malicious commit, and redirected a version tag. The payload scanned GitHub Actions runner memory for secrets and printed them into workflow logs, using the platform’s own logs as the exfiltration channel. (openssf.org) From there, the blast radius widened. OpenSSF said secrets exposed during the `reviewdog` attack were likely reused to compromise `tj-actions/changed-files`, where attackers repointed version tags from `v1.0.0` through `v44.5.1` to a malicious commit. StepSecurity reported that the action was used in more than 23,000 repositories, which is exactly why these attacks are so attractive: one trusted dependency can sit inside thousands of automated workflows. (openssf.org) The detail that should worry engineering teams is not just that code was changed. It is how little friction the attacker faced once they were inside the pipeline. GitHub’s advisory for CVE-2025-30066 says the malicious script extracted secrets from runner process memory and printed them in GitHub Actions logs, making them publicly accessible in repositories with public workflow logs. That means a build system can become both the target and the leak path. (github.com) This is why defenders are moving their attention to workflow secrets first. Secrets in a continuous integration job are often more powerful than passwords on a single server because they can unlock cloud accounts, package registries, signing services, and deployment platforms. GitHub’s secure-use guidance warns that anyone with write access to a repository may have read access to repository secrets and recommends minimum permissions for the built-in `GITHUB_TOKEN`, log deletion, and secret rotation if exposure occurs. (docs.github.com) The second priority is third-party action vetting. Many teams treat a reusable build action like a harmless helper library, but in practice it executes inside a privileged automation context. OpenSSF’s guidance after the `tj-actions` and `reviewdog` incidents highlighted tag redirection as a key danger: maintainers thought they were using safe versions, but version tags had been moved to malicious code. (openssf.org) That is pushing more teams toward immutable references and stricter trust rules. Instead of pulling a third-party action by a movable version tag alone, defenders increasingly pin to specific commit hashes, restrict which actions can run, and reduce what each workflow token can do. GitHub’s secure-use reference explicitly recommends least privilege for tokens and provides dedicated guidance on using third-party actions safely within workflows. (docs.github.com) The third priority is proving that a released artifact really came from the workflow you think it came from. GitHub’s artifact attestation system creates cryptographically signed claims that tie a software artifact to the repository, commit, workflow, organization, and triggering event that produced it. GitHub says these attestations can be verified by consumers, and that they provide build provenance and integrity guarantees when verification is actually enforced. (docs.github.com) Those attestations are part of a broader push toward software supply-chain evidence instead of blind trust. GitHub says artifact attestations can include a software bill of materials, and its documentation maps them to Supply-chain Levels for Software Artifacts, or SLSA, an industry framework for evaluating supply-chain security maturity. On GitHub, artifact attestations alone provide SLSA version 1.0 Build Level 2, while reusable workflows can help organizations reach Build Level 3. (docs.github.com) The practical takeaway is simple: the most dangerous machine in many companies is no longer the internet-facing server. It is the build runner that can read secrets, call cloud accounts, fetch third-party code, and stamp a release as trusted. CISA and NSA’s guidance lists exposed secrets, insufficient pipeline access controls, poisoned pipeline execution, insecure configuration, and risky third-party services among the main threat areas for continuous integration and continuous delivery environments. (media.defense.gov) So the defensive checklist is changing. Teams still need patched hosts and hardened production systems, but they now also need short-lived credentials through OpenID Connect, minimal permissions on workflow tokens, careful review of every external action, secret rotation after any suspected leak, and verification of signed build outputs before deployment. GitHub’s security guidance explicitly recommends OpenID Connect for cloud authentication and positions artifact attestations as a way to verify where and how software was built. (docs.github.com) What security observers are seeing is not a fad. It is a move toward the highest-leverage point in the software stack. If attackers can tamper with the system that builds software, they do not need to chase every server one by one. They can stand upstream and let trust do the rest. (media.defense.gov)