CI/CD security

Why pipelines are a target

• They hold the keys. Cloud credentials, registry tokens and signing keys all pass through CI.
• They run other people's code. Every dependency, install script and third-party action executes on the runner.
• They reach production. Whatever comes out of the pipeline is trusted, signed and shipped. An attacker in the build reaches every customer at once.
• Few people watch them. Workflow files change rarely and get less review than application code.

The tj-actions compromise and the Shai-Hulud npm worm both went after secrets in CI. See what is a supply chain attack for how these attacks unfold.

The main CI/CD security risks

The OWASP Top 10 CI/CD Security Risks is the standard reference. Grouped by what goes wrong:

Area	OWASP risks	What it looks like
Who can change what	Insufficient flow control, inadequate identity and access management	Code reaches production without review, or old accounts keep their access
What runs in the pipeline	Dependency chain abuse, poisoned pipeline execution	A malicious package or a changed workflow runs with the job's access
What a job can reach	Insufficient pipeline-based access controls, insufficient credential hygiene	One job can read every secret, and tokens live for years
How it is set up	Insecure system configuration, ungoverned use of third-party services	Unpatched runners, and integrations with more access than they need
What you can prove	Improper artifact integrity validation, insufficient logging and visibility	Nobody can tell what went into a release or what a job connected to

For each risk mapped to runner controls, see runner security compared.

CI/CD security best practices

1. Treat pipeline definitions as production code. Require review on workflow files, and keep untrusted pull requests away from secrets.
2. Limit what each job can do. Give tokens the least permission they need, and prefer short-lived credentials to stored secrets.
3. Pin third-party actions to a commit hash. Tags can be moved to other code.
4. Isolate jobs. Run each job in a fresh environment, so that nothing carries over to the next.
5. Control outbound traffic. A build needs known sources and known destinations. Blocking everything else stops stolen secrets from leaving. See GitHub Actions egress policy.
6. Record what happened. Keep an SBOM of each build and a log of its network activity, so that you can answer questions afterward.

For the step-by-step version, see the CI/CD pipeline security checklist.

Types of CI/CD security tools

Type	What it does	Examples
Runner security	Isolates jobs and controls what they can reach while they run	CRACI, StepSecurity
Posture management	Finds risky pipeline and repository settings	Legit Security, Cycode, Apiiro, OX Security
Code and dependency scanning	Checks code, dependencies and secrets on each change	GitHub Advanced Security, Snyk, Semgrep
SBOM and evidence	Records what went into each release	CRACI, Syft, Anchore

These work at different stages, so most teams combine them. A scanner looks at files before the build, posture tools look at settings, and runner security works while the job runs, which is when a malicious package acts. See software supply chain security tools compared and DevSecOps tools compared.

Where CRACI fits

CRACI secures the build while it runs. It replaces your GitHub-hosted runners with faster, lower-cost ones: each job runs in its own isolated virtual machine, an egress policy blocks connections the build does not need, and every package the job fetches goes into an SBOM. Because the policy allows only what the build needs, it protects you even against an attack nobody has seen before.

CRACI does not check your workflow configuration, scan source code or secrets, or sign provenance, so keep or add tools for those. GitHub Actions is the supported CI system today, and other CI systems are on the roadmap.

CI/CD security: frequently asked questions

What is CI/CD security?

It is the practice of protecting the pipelines that build, test and ship software, including their credentials, the code they run and the artifacts they produce.

What are the biggest CI/CD security risks?

Malicious dependencies and third-party actions, poisoned pipelines, over-permissioned tokens and long-lived secrets, and a lack of visibility into what a build did. The OWASP Top 10 CI/CD Security Risks is the standard list.

What is poisoned pipeline execution?

An attacker changes what a pipeline runs, for example by editing a workflow file or a script it calls through a pull request, so that their code runs with the pipeline's access.

How do you secure a CI/CD pipeline?

Review pipeline changes, give each job the least access it needs, pin third-party actions by commit hash, isolate jobs, restrict outbound traffic and keep a record of what each build did.

What is the difference between CI/CD security and DevSecOps?

DevSecOps is the broader practice of building security into how software is developed. CI/CD security focuses on the pipeline itself, which DevSecOps tools also depend on.

Do GitHub Actions need extra security?

GitHub provides controls such as token permissions and secret scanning, but you have to configure them, and hosted runners do not restrict outbound traffic by default. Most teams add pinning, review rules and runner controls.