To embed security in CI/CD, do two things: protect the pipeline as the valuable system it is, and add checks inside it that run on every change. Scope credentials tightly, pin and verify what the build pulls in, and let policy gates block builds that break agreed rules.
Why is the pipeline itself a target?
OWASP's Top 10 CI/CD Security Risks project states that CI/CD systems deliver code from an engineer's workstation to production, and that attackers realize CI/CD services offer an efficient path to an organization's crown jewels. Compromise the pipeline and you can ship anything.
The ten risks it lists are: 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.
Notice how few of those are about the code under test. They are about who can change the pipeline, what it trusts and what it records.
What belongs inside the pipeline?
Checks that match each stage.
- On commit: secret detection, so credentials never enter history.
- On pull request: static analysis, dependency and license checks, and review rules requiring a second person for pipeline and infrastructure files.
- On build: pinned dependency versions, a software bill of materials, and a provenance record of how the artifact was built.
- Before release: policy gates on known exploited vulnerabilities, signing of artifacts, and verification of signatures at deploy time.
- After release: logging of who deployed what, and alerts on changes outside the normal path.
The SLSA framework offers a vocabulary for build integrity, with incremental levels that help producers secure their supply chain and let consumers judge whether to trust an artifact. NIST SP 800-204C applies DevSecOps to cloud-native applications, including policy as code and infrastructure as code among five code types it names.
A constructed example
A team's pipeline uses one long-lived token with write access to production and the container registry. Anyone who can edit the pipeline file can read it. A contributor's pull request modifies the build script to print environment variables.
Fixes in order of value: remove the standing token and use short-lived credentials issued per job; require review by a code owner for changes to pipeline files; restrict which branches can deploy; run untrusted pull requests in a separate, low-privilege runner with no secrets. Each one maps to a risk in OWASP's list: credential hygiene, flow control, pipeline-based access control and poisoned pipeline execution.
None of that needed a new scanner.
How to check or apply this
- Draw the pipeline: triggers, runners, credentials, artifact stores and deploy targets.
- Walk the OWASP list against the drawing and note which risks apply.
- Replace long-lived secrets with short-lived, per-job credentials scoped to one environment.
- Protect pipeline definitions with code owners and branch protection.
- Separate runners for untrusted code, with no access to secrets or production.
- Pin dependencies and actions to exact versions or digests, and review updates.
- Generate an SBOM and provenance for every release artifact, and sign it.
- Add gates for secrets, known exploited vulnerabilities and license rules, and decide in advance which findings block and which warn.
- Log pipeline changes and deployments to a place the pipeline cannot edit.
- Measure build time added by checks. Slow gates get bypassed.
Where does Safeguard fit?
The Safeguard CLI can run in CI to generate SBOMs, scan dependencies and gate builds, with SARIF and JUnit output so results appear in your existing tooling. Policies and gates let you set what blocks a build. You remain in charge of the rules.
How do you keep developers on side?
Fast feedback beats strict rules. Run quick checks on every push and heavier ones nightly. Show findings in the pull request, with a clear fix. Start new gates in warn mode, show the team the count, then enforce when the noise is low. A gate that blocks on false positives teaches people to work around it.
Quick check
Should every finding fail the build?
No. Fail on a short list you have agreed, such as secrets and known exploited vulnerabilities in reachable code, and report the rest as warnings with owners and due dates.
What is poisoned pipeline execution?
An item in OWASP's CI/CD risk list: an attacker who can change pipeline configuration or the files it runs makes the pipeline execute malicious commands with its privileges. Protect pipeline definitions and isolate untrusted runs.
Sources
- OWASP Top 10 CI/CD Security Risks
- SLSA: About SLSA
- NIST SP 800-204C: Implementation of DevSecOps for a Microservices-based Application with Service Mesh
- NIST SP 800-218: Secure Software Development Framework
Last reviewed: 18 October 2026.
