Vulnerability Engineer codziennie łączy dane z wielu źródeł: bazę NVD, GitHub Advisory Database, advisory producenta, tracker dystrybucji, katalog CISA KEV, EPSS. Problem w tym, że o tym samym CVE potrafią one mówić różne rzeczy — inny CVSS, inny status „affected”, inną dostępność poprawki. LAB posadził te źródła przy jednym stole i kazał im rozmawiać. Poniższa rozmowa jest fikcją analityczną (patrz ramka wyżej), ale każdy jej wątek opiera się na realnym przypadku opisanym na blogu.
Przy stole (persony AI)
- NVD (NIST) — bazowy rekord CVE i „kanoniczny” CVSS liczony bez kontekstu wdrożenia.
- GHSA (GitHub Advisory Database) — widok ekosystemowy (pakiety, wersje), czasem z polami
Unknown. - Red Hat Product Security — affectedness, backporty, VEX i „not affected” z uzasadnieniem.
- Canonical / Ubuntu Security — USN, poprawki (także przez Pro/ESM), czasem fix bez CVE.
- GitHub Security (GHES) — release notes producenta i konkretne fixed builds.
- Cisco PSIRT — advisory, ekspozycja domyślna, workaroundy.
- Spring Security — severity producenta i warunki konfiguracyjne exploitu.
- CISA (KEV) — dowód realnej eksploatacji.
- FIRST (EPSS) — predykcja prawdopodobieństwa eksploatacji.
- VMRT Lab — moderator; nie rozstrzyga, kto ma rację, tylko pyta „na jakie pytanie odpowiadasz?”.
Runda 1 — „Jaki to ma CVSS?” „To zależy, kogo pytasz.”
Weźmy CVE-2026-59283. My klasyfikujemy je jako Medium — bo exploit wymaga jednocześnie SimpleEvaluationContext i aktywnego kompilatora SpEL. Bez tych warunków nie ma czego eskalować.
A u nas ten sam CVE to 9.1 Critical (AV:N/AC:L/PR:N/UI:N/C:N/I:H/A:H). Opisujemy najgorszy realistyczny wektor, nie typową konfigurację. To nie jest „pomyłka” względem Springa — to inny model attack path.
My dajemy liczbę bazową, bez wiedzy o tym, czy u Ciebie compiler jest włączony. To świadomy kompromis: porównywalność kosztem kontekstu. Apache Tika to ten sam mechanizm — my mówimy 7.5 (AV:N), CVE/CISA 5.9 (AV:L), a niektóre bazy 8.7. Każdy opisuje inny poziom systemu: bibliotekę, warunek dostarczenia pliku albo gotową aplikację sieciową.
Czyli rozbieżność CVSS bywa nie błędem, tylko informacją — sygnałem, że trzeba dopytać o wektor. Zobacz też FreeRDP (dwa różne CVSS jednego CVE) i Linux netfs 64068 (spór o wektor jako problem jakości danych).
Runda 2 — „Jesteście affected?” „Wersja tak, ale ścieżki ataku nie.”
Najczęstsze nieporozumienie. „Pakiet w podatnej wersji” to nie to samo co „exploitable”. W containerd komponent bywa obecny, ale nieuruchomiony — status VEX not_affected z uzasadnieniem vulnerable_code_not_in_execute_path to nie wykręt, to warstwa, której skaner wersji nie ma. W Linux xfrm istnieje publiczny exploit, a mimo to RHEL potrafi być not affected — bo liczy się konfiguracja i backport.
My mamy drugą stronę tej monety: Nexus 9000 jest podatny w konfiguracji domyślnej — porty w domyślnym VRF, bez włączania żadnej funkcji. To zasługuje na wyższy confidence niż „może ktoś to włączył”. Affectedness to nie zawsze „opt-in”.
Zgoda — dlatego my odróżniamy „affected by version” od „exploitable here”. W SCTP podatność żyje tylko przy wyłączonym cookie auth; sugerujemy nawet blacklistę modułu, jeśli protokół jest nieużywany. To jest not_exploitable — subsystem disabled, nie „nie ma problemu”.
Uwaga na drugą krawędź tego ostrza: „not affected, bo nieosiągalne” bywa wygodną wymówką, gdy nikt realnie nie sprawdził call-grafu. Reachability zniżający ryzyko wymaga równie twardego dowodu, jak ten, który je podnosi. Inaczej to tylko ładniej brzmiący false negative.
Runda 3 — „Jest poprawka?” „Jest. Pytanie: dla kogo i gdzie.”
„Fix available” to za mało. W BioSig (USN-8713-1) poprawka istnieje dla 22.04/24.04/26.04 LTS — ale tylko przez Ubuntu Pro / ESM Apps. Skaner zobaczy fixed version, a patch manager bez uprawnienia jej nie pobierze. To nie jest EOL — to inna ścieżka utrzymania konkretnego komponentu.
U nas odwrotny problem — danych, nie dostępności. Dla CVE-2026-19118 opublikowaliśmy konkretne fixed builds (3.17.20–3.22.0) w release notes, a GitHub Advisory Database wciąż pokazuje Affected/Patched: Unknown. Ten sam dostawca, dwa różne poziomy szczegółowości.
I skrajny przypadek: PAM (USN-8688-1) — naprawiliśmy obejście blokady logowania bez CVE. Jeśli Twój pipeline śledzi wyłącznie numery CVE, tej poprawki po prostu nie zobaczy.
Dochodzi jeszcze lineage poprawki. W BIND „upstream EOL” nie znaczy „dystrybucja nie łata” — my backportujemy do wspieranych strumieni. Wersja upstream i wersja pakietu dystrybucji to dwie różne osie.
Runda 4 — „To jak pilne to jest?” „Severity to nie priorytet.”
My nie liczymy score'u. Mówimy jedno: to jest realnie eksploatowane. W JFrog CVSS to tylko 5.3 Medium, a mimo to trafiło do KEV — bo są dowody ataków. KEV to fakt, nie predykcja.
A my dajemy predykcję. W CVE-2026-68820 EPSS wynosił ~0,356%, a KEV = tak. To nie sprzeczność — my szacujemy prawdopodobieństwo, CISA potwierdza obserwację. Dwa różne pytania.
I dlatego sam wysoki CVSS nie wystarcza w drugą stronę: w OpenShift ACM mamy 9.9, a EPSS bardzo niski. Liczba bazowa krzyczy „Critical”, threat intel mówi „spokojnie”. Priorytet rodzi się dopiero z połączenia tych sygnałów.
Czyli nikt przy tym stole nie odpowiada na pytanie „co mam zrobić ja". Odpowiadają na cząstkowe pytania. Decyzję (SSVC: Track / Attend / Act) składa Vulnerability Engineer, dokładając kontekst zasobu, którego żadne z tych źródeł nie zna.
Kto na jakie pytanie odpowiada
Sedno rozmowy: źródła nie „kłamią” — po prostu odpowiadają na różne pytania. Pomieszanie ich to najczęstsza przyczyna złych decyzji.
| Źródło | Na jakie pytanie odpowiada | Czego NIE wie |
|---|---|---|
| NVD | Jak groźna jest podatność „w ogóle” (CVSS bazowy)? | Twojej konfiguracji, wersji dystrybucji, ekspozycji. |
| GHSA | Który pakiet/wersja ekosystemu jest dotknięta? | Bywa niepełne (Unknown) mimo danych u vendora. |
| Red Hat / Canonical | Czy ten pakiet w tej dystrybucji jest affected i naprawiony? | Czy u Ciebie ścieżka ataku jest realnie osiągalna. |
| Vendor (GitHub, Cisco, Spring) | Które buildy/wersje naprawiają problem i pod jakim warunkiem? | Jak to mapuje się na Twój inventory i ryzyko. |
| CISA (KEV) | Czy to jest realnie eksploatowane (dowód)? | Jak bardzo dotyczy akurat Twojego zasobu. |
| FIRST (EPSS) | Jakie jest prawdopodobieństwo eksploatacji (predykcja)? | Czy atak już się zdarzył; kontekstu zasobu. |
Co z tego wynika dla Vulnerability Engineera
- Zachowuj provenance, nie wybieraj „najwyższej liczby”. Trzymaj obok siebie CVSS vendora, NVD i GHSA z etykietą źródła — rozbieżność to sygnał, nie szum.
- „Affected” to trzy różne pytania: wersja obecna? kod osiągalny? exploit możliwy tutaj? Każde wymaga osobnego dowodu — w obie strony.
- „Fix available” rozbij na warstwy: upstream / vendor / standardowe repo / entitlement (Pro/ESM). Skaner może znać wersję, której patch manager nie pobierze.
- Nie opieraj procesu wyłącznie o numer CVE: bywa fix bez CVE (Ubuntu PAM) i rekord z polami
Unknown(GHES). - Severity ≠ priorytet. Łącz KEV (dowód) + EPSS (predykcja) + kontekst zasobu w decyzję SSVC, zamiast czytać jedną liczbę.
Red Team — zanim potraktujesz to dosłownie
- Ta rozmowa to uproszczenie: realne zespoły PSIRT/Product Security robią znacznie więcej niż jedna „kwestia” w dialogu, a ich procesy różnią się między produktami.
- Persony są wygenerowane przez AI i mogą upraszczać lub uśredniać stanowiska — traktuj je jak ilustrację mechanizmu, nie jak opis polityki konkretnej firmy.
- Wszystkie liczby i statusy (CVSS, EPSS, wersje) pochodzą z konkretnych wpisów — zawsze weryfikuj u źródła, bo dane o CVE zmieniają się w czasie.
Odniesienia (wpisy na tej stronie)
- Rozbieżny CVSS: Spring SpEL, Apache Tika, FreeRDP, Linux netfs 64068
- Affectedness / VEX / reachability: containerd, Linux xfrm (RHEL not affected), Linux SCTP, Cisco Nexus (default exposure)
- Dostępność i jakość danych o poprawce: Ubuntu BioSig (Pro/ESM), Ubuntu PAM (fix bez CVE), GHES (GHSA „Unknown”), BIND (backport dystrybucji)
- Severity vs priorytet: KEV vs EPSS, JFrog Medium + KEV, OpenShift ACM 9.9 vs EPSS
- Szersze ujęcie: Synteza 92 przypadków — gdzie pęka proces VM
Nota metodyczna: to jest wynik pracy VMRT Lab — wieloagentowego procesu analitycznego realizowanego przez model AI. „Głosy” dostawców (Red Hat, Ubuntu/Canonical, GitHub, Cisco, Spring, NVD, GHSA, CISA, FIRST) to syntetyczne persony wygenerowane przez AI na podstawie publicznych advisory i pól danych opisanych w linkowanych wpisach — nie są to cytaty ani oficjalne stanowiska tych organizacji. Nazwy firm i projektów użyto wyłącznie w celu opisowym (nominatywnie), aby zilustrować, jak różne źródła opisują to samo CVE. Materiał edukacyjny — przed wykorzystaniem w decyzjach zweryfikuj u człowieka i u źródła. Stan: 4 września 2026.