CI/CD security
CI/CD security covers the attack surface introduced by your build and deploy pipelines: GitHub Actions workflows, Dockerfiles, IaC configs, dependency management, and secret handling. Distinct from (and complementary to) application-layer AppSec.
Why CI/CD became its own attack surface
Through the 2010s, application security focused on the running app: input validation, auth, crypto, SQL injection. CI/CD pipelines were dev infrastructure — out of scope for security teams.
Then a few things changed. (1) Pipelines started touching production directly — Continuous Deployment makes the pipeline the production-pushing surface. (2) Supply-chain attacks (SolarWinds, ua-parser-js, event-stream, codecov, several others) showed pipelines as a primary attacker target. (3) GitHub Actions usage exploded — millions of public workflows, many copy-pasted insecure patterns.
By 2022 'CI/CD security' had its own terminology, separate from AppSec, separate from infra security. Today it's its own discipline with dedicated tooling.
The CI/CD attack surface — what's actually at risk
Workflow YAML — the most-attacked surface. Misconfigured triggers (pull_request_target + checkout fork code), missing permissions, unpinned action versions, untrusted input in run blocks, self-hosted runner abuse on public repos.
Dockerfile — base image trust (`:latest` tag), apt-get install bloat, ADD instead of COPY, curl-pipe-sh installation, running as root.
IaC configs (Terraform, K8s manifests, CloudFormation) — public S3 buckets, security groups open to 0.0.0.0/0 on sensitive ports, K8s pods without resource limits, hardcoded credentials in environment blocks.
Dependency management — lockfile drift, unpinned packages, dependency confusion (registries that auto-promote internal package names).
Secrets handling — env vars echoed to logs, base64-encoded secrets bypassing GitHub's masking, secrets in commit history.
Why CI/CD security is hard to retrofit
AppSec tools scan source code at build time. CI/CD security tools have to scan the build infrastructure itself — workflow YAML, Dockerfiles, IaC — which sit alongside source but aren't compiled into the running app.
Many AppSec tools added 'CI/CD scanning' as a feature but their core engines (CodeQL, Semgrep, etc.) were designed for application code. The patterns that matter in CI/CD are different — they're about configuration, trust boundaries, and pipeline structure, not application logic.
Specialist CI/CD security tools emerged (Cycode, Legit, Apiiro, Spectral, and LGTM Security) precisely because the patterns to detect are different enough that retrofitting AppSec tools didn't work well.
The three enforcement gates
CI/CD security tooling generally enforces at three points:
(1) Inline PR review. When a PR modifies workflow / Docker / IaC files, scan the diff and comment on findings. Same UX as code review.
(2) Merge-block Check Run. GitHub branch protection respects checks; a failing security check refuses the merge until resolved.
(3) Runtime watchdog. A GitHub Action installed on default branch that runs on every push (including direct commits and force pushes that bypass PR review), scans for the same patterns, and either alerts or auto-creates a revert PR.
All three together provide defense in depth. Single-gate tools miss attacks that arrive via non-PR paths (admin push, force push from collaborator with elevated permissions).
Standards + compliance signals
OWASP CI/CD Top 10 — the closest thing to a canonical risk list. Covers CICD-SEC-01 (Insufficient Flow Control) through CICD-SEC-10 (Insufficient Logging & Visibility). LGTM Security maps several detectors to specific OWASP items.
NIST Secure Software Development Framework (SSDF) — broader framework covering pipeline security as part of secure dev. PS.1.1 (secret detection) and PO.5.1 (audit log retention) are the relevant items.
OSSF Scorecard — open-source project security scorecard. Includes Pinned-Dependencies, Token-Permissions, and Dangerous-Workflow checks that overlap with LGTM Security's detector set.
For India-specific compliance, DPDP Act 2023's reasonable-security-practices (§24) is the relevant statute. CI/CD security with an audit log helps demonstrate compliance.
See LGTM Security's CI/CD detector set
16 deterministic detectors · 3 enforcement gates · runtime watchdog
Go to the product pageFAQs
Is CI/CD security the same as DevSecOps?
DevSecOps is broader — the overall practice of integrating security into the dev lifecycle. CI/CD security is a subset focused specifically on pipeline configuration risks. DevSecOps includes SAST, DAST, SCA, secrets scanning, and CI/CD security. The terms get used interchangeably; they shouldn't be.
What's the difference between CI/CD security and SAST?
SAST (Static Application Security Testing) scans application source code for vulnerabilities in the code logic — SQL injection, XSS, buffer overflows. CI/CD security scans pipeline configuration files — workflows, Dockerfiles, IaC — for misconfigurations and trust-boundary violations. Different files, different patterns, different attackers.
Can I just use GitHub's built-in security features?
GitHub provides Dependabot (dependency vulnerabilities), Secret Scanning (committed secrets), CodeQL (SAST for code logic), and Push Protection (block secrets at push). They don't cover the CI/CD-specific patterns (workflow misconfigs, Docker base-image risk, IaC misconfig). Use both — dedicated CI/CD security complements the GitHub-built-in stack rather than replacing it.
How often does CI/CD-related compromise actually happen?
Often enough to track. The SolarWinds breach (2020) was a build-pipeline compromise. ua-parser-js (2021), event-stream (2018), codecov (2021), several others. Smaller-scale incidents — leaked AWS keys via misconfigured workflows — happen weekly in public repos. The MITRE ATT&CK framework added 'Supply Chain Compromise' as a top-level technique in 2020.
What's the ROI vs. cost of CI/CD security tooling?
Hard to quantify pre-incident, obvious post-incident. The cost of a CI/CD security tool is low (typically ₹399-2000/month for small-team SaaS). The cost of a single supply-chain breach is anywhere from 'a weekend of rotation work' to existential (lost customer trust on a security-positioned product). The ROI math is asymmetric — small known cost vs unbounded tail risk.
Related across LGTM
Related terms
pull_request_target attack
A pull_request_target attack abuses GitHub Actions workflows that combine the pull_request_target trigger (runs with base-repo secrets) with checking out fork-controlled code, giving an attacker's fork PR access to your secrets.
Self-hosted runner abuse
Self-hosted runner abuse: an attacker forks a public repo using a self-hosted GitHub Actions runner, opens a PR, and gets remote code execution on the runner's host — often the maintainer's own infrastructure.
Pinned GitHub Action (SHA vs tag)
A pinned GitHub Action references a specific commit SHA rather than a mutable tag (like v3) or branch. Pinning to a SHA means the action's source code can't change underneath you — a key supply-chain defense.
Software supply-chain attack
A software supply-chain attack compromises a software product by attacking something earlier in the build/distribute chain: a dependency, a build tool, a package registry, a CI/CD pipeline, or a maintainer account. The downstream consumer ships compromised code without knowing.
GitHub App permissions
GitHub App permissions are the granular scopes an installed GitHub App requests on a repository: contents (read source), pull requests (read+write), checks (write Check Runs), metadata (read repo info), etc. Each permission level (none / read / write / admin) controls what the App can do with that resource.