Průměrná doba od commitu po produkci se za poslední tři roky zkrátila z týdnů na hodiny. Bezpečnostní review ale pořád trvá dny — a to je problém. Tenhle průvodce ukazuje, jak zapojit pět vrstev bezpečnostního skenování přímo do CI/CD pipeline tak, aby se build zastavil dřív, než se zranitelnost dostane do produkce. Žádná teorie — konkrétní konfigurace pro GitHub Actions, GitLab CI i Jenkins.

Proč ruční security review v roce 2026 nestačí¶

Představte si vývojový tým, který deployuje 15× denně. Každý deploy prochází code review, unit testy, integration testy, linting. Ale bezpečnostní review? To dělá jeden security engineer, který nestíhá, a tak se „kritické” pull requesty mergeují s poznámkou „security review later.” Later nikdy nepřijde.

Tohle není okrajový případ. Podle Snyk 2025 State of Application Security reportu 76 % organizací přiznává, že bezpečnostní testování zpomaluje jejich release cycle. Výsledek? Buď se bezpečnost obchází, nebo se deployuje pomaleji, než je nutné. Oboje je špatně.

DevSecOps pipeline řeší tento trade-off radikálně: bezpečnostní kontroly běží automaticky, paralelně s ostatními testy, při každém commitu. Vývojář dostane feedback za minuty, ne za dny. Security tým se přesouvá z role gatekeepera do role architekta — definuje pravidla, ne kontroluje každý pull request.

V CORE SYSTEMS implementujeme DevSecOps pipeline pro klienty od fintechu po veřejnou správu. Z praxe víme, že správně nastavený pipeline sníží počet bezpečnostních incidentů v produkci o 60–80 % a zároveň zrychlí release cycle, protože odpadá manuální čekání na security approval.

Pět vrstev bezpečnostního skenování¶

DevSecOps pipeline není jeden nástroj — je to orchestrace pěti komplementárních vrstev skenování. Každá vrstva zachytává jiný typ zranitelnosti, v jiné fázi životního cyklu kódu. Vynecháte-li jednu, máte slepé místo.

1. SAST — Static Application Security Testing¶

SAST analyzuje zdrojový kód bez jeho spuštění. Hledá vzory, které vedou ke zranitelnostem: SQL injection, XSS, hardcoded secrets, insecure deserialization, path traversal. SAST vidí kód tak, jak ho čte vývojář — umí ukázat přesný řádek a vysvětlit, proč je problematický.

Semgrep je v roce 2026 de facto standard pro SAST v moderních týmech. Na rozdíl od legacy nástrojů (Fortify, Checkmarx) je open-source, rychlý a jeho pravidla se píší v YAML, ne v proprietárním jazyce. Semgrep Pro přidává cross-file a cross-function analýzu (taint tracking), která dramaticky snižuje false positives.

Konkrétní příklad: Semgrep rule pro detekci SQL injection v Pythonu:

`# .semgrep/sql-injection.yml

rules:

- id: python-sql-injection

patterns:

- pattern: |

cursor.execute(f”…{$VAR}…”)

- pattern-not: |

cursor.execute(f”…{int($VAR)}…”)

message: |

SQL injection: user input $VAR interpolated

directly into SQL query. Use parameterized queries.

severity: ERROR

languages: [python]

metadata:

cwe: CWE-89

owasp: A03:2021`

V praxi kombinujeme Semgrep s custom pravidly specifickými pro klientův tech stack. Jeden náš fintech klient měl interní ORM wrapper, který obcházel standardní parameterized queries — generic SAST to nikdy nechytil. Custom Semgrep rule ano.

2. SCA — Software Composition Analysis¶

Moderní aplikace se z 70–90 % skládají z open-source závislostí. SCA skenuje tyto závislosti proti databázím známých zranitelností (NVD, GitHub Advisory Database, OSV) a identifikuje knihovny s CVE.

Snyk Open Source jde dál než prosté CVE matching. Analyzuje reachability — zda váš kód skutečně volá zranitelnou funkci v závislosti. Log4j (CVE-2021-44228) je v dependency tree? Snyk ověří, jestli vaše aplikace vůbec používá JNDI lookup. Pokud ne, priority se dramaticky mění.

Klíčové metriky SCA, které sledujeme:

• Závislosti s known CVE: kolik závislostí má aktivní CVE? Cíl: 0 critical, <5 high.
• Dependency freshness: jak staré jsou vaše dependencies? Závislost 3+ roky bez update je červená vlajka.
• License compliance: používáte GPL knihovnu v proprietárním produktu? SCA to odhalí dřív než právník.
• Transitive dependencies: vaše přímá závislost je OK, ale její závislost má critical CVE. SCA skenuje celý strom.

3. DAST — Dynamic Application Security Testing¶

DAST testuje běžící aplikaci zvenčí — jako útočník. Posílá malformed requesty, testuje autentizaci, hledá exposed endpointy, ověřuje HTTP security headers. DAST najde věci, které SAST nevidí: misconfigurované servery, chybějící CORS policy, session management problémy.

V CI/CD pipeline typicky DAST běží proti staging prostředí po úspěšném deployi. OWASP ZAP (Zed Attack Proxy) je open-source volba, pro enterprise nasazení doporučujeme Burp Suite Enterprise nebo Snyk DAST (dříve Probely).

Ukázka integrace ZAP do GitHub Actions:

`# .github/workflows/dast.yml

dast-scan:

runs-on: ubuntu-latest

needs: deploy-staging

steps:

- name: ZAP Full Scan

uses: zaproxy/action-full-scan@v0.12.0

with:

target: ‘https://staging.example.com’

rules_file_name: ‘.zap/rules.tsv’

cmd_options: ‘-a -j’

- name: Upload SARIF

uses: github/codeql-action/upload-sarif@v3

with:

sarif_file: ‘report.sarif’`

4. Container Scanning¶

Pokud deployujete kontejnery (a v roce 2026 — kdo ne?), musíte skenovat base image i application layer. Zranitelný Alpine base image s CVE v OpenSSL nebo libcurl je vstupní brána, kterou SAST nikdy neuvidí.

Trivy od Aqua Security je nejrozšířenější open-source container scanner. Skenuje OS packages, language-specific dependencies, IaC misconfigurace i secrets — vše v jednom nástroji. V CORE SYSTEMS implementujeme Trivy jako povinný krok v CI pipeline i jako admission controller v Kubernetes (přes Trivy Operator).

`# Trivy v CI — GitHub Actions

container-scan:

runs-on: ubuntu-latest

steps:

- name: Build image

run: docker build -t myapp:${{ github.sha }} .

- name: Trivy vulnerability scan

uses: aquasecurity/trivy-action@0.28.0

with:

image-ref: ‘myapp:${{ github.sha }}’

format: ‘sarif’

output: ‘trivy-results.sarif’

severity: ‘CRITICAL,HIGH’

exit-code: ‘1’ # fail build on findings

- name: Upload to GitHub Security

uses: github/codeql-action/upload-sarif@v3

with:

sarif_file: ‘trivy-results.sarif’`

Klíčový detail: skenujte finální image, ne jen Dockerfile. Multi-stage build může ve finální stage obsahovat jiné packages než v builder stage. A skenujte při každém buildu — nové CVE se objevují denně.

5. IaC Scanning — Infrastructure as Code¶

Terraform, Helm charty, Kubernetes manifesty, CloudFormation, Pulumi — vaše infrastruktura je kód a potřebuje security review jako jakýkoli jiný kód. IaC scanning odhalí misconfigurace dřív, než se dostanou do produkce: S3 buckety bez encryption, security groups s 0.0.0.0/0, Kubernetes pods s privileged: true.

Checkov od Bridgecrew (Palo Alto) je nejkomplexnější open-source IaC scanner. Podporuje 1000+ built-in pravidel pro Terraform, CloudFormation, Kubernetes, Helm, ARM templates a Docker. Custom policies se píší v Pythonu nebo YAML.

`# Checkov v GitLab CI

iac-scan:

stage: test

image: bridgecrew/checkov:latest

script:

- checkov -d ./terraform/

–framework terraform

–output sarif

–soft-fail-on LOW

–hard-fail-on CRITICAL,HIGH

–skip-check CKV_AWS_18 # intentional public bucket

- checkov -d ./k8s/

–framework kubernetes

–hard-fail-on CRITICAL`

V CORE SYSTEMS implementujeme Checkov s custom policy packem pro každého klienta. Bankovní klient má striktní pravidla na encryption at rest pro všechny storage services. E-commerce klient potřebuje specifické network isolation rules pro PCI DSS compliance. Generic pravidla nestačí.

Kompletní pipeline — jak to celé zapojit dohromady¶

Pět nástrojů je pět pohyblivých částí. Klíč je v orchestraci — kdy co běží, jak se výsledky agregují, a kdy se build zastaví.

Tady je referenční pipeline architektura, kterou používáme jako základ pro většinu klientských nasazení:

Fáze 1: Pre-commit & PR (sekundy)¶

Secret detection: git-secrets nebo gitleaks jako pre-commit hook. Zastaví commit s AWS keys, API tokeny, privátními klíči.

SAST (rychlý mód): Semgrep s –fast flag — skenuje jen changed files. Feedback do 30 sekund.

Proč tady: Vývojář dostane feedback okamžitě, ještě před push. Nejlevnější místo k opravě.

Fáze 2: CI Build (minuty)¶

SAST (plný mód): Semgrep cross-file analýza celého repozitáře. Taint tracking, data flow analysis.

SCA: Snyk test nebo Trivy fs scan — celý dependency tree, reachability analýza, license check.

IaC scan: Checkov na Terraform, Helm, K8s manifesty. Paralelně s SAST a SCA.

Container scan: Trivy image scan po docker build. Severity threshold: CRITICAL = fail, HIGH = warning.

Proč tady: Tyto scany běží paralelně (1–3 minuty celkem). Build failure zastaví merge do main.

Fáze 3: Post-deploy staging (minuty–hodina)¶

DAST: ZAP nebo Burp Suite proti staging environmentu. Baseline scan (5 min) při každém deployi, full scan (30–60 min) noční cron job.

API security testing: Validace OpenAPI spec, fuzz testing API endpointů, autentizační a autorizační edge cases.

Proč tady: DAST potřebuje běžící aplikaci. Staging je bezpečné prostředí pro destruktivní testy.

Fáze 4: Production runtime (kontinuálně)¶

Container runtime scanning: Trivy Operator v Kubernetes — kontinuální skenování running images proti nově publikovaným CVE.

SBOM monitoring: CycloneDX nebo SPDX SBOM se generuje při buildu a kontinuálně se monitoruje. Nový CVE v dependency? Alert.

Proč tady: Nový CVE se objeví po deployi. Runtime scanning zajistí, že se o něm dozvíte do hodin, ne za týdny.

Kompletní GitHub Actions pipeline — copy-paste ready¶

Tady je reálná konfigurace, kterou používáme jako základ. Upravte severity thresholdy a skip-check seznamy podle vašeho risk appetite:

`# .github/workflows/devsecops.yml

name: DevSecOps Pipeline

on:

pull_request:

branches: [main, develop]

push:

branches: [main]

jobs:

# — SAST —

sast:

runs-on: ubuntu-latest

permissions:

security-events: write

steps:

- uses: actions/checkout@v4

- name: Semgrep SAST

uses: semgrep/semgrep-action@v1

with:

config: >-

p/default

p/owasp-top-ten

p/cwe-top-25

.semgrep/

env:

SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_TOKEN }}

# — SCA —

sca:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Snyk dependency scan

uses: snyk/actions/node@master

with:

args: –severity-threshold=high

env:

SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

# — IaC Scan —

iac:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Checkov IaC scan

uses: bridgecrewio/checkov-action@v12

with:

directory: ./infrastructure/

framework: terraform,kubernetes

soft_fail_on: LOW,MEDIUM

hard_fail_on: CRITICAL,HIGH

# — Container Scan —

container:

runs-on: ubuntu-latest

needs: [sast, sca] # build only if code is clean

steps:

- uses: actions/checkout@v4

- name: Build image

run: docker build -t app:${{ github.sha }} .

- name: Trivy container scan

uses: aquasecurity/trivy-action@0.28.0

with:

image-ref: ‘app:${{ github.sha }}’

format: ‘sarif’

severity: ‘CRITICAL,HIGH’

exit-code: ‘1’

- name: Generate SBOM

run: trivy image –format cyclonedx

–output sbom.json app:${{ github.sha }}

- uses: actions/upload-artifact@v4

with:

name: sbom

path: sbom.json`

Secret management — první linie obrany¶

GitGuardian 2025 State of Secrets Sprawl report odhalil 12,8 milionu nových hardcoded secrets na veřejném GitHubu za rok 2024. AWS klíče, database credentials, API tokeny — vše commitnuté do repozitářů. A to jsou jen veřejné repo. V privátních je situace horší, protože vývojáři mají falešný pocit bezpečí.

Pre-commit hook s gitleaks je minimum. Konfigurace:

`# .pre-commit-config.yaml

repos:

- repo: https://github.com/gitleaks/gitleaks

rev: v8.22.0

hooks:

- id: gitleaks

.gitleaks.toml — custom rules¶

[extend]

useDefault = true

[[rules]]

id = “internal-api-key”

description = “Internal API key pattern”

regex = ‘’‘CORE_API_[A-Za-z0-9]{32,}’‘’

tags = [“api”, “internal”]`

Ale pre-commit hook je opt-in — vývojář ho může obejít s --no-verify. Proto secret scanning musí běžet i v CI jako server-side gate. GitHub nabízí native secret scanning s push protection. GitLab má Secret Detection jako součást CI template. Pro self-hosted řešení použijte gitleaks nebo TruffleHog v CI jobu.

Jak neutopit tým v false positives¶

Nejrychlejší způsob, jak zabít DevSecOps adopci, je zaplavit vývojáře stovkami alertů, z nichž 80 % jsou false positives. Tým začne ignoring security findings a celý effort je k ničemu. V CORE SYSTEMS tohle řešíme třístupňovým přístupem:

1. Severity-based gating: Ne všechna zjištění jsou equal. Build failuje pouze na CRITICAL a HIGH. MEDIUM generuje warning v PR commentu. LOW jde do security dashboardu — nikdy neblokuje build.

2. Baseline a suppression: Při první integraci nástroje do existujícího projektu dostanete stovky findings z legacy kódu. Řešení: vytvořte baseline soubor s existujícími findings. CI pak reportuje pouze nové nálezy. Legacy findings řešíte v rámci tech debt sprintu, ne jako blocker každého PR.

`# Semgrep — ignorování existujících findings

Při první integraci:¶

semgrep –config auto –sarif –output baseline.sarif .

V CI — jen nové nálezy:¶

semgrep –config auto –baseline-commit ${{ github.event.pull_request.base.sha }}`

3. Tuning pravidel: Generic rulesets obsahují pravidla, která pro váš stack nemají smysl. Java serialization rules v Python projektu? Vypněte. PHP-specifické XSS v Go backendu? Vypněte. Každý měsíc review suppressed findings — pokud pravidlo generuje >50 % false positives, upravte ho nebo nahraďte custom verzí.

SBOM a Supply Chain Security — povinnost, ne nice-to-have¶

EU Cyber Resilience Act (CRA), který vstupuje v platnost v roce 2027 s přechodným obdobím od 2025, vyžaduje Software Bill of Materials (SBOM) pro všechny produkty s digitálními prvky prodávané na EU trhu. Americký Executive Order 14028 totéž vyžaduje pro federální dodavatele.

SBOM není PDF s výčtem knihoven. Je to strojově čitelný soubor (CycloneDX nebo SPDX formát) obsahující:

• Komponenty: všechny závislosti — přímé i tranzitivní, včetně verzí.
• Licence: pod jakou licencí každá komponenta je.
• Vulnerabilities: známé CVE v době generování.
• Provenance: odkud komponenta pochází (registry, commit hash).

Generování SBOM patří do CI pipeline jako artifact buildu:

`# SBOM generování s Trivy

trivy image –format cyclonedx \

–output sbom-$(date +%Y%m%d).cdx.json \

myapp:${{ github.sha }}

Alternativa: syft (Anchore)¶

syft packages myapp:${{ github.sha }} \

-o cyclonedx-json=sbom.cdx.json

Validace a signing¶

cosign attest –predicate sbom.cdx.json \

–type cyclonedx \

myapp:${{ github.sha }}`

V CORE SYSTEMS implementujeme SBOM pipeline s kontinuálním monitoringem — SBOM se generuje při každém buildu a ukládá do centrálního registru (Dependency-Track). Když se objeví nový CVE, systém automaticky identifikuje všechny deployované verze, které obsahují dotčenou komponentu, a vytvoří ticket s prioritou podle severity a reachability.

Metriky úspěchu — co měřit a jaké cíle nastavit¶

DevSecOps pipeline bez metrik je security theater. Měříte, abyste věděli, jestli investice funguje. Tady jsou metriky, které doporučujeme sledovat od prvního dne:

• Mean Time to Remediation (MTTR): průměrná doba od detekce zranitelnosti po opravu. Critical CVE cíl: <24 hodin. High: <7 dní. MTTR pod 72 hodin pro critical je top decile.
• Escape rate: kolik zranitelností projde celým pipeline a dostane se do produkce. Cíl: <5 % z celkových findings. Tohle je ultimátní metrika efektivity pipeline.
• False positive rate: kolik findings security tým označí jako false positive. Nad 30 % = pipeline potřebuje tuning. Nad 50 % = vývojáři přestanou brát alerts vážně.
• Security debt trend: celkový počet open security findings v čase. Měl by klesat nebo být stabilní, nikdy ne rostoucí.
• Pipeline failure rate: kolik buildů failuje na security checks. Nad 20 % = pravidla jsou příliš striktní nebo generují příliš false positives.
• Developer friction: jak dlouho security scans přidávají k CI pipeline. Cíl: <5 minut pro SAST+SCA+container scan. Nad 10 minut vývojáři začnou obcházet.
• Coverage: kolik repozitářů má aktivní DevSecOps pipeline. Cíl: 100 % pro production workloady.

Dashboard doporučujeme v Grafaně s daty z SARIF reportů agregovaných přes DefectDojo nebo GitHub Security Overview. Týdenní security standup (15 minut) s review těchto metrik drží tým accountable.

Implementační roadmapa — 8 týdnů od nuly k produkci¶

DevSecOps pipeline nemusíte budovat rok. S jasnými prioritami a správnými nástroji máte funkční pipeline za 8 týdnů:

Týden 1–2: Foundation¶

Secret scanning: gitleaks pre-commit hook + CI job. Okamžitá hodnota, minimální effort.

SCA: Snyk nebo Trivy fs scan v CI. Jedno z nejjednodušších rozšíření — npm audit / pip-audit nestačí.

Výstup: Každý PR má secret scan a dependency scan. Build failuje na critical CVE.

Týden 3–4: SAST & Container¶

SAST: Semgrep s p/default + p/owasp-top-ten rulesets. Baseline pro existující kód.

Container scanning: Trivy image scan po docker build. Severity threshold nastavte podle kontextu.

Výstup: PR comments s SAST findings. Container images skenovány před push do registry.

Týden 5–6: IaC & DAST¶

IaC scanning: Checkov na Terraform/Kubernetes. Custom policy pack pro vaše prostředí.

DAST: ZAP baseline scan proti staging po každém deployi. Full scan jako noční cron.

Výstup: Infrastrukturní misconfigurace zachyceny v PR. Staging skenován automaticky.

Týden 7–8: Observability & Tuning¶

Dashboard: Grafana dashboard s MTTR, escape rate, false positive rate. Data z DefectDojo nebo native GitHub/GitLab.

Tuning: Review false positives, adjust severity thresholds, custom rules pro specifické patterny.

SBOM: Automatické generování při buildu, upload do Dependency-Track.

Výstup: Měřitelný DevSecOps pipeline s metrikami a continuous improvement procesom.

Nejčastější chyby z praxe¶

Za dva roky nasazování DevSecOps pipeline u klientů jsme viděli stejné chyby znovu a znovu:

• „Zapneme vše najednou na všech repozitářích”: Vývojáři dostanou stovky alertů přes noc. Výsledek: odpor, obcházení, vypnutí. Začněte jedním pilot projektem, vylaďte pravidla, pak rollout.
• Security tým definuje pravidla bez vývojářů: Pravidla, která nedávají smysl pro daný stack, generují false positives a frustraci. Vývojáři musí být součástí definice pravidel od začátku.
• Žádný ownership nad findings: Security scan najde 200 findings, ale nikdo je nemá v backlogu. Každý finding potřebuje ownera a SLA na remediaci.
• Ignorování base images: Tým skenuje svůj kód, ale používá 3 roky starý Node.js base image s 47 CVE. Base image hygiene je základ — pinujte verze, používejte distroless nebo chainguard images.
• Chybějící feedback loop: Pipeline běží, ale výsledky nikdo nečte. Integrace do PR comments, Slack notifikace pro critical findings, týdenní security standup — to jsou mechanismy, které drží pozornost.
• Security jako gate místo guardrail: DevSecOps pipeline nemá být zeď, o kterou se rozbíjejí PR. Má být vodítko — soft-fail s jasnou komunikací je lepší než hard-fail bez kontextu.

Nástroje v kontextu — rozhodovací matice 2026¶

Výběr nástrojů závisí na tech stacku, budget, a zda preferujete best-of-breed nebo single-vendor approach:

Open-source stack (€0 licenční náklady)¶

SAST: Semgrep OSS — komunitní pravidla, single-file analýza, rychlý.

SCA: Trivy fs — skenuje lockfiles, podporuje 20+ package managerů.

Container: Trivy image — OS packages + language deps v jednom skenu.

IaC: Checkov — 1000+ pravidel, Terraform/K8s/CloudFormation/Helm.

DAST: OWASP ZAP — automatizovaný baseline a full scan.

Secrets: gitleaks — pre-commit + CI, custom regex patterns.

Enterprise stack (konsolidovaný)¶

Snyk platforma: SAST (Snyk Code), SCA (Snyk Open Source), container (Snyk Container), IaC (Snyk IaC) — jeden dashboard, jedna policy engine, integrace s IDE.

Alternativa: GitHub Advanced Security — CodeQL pro SAST, Dependabot pro SCA, secret scanning, native SARIF aggregace.

DAST: Burp Suite Enterprise nebo Snyk DAST — scheduled scans, CI integrace, authenticated scanning.

V CORE SYSTEMS implementujeme obě varianty podle kontextu klienta. Startupy a menší týmy začínají na open-source stacku — Trivy + Semgrep + Checkov pokryjí 80 % potřeb za nulové licenční náklady. Enterprise klienti s 50+ repozitáři typicky profitují z konsolidované platformy (Snyk, GitHub Advanced Security), protože redukce operační zátěže vyváží licenční náklady.

Závěr: Pipeline je produkt, ne projekt¶

DevSecOps pipeline není jednorázová implementace. Je to interní produkt, který potřebuje ownera, roadmapu, feedback loop a kontinuální zlepšování. Pravidla se mění s novými typy zranitelností. Nástroje se aktualizují. Thresholdy se zpřísňují, jak tým zraje.

Začněte malé — secret scanning a SCA v jednom repozitáři. Přidávejte vrstvy po dvou týdnech. Za dva měsíce budete mít pipeline, který zachytí 90 % zranitelností dřív, než se dostanou do pull requestu. A co je důležitější — vývojáři budou security brát jako součást svého workflow, ne jako překážku.

V roce 2026 otázka není, jestli automatizovat bezpečnost v CI/CD. Otázka je, kolik zranitelností propustíte do produkce, než začnete. Každý den bez DevSecOps pipeline je den, kdy se spoléháte na štěstí místo na systém.