Управління вразливостями
Сканування вразливостей, patch management, dependency scanning з Dependabot та Snyk, SBOM для AI-проєктів
📎ОФІЦІЙНА ДОКУМЕНТАЦІЯ
Управління вразливостями
Систематичний процес ідентифікації, оцінки, виправлення та верифікації вразливостей -- особливо критичний при використанні AI для генерації коду.
Процес управління вразливостями
Сканування вразливостей
Типи сканування
| Тип | Інструменти | Що сканує |
|---|---|---|
| Infrastructure | Nessus, Qualys, OpenVAS | Сервери, мережеве обладнання |
| Container | Trivy, Grype, Snyk Container | Docker images |
| Dependency | Dependabot, Snyk, Renovate | Бібліотеки та пакети |
| Code | SonarQube, Semgrep, CodeQL | Вихідний код |
| Cloud | Prowler, ScoutSuite | Cloud-конфігурація |
Dependency Scanning
AI-код часто додає нові залежності, які можуть мати вразливості:
Dependabot (GitHub)
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 10
security-updates-only: true
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
Snyk
# Сканування проєкту
snyk test
# Моніторинг на постійній основі
snyk monitor
# Автоматичне виправлення
snyk fix
AI-згенерований код може додавати залежності, які ви не очікували. Завжди перевіряйте зміни в lock-файлах (package-lock.json, yarn.lock) при review PR з AI-кодом.
Patch Management
Стратегія оновлень
| Severity | SLA на виправлення | Приклад |
|---|---|---|
| Critical (CVSS 9.0-10.0) | 24-48 годин | RCE в production |
| High (CVSS 7.0-8.9) | 7 днів | SQL injection, auth bypass |
| Medium (CVSS 4.0-6.9) | 30 днів | XSS, information disclosure |
| Low (CVSS 0.1-3.9) | 90 днів | Minor issues |
Автоматизація оновлень
- Dependabot -- автоматичні PR з оновленнями залежностей
- Renovate -- гнучкіша альтернатива з auto-merge
- Snyk -- PR з виправленнями та рекомендаціями
Стратегія оновлення AI-залежностей
AI-бібліотеки (transformers, langchain, openai SDK) оновлюються часто:
- Pin точні версії в lock-файлах
- Тестуйте оновлення в staging перед production
- Моніторьте breaking changes
- Підтримуйте SBOM актуальним
SBOM (Software Bill of Materials)
Навіщо SBOM
SBOM -- це повний список компонентів програмного забезпечення:
- Ідентифікація всіх залежностей (прямих та транзитивних)
- Швидке реагування на нові CVE
- Compliance з регуляторними вимогами
- Прозорість supply chain
Формати SBOM
| Формат | Організація | Використання |
|---|---|---|
| CycloneDX | OWASP | Безпека, vulnerability tracking |
| SPDX | Linux Foundation | Ліцензування, compliance |
| SWID | ISO/IEC | Ідентифікація ПЗ |
Генерація SBOM
# CycloneDX для Node.js
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
# Syft (мультимовний)
syft . -o cyclonedx-json > sbom.cdx.json
syft . -o spdx-json > sbom.spdx.json
# Trivy
trivy fs --format cyclonedx --output sbom.cdx.json .
Метрики
Відстежуйте ефективність управління вразливостями:
| Метрика | Ціль |
|---|---|
| MTTR (Mean Time to Remediate) | < 7 днів для High/Critical |
| Coverage | 100% активів скановано |
| Patch compliance | > 95% патчів встановлено вчасно |
| Open vulnerabilities | Зменшення від місяця до місяця |
| False positive rate | < 10% |
Див. також
SAST, DAST та SCA інструменти
SIEM та виявлення аномалій
Вимоги стандартів та регуляцій