Proč je bezpečnost CI/CD kritická
CI/CD (Continuous Integration/Continuous Delivery/Deployment) urychluje vývoj, ale zároveň otevírá nové vektory útoku: neověřené kódové změny, závislosti třetích stran, kompromitované build servery, exfiltrace tajemství, otrávené artefakty nebo zneužití oprávnění v cloudu. Bezpečnostní strategie pro CI/CD proto musí zahrnovat řízení identity a přístupu, zajištění integrity buildů, správu tajemství, odolné artefaktové řetězce, politiky nasazení a průběžné ověřování (SAST/SCA/DAST/IaC/K8s). Cílem je dosáhnout důvěryhodné pipeline, v níž je každá změna auditovatelná, reprodukovatelná a prokazatelně podepsaná.
Rámce a standardy: SSDF, SLSA a zásady dodavatelského řetězce
- NIST SSDF (Secure Software Development Framework) – procesní rámec pro bezpečný vývoj a pipeline (požadavky, ověřování, audit).
- SLSA (Supply-chain Levels for Software Artifacts) – úrovně důvěry (1–4) pro buildy, provenance a ověřování artefaktů.
- SBOM – katalog závislostí (SPDX, CycloneDX) generovaný v CI a přiložený k release.
- Compliance – mapování na ISO 27001, SOC 2, PCI DSS či odvětvové regulace.
Threat modeling CI/CD: kde jsou největší rizika
- Kód a revize – nedostatečné code review, slabá pravidla pro větve a PR z forků.
- Runnery a build stroje – sdílené či trvale běžící instance, zneužitelná cache, přístup do interních sítí.
- Tajemství a konfigurace – únik v logu, artefaktu nebo přes PR od neznámé identity.
- Závislosti a akce – tagy „latest“ u akčních kroků, dependency confusion, typosquatting v registru balíčků.
- Artefakty a registry – otrávení binárek, nahrazení imagí, chybějící podpisy a politiky přijetí.
Řízení identity a přístupu (IAM) v CI/CD
- Least privilege – pipeline, kroky a runnery mají jen nezbytná oprávnění; oddělit čtení a zápis do registrů a cloudových účtů.
- Krátkodobé identity – federace OIDC z CI do cloudu (AWS/GCP/Azure) místo dlouhodobých klíčů.
- Schvalování a SoD – oddělení povinností (člověk, který provede merge, nenasazuje; dvoučlenné schválení pro produkci).
- 2FA a podpis commitů – vyžadovat 2FA u SCM a podpisy GPG/Sigstore pro commity a tagy.
Ochrana repozitářů a větví
- Branch protection – vyžadovat review, kontroly statusu, zákaz force-push, povinné testy a skeny před merge.
- PR z forků – spouštět pouze „bezpečné“ joby bez tajemství; citlivé kroky (nasazení, publikace) spouštět až po merge.
- CODEOWNERS – povinné schvalování odborníky z příslušných oblastí pro kritické cesty (build skripty, Dockerfile, IaC).
Bezpečnost pipeline jako kódu
- Pinování kroků – akce a pluginy připnout na commit SHA, nikoli na
latest; verze auditovat. - Opětovná použitelnost – centrální knihovna schválených workflow/šablon, které procházejí bezpečnostní revizí.
- Policy as Code – OPA/Conftest/Semgrep policy gate: zákaz nebezpečných kroků (
curl|bash), povinné skeny, podpisy, sběr SBOM.
Tajemství a citlivá data v CI/CD
- Vault/Secrets Manager – dynamická pověření s krátkým TTL; automatická rotace klíčů.
- Maskování a redakce – maskovat citlivé hodnoty v logu, zakázat echo tajemství; artefakty šifrovat.
- Tajemství pro jednotlivá prostředí – oddělit dev/test/prod; auditovat přístupy a vyžadovat schválení pro produkční proměnné.
Build prostředí: hermetická a reprodukovatelná
- Hermetické buildy – zákaz neřízeného internetu během buildu; používání interních mirrorů a registrů.
- Reprodukovatelnost – připnutí verzí, zamčené lockfile, deterministická kompilace a časová razítka.
- Ephemeral runnery – jednorázové build stroje bez perzistentní cache; v případě potřeby cache používat izolovanou a podepsanou.
Bezpečnost kontejnerů v pipeline
- Důvěryhodné základní image – pouze z interního registru; pravidelné rebuildy s ohledem na nová CVE.
- Skenování imagí – skenování závislostí (OS i aplikace), zákaz release při kritických CVE bez výjimek.
- Podpisy a attestace – podepisovat obrazy (Sigstore/Cosign), generovat SLSA provenance; ověřovat v admission kontroleru.
Artefaktové řetězce a registry
- Privátní registry – oddělené role pro čtení a zápis; auditní logy a retenční politiky WORM pro release.
- Integrita – kryptografické podpisy a attestace in-toto; kontrola při nasazení (admission policy).
- Model propagace – artefakty se „povýší“ z dev→staging→prod bez rekompilace; jeden původ pro audit.
Skenování kódu a konfigurací v CI
- SAST/Semgrep/Bandit – statická analýza při PR; blokování kritických nálezů.
- SCA/Dependency review – audit třetích stran, zákaz licencí mimo stanovenou politiku, automatické PR pro bezpečné aktualizace.
- IaC scanning – šablony Terraform/CloudFormation/K8s podle baseline (CIS, vlastní pravidla).
- DAST/IAST – dynamické testy v preview prostředích; fuzzing klíčových API.
- Secrets scanning – gitleaks/trufflehog v pre-commit a v CI; automatická revokace uniklých klíčů.
Bezpečné nasazení: gates, schválení a GitOps
- Chráněná prostředí – nasazení do staging/prod vyžaduje výslovné schválení; auditovatelná vydání.
- GitOps – deklarativní stav v repozitáři; průběžná reconciliace a RBAC přes SCM.
- Canary/Blue-Green – postupné zpřístupňování, automatický rollback na základě metrik (SLO/SLI).
Admission politika Kubernetes
- OPA Gatekeeper/Kyverno – vynucení podpisů imagí, zákaz
:latest, omezení privilegií, limity prostředků. - Runtime security – seccomp/AppArmor, pod security policy, read-only root FS, žádné
privileged. - Network policy – „deny by default“ pro egress/ingress; oddělení CI agentů od produkce.
Provozní bezpečnost infrastruktury CI
- Segmentace sítě – runnery v izolované VLAN/NSG; egress allowlist pouze pro registry a mirrory.
- Aktualizace a hardening – pravidelné záplatování orchestrátoru CI, runnerů a agentů.
- Monitoring – metriky front, doby běhu jobů, anomálního egressu, selhání podpisů a skenů.
Logování, audit a forenzní připravenost
- Logy odolné proti neoprávněným změnám – centralizace, WORM/immutable storage, dlouhá doba uchovávání pro vyšetřování.
- Sledovatelnost – vazba commit → build → SBOM → podpis → release → nasazení (end-to-end trail).
- Runbooky IR – postupy pro případ kompromitace pipeline (revokace klíčů, zneplatnění artefaktů, audit zásahů).
Licenční a právní aspekty
- Licenční politika – povolené/zakázané licence; automatické reporty v release.
- Export/Compliance – evidence kryptografie a komponent pro dodavatelské řetězce.
Metriky a KPI bezpečného CI/CD
- Předstihové a zpožděné metriky – % artefaktů s podpisem, pokrytí SBOM, doba záplatování kritických CVE, míra připnutých kroků.
- Quality gates – podíl PR blokovaných z bezpečnostních důvodů, úspěšnost skenů bez kritických nálezů, MTTR při incidentu v pipeline.
Typické chyby a jak se jim vyhnout
- „latest“ všude – kroky, image i závislosti musí být připnuté; jinak nelze zajistit reprodukovatelnost.
- Tajemství v logu – povinné maskování a zákaz
set -xu shellů s přihlašovacími údaji. - Spouštění neověřeného kódu s tajemstvími – PR z forků bez přístupu k tajemstvím; schválení po merge.
- Sdílené persistentní runnery – přejít na ephemeral runnery; čistit cache a pracovní prostor.
- Chybějící podpisy – bez kryptografických podpisů a attestací nelze ověřit původ.
Kontrolní seznam před releasem
- Code review s CODEOWNERS a povinnými testy, skeny SAST/SCA/Secrets/IaC bez kritických nálezů.
- Hermetický build, připnuté verze, vygenerovaný SBOM.
- Artefakty a image podepsané (Cosign), uložené v privátním registru s auditními logy.
- Deployment gate: schválení, canary a automatický rollback.
- Admission politika v clusterech vynucuje podpisy a baseline.
Plán zlepšování (0–30–90–180 dní)
- 0–30 dní – zavést 2FA a branch protection, připnout akce, aktivovat skenování SAST/SCA/Secrets, oddělit PR z forků od tajemství.
- 30–90 dní – OIDC do cloudu, Vault pro tajemství, hermetické buildy s interními registry, generovat SBOM a zavést základní podpisy.
- 90–180 dní – SLSA provenance, ověřování Cosign při nasazení, politiky Gatekeeper/Kyverno, GitOps s propagací bez rekompilace, WORM logy a cvičení IR.
Závěr
Bezpečnost CI/CD je soustavná disciplína: vyžaduje kombinaci procesních opatření (review, schvalování, SoD), technických kontrol (pinování, skenování, podpisy, hermetičnost), odolné infrastruktury (ephemeral runnery, segmentace, registr s auditem) a měřitelných politik (policy as code, KPI). Organizace, které zavedou principy SLSA/SSDF, přijmou GitOps, ověří původ artefaktů a zautomatizují bezpečnostní kontroly v celé pipeline, získají schopnost doručovat software rychle a zároveň důvěryhodně.
