{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://atlas.maintz.dev/)"},"id":"platform/pipeline","url":{"en":"https://atlas.maintz.dev/en/terms/platform/pipeline/","da":"https://atlas.maintz.dev/da/terms/platform/pipeline/"},"term":{"en":"Pipeline","da":"Pipeline"},"aka":{"en":["build pipeline","CI/CD pipeline","deployment pipeline"],"da":["byggepipeline","udrulningspipeline"]},"domain":["platform"],"cluster":"delivery","layer":"delivery","status":"current","summary":{"en":"A fixed, automatic chain of steps that takes a code change from saved file to running software, stopping if any step fails.","da":"En fast, automatisk kæde af trin, der fører en kodeændring fra gemt fil til kørende software og stopper, hvis et trin fejler."},"body":{"formal":{"en":"A written description of ordered stages, such as build, test, security scan, package and deploy, that a CI/CD system runs on every change, where each stage must pass before the next one starts.","da":"En skriftlig beskrivelse af faser i fast rækkefølge - fx at bygge, teste, scanne og pakke softwaren og rulle den ud - som et CI/CD-system kører for hver ændring, og hvor hver fase skal bestå, før den næste går i gang."},"plain":{"en":"Like a car factory's assembly line, where each station does one job and a car that fails the brake test never reaches the showroom.","da":"Som samlebåndet på en bilfabrik, hvor hver station udfører én opgave, og en bil, der dumper bremsetesten, aldrig når ud i forretningen."},"inPractice":{"en":"At a ferry company, the pipeline for the ticket booking site stops a Friday release because a test finds child fares priced as adult fares; nothing reaches customers until the fault is fixed.","da":"Hos et færgeselskab stopper pipelinen for billetbookingen en frigivelse om fredagen, fordi en test viser, at børnebilletter bliver prissat som voksenbilletter; intet når ud til kunderne, før fejlen er rettet."},"whyItMatters":{"en":"The pipeline is where rules become automatic and hard to skip, but it also holds keys to production, so an attacker who takes it over can ship harmful code to every user.","da":"Pipelinen er stedet, hvor regler bliver automatiske og svære at springe over, men den har også nøglerne til driften, så en angriber, der overtager den, kan sende skadelig kode ud til alle brugere."}},"deepDive":{"en":"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.\n\nSound 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.\n\nBecause 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.\n\nMitigations 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.","da":"En pipeline defineres som kode i det repository, den bygger: .github/workflows/*.yml til GitHub Actions, .gitlab-ci.yml, en Jenkinsfile, azure-pipelines.yml osv. Den fælles model er udløsere (push, pull request, tag, tidsplan, manuel start), der starter en kørsel; en kørsel består af jobs arrangeret som en rettet acyklisk graf via eksplicitte afhængigheder (needs, dependsOn, stages); hvert job udfører en liste af trin på en runner eller agent, som kan være en flygtig hostet VM eller en selvhostet maskine. Jobs udveksler output via artefakter og gøres hurtigere med caches; matrix-strategier folder et job ud over versioner eller platforme; udrulningsjobs rammer navngivne miljøer, der kan kræve manuel godkendelse, beskyttede grene eller ventetider.\n\nGode designprincipper følger af kontinuerlig levering. Byg én gang og promovér det samme uforanderlige artefakt, identificeret ved digest, gennem test, staging og produktion i stedet for at bygge om per miljø; hold builds hermetiske og reproducerbare ved at låse værktøjskæder og afhængigheder; fejl hurtigt ved at køre billige tjek først; og gør hvert udrulningstrin idempotent, så en genkørsel er sikker. Pipelines producerer også dokumentation: testrapporter, scanningsresultater, SBOM'er og signeret provenance. SLSA's Build-spor definerer niveauer for det sidste - L1 kræver, at provenance findes, L2 kræver, at en hostet byggeplatform genererer og signerer den, og L3 kræver en hærdet platform, hvor kørsler ikke kan påvirke hinanden, og byggetrin ikke kan nå nøglen, der signerer provenance.\n\nFordi en pipeline udfører kode fra repositoryet med adgang til hemmeligheder, er den selv en angrebsflade, katalogiseret i OWASP Top 10 CI/CD Security Risks. Poisoned pipeline execution (CICD-SEC-4) opstår, når en angriber kan ændre, hvad der kører - fx et GitHub Actions-workflow udløst af pull_request_target, der checker den upålidelige pull request-kode ud og bygger den, mens repositoryets hemmeligheder er tilgængelige. Script-injektion opstår, når strenge, som angriberen styrer, fx titlen på et issue, interpoleres med ${{ }} direkte ind i en run:-shellblok. Tredjeparts-actions og plugins er afhængigheder, der kører med jobbets fulde rettigheder; kompromitteringen af tj-actions/changed-files i marts 2025 (CVE-2025-30066) virkede, fordi mange workflows henviste til den via et foranderligt tag. Selvhostede runners koblet til offentlige repositories kan overtages og overleve mellem jobs, og delte caches kan forgiftes.\n\nModtræk er tokens med mindste privilegium (begræns standardrettighederne for GITHUB_TOKEN per job), OIDC-føderering, så jobs får kortlivede cloud-legitimationsoplysninger afgrænset til repository, gren og miljø, fastlåsning af actions til fulde commit-SHA'er med automatiske opdaterings-PR'er, flygtige runners, adskillelse af builds af upålidelige pull requests fra privilegerede frigivelsesjobs og beskyttelse af selve pipelinedefinitionen via gennemgang fra code owners. Pipelinen er den eksekverbare implementering; CI/CD er den praksis, den tjener."},"howTo":{"steps":{"en":["Define the pipeline as code in the repository it builds, and protect the pipeline files with code-owner review so changes to them are reviewed like any other code.","Order the stages so cheap checks run first - build, unit tests, security scans, packaging - and deployment jobs run last.","Build once and promote the same immutable artefact, identified by its digest, through test, staging and production.","Pin toolchains, dependencies and third-party actions or plugins to exact versions or full commit SHAs, and let an update bot propose upgrades as pull requests.","Make the default job token read-only, grant each job only the permissions it needs, and use OIDC federation for short-lived cloud credentials scoped to repository, branch and environment.","Build untrusted pull requests without secrets on ephemeral runners, separate from privileged release jobs, and never insert untrusted text such as issue titles directly into shell commands.","Protect production deployments with named environments that require approval or a protected branch.","Make the pipeline produce evidence for each release - test reports, scan results, an SBOM and signed provenance - aiming for SLSA Build Level 2 or 3."],"da":["Definér pipelinen som kode i det repository, den bygger, og beskyt pipelinefilerne med gennemgang fra code owners, så ændringer i dem gennemgås som al anden kode.","Læg faserne i en rækkefølge, hvor billige tjek kører først - build, enhedstests, sikkerhedsscanninger, pakning - og udrulningsjobs kører sidst.","Byg én gang, og promovér det samme uforanderlige artefakt, identificeret ved sin digest, gennem test, staging og produktion.","Lås værktøjskæder, afhængigheder og tredjeparts-actions eller plugins til præcise versioner eller fulde commit-SHA'er, og lad en opdateringsbot foreslå opgraderinger som pull requests.","Gør jobbets standardtoken skrivebeskyttet, giv hvert job kun de rettigheder, det har brug for, og brug OIDC-føderering til kortlivede cloud-legitimationsoplysninger afgrænset til repository, gren og miljø.","Byg upålidelige pull requests uden hemmeligheder på flygtige runners, adskilt fra privilegerede frigivelsesjobs, og indsæt aldrig upålidelig tekst som titlen på et issue direkte i shell-kommandoer.","Beskyt udrulninger til produktion med navngivne miljøer, der kræver godkendelse eller en beskyttet gren.","Lad pipelinen producere dokumentation for hver udgivelse - testrapporter, scanningsresultater, en SBOM og signeret provenance - med SLSA Build Level 2 eller 3 som mål."]},"pitfalls":{"en":["Using triggers such as pull_request_target that check out untrusted code while repository secrets are available.","Referring to third-party actions by mutable tags, which is how the 2025 tj-actions/changed-files compromise spread.","Attaching self-hosted runners to public repositories, where any pull request can take over the machine.","Rebuilding separately for each environment, so what was tested is not what reaches production."],"da":["At bruge udløsere som pull_request_target, der checker upålidelig kode ud, mens repositoryets hemmeligheder er tilgængelige.","At henvise til tredjeparts-actions via foranderlige tags, hvilket var sådan, kompromitteringen af tj-actions/changed-files spredte sig i 2025.","At koble selvhostede runners til offentlige repositories, hvor enhver pull request kan overtage maskinen.","At bygge forfra for hvert miljø, så det, der blev testet, ikke er det, der når produktion."]},"guides":[{"title":"SLSA v1.2 - Build Track Basics","url":"https://slsa.dev/spec/v1.2/build-track-basics","publisher":"OpenSSF","tier":"reference"},{"title":"GitHub Actions - Secure use reference","url":"https://docs.github.com/en/actions/reference/security/secure-use","publisher":"GitHub","tier":"official-doc"},{"title":"GitHub Actions - OpenID Connect","url":"https://docs.github.com/en/actions/concepts/security/openid-connect","publisher":"GitHub","tier":"official-doc"},{"title":"CI/CD Security Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"}]},"edges":[{"type":"part-of","to":"platform/ci-cd","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/secrets-management","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/vulnerability-scanning","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/software-composition-analysis","confidence":"high","strength":"normal"}],"depth":0,"sources":[{"title":"NIST SP 800-204D - Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines","url":"https://csrc.nist.gov/pubs/sp/800/204/d/final","tier":"standard","publisher":"NIST"},{"title":"SLSA v1.2 - Build Track Basics","url":"https://slsa.dev/spec/v1.2/build-track-basics","tier":"reference","publisher":"OpenSSF"},{"title":"OWASP Top 10 CI/CD Security Risks","url":"https://github.com/OWASP/www-project-top-10-ci-cd-security-risks","tier":"reference","publisher":"OWASP Foundation"}],"draft":true}