Your CI/CD pipeline has access to everything that matters: source code, cloud credentials, signing keys and production. That makes it an attractive target, and recent incidents show attackers know it.
Two incidents worth understanding
- xz Utils (2024): a backdoor was planted in versions 5.6.0 and 5.6.1 of xz, a compression library present on many Linux systems, by a contributor who had spent a long time earning maintainer trust. It was discovered in March 2024, largely by chance, before it reached most stable distributions. It is tracked as CVE-2024-3094.
- tj-actions/changed-files (2025): in March 2025 this widely used GitHub Action was compromised, and its existing version tags were pointed at malicious code that printed CI secrets into workflow logs. Repositories that referenced the action by a version tag ran the malicious code automatically. It is tracked as CVE-2025-30066.
Lock down third-party actions and dependencies
- Pin GitHub Actions and other CI plugins to a full commit SHA, not a tag such as v4, because tags can be moved. Tools such as Dependabot can still propose updates to pinned versions.
- Commit lockfiles and install with exact versions in CI.
- Review new dependencies before adding them, and prefer well-maintained projects with several active maintainers.
- Scan dependencies for known vulnerabilities on every build.
Remove long-lived secrets
- Use OpenID Connect (OIDC) federation so workflows receive short-lived cloud credentials for each run, instead of storing static access keys. AWS, Azure and Google Cloud all support it with GitHub Actions and other CI systems.
- Set the default GITHUB_TOKEN permissions to read-only and grant write access per job only where needed.
- Do not expose secrets to workflows triggered by pull requests from forks.
- Rotate any secret that has ever appeared in a log.
Protect what reaches production
- Require reviews and passing checks before merging to the main branch, and protect release branches and tags.
- Separate build and deploy permissions, and require approval for production deployments.
- Generate a software bill of materials (SBOM) in a standard format such as SPDX or CycloneDX, so you can answer quickly whether you are affected by the next vulnerability.
- Sign build artifacts and container images, and verify signatures before deployment. The SLSA framework offers a graded path for build integrity.
Start with an inventory
List every pipeline, the secrets each one can read and the third-party actions or plugins it runs. Most teams find long-forgotten credentials and unpinned actions in the first hour. Fixing those closes the paths that recent attacks actually used.
