Pipeline security
What it is
Pipeline security is the set of controls that protect a CI/CD pipeline from abuse: approval gates, lateral separation of build/test/release zones, least-privilege agents, secrets stored and referenced safely, and protection of the branch/repo that feeds them. It treats the pipeline as the deployment path an attacker would target to inject bad code.
Why it exists
A pipeline is trusted to take code and ship it. If an attacker compromises a pipeline (a poisoned dependency, an over-privileged agent, or an embedded plaintext secret), they gain a path toward shipping malicious software — a supply-chain attack. Pipeline security shrinks that attack surface.
Key ideas
- Approval gates — a human authorizes risky stages (e.g. before write access to a prod release), so an automated step can never fully self-serve.
- Lateral separation / zones — keep untrusted (fork/PR) work, build work, and release work on separate agents/pools so a compromised host can’t move sideways to more sensitive secrets.
- Least privilege — agents and actions run with the narrowest identity/role they need; no standing prod credentials.
- Secrets — encrypted, masked secret variables / GitHub encrypted secrets reference-only by name; never commit or log them.
- AuthN best practice — prefer OIDC / federated identity (GitHub ↔ Azure) over static tokens; rotate and scope PATs.
Exam notes
- Secret variables are encrypted, masked in logs, and referenced in YAML — a frequent exam topic.
- Approval + separation + least privilege is the standard answer for a secure pipeline design.
- Branch protection on main is the entry control; pipeline controls are the middle; signed artifacts are the output.
Diagram
![TODO diagram: pipeline trust boundary — source → build/test zones → signed release artifacts]
Related
pipeline-security-controls · branch-protection-and-policies · dependency-and-supply-chain · azure-pipelines · integration-testing