Управління вразливостями: агрегація та пріоритизація

Без єдиної системи вразливості множаться: що робити?

Уявіть: у вашій компанії працюють Trivy, Snyk, OWASP ZAP і Checkmarx — 5 різних сканерів, кожен зі своїм інтерфейсом. Без єдиної системи агрегації вразливостей інженери витрачають до 40 годин на місяць на ручний тріаж, погодження та звітність. Результат: критичні проблеми пропускаються, а low‑priority вразливості накопичуються. За даними CISA, понад 50% атак використовують відомі вразливості з KEV — це підтверджує необхідність автоматизації. Згідно з офіційною документацією DefectDojo, платформа підтримує понад 100 типів сканерів. Наші інженери (сертифікації AWS, CKS, CISSP — понад 5 років досвіду в DevSecOps) впроваджують DefectDojo та Dependency‑Track, щоб автоматизувати агрегацію вразливостей, дедуплікацію та пріоритизацію вразливостей. Результат — економія часу на 80% і скорочення MTTR до 24 годин на P1. За час роботи ми провели десятки проектів з VM — понад 20 успішних впроваджень — що дозволило скоротити ручний аналіз у середньому в 5 разів. Ми гарантуємо якість, спираючись на багаторічний досвід та сертифікації.

Вибір інструментів та архітектура

Три основні підходи:

• DefectDojo — open source платформа. Приймає результати з 100+ сканерів (Trivy, Snyk, Checkmarx, ZAP, Burp), дедуплікує за CPE/CVE, групує за продуктами та командами, дозволяє призначати SLA і синхронізуватися з Jira.
• Dependency-Track — спеціалізований для SCA та SBOM. Отримує CycloneDX/SPDX звіти, безперервно звіряє компоненти з NVD, OSV, GitHub Advisories. Dashboard з метриками за часом.
• Комерційні платформи (Snyk, Wiz, Tenable.io, JFrog Xray) — краща інтеграція, дорожче, менше кастомізації.

Для більшості команд, які не мають великого security budget, зв'язка DefectDojo + Dependency-Track закриває 80% потреб. За нашими даними, ця зв'язка краща за комерційні рішення в 3 рази за ціною при порівнянній функціональності.

Потік даних:

CI/CD pipelines
├── Trivy (fs + image) → SARIF / JSON
├── Snyk (code + oss) → SARIF / JSON
├── GitLeaks → JSON
├── Checkmarx → SARIF
└── OWASP ZAP → JSON
│
▼
DefectDojo API (імпорт результатів, дедуплікація)
│
├── Engagement per Product per Sprint
├── Finding deduplication по hash
├── JIRA sync (критичні findings → tickets)
└── Metrics: open/closed/accepted risk

DefectDojo: встановлення та базове налаштування

# Docker Compose cd django-DefectDojo ./dc-build.sh docker compose up -d # Helm в k8s helm repo add defectdojo https://raw.githubusercontent.com/DefectDojo/django-DefectDojo/helm-charts helm install defectdojo defectdojo/defectdojo \
    --namespace security \
    --create-namespace \
    --set django.ingress.enabled=true \
    --set django.ingress.host=defectdojo.internal \
    --values my-values.yaml

Технічна реалізація: від CI/CD до пріоритизації

Налаштування автоматичного імпорту з CI/CD

Імпорт результатів через API (GitLab CI):

---
upload-to-defectdojo:
  stage: .post
  image: curlimages/curl:latest
  when: always
  script:
    - |
      ENGAGEMENT_ID=$(curl -s -X POST \
        -H "Authorization: Token $DEFECTDOJO_API_TOKEN" \
        -H "Content-Type: application/json" \
        "$DEFECTDOJO_URL/api/v2/engagements/" \
        -d "{ \"product\": $DEFECTDOJO_PRODUCT_ID, \"name\": \"CI scan - $CI_COMMIT_SHORT_SHA\", \"target_start\": \"$(date +%Y-%m-%d)\", \"target_end\": \"$(date +%Y-%m-%d)\", \"status\": \"In Progress\", \"engagement_type\": \"CI/CD\" }" | jq -r '.id')
    - |
      curl -s -X POST \
        -H "Authorization: Token $DEFECTDOJO_API_TOKEN" \
        -F "engagement=$ENGAGEMENT_ID" \
        -F "scan_type=Trivy Scan" \
        -F "[email protected]" \
        -F "minimum_severity=High" \
        -F "active=true" \
        -F "verified=false" \
        -F "close_old_findings=true" \
        "$DEFECTDOJO_URL/api/v2/import-scan/"
    - |
      if [ -f zap-report.json ]; then
        curl -s -X POST \
          -H "Authorization: Token $DEFECTDOJO_API_TOKEN" \
          -F "engagement=$ENGAGEMENT_ID" \
          -F "scan_type=ZAP Scan" \
          -F "[email protected]" \
          -F "minimum_severity=High" \
          "$DEFECTDOJO_URL/api/v2/import-scan/"
      fi
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
---

Dependency-Track: робота з SBOM:

---
generate-and-upload-sbom:
  stage: security
  image: aquasec/trivy:latest
  entrypoint: [""]
  script:
    - trivy fs --format cyclonedx --output sbom-fs.json .
    - trivy image --format cyclonedx --output sbom-image.json $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - |
      curl -X PUT -H "X-API-Key: $DEPENDENCY_TRACK_API_KEY" -H "Content-Type: application/json" \
        "$DEPENDENCY_TRACK_URL/api/v1/bom" \
        -d "{\"project\": \"$DTRACK_PROJECT_UUID\", \"bom\": \"$(base64 -w 0 sbom-image.json)\"}"
  artifacts:
    paths:
      - sbom-*.json
    expire_in: 90 days
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
---

Чому CVSS не завжди достатній?

CVSS 9.8 — теоретичний максимум ризику. Реальний ризик = CVSS × exploitability in context × asset criticality. Компонент з CVSS 7.5 у public-facing API без аутентифікації небезпечніший, ніж CVSS 9.8 у offline batch-сервісі. Тому в рамках DevSecOps практик ми застосовуємо додаткові фактори.

CISA KEV: пріоритизація за експлойтами

import json, requests

def enrich_with_kev(trivy_report_path):
    # Збагачуємо звіт Trivy даними CISA KEV та призначаємо пріоритет P1
    kev = requests.get("https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json").json()
    kev_ids = {v['cveID'] for v in kev['vulnerabilities']}
    with open(trivy_report_path) as f:
        report = json.load(f)
    for result in report.get('Results', []):
        for vuln in result.get('Vulnerabilities', []):
            if vuln.get('VulnerabilityID') in kev_ids:
                vuln['InKEV'] = True
                vuln['Priority'] = 'P1'
    return report