Cybersecurity glossary
What is a Build Pipeline?
Learn what a build pipeline is, how source becomes deployable artifacts, where security controls belong, and how compromised builds enable supply-chain attacks.
Definition
A build pipeline is an automated sequence of steps that transforms source code and dependencies into verified artifacts—typically compiling or packaging, running tests, applying security checks, and publishing outputs for deployment.
Why build pipelines matter
Hand-built release artifacts do not scale and cannot be audited. A build pipeline standardizes how source becomes something you can deploy: the same steps, the same toolchain policy, and a trail of logs.
That convenience also concentrates trust. Whoever controls the pipeline effectively controls what customers run.
Core jobs of a build pipeline
Resolve inputs
Fetch pinned source, dependencies, and tool versions under policy—not whatever is newest on the internet.
Transform and test
Compile, bundle, unit/integration test, and fail fast on broken quality gates.
Security verify
Run SAST, SCA, secret scanning, and policy checks before an artifact is published.
Publish outputs
Emit versioned artifacts, SBOMs, signatures, and provenance to trusted registries.
Typical build pipeline flow
Trigger
A commit, tag, or approved release request starts a job on an isolated runner.
Checkout and setup
Source is fetched at a fixed revision; the builder image and tools are pinned.
Dependency fetch
Lockfiles and checksums constrain what packages enter the build graph.
Build and test
Compilation/packaging and automated tests produce candidate artifacts.
Scan and attest
Security scans run; signatures and provenance bind the result to this run.
Publish
Only successful, policy-compliant artifacts land in the release registry.
Build pipeline risks vs controls
| Risk | Example | Primary control |
|---|---|---|
| Untrusted dependencies | Typosquat package pulled during install | Lockfiles, allowlists, and dependency scanning |
| Mutable builders | Latest base image silently changes | Pinned digests and rebuild on intentional upgrades |
| Secret leakage | Long-lived cloud key in runner env | OIDC short-lived credentials and secret scanning |
| Poisoned publish | Compromised job pushes malware as v1.2.3 | Protected environments, signing, and dual control |
Secure build pipeline checklist
- Run builds on isolated, patched runners with least privilege.
- Pin toolchains and base images by digest, not floating tags.
- Require lockfiles and verify dependency integrity before install.
- Block publishing when critical security gates fail.
- Keep production deploy credentials out of routine PR builds.
- Sign artifacts and generate provenance for release candidates.
- Protect branch rules so attackers cannot silently change pipeline YAML.
- Retain build logs and attestations long enough for incident response.
The practical takeaway
A build pipeline is the automated path from source to artifact. It improves speed and consistency—and becomes a high-value target the moment organizations trust its outputs blindly.
Design the pipeline as production infrastructure: pin inputs, verify dependencies, minimize secrets, sign results, and prove how each binary was made.
Related security terms
CI/CD Pipeline
Broader automation that includes delivery and deployment beyond the build.
Build Provenance
Metadata proving how and where an artifact was produced.
Pipeline Poisoning
Attacks that abuse pipeline trust to inject malicious artifacts.
Reproducible Build
Builds that produce bit-for-bit identical outputs from the same inputs.
Artifact Signing
Cryptographic signing so consumers can verify build outputs.
Frequently asked questions
What is a build pipeline in simple terms?
It is the automated factory line that turns code into installable software—compiling, testing, scanning, and packaging without hand-built mystery binaries.
Is a build pipeline the same as CI/CD?
Related but narrower. The build pipeline is usually the CI portion that produces artifacts. CI/CD also covers release promotion and deployment.
Why do attackers target build pipelines?
A compromised pipeline can ship trusted malware to every consumer of the artifact, often with signatures and distribution channels already in place.
What should a secure build pipeline include?
Hermetic or pinned toolchains, dependency verification, secret hygiene, isolated runners, signed outputs, provenance attestations, and least-privilege credentials.
What is a hermetic build?
A build that depends only on declared, controlled inputs—not ambient packages or mutable network fetches—so results are predictable and auditable.
Should production secrets be available during builds?
Generally no. Prefer short-lived OIDC federation or scoped tokens. Long-lived cloud keys on shared runners are a frequent breach path.
How do you know a pipeline produced a given binary?
Use signed provenance (for example SLSA attestations) that bind the artifact digest to source revision, builder identity, and build parameters.
References
Explore authoritative guidance and frameworks related to build pipeline.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.