Vulnerability Management: агрегация и приоритизация уязвимостей

Без единой системы уязвимости множатся: что делать?

Представьте: в вашей компании работают Trivy, Snyk, OWASP ZAP и Checkmarx — 5 разных сканеров, каждый со своим интерфейсом. Без единой системы управления уязвимостями инженеры тратят до 40 часов в месяц на ручной триаж, согласование и отчётность. Результат: критичные проблемы пропускаются, а low‑priority уязвимости копятся. По данным CISA, более 50% атак используют известные уязвимости из KEV — и это только подтверждает необходимость автоматизации. Согласно официальной документации DefectDojo, платформа поддерживает более 100 типов сканеров. Наши инженеры (сертификации AWS, CKS, CISSP) внедряют DefectDojo и Dependency‑Track, чтобы автоматизировать агрегацию, дедупликацию и приоритизацию. Результат — экономия времени на 80% и сокращение MTTR до 24 часов на P1. За время работы мы провели десятки проектов по VM, что позволило сократить ручной анализ в среднем в 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 раза дешевле Snyk Enterprise при сопоставимой функциональности.

Поток данных:

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-сервисе.

Что такое CISA KEV и как он помогает приоритизировать уязвимости?

KEV (Known Exploited Vulnerabilities) от CISA — перечень активно используемых уязвимостей. Если CVE есть в этом списке, treat as P1 независимо от CVSS.

Система приоритетов:

import json, requests

def enrich_with_kev(trivy_report_path):
    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

Процесс внедрения и результаты

Ключевые метрики

• MTTR by severity — среднее время от обнаружения до fix
• Open Critical trend — динамика за 30/60/90 дней
• SLA compliance rate — процент findings, закрытых в рамках SLA
• Reopen rate — качество исправлений
• Suppress rate — доля принятого риска

DefectDojo строит эти метрики автоматически. Для Grafana можно экспортировать через Prometheus exporter (документация DefectDojo доступна на GitHub).

Сравнение DefectDojo, Dependency-Track и коммерческих платформ

Процесс внедрения

• Аудит текущего стека безопасности и процессов
• Развёртывание DefectDojo и/или Dependency-Track (Docker Compose или Helm)
• Интеграция импорта результатов из CI/CD (GitLab, GitHub Actions, Jenkins)
• Настройка дедупликации, политик приоритизации и SLA
• Jira/GitLab синк для автоматизации назначения задач
• Дашборды и еженедельная отчётность
• Документация архитектуры и скриптов
• Обучение команды работе с платформой

Что входит в работу

• Аудит — анализ текущих сканеров, форматов отчётов, процессов триажа
• Развёртывание — установка и настройка DefectDojo/Dependency-Track в вашей инфраструктуре (Docker, k8s, bare metal)
• Интеграции — CI/CD pipelines, Jira, Slack, единый вход (SSO)
• Политики приоритизации — настройка правил с учётом ваших SLA и asset criticality
• Дашборды — Grafana + Prometheus exporter для мониторинга метрик
• Документация — архитектурная схема, runbook по эксплуатации, скрипты автоматизации
• Обучение — воркшоп для команды (2-4 часа) по работе с платформой
• Пост-релизная поддержка — 2 недели сопровождения после внедрения

Ориентировочные сроки

Средний проект занимает от 2 недель (одна команда, простой стек) до 2-3 месяцев (крупная организация, enterprise интеграции). Стоимость рассчитывается индивидуально. Экономия на ручной обработке отчётов — до 40 часов в месяц, что приносит существенную экономию. Инвестиции окупаются в течение нескольких месяцев. Мы работаем под ключ: от аудита до пост-релизной поддержки.

Свяжитесь с нами для оценки вашего проекта. Закажите консультацию, и мы подберём оптимальную архитектуру управления уязвимостями под ваш стек.