Bezpečnost5 min čtení

Vulnerability Management

Správa zranitelností od detekce po remediaci - jak efektivně prioritizovat, sledovat a opravovat bezpečnostní problémy ve vašich aplikacích.

Ing. Gleb Kushnir, zakladatel · Aktualizováno

Co je Vulnerability Management?

Vulnerability Management je systematický proces identifikace, hodnocení, prioritizace a remediace bezpečnostních zranitelností. Nejde jen o spouštění scannerů - jde o celý životní cyklus od nalezení problému až po ověření jeho opravy. Klíčové je mít centrální místo kde sledujete všechny findings a můžete efektivně pracovat na jejich řešení.

Životní cyklus zranitelností

Vulnerability Lifecycle

1. Discovery - Detekce

Nalezení zranitelností pomocí automatizovaných nástrojů

  • SAST scannery (Semgrep, SonarQube)
  • SCA nástroje (Snyk, Dependabot)
  • DAST nástroje (ZAP by Checkmarx, dříve OWASP ZAP)
  • Container scanning (Trivy)
  • Secret detection (Gitleaks)

2. Triage - Hodnocení

Posouzení závažnosti a relevance nalezení

  • Je to skutečný problém nebo false positive?
  • Jaká je závažnost (CVSS score)?
  • Je zranitelnost exploitable v našem kontextu?
  • Přiřazení CWE kategorie

3. Prioritization - Prioritizace

Určení pořadí řešení na základě rizika

  • Kritičnost systému (production vs dev)
  • Pravděpodobnost zneužití (EPSS) a výskyt v katalogu CISA KEV
  • Business impact
  • Snadnost remediace

4. Remediation - Oprava

Odstranění nebo zmírnění zranitelnosti

  • Fix v kódu
  • Update závislostí
  • Konfigurační změna
  • Compensating control (WAF pravidlo)

5. Verification - Ověření

Potvrzení že oprava funguje

  • Re-scan po opravě
  • Penetration testing
  • Code review
  • Uzavření tiketu

DefectDojo - Vulnerability Management Platform

DefectDojo je open-source platforma pro správu bezpečnostních nálezů. Integruje se s mnoha scanning nástroji a poskytuje centrální místo pro sledování všech zranitelností.

Hierarchie v DefectDojo

  • Product Type: Nejvyšší úroveň - např. "Microservices Application"
  • Product: Konkrétní aplikace/služba - např. "Payment Service"
  • Engagement: Časový okamžik testování - např. "Release v2.1.0"
  • Test: Typ testu - např. "SAST Scan", "Dependency Check"
  • Finding: Konkrétní nalezená zranitelnost

V DefectDojo Pro od verze 3.0 uživatelské rozhraní označuje Product Type jako Organization a Product jako Asset. Názvy endpointů a polí v API v2 zůstaly stejné, takže stávající automatizace funguje dál (dokumentace DefectDojo).

Import scan results do DefectDojo

Endpoint /api/v2/import-scan/ neočekává ID produktu, ale buď ID engagementu (engagement), nebo kombinaci product_name + engagement_name. S auto_create_context si DefectDojo chybějící engagement vytvoří sám (ImportScanSerializer).

# GitLab CI - automatický upload do DefectDojo upload_to_defectdojo: stage: report image: python:3.13 script: - pip install requests - | python << 'EOF' import requests import json import os DEFECTDOJO_URL = os.environ['DEFECTDOJO_URL'] API_KEY = os.environ['DEFECTDOJO_API_KEY'] PRODUCT_NAME = os.environ['DEFECTDOJO_PRODUCT_NAME'] headers = { 'Authorization': f'Token {API_KEY}', } # Upload Semgrep results with open('semgrep-results.json', 'rb') as f: response = requests.post( f'{DEFECTDOJO_URL}/api/v2/import-scan/', headers=headers, data={ 'product_name': PRODUCT_NAME, 'auto_create_context': 'true', 'engagement_name': f'CI-{os.environ["CI_PIPELINE_ID"]}', 'scan_type': 'Semgrep JSON Report', 'active': 'true', 'verified': 'false', 'minimum_severity': 'Info', }, files={'file': f} ) print(f'Semgrep upload: {response.status_code}') response.raise_for_status() # Upload Trivy results with open('trivy-results.json', 'rb') as f: response = requests.post( f'{DEFECTDOJO_URL}/api/v2/import-scan/', headers=headers, data={ 'product_name': PRODUCT_NAME, 'auto_create_context': 'true', 'engagement_name': f'CI-{os.environ["CI_PIPELINE_ID"]}', 'scan_type': 'Trivy Scan', 'active': 'true', }, files={'file': f} ) print(f'Trivy upload: {response.status_code}') response.raise_for_status() EOF dependencies: - semgrep_scan - trivy_scan

CWE - Common Weakness Enumeration

CWE je standardizovaný seznam bezpečnostních slabin v software a hardware. Každá zranitelnost má přiřazené CWE ID, které přesně identifikuje typ problému. V žebříčku 2025 CWE Top 25 od MITRE jsou na prvních dvou místech XSS (CWE-79) a SQL Injection (CWE-89).

Příklady CWE kategorií

  • CWE-89: SQL Injection
  • CWE-79: Cross-site Scripting (XSS)
  • CWE-798: Use of Hard-coded Credentials
  • CWE-22: Path Traversal
  • CWE-918: Server-Side Request Forgery (SSRF)
  • CWE-502: Deserialization of Untrusted Data

CWE vs OWASP Top 10

OWASP Top 10 jsou široké kategorie. CWE jsou specifické typy zranitelností které do těchto kategorií spadají. Například CWE-89 (SQL Injection) a CWE-79 (XSS) obě spadají do kategorie A05:2025 Injection v aktuálním OWASP Top 10:2025.

Prioritizace zranitelností

CVSS - Common Vulnerability Scoring System

Standardní metrika pro hodnocení závažnosti zranitelností na škále 0-10. Aktuální verzí je CVSS v4.0 od FIRST (vydána v listopadu 2023). Kvalitativní stupnice zůstala stejná jako ve verzi 3.1:

  • 0.0: None
  • 0.1 - 3.9: Low
  • 4.0 - 6.9: Medium
  • 7.0 - 8.9: High
  • 9.0 - 10.0: Critical

CVSS v4.0 rozlišuje, které skupiny metrik skóre obsahuje: CVSS-B (jen Base), CVSS-BT (Base + Threat), CVSS-BE a CVSS-BTE (včetně Environmental). Samotné Base skóre popisuje závažnost, ne riziko ve vašem prostředí.

Pozor na zdroj skóre: od 15. dubna 2026 NIST v NVD přednostně obohacuje jen CVE z katalogu KEV, software používaný federální vládou USA a kritický software podle EO 14028. Ostatní CVE dostávají stav „Lowest Priority - not scheduled for immediate enrichment“ a NIST už běžně nepřidává vlastní skóre, pokud ho dodala CNA (NIST). Počítejte proto se skóre od CNA nebo výrobce a s tím, že u řady CVE v NVD obohacení chybí.

EPSS - Exploit Prediction Scoring System

EPSS od FIRST odhaduje pravděpodobnost, že publikovaná CVE bude zneužita v reálném provozu během následujících 30 dnů. Skóre se přepočítává denně a pomáhá prioritizovat reálná rizika.

CISA KEV - Known Exploited Vulnerabilities

Katalog KEV americké agentury CISA obsahuje zranitelnosti s CVE ID, spolehlivým důkazem aktivního zneužití a jasným postupem nápravy. Zranitelnost v KEV patří na začátek fronty bez ohledu na CVSS. Direktiva BOD 26-04 z 10. června 2026 nahradila BOD 22-01 a stanovuje federálním úřadům USA lhůty podle expozice aktiva, výskytu v KEV, automatizovatelnosti útoku a technického dopadu (vychází z metodiky SSVC). Nejkratší lhůta jsou 3 dny. Pro firmy mimo federální správu USA není závazná, ale je užitečným měřítkem.

# Příklad prioritizace findings Priority 1 (Fix ASAP): - CVSS >= 9.0 - CVE v CISA KEV katalogu - EPSS > 0.5 (50% pravděpodobnost exploitu) - Production system - Internet-facing Priority 2 (Fix this sprint): - CVSS 7.0 - 8.9 - Any EPSS - Production system Priority 3 (Fix next sprint): - CVSS 4.0 - 6.9 - Production system Priority 4 (Backlog): - CVSS < 4.0 - Non-production - False positives candidate

Práce s false positives

Ne každý finding je skutečný problém. Security scannery často generují false positives. Důležité je je správně identifikovat a označit, aby nezatěžovaly další analýzu.

Jak se vyhnout false positive overload

  • Konfigurujte scannery pro váš stack (ignorujte nerelevantní pravidla)
  • Používejte baseline - porovnávejte s předchozími scany
  • Označujte false positives v DefectDojo
  • Vytvářejte exceptions pro známé false positives
  • Pravidelné review a čištění starých findings

Vulnerability Management Best Practices

Proces

  • Definujte SLA pro remediaci podle severity (např. Critical=24h, High=7d; pro srovnání BOD 26-04 dává u nejrizikovějších KEV zranitelností 3 dny)
  • Automaticky importujte scan results do centrální platformy
  • Pravidelné triage meetings (týdenní)
  • Sledujte metriky (MTTR, open findings count, trend)
  • Reportujte managementu (měsíční security posture report)

Developer Education

  • Používejte findings jako učební materiál
  • Ukažte developerům jak vypadá SQL injection v jejich kódu
  • Security workshops zaměřené na nejčastější problémy
  • Sdílejte CWE dokumentaci
  • Cílem je méně nových zranitelností, ne jen opravovat staré

Co NEDĚLAT

  • Ignorovat findings protože "není čas"
  • Označovat všechno jako false positive
  • Mít stovky neřešených findings (alert fatigue)
  • Opravovat pouze kritické a ignorovat ostatní
  • Nemít žádnou metriku nebo reporting

Zdroje

  1. FIRST: CVSS v4.0 Specification Document (červen 2024)
  2. FIRST: Exploit Prediction Scoring System (EPSS) (říjen 2026)
  3. CISA: Known Exploited Vulnerabilities Catalog (červen 2026)
  4. CISA: BOD 26-04: Prioritizing Security Updates Based on Risk (červen 2026)
  5. NIST: NIST Updates NVD Operations to Address Record CVE Growth (duben 2026)
  6. MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses (prosinec 2025)
  7. OWASP: A05:2025 Injection (listopad 2025)
  8. DefectDojo: Asset Hierarchy (Pro) (říjen 2026)
  9. DefectDojo (GitHub): dojo/api_v2/serializers.py (říjen 2026)
  10. ZAP: ZAP has joined forces with Checkmarx (září 2024)

Další články z tématu

Bezpečnost5 min čtení

Bezpečnost CI/CD Pipeline

Komplexní průvodce zabezpečením CI/CD pipeline: secrets management, security gates, secure deployment a integrace DevSecOps s praktickými příklady a nástroji.

Bezpečnost9 min čtení

Bezpečnost kontejnerů

Komplexní průvodce zabezpečením Docker kontejnerů a Kubernetes clusterů: image scanning, runtime protection, správa secrets a network policies v praxi.

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