Pipeline

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.

Gode 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.

Fordi 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.

Modtræ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.