Bezpečnost CI/CD procesů: DevSecOps

Bezpečnostní aspekty CI/CD procesů: DevSecOps

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 -x u 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ě.