The DevOps practices that reduce risk most protect the pipeline itself: scoped identities, pinned and reviewed dependencies, isolated and verifiable builds, short lived credentials, and logs that show who changed what. A pipeline holds secrets and deploys to production, so attackers treat it as a target.
Why is the pipeline a target?
It has credentials for source control, registries and cloud accounts, and it has permission to ship code to production. Compromise it and you can alter software without touching the application's own repository. The OWASP Top 10 CI/CD Security Risks project lists the ways this happens: insufficient flow control mechanisms, inadequate identity and access management, dependency chain abuse, poisoned pipeline execution, insufficient pipeline based access controls, insufficient credential hygiene, insecure system configuration, ungoverned usage of third party services, improper artifact integrity validation, and insufficient logging and visibility.
Which risks should you tackle first?
Pick by how often they bite and how cheap the fix is.
Credentials. Replace long lived secrets with short lived tokens issued at job time. Give each pipeline job only the permissions it needs, and no more.
Flow control. Require review before code reaches the main branch and before a deploy job runs. One person should not be able to write, approve and ship a change alone.
Poisoned pipeline execution. The pipeline definition is code. If a pull request from an untrusted fork can change it and run with secrets, an attacker can read them. Run untrusted code without secrets.
Dependencies. Pin versions, use a lockfile and review additions. A new transitive package is new code in your build.
Artifact integrity. Sign what you build and verify before deploying. SLSA describes incrementally adoptable guidelines for supply chain security that let consumers decide whether to trust a package, and its levels give you a ladder to climb.
Visibility. Keep logs of pipeline runs, approvals and secret access outside the system being logged.
A constructed example
A team's workflow runs tests on every pull request, including from forks, and the test job can read a deploy token. An outside contributor edits the workflow file in a pull request to print the token. The fix is three small changes: forks run in a job with no secrets, the deploy token is issued only to a protected branch job, and the token expires in minutes. Nothing about the application changed.
Do not overlook the build environment itself. Runners that are reused between jobs can carry files, caches and credentials from one job to the next, so prefer fresh, isolated runners for anything that handles secrets. Keep the runner image patched, limit its outbound network access to the registries it needs, and treat third party actions and plugins as dependencies: pin them to a specific version or commit and review changes before updating.
Where do tools fit?
Tools enforce what the process decides. Dependency and SBOM scanning shows what you ship, reachability analysis helps rank which flaws matter, and policies and gates can block a merge that breaks an agreed rule. Safeguard provides these, plus optional automated fix pull requests, which are off by default so a human decides what merges. You can see how a gate behaves in the demo below.
What to do
- Inventory every pipeline and the secrets each one can read.
- Swap long lived secrets for short lived, scoped credentials.
- Protect the main branch and the deploy job with required review.
- Run untrusted pull requests without secrets.
- Pin dependencies and review changes to lockfiles.
- Sign build outputs and verify the signature at deploy time.
- Send pipeline logs to a store the pipeline cannot edit.
Quick check
What is the first fix if I can only do one?
Remove long lived secrets from the pipeline and scope what remains, since stolen credentials turn a small flaw into a production breach.
Does signing artifacts replace code review?
No. Signing shows an artifact came from your pipeline unchanged. Review is what decides whether the code in it should have been built.
Sources
- OWASP Top 10 CI/CD Security Risks
- SLSA, About
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
