Skanowanie wrażliwości i łatki

Krótkie podsumowanie

Zarządzanie podatnością jest ciągły cykl: wykrywanie → ocena ryzyka → eliminacja (patch/migration/config) → weryfikacja → raportowanie. Technologie skanowania (SCA/SAST/DAST/IAST/Cloud/Container) dają sygnały, a kontekst (ekspozycja, uprawnienia, dane, EPSS, exploits) określa priorytet. Celem jest zmniejszenie rzeczywistego ryzyka bez przestojów biznesowych przy użyciu automatyzacji, obliczeń kanaryjskich i jasnych SLO.

Taksonomia skanowania

SCA (Software Composition Analysis): analiza zależności/licencji; Odkrycie CVE w bibliotekach, SBOM.
SAST-Statyczna analiza rodzimego kodu przed montażem.
DAST: dynamiczna czarna skrzynka kontra usługa uruchomienia.
IAST: czujniki w aplikacji (podczas testów) - mniej FP, głębszy kontekst.
Kontener/Skanowanie systemu operacyjnego: obrazy (obraz podstawowy, pakiety), hosty (jądro/pakiety/konfiguracje), wskaźniki CIS.
Cloud/Infra (CSPM/KSPM): cloud/K8s błędne konfiguracje (IAM, sieci, szyfrowanie, publiczne wiadra).
Skanowanie tajemnic: wycieki klucza/tokena w repozytoriach i obrazach.
Skanowanie binarne/artefakt: weryfikacja zebranych artefaktów (podpisy, luki).

Model ryzyka i ustalanie priorytetów

Wynik = CVSS v3. x (podstawa) × EPSS (prawdopodobieństwo wykorzystania) × kontekst (narażenie, dane, przywileje, środki wyrównawcze).

• Ekspozycja w Internecie/wewnątrz, obecność WAF/mTLS/izolacja.
• Dane: PII/finance/secrets.
• Przywileje procesu/węzła, potencjał ruchu bocznego.
• Dostępność publicznych ataków eksploatacyjnych/masowych, wymagania dotyczące zgodności.

Przykład wektora CVSS: 'CVSS: 3. 1/AV: N/AC: L/PR: N/UI: N/S: U/C: H/I: H/A: H '→ krytykowane; jeżeli usługa jest publiczna i bez środków wyrównawczych - P1.

• P1 (krytyczny, obsługiwany): fix ≤ 48 h.
• P2 (wysoki): fix ≤ 7 dni.
• P3 (średnia): fix ≤ 30 dni.
• P4 (low/inform): planned/by backlog.

Zarządzanie podatnością na zagrożenia

1. Inwentaryzacja aktywów: usługi, obrazy, klastry, systemy operacyjne, pakiety, zależności, wersje.
2. Skanowanie zaplanowane i imprezy: commits, builds, dumps, daily/weekly windows.
3. Triage: deduplication, normalizacja (CVE → Bilet), mapowanie do właściciela.
4. Priorytety według kontekstu: CVSS/EPSS + ekspozycja/dane.
5. Remediacja: patch/dependency update/config hartnening/virtual patch (WAF).
6. Weryfikacja: ratowanie, testy, kanarka.
7. Sprawozdawczość: wskaźniki zamknięcia, wiek słabości, zgodność SLO.
8. Lekcje: naprawić szablony (obraz podstawowy, wykres Helm), zasady dotyczące przyszłości.

Integracja z CI/CD

W kroku PR: SAST + SCA + tajne skanowanie; „break build” przez P1/P2 lub wymóg zastosowania.
Na etapie budowy: skanowanie obrazu, generacja SBOM (CycloneDX/SPDX), podpis artefaktowy (cosign).
Na etapie wdrażania: Polityka wstępu - zabronić obrazów z 'rytmicznymi/wysokimi' lukami i bez podpisu/SBOM.
Po etapie: DAST/IAST przed ustawianiem i częściową produkcją (profile bezpieczne).

Przykład: Remont/Dependabot (fragment)

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

Polityka przyjmowania (Kubernetes, OPA/Gatekeeper - uproszczone)

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])
}

Zarządzanie łatami (środki trwałe, kontenery, K8s)

ОZ (Linux/Windows)

Okno łatki: zwykłe okna + nadzwyczajne okna awaryjne dla P1.
Strategia: Kanaryjskie 5-10% węzłów najpierw, a następnie fale.
Automatyczne wdrożenie: Ansible/WSUS/Intune/SSM; sprawdzanie ograniczeń i rolki.
Kernel Live Patching (w miarę możliwości) w celu zminimalizowania przestojów.
Usługi restart: zarządzane drenaż/kordon dla węzłów K8s, graceful shutdown.

Pojemniki

Podejście niezmienne: nie „apt upgrade” w czasie trwania; odbudować obraz z aktualizowaną bazą.
Obrazy bazowe: regularnie aktualizuj złote obrazy (Alpine/Debian/Distroless), naprawiaj wersje (digest).
Zespoły wielostopniowe: zminimalizować powierzchnię (usunąć narzędzia budowlane).
Pre-deploy Scan - Blok obrazów z krytycznymi CSC.

Kubernetes/Siatka serwisowa

Control Plane: terminowo drobne wydania, zamykanie CVE k8s/etcd/containerd.
Czas trwania węzła OS/Container: zaplanowane aktualizacje, kompatybilność wersji.
Siatka/Ingress: Wysłannik/Istio/NGINX wersje są krytyczne (często CVE w parserach/NTTR3).
Zasady przyjmowania: zakaz „: najnowszy”, wymóg podpisu, ograniczenia podatności.

Wirtualne plastry i środki wyrównawcze

• WAF/WAAP: podpis/model pozytywny dla określonego punktu końcowego.
• Flagi funkcji: Wyłączyć funkcje podatne na zagrożenia.
• Sieć ACL/mTLS/IP permit-list: ograniczyć dostęp do usługi vulnerable.
• Utwardzanie Config: obniżanie praw, piaskownica, tylko do odczytu FS, wyłączanie niebezpiecznych modułów.
• Redukcja żetonów/kluczy TTL, rotacja tajemnic.

Akceptacja ryzyka

Wyjątek jest wydawany z biletem z: uzasadnieniem, środkami wyrównawczymi, SLA do eliminacji, datą rewizji.
Sprawozdanie jako „tymczasowa akceptacja ryzyka” i zawarte w comiesięcznym przeglądzie.

Obserwowalność i wskaźniki

• Średni czas Do Patch (MTTP) ма P1/P2/P3.
• Udział aktywów objętych skanowaniem (%).
• Wiek otwartych luk (p50/p90), zaległości w spalaniu.
• Odsetek obrazów z SBOM i podpisem.

• Zakończenie SLO poprzez zamknięcie terminów (np. 95% P1 ≥ ≤ 48 godzin)
• Wpływ na czas uptime (liczba incydentów plaster).
• Wielokrotne wykrywanie tego samego CVE (poprawienie jakości w szablonach).

Playbooks (skrócony)

P1: Krytyczny RCE w służbie publicznej

1. Aktywacja reguły WAF/plaster wirth.
2. Zablokuj dostęp do nieautoryzowanych źródeł (w stosownych przypadkach).
3. Pilny obraz odbudować/OS patch, → fala kanaryjska.
4. Powtarzająca się kontrola DAST/telemetria, monitorowanie błędów.
5. Po incydencie: naprawić poprawkę w podstawowym obrazie/wykresie Helm, dodać test do CI.

1. Natychmiastowa rotacja sekretów/kluczy, cofnięcie żetonów.

2. Znalezienie śladów użycia, ograniczenie punktów końcowych.

3. Skanowanie repo/obrazów dla tajemnic, wdrożenie skanera wstępnego.

Przykłady artefaktów

1) Raport SQL na temat gorących luk

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) Polityka przyjmowania (Kyverno, krytyczny blok wrażliwości)

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) Generacja i podpis SBOM (fragment Makefile)

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

Specyfika dla iGaming/fintech

Obszary wysokiego ryzyka: bramy płatności, backfix płatności, przeciwdziałanie oszustwom, przetwarzanie PII/PAN - P1/P2 systemy priorytetowe.
Okna serwisowe: koordynacja z turniejami/promocjami, przedciepłymi buforami, kanarkami w regionach o niskim obciążeniu.
Regulacja (PCI DSS/RODO): harmonogram ustalania luk, dowody (zrzuty ekranu/raporty), segmentacja strefy CHD, szyfrowanie.
Integracje partnerskie: wymagają wersji SDK/klienci, obowiązkowe SCA i HMAC/mTLS na hakach webowych.

Częste błędy

„Skanuj wszystko - nic nie naprawić”: brak właścicieli i SLO.
Skupienie się tylko na CVSS bez kontekstu (ekspozycja, EPSS, dane).
Łatać w czasie trwania kontenera zamiast odbudowywać obraz.
Brak planów kanaryjskich/odwróconych.
Ignorowanie błędnych konfigur cloud/K8s (często bardziej krytycznych niż CVE).
Brak SBOM/podpis - łańcuch dostaw.

Plan działania w zakresie wdrażania

1. inwentaryzacja aktywów i właścicieli; ujednolicony rejestr usług/obrazów.
2. Stos skanera: SCA/SAST/DAST/Container/Cloud + secret-scan; integracja z CI/CD.
3. Polityka SLO i priorytety: kontekst CVSS + EPSS +; szablony biletów.
4. Przyjmowanie/kodeks polityki: zakaz krytycznych luk, wymóg dotyczący SBOM/podpisów.
5. Procesy łatki: okna, kanarki, rolki; autopiloty dla wersji drobnych/łatek.
6. Sprawozdawczość i wskaźniki: MTTP, zasięg, wiek; tygodniowy przegląd ryzyka.
7. Regularne ćwiczenia: symulacja krytycznego CVE, weryfikacja odtwarzaczy i odwrót.

Wynik

Dojrzałe zarządzanie luką jest procesem, a nie jednorazowym „oczyszczaniem”: automatyczne wykrywanie, priorytetyzacja kontekstu, płynne łaty przez kanary/rollback, policy-as-code przy wejściu do prod i przejrzyste wskaźniki wykonania. Poprzez zabezpieczenie zamków w podstawowych obrazach i wzorach, zmniejsza się ryzyko powtórzenia i utrzymuje powierzchnię ataku pod stałą kontrolą.