By Ashish Kurmi
CI/CD pipelines are increasingly becoming high-value targets for attackers. With access to secrets, source code, and infrastructure, they offer a direct route to supply chain compromise. The recent breaches involving tj-actions/changed-files and reviewdog/action-setup are not just isolated events, they are harbingers of a new generation of CI/CD-targeted supply chain attacks.
This guide is tailored for open-source maintainers, offering practical steps to secure GitHub Actions workflows and protect against such chained compromises. It provides background on what happened in the reviewdog and tj-actions incidents, why those attacks were so dangerous, and a defense-in-depth blueprint of best practices to harden your CI/CD pipeline.
Anatomy of the Attack Chain
These incidents were not isolated. Instead, they formed a cascading compromise where one breach directly enabled the next. This chain of exploits shows how interconnected and fragile CI/CD environments can be when foundational security practices are missing.
Stage One: Compromise of the reviewdog Organization
The first breach began in the reviewdog GitHub organization. A flawed contributor management process allowed an attacker to escalate privileges:
- The attacker exploited an automated invitation process to join the @reviewdog/actions-maintainer team.
- This team had write access to several repositories, including reviewdog/action-setup.
- Using this access, the attacker pushed a malicious commit and redirected the v1 tag to point to it.
- The payload was a Python script that scanned GitHub Actions runner memory for secrets and printed them to the workflow logs.
Instead of using a remote server to steal secrets, the attacker relied on GitHub’s own logs as the exfiltration channel. This approach was simple and effective and it avoided triggering traditional security alerts.
Stage Two: Compromise of tj-actions Using Stolen Credentials
Secrets exposed during the reviewdog attack likely included credentials for the bot account used by tj-actions. These were reused to compromise a second project:
- The attacker used the stolen credentials to gain access to the tj-actions/changed-files repository.
- They updated every version tag, from v1.0.0 through v44.5.1, to point to a single malicious commit.
- That commit contained similar exploit code, designed to dump secrets to the build logs during CI runs.
- This action was widely used across the open-source ecosystem, which significantly expanded the impact.
Why These Attacks Were So Dangerous
These attacks were particularly severe because they combined subtle techniques that bypassed normal safeguards:
- Tag Redirection: Every version tag pointed to the same malicious commit. Maintainers who thought they were using a safe version were unknowingly executing malicious code.
- Log-Based Exfiltration: No outbound network exfiltration was needed; secrets were dumped directly into the CI logs.
- Chained Exploitation: A single breach enabled a follow-on compromise of another widely used action. This demonstrated how CI/CD can become a vulnerable supply chain.
- Stealth and Sophistication: The commits were unsigned. Bots like Renovate were spoofed as authors. No signature or reputation-based tooling detected the compromise.
What Made These Attacks Possible
Several security gaps and insecure practices contributed to the success of these exploits:
- Use of mutable tags instead of full-length commit SHAs for GitHub Actions.
- Unprotected secrets accessible in memory during workflow runs.
- Lack of tag protection and minimal visibility into changes to tags or workflows.
- Absence of runtime monitoring for suspicious behavior in CI pipelines.
- Overly broad access controls, such as excessive maintainer team privileges.
A Defense-in-Depth Blueprint for Maintainers
Maintainers can significantly harden their CI/CD pipelines by adopting a defense-in-depth approach that addresses these weaknesses from multiple angles. The following blueprint outlines key measures for open-source maintainers:
Lock Down Actions Usage
- Pin to Commit SHAs: Never reference tags like @v1 or @main. Always pin to full commit hashes for immutability. Pinning ensures that you run a known good version of an action that cannot be changed or retagged by an attacker.
- Restrict Allowed Actions: Use GitHub’s allowed-actions policy to explicitly permit only trusted actions. For example, restrict workflows to use actions from your organization or pre-approved publishers.
- Audit Dependencies: Periodically review third-party actions and remove any that are unused or unmaintained.
Secure Contributor and Repository Settings
- Enforce Multi-Factor Authentication (MFA): Require all contributors with commit or release privileges to enable Multi-Factor Authentication. This significantly lowers the risk of account compromise due to stolen or reused credentials.
- Audit Write Access Regularly: Conduct regular audits of users who have write access to your repositories and GitHub organization. Follow the principle of least privilege by granting write or tag-push permissions only to users who absolutely need them.
- Enable Tag and Branch Protection Rules: Configure branch protection rules for critical branches such as main, and apply similar controls to release tags. If supported, prevent untrusted users from creating or modifying tags to help guard against tampering.
- Monitor for Workflow and Tag Changes: Set up monitoring to detect unexpected changes. Use alerts or automated scripts to notify you if a workflow file is modified or if a release tag is moved.
Secrets and Workflow Isolation
- Avoid Persistent Credentials: Eliminate persistent credentials if possible. Avoid storing long-lived secrets in your CI, use short-lived tokens or federated credentials instead (for example, utilize GitHub’s OIDC tokens to obtain cloud credentials on the fly).
- Use GitHub Environments to Protect Secrets: Environments allow you to impose checks (like required reviews or timing restrictions) before certain secrets can be used by a workflow.
- Require Manual Approvals for Sensitive Workflows: Add manual approval steps to workflows that involve sensitive secrets. A human review helps ensure that only trusted code is allowed to access your most critical secrets.
Implement Runtime Security and Monitoring
- Monitor CI/CD runners for unusual behaviors such as unexpected outbound traffic or file modifications. Consider adding a runtime security agent such as Harden-Runner to your pipeline.
- Use anomaly detection based on baseline behavior – define what normal looks like for each workflow and flag any deviation. For example, if a build job suddenly makes network calls or reads memory it never did before, it should be investigated.
- Scan build logs for leaked secrets and suspicious strings. Implement automated scans of workflow logs to catch any credentials or tokens that might have been unexpectedly output. This can provide a last line of defense to detect compromise after the fact.
CI/CD Best Practices for Long-Term Resilience
- Integrate OpenSSF Scorecard checks into CI: The OpenSSF Scorecard tool can automatically assess your repository’s security best practices (including many of the above measures) and alert you to weaknesses.
- Keep Dependencies and Actions Up to Date: Automate the updating of dependencies and GitHub Actions using tools like Renovate or Dependabot. Staying current with updates helps you apply security patches promptly and use the safest available versions of third-party components.
- Avoid Mutable Tags When Referencing Actions: Do not use mutable tags (such as latest) when specifying actions in your workflows. These tags can change over time without your knowledge. Instead, use full-length commit SHAs to ensure your workflows always run with the exact code you have reviewed and approved.
- Configure Fine-Grained Permissions for GITHUB_TOKEN: Use GitHub’s fine-grained permission model for the GITHUB_TOKEN. Configure the built-in GITHUB_TOKEN with the minimum scopes needed. Limit access to only the resources each job needs, so that even if an action is compromised, it cannot abuse excessive repository permissions.
Conclusion
The recent tj-actions and reviewdog incidents highlight a pivotal security lesson: CI/CD pipelines must be treated as production-level assets and secured with the same rigor. Attackers are actively targeting build infrastructure, and these exploits show how a seemingly small weakness can cascade into a serious breach.
Crucially, the tj-actions and reviewdog compromises are not isolated incidents – they serve as a blueprint for attackers. Maintainers need to shift their mindset to assume that any third-party component or credential in their CI pipeline can be a potential target. The call to action is clear: adopt secure defaults and defense-in-depth practices for your CI/CD workflows now, before attackers strike. By implementing the measures outlined above, you can significantly reduce the risk of becoming the next victim of a CI/CD supply chain attack.
About the Author
Ashish Kurmi is the Co-founder and CTO of StepSecurity, where he works to improve the security posture of open source projects and CI/CD systems.