CI/CD cyber security is the practice of protecting the build and deployment pipeline itself — the runners, secrets, dependencies, and artifacts that turn code into running software — because that pipeline is now one of the highest-value targets an attacker can reach. A developer laptop compromise affects one person; a CI/CD compromise can inject malicious code into everything the organization ships. The SolarWinds attack drove this home: attackers did not breach the product's source in an obvious way, they compromised the build system and inserted their backdoor during compilation, so the malicious code was signed with the legitimate certificate and distributed to thousands of customers as a trusted update.
Why the pipeline is such a rich target
Think about what a CI/CD runner has access to. It holds cloud deployment credentials, container registry tokens, code-signing keys, database passwords, and the source code of everything it builds. It runs automatically, often with broad permissions, and it produces the artifacts your customers trust. Compromise that environment and you inherit all of it at once.
The attacker's math is simple: instead of attacking every downstream victim, attack the one system that builds and signs the software they all install. That leverage is why supply-chain and pipeline attacks have grown so fast, and why "CI/CD cyber security" is now a discipline rather than an afterthought bolted onto DevOps.
Secure the runners
Build runners execute untrusted code by design — your dependencies, your build scripts, and increasingly code from pull requests. Treat them accordingly.
Use ephemeral runners. A fresh, disposable environment per job means malicious code cannot persist between builds or harvest state left by a previous run. Long-lived runners accumulate secrets, caches, and compromise.
Isolate builds from each other. One job should not be able to read another's workspace or environment. On self-hosted runners, this means proper sandboxing and not sharing a runner across trust boundaries — a public repo's PR builds must never run on a runner that also builds production.
Lock down PR builds from forks. Pull requests from forks are the classic injection point: a contributor's malicious workflow change or build script can exfiltrate secrets if the CI system exposes them to fork builds. Require approval before running workflows from forks, and do not expose production secrets to untrusted PR contexts.
Manage secrets properly
Secrets are what the attacker is after, so how you handle them is the core of CI/CD cyber security.
Prefer short-lived, workload-scoped credentials over static long-lived tokens. OIDC-based federation — where the CI system exchanges a signed identity token for temporary cloud credentials scoped to that specific job — removes the standing AWS_SECRET_ACCESS_KEY or NPM_TOKEN that would otherwise sit in your secrets store waiting to leak. GitHub Actions OIDC trusted publishing, for example, lets a pipeline publish to npm without a long-lived token at all.
Scope every secret to the minimum. A token that can only deploy to staging cannot wreck production. A registry token scoped to one package cannot poison others.
Never echo secrets into logs, and scan your history for the ones that already leaked. Committed credentials are a leading breach cause; rotate anything that has touched a log or a commit.
Govern dependencies at build time
Most CI/CD compromises arrive through the front door: a dependency. Your build pulls in hundreds of transitive packages, and any of them can run install-time scripts inside the runner that holds your secrets. The ua-parser-js and 2025 chalk/debug incidents both executed exactly this way.
Pin exact versions with a lockfile and enforce reproducible installs (npm ci, not npm install) so a compromised registry cannot silently swap a tarball. Constrain install scripts where you can. And scan the full dependency tree — production and dev — on every build, because dev tooling runs in the same privileged runner. Software composition analysis is the control that makes this continuous rather than a quarterly audit; our SCA overview covers how it inventories and flags dependencies on each commit. An SCA tool such as Safeguard can gate a build when a dependency with a known-critical, reachable vulnerability enters the tree, so the pipeline itself refuses to ship the risk.
Layer dynamic testing into the pipeline for the runtime issues static scanning misses. Running dynamic application security testing against a deployed preview environment catches the auth bypasses and injection flaws that only appear when the app is exercised.
Protect and verify artifacts
The output of the pipeline needs integrity guarantees so a downstream consumer can trust it.
Sign your artifacts and generate provenance. Build provenance (attesting what source and what build steps produced an artifact) plus signing lets consumers verify that an image or package really came from your pipeline and was not tampered with afterward. Generate an SBOM for each build so you have an exact record of what went in.
Control the promotion path. Artifacts should flow through defined stages with checks between them, not get pushed straight to production from a developer's machine. Immutable artifacts — build once, promote the same bytes through environments — prevent the "it passed in staging but something different shipped" class of problem.
Build security into the pipeline, not around it
The through-line of CI/CD cyber security is that controls belong inside the pipeline as automated gates, not in a review meeting after the fact. Dependency scanning, secret detection, artifact signing, and policy checks that fail the build when violated are what make security continuous. A gate that runs on every commit catches the regression the day it happens; a manual review catches it whenever someone gets around to it. For the taxonomy of code that these controls are defending against, see our post on what is a possible effect of malicious code.
FAQ
What is the biggest CI/CD security risk?
Compromised secrets in the build environment and malicious dependencies that run inside it. The runner holds deployment credentials and signing keys, so a single compromised dependency executing an install script can exfiltrate everything needed to poison what you ship. Short-lived credentials and dependency scanning address both.
Should PR builds from forks have access to secrets?
No. Fork PRs can contain malicious workflow or build-script changes, so exposing production secrets to them is a direct exfiltration path. Require approval before running fork workflows and withhold sensitive secrets from untrusted PR contexts.
What are ephemeral runners and why do they matter?
Ephemeral runners are disposable build environments created fresh for each job and destroyed after. They prevent malicious code from persisting between builds or reading state and secrets left by previous runs, which long-lived shared runners accumulate over time.
How does dependency scanning fit into CI/CD?
Run software composition analysis as an automated gate on every commit. It inventories the full dependency tree, matches versions against advisory databases, and can fail the build when a critical, reachable vulnerability enters — stopping the risk inside the pipeline rather than discovering it in production.