Bezpečnost5 min čtení

CI/CD Security

Zabezpečení CI/CD pipeline - secrets management, security gates, bezpečný deployment a integrace security scannerů do vašeho release procesu.

Proč je CI/CD Security důležitá?

Co je CI/CD security? CI/CD security je soubor postupů a kontrol, které chrání pipeline pro sestavení, testování a nasazení softwaru. Zahrnuje správu secrets, řízení přístupu k pipeline a runnerům, ověřování integrity závislostí a artefaktů a automatické bezpečnostní kontroly (SAST, SCA, skenování kontejnerů), které zastaví nasazení zranitelného kódu do produkce.

CI/CD pipeline má přístup k vašemu zdrojovému kódu, credentials, production prostředím a artifact repositories. Kompromitovaná pipeline může být využita k nasazení malware, krádeži secrets nebo přístupu do production. Zabezpečení pipeline je kritickou součástí DevSecOps strategie.

Že nejde o teorii, ukázal březen 2026: útočníci přepsali téměř všechny verzní tagy GitHub Action trivy-action na škodlivé commity a vydali podvržený Trivy v0.69.4. Aqua Security doporučuje považovat všechny secrets dostupné z runnerů, které tehdy používaly měnitelné tagy, za kompromitované (Aqua Security).

DevSecOps Pipeline architektura

Security Gates v CI/CD

1. Pre-commit

Kontroly před commitnutím kódu

  • Pre-commit hooks (secrets detection)
  • Linting a formátování
  • Local SAST scan

2. Build Stage

Kontroly při buildování

  • SAST - statická analýza kódu
  • SCA - analýza závislostí
  • Secret scanning (Gitleaks)
  • License compliance

3. Test Stage

Security testy

4. Deploy Stage

Kontroly před nasazením

  • DAST - dynamické testování
  • Approval gates pro production
  • Deployment verification

5. Post-deploy

Kontinuální monitoring

  • Runtime security monitoring
  • Vulnerability alerts
  • Compliance checks

Secrets Management

Správné zacházení se secrets (API klíče, hesla, certificates) je jedna z nejdůležitějších částí CI/CD security.

NIKDY nedělejte

  • Hardcoded secrets v kódu nebo pipeline konfiguracích
  • Secrets v environment variables bez šifrování
  • Sdílení secrets mezi prostředími (dev/prod)
  • Dlouhodobé statické access keys
  • Secrets v Docker images

Správné řešení secrets

GitLab vydává jobu krátkodobý OIDC token (id_tokens), který AWS STS vymění za dočasné credentials. Postup podle dokumentace GitLabu:

# Přijatelné - statické klíče jako protected + masked CI/CD proměnné # AWS_ACCESS_KEY_ID a AWS_SECRET_ACCESS_KEY se nastavují v CI/CD settings # projektu, nikdy ne přímo v .gitlab-ci.yml # Lepší - OIDC (žádné statické klíče) deploy: id_tokens: GITLAB_OIDC_TOKEN: aud: https://gitlab.com # musí odpovídat audience OIDC providera v AWS IAM script: - | export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" \ $(aws sts assume-role-with-web-identity \ --role-arn "$AWS_ROLE_ARN" \ --role-session-name "gitlab-$CI_PROJECT_ID-$CI_JOB_ID" \ --web-identity-token "$GITLAB_OIDC_TOKEN" \ --duration-seconds 3600 \ --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \ --output text)) # Nejlepší - OIDC + external secrets manager deploy_with_secrets: # AWS credentials získané přes OIDC jako v jobu výše script: - | # Získání secrets z AWS Secrets Manager až za běhu jobu export DB_PASSWORD=$(aws secretsmanager get-secret-value \ --secret-id prod/db/password \ --query SecretString --output text)

Příklad: Bezpečná DevSecOps Pipeline

# .gitlab-ci.yml - DevSecOps Pipeline stages: - test - build - scan - deploy variables: DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA # Pinujte přesné verze nástrojů (ideálně i @sha256 digest), nikdy :latest GITLEAKS_IMAGE: zricethezav/gitleaks:v8.30.1 SEMGREP_IMAGE: semgrep/semgrep:1.181.0 DEPCHECK_IMAGE: owasp/dependency-check:13.0.0 TRIVY_IMAGE: aquasec/trivy:0.76.0 # ===== TEST STAGE ===== # Secret detection gitleaks: stage: test image: name: $GITLEAKS_IMAGE entrypoint: [""] variables: GIT_DEPTH: 0 # celá historie, aby gitleaks prošel všechny commity script: - gitleaks git . --report-format json --report-path gitleaks-report.json artifacts: paths: [gitleaks-report.json] when: always allow_failure: true # SAST - statická analýza (Semgrep CE, bez přihlášení) semgrep: stage: test image: $SEMGREP_IMAGE script: - semgrep scan --config auto --json --output semgrep-results.json artifacts: paths: [semgrep-results.json] when: always allow_failure: true # SCA - dependency scanning dependency_check: stage: test image: name: $DEPCHECK_IMAGE entrypoint: [""] script: - /usr/share/dependency-check/bin/dependency-check.sh \ --project "MyApp" \ --scan . \ --nvdApiKey "$NVD_API_KEY" \ --format JSON \ --out dependency-check-report.json artifacts: paths: [dependency-check-report.json] when: always allow_failure: true # ===== BUILD STAGE ===== build_image: stage: build image: docker:29 services: - docker:29-dind script: - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY" - docker build -t $DOCKER_IMAGE . - docker push $DOCKER_IMAGE rules: - if: $CI_COMMIT_BRANCH == "main" # ===== SCAN STAGE ===== # Container image scanning - security gate: HIGH/CRITICAL zastaví pipeline trivy: stage: scan image: name: $TRIVY_IMAGE entrypoint: [""] variables: TRIVY_USERNAME: $CI_REGISTRY_USER TRIVY_PASSWORD: $CI_REGISTRY_PASSWORD script: - trivy image --exit-code 1 --severity HIGH,CRITICAL \ --format json --output trivy-results.json $DOCKER_IMAGE artifacts: paths: [trivy-results.json] when: always needs: [build_image] rules: - if: $CI_COMMIT_BRANCH == "main" # ===== DEPLOY STAGE ===== deploy_staging: stage: deploy environment: name: staging script: - echo "Deploying to staging..." needs: [trivy] rules: - if: $CI_COMMIT_BRANCH == "main" deploy_production: stage: deploy environment: name: production script: - echo "Deploying to production..." needs: [deploy_staging] rules: - if: $CI_COMMIT_BRANCH == "main" when: manual # Vyžaduje manuální schválení

Příklad používá rules místo zastaralých klíčových slov only/except (GitLab Docs), příkaz gitleaks git místo detect, který je od verze 8.19.0 označen jako zastaralý (Gitleaks), a semgrep scan, který na rozdíl od semgrep ci nevyžaduje účet v Semgrep AppSec Platform (Semgrep Docs). Dependency-Check bez API klíče NVD čeká mezi požadavky výrazně déle (OWASP Dependency-Check). Volby trivy image popisuje CLI reference Trivy.

CI/CD Security Best Practices

Pipeline Configuration

  • Pipeline as Code v Git repozitáři
  • Protected branches - žádné přímé pushe do main
  • Required code reviews
  • Signed commits
  • Pinned verze nástrojů a images: GitHub Actions na celý commit SHA (GitHub Docs), container images na digest
  • Provenance build artefaktů podle SLSA v1.2

Secrets & Access

  • OIDC/Workload Identity místo statických klíčů
  • External secrets manager (Vault, AWS Secrets Manager)
  • Rotace secrets
  • Least privilege pro pipeline service accounts
  • Audit logging všech přístupů

Security Gates

  • Fail pipeline na critical findings
  • Manual approval pro production deploys
  • Security review pro infrastructure změny
  • Rollback mechanismy
  • Deployment windows

Bezpečnostní rizika v CI/CD

Podle OWASP Top 10 CI/CD Security Risks:

  • Poisoned Pipeline Execution (PPE, CICD-SEC-4) - manipulace pipeline konfigurací
  • Dependency Confusion jako součást Dependency Chain Abuse (CICD-SEC-3) - zneužití package managerů
  • Credential theft z pipeline logů (Insufficient Credential Hygiene, CICD-SEC-6)
  • Supply chain attacks přes build nástroje
  • Privilege escalation přes self-hosted runnery

Zdroje

  1. OWASP: Top 10 CI/CD Security Risks (říjen 2026)
  2. Aqua Security: Trivy Supply Chain Attack: What You Need to Know (duben 2026)
  3. GitLab Docs: Configure OpenID Connect in AWS to retrieve temporary credentials (říjen 2026)
  4. GitLab Docs: Deprecated keywords (říjen 2026)
  5. GitHub Docs: Secure use reference (říjen 2026)
  6. Gitleaks: README (GitHub) (březen 2026)
  7. Aqua Security: tfsec is now part of Trivy (GitHub) (říjen 2026)
  8. Trivy Docs: trivy image CLI reference (říjen 2026)
  9. Semgrep Docs: Semgrep Community Edition in CI (říjen 2026)
  10. OWASP Dependency-Check: CLI arguments (říjen 2026)
  11. SLSA: Specification v1.2 (říjen 2026)

Chcete to mít vyřešené bez vlastního DevOps týmu?

Náš čtyřčlenný DevOps tým se o vaši platformu stará za pevnou měsíční cenu.

Nebo napište na info@devsecops.cz. Údaje zpracujeme podle zásad ochrany soukromí.