Pipeline

A pipeline is defined as code in the repository it builds: .github/workflows/*.yml for GitHub Actions, .gitlab-ci.yml, a Jenkinsfile, azure-pipelines.yml and so on. The common model is triggers (push, pull request, tag, schedule, manual dispatch) that start a run; a run consists of jobs arranged as a directed acyclic graph through explicit dependencies (needs, dependsOn, stages); each job executes a list of steps on a runner or agent, which may be an ephemeral hosted VM or a self-hosted machine. Jobs exchange outputs through artefacts and speed up through caches; matrix strategies fan a job out over versions or platforms; deployment jobs target named environments that can require manual approval, protected branches or wait timers.

Sound design principles follow from continuous delivery. Build once and promote the same immutable artefact, identified by digest, through test, staging and production rather than rebuilding per environment; keep builds hermetic and reproducible by pinning toolchains and dependencies; fail fast by running cheap checks first; and make every deployment step idempotent so a rerun is safe. Pipelines also generate evidence: test reports, scan results, SBOMs and signed provenance. The SLSA Build track defines levels for the latter - L1 requires provenance to exist, L2 requires a hosted build platform to generate and sign it, and L3 requires a hardened platform where runs cannot influence one another and build steps cannot reach the provenance signing key.

Because a pipeline executes code from the repository with access to secrets, it is itself an attack surface, catalogued in the OWASP Top 10 CI/CD Security Risks. Poisoned pipeline execution (CICD-SEC-4) occurs when an attacker can change what runs - for example a GitHub Actions workflow triggered by pull_request_target that checks out and builds the untrusted pull-request head while holding repository secrets. Script injection occurs when attacker-controlled strings such as an issue title are interpolated with ${{ }} directly into a run: shell block. Third-party actions and plugins are dependencies that execute with full job privileges; the March 2025 tj-actions/changed-files compromise (CVE-2025-30066) worked because many workflows referenced it by a mutable tag. Self-hosted runners attached to public repositories can be taken over and persist between jobs; shared caches can be poisoned.

Mitigations include least-privilege tokens (restricting the default GITHUB_TOKEN permissions per job), OIDC federation so jobs receive short-lived cloud credentials scoped to repository, branch and environment, pinning actions to full commit SHAs with automated update PRs, ephemeral runners, separating untrusted pull-request builds from privileged release jobs, and protecting the pipeline definition itself through code-owner review. The pipeline is the executable implementation; CI/CD is the practice it serves.