Сканування вразливостей і патчі

Коротке резюме

Управління вразливостями - це безперервний цикл: виявлення → оцінка ризику → усунення (патч/міграція/конфіг) → перевірка → звітність. Технології сканування (SCA/SAST/DAST/IAST/Cloud/Container) дають сигнали, а контекст (експонованість, привілеї, дані, EPSS, експлойти) визначає пріоритет. Мета - знизити реальний ризик без простою бізнесу, використовуючи автоматизацію, канарні викладки і чіткі SLO.

Таксономія сканування

SCA (Software Composition Analysis): аналіз залежностей/ліцензій; виявлення CVE в бібліотеках, SBOM.
SAST: статичний аналіз власного коду до складання.
DAST: динамічний «чорний ящик» проти працюючого сервісу.
IAST: датчики всередині програми (під час тестів) - менше FP, глибше контекст.
Container/OS Scan: образи (base image, пакети), хости (ядро/пакети/конфіги), CIS-бенчмарки.
Cloud/Infra (CSPM/KSPM): місконфіги хмари/K8s (IAM, мережі, шифрування, публічні бакети).
Secrets Scan: витоку ключів/токенів в репозиторіях і образах.
Binary/Artifact Scan: перевірка зібраних артефактів (підписи, уразливості).

Ризик-модель і пріоритизація

Оцінка = CVSS v3. x (база) × EPSS (ймовірність експлуатації) × контекст (експонованість, дані, привілеї, компенсуючі заходи).

Контекстні фактори:

Експонованість в Інтернет/всередині, наявність WAF/mTLS/ізоляції.
Дані: PII/фінанси/секрети.
Привілеї процесу/вузла, lateral movement-потенціал.
Наявність публічного експлойту/масових атак, вимоги комплаєнсу.

Приклад CVSS-вектора: `CVSS:3. 1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'→ критикував; якщо сервіс публічний і без компенсуючих заходів - P1.

SLO-пороги (приклад):

P1 (критичні, експлуатовані): фікс ≤ 48 год.
P2 (високі): фікс ≤ 7 днів.
P3 (середні): фікс ≤ 30 днів.
P4 (низькі/інформ.) : планово/по беклогу.

Життєвий цикл управління вразливостями

1. Інвентаризація активів: сервіси, образи, кластери, ОС, пакети, залежності, версії.
2. Сканування за розкладом та за подією: коміти, збірки, деплою, щодобові/щотижневі вікна.
3. Тріаж: дедуплікація, нормалізація (CVE→Ticket), мапінг на власника.
4. Пріоритизація за контекстом: CVSS/EPSS + експонованість/дані.
5. Ремедіація: патч/оновлення залежності/конфіг-хардненінг/віртуальний патч (WAF).
6. Верифікація: повторне сканування, тести, канарка.
7. Звітність: метрики закриття, вік вразливостей, відповідність SLO.
8. Уроки: фікс в шаблонах (base image, Helm chart), політика на майбутнє.

Інтеграція в CI/CD

На етапі PR: SAST + SCA + секрет-скан; «break build» за P1/P2 або вимога апрува.
На етапі build: скан образу, генерація SBOM (CycloneDX/SPDX), підпис артефактів (cosign).
На етапі deploy: політика допуску (Admission) - заборона образів з'critical/high'уразливостями і без підпису/SBOM.
Постдеплою: DAST/IAST проти стейджингу і частково production (безпечні профілі).

Приклад: Renovate/Dependabot (фрагмент)

json
{
"extends": ["config:recommended"],
"vulnerabilityAlerts": { "enabled": true },
"packageRules": [
{ "matchUpdateTypes": ["minor","patch"], "automerge": true },
{ "matchManagers": ["dockerfile"], "enabled": true }
]
}

Політика допуску (Kubernetes, OPA/Gatekeeper - спрощено)

rego package policy.vuln

deny[msg] {
input.image.vuln.critical > 0 msg:= sprintf("Image %s has critical vulns", [input.image.name])
}

deny[msg] {
input.image.sbom == false msg:= sprintf("Image %s without SBOM", [input.image.name])
}

Патч-менеджмент (ОС, контейнери, K8s)

ОС (Linux/Windows)

Patch window: регулярні вікна + екстрені позачергові для P1.
Стратегія: спочатку канарка 5-10% вузлів, потім хвилі.
Авторозвертання: Ansible/WSUS/Intune/SSM; перевірка залежностей і відкати.
Kernel Live Patching (де можливо) для мінімізації простою.
Рестарт-сервісів: керований drain/cordon для K8s нод, graceful shutdown.

Контейнери

Immutable-підхід: не «apt upgrade» в рантаймі; Переглянути зображення з оновленою базою.
Базові образи: регулярно оновлювати golden images (Alpine/Debian/Distroless), закріплювати версії (digest).
Багатостадійні збірки: мінімізувати поверхню (видаляти build-tools).
Перевірка перед деплоєм: блок образів з критичними CVE.

Kubernetes/Service Mesh

Control Plane: своєчасні мінорні релізи, закриття CVE k8s/etcd/containerd.
Node OS/Container runtime: планові оновлення, сумісність версій.
Mesh/Ingress: версії Envoy/Istio/NGINX - критичні (часто CVE в парсерах/НТТР3).
Admission Policies: заборона':latest', вимога підпису, ліміти на вразливості.

Віртуальні патчі та компенсуючі заходи

Коли патч неможливий швидко:

WAF/WAAP: сигнатура/позитивна модель для конкретного ендпоінта.
Фічфлаги: вимкнути вразливу функціональність.
Мережеві ACL/мТLS/IP allow-list: обмежити доступ до вразливого сервісу.
Конфіг-хардненінг: зниження прав, sandbox, read-only FS, відключення небезпечних модулів.
Скорочення TTL токенів/ключів, ротація секретів.

Управління винятками (Risk Acceptance)

Виняток оформляється тікетом з: обґрунтуванням, компенсуючими заходами, SLA на усунення, датою перегляду.
У звітності позначати як «тимчасове прийняття ризику» і включати в щомісячний огляд.

Спостережуваність і метрики

Технічні:

Mean Time To Patch (MTTP) по P1/P2/P3.
Частка активів, покритих скануванням (%).
Вік відкритих вразливостей (p50/p90), backlog burn-down.
Відсоток образів з SBOM і підписом.

Бізнес/SLO:

Виконання SLO за термінами закриття (наприклад, ≥ 95% P1 ≤ 48 год).
Вплив на аптайм (кількість інцидентів при патчах).
Повторні виявлення тих же CVE (якість фіксу в шаблонах).

Плейбуки (скорочено)

P1: Критична RCE в публічному сервісі

1. Активувати WAF-правило/вірт-патч.
2. Заблокувати доступ до неавторизованих джерел (якщо допустимо).
3. Термінова перезбірка образу/патч ОС, канарка → хвилі.
4. Повторний DAST/перевірка телеметрії, моніторинг помилок.
5. Пост-інцидент: закріпити фікс в базовому образі/Helm chart, додати тест в CI.

Secret leak (авторизація):

1. Негайна ротація секретів/ключів, відкликання токенів.

2. Пошук слідів використання, обмеження ендпоінтів.

3. Скани репо/образів на секрети, впровадження pre-commit сканера.

Приклади артефактів

1) SQL-звіт по «гарячих» вразливостях

sql
SELECT service, cve, cvss, epss, exposed, has_exploit, created_at,
PRIORITY(exposed, has_exploit, cvss, epss) AS prio
FROM vuln_findings
WHERE status = 'open' AND (cvss >= 8.0 OR has_exploit = true)
ORDER BY prio DESC, created_at ASC;

2) Політика Admission (Kyverno, блок critical вразливостей)

yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata:
name: block-critical-vulns spec:
validationFailureAction: Enforce rules:
- name: image-must-have-no-critical match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image contains critical vulnerabilities"
pattern:
metadata:
annotations:
vuln.scanner/critical: "0"

3) Генерація SBOM і підпис (Makefile фрагмент)

make sbom:
cyclonedx create --output sbom.json sign:
cosign sign --key cosign.key $(IMAGE_DIGEST)

Специфіка для iGaming/фінтех

Зони підвищеного ризику: платіжні шлюзи, бекофіс виплат, антифрод, обробка PII/PAN - патчі пріоритет P1/P2.
Вікна обслуговування: узгодження з турнірами/акціями, pre-warm кешів, канарки на низьконавантажених регіонах.
Регуляторика (PCI DSS/GDPR): терміни усунення вразливостей, докази (скріншоти/звіти), сегментація CHD-зони, шифрування.
Партнерські інтеграції: вимагати версіоновані SDK/клієнти, мандатний SCA і HMAC/mTLS на вебхуках.

Типові помилки

«Сканим все - чиним нічого»: немає власників і SLO.
Фокус тільки на CVSS без контексту (експонованість, EPSS, дані).
Патч в рантаймі контейнера замість перезбірки образу.
Відсутність канарок/rollback-планів.
Ігнор місконфігів хмари/K8s (часто критичніше CVE).
Немає SBOM/підпису - слабка простежуваність (supply chain).

Дорожня карта впровадження

1. Інвентаризація активів і власників; єдиний реєстр сервісів/образів.
2. Стек сканерів: SCA/SAST/DAST/Container/Cloud + secret-scan; інтеграція в CI/CD.
3. Політики SLO та пріоритизації: CVSS + EPSS + контекст; шаблони тікетів.
4. Admission/Policy-as-Code: заборона критичних вразливостей, вимога SBOM/підписів.
5. Патч-процеси: вікна, канарки, відкати; автопілоти для мінор/патч-версій.
6. Звітність та метрики: MTTP, покриття, вік; щотижневий огляд ризику.
7. Регулярні навчання: симуляція критичної CVE, перевірка плейбуків і rollback.

Підсумок

Зріле управління вразливостями - це процес, а не разова «прочищення»: автоматичне виявлення, контекстна пріоритизація, безпростійні патчі через канарки/rollback, policy-as-code на вході в прод і прозорі метрики виконання. Закріплюючи фікси в базових образах і шаблонах, ви знижуєте ризик повторення і тримаєте поверхню атаки під стійким контролем.