Secure a CI/CD pipeline in this order: lock down access and credentials, check dependencies, harden the build runners, record provenance for what you build, then verify artifacts before deploy. Early steps are cheap and remove the easiest attack paths. Later steps need more design.
Why start with the pipeline itself?
The OWASP Top 10 CI/CD Security Risks says CI/CD systems deliver code from an engineer's workstation to production, and that attackers have turned their attention to them because they are an efficient path to an organization's most valuable assets. The list names ten risks, from insufficient flow control and weak identity management to dependency chain abuse, poisoned pipeline execution, weak credential hygiene, ungoverned third party services and improper artifact integrity validation.
Several of those are about who and what can run in the pipeline, not about scanning. That drives the order.
What is the order, and why?
1. Access and flow control. Require review before code merges to protected branches, so no single person can push straight through the pipeline. Give pipeline identities only the permissions each job needs. This addresses the first, second and fifth items in the OWASP list.
2. Credentials. Remove long lived secrets from pipeline variables where you can, scan for secrets in code and logs, and rotate what remains. The OWASP list has a dedicated entry for insufficient credential hygiene.
3. Dependencies. Inventory what you pull in, pin versions, and check for known vulnerabilities and suspicious packages before they reach the build. NIST's Secure Software Development Framework, SP 800-218, is a core set of practices that producers integrate into any development model, and it gives buyers a common vocabulary to ask suppliers about. Use it to frame this step.
4. Third party actions and plugins. Pin them to a specific version or digest, review what they can access and remove those you do not use. Ungoverned use of third party services is its own risk category.
5. Build environment. Run builds on hardened, isolated runners that are not shared with untrusted jobs. In SLSA terms, the focus here is tampering during the build.
6. Provenance. SLSA's build track starts at level 1 with provenance showing how a package was built, which helps with mistakes and documentation. Level 2 adds signed provenance from a hosted build platform to address tampering after the build. Level 3 adds a hardened build platform. Pick the level that matches your risk and move up.
7. Verify before deploy. Check signatures and provenance at the point of use. SLSA's purpose is to let consumers compare an artifact's actual provenance to what they expect.
8. Log and watch. The last OWASP item is insufficient logging and visibility. Keep records of who ran what, so you can investigate.
What are the honest limits?
A scan at step three finds known problems. It cannot see what nobody has published. Provenance shows how something was built and says nothing about whether the source was trustworthy. And more controls slow delivery, so adopt them in stages and measure the pain.
See a pipeline check in the CI/CD actions demo.
What to do
- Protect main branches and require review, then trim pipeline permissions.
- Replace long lived secrets, and add secret scanning to code and logs.
- Build a dependency inventory and pin versions.
- Pin and review third party actions.
- Move builds to isolated, hardened runners.
- Generate provenance, then sign it.
- Verify provenance and signatures before deploy.
- Keep logs and review them on a schedule.
Quick check
Do I need SLSA level 3 on day one?
No. Level 1 gives you provenance. Move up as your risk and tooling allow.
Is a vulnerability scan enough for pipeline security?
No. Many CI/CD risks concern access, credentials and build integrity, which scanning dependencies does not address.
Sources
- OWASP Top 10 CI/CD Security Risks, fetched 18 October 2026
- SLSA v1.0: Security levels, fetched 18 October 2026
- NIST SP 800-218, Secure Software Development Framework, fetched 18 October 2026
Last reviewed: 18 October 2026.
