CVSS jest najczęściej używanym sposobem opisania, jak groźna jest podatność. Trafia do raportów, do SLA, do tabel priorytetów. Problem zaczyna się wtedy, gdy staje się jedynym kryterium — bo do tego się nie nadaje. CVSS mówi, jak groźna może być podatność w ogóle. Nie mówi, jak groźna jest u Ciebie.
Problem
Najczęstszy schemat: bierzemy listę ze skanera, sortujemy malejąco po CVSS i pracujemy od góry. Wszystko 9.0+ to „critical", więc tym się zajmujemy. Brzmi rozsądnie. W praktyce prowadzi to do tego, że zespoły łatają teoretycznie groźne podatności na systemach, których nikt nie atakuje, a realnie wykorzystywane luki o średnim score czekają w kolejce.
Score, który najczęściej widzimy, to CVSS Base. Z założenia opisuje on właściwości samej podatności — w oderwaniu od Twojego środowiska. To nie jest wada skali. To jej zakres.
Dlaczego to ma znaczenie
Ten sam numer CVSS może oznaczać dwie zupełnie różne rzeczy:
- CVSS 9.8 w bibliotece, która siedzi w obrazie bazowym w rejestrze i nigdzie nie działa — wysoki numer, niskie realne ryzyko.
- CVSS 6.5 w usłudze wystawionej do internetu, z publicznym exploitem, na krytycznej ścieżce biznesowej — średni numer, ryzyko, którym zajmujesz się dzisiaj.
wysoki CVSS ≠ wysoki priorytet
Priorytet nie wynika z samego score. Wynika z trzech rzeczy, których CVSS Base nie zna: czy to jest wystawione, czy istnieje (i jest używany) exploit, oraz ile to dla Ciebie znaczy.
Co ciekawe, sam standard CVSS to wie. Oprócz metryk bazowych ma metryki środowiskowe i temporalne, które pozwalają urealnić ocenę, a w wersji 4.0 doszły metryki uzupełniające. Tylko że w praktyce prawie nikt ich nie wypełnia — zostaje goły Base score prosto ze skanera.
Przykład z organizacji
Wróćmy do rejestru Harbor ze skanowaniem Trivy. Trivy poda Ci CVSS dla każdej podatności w każdym obrazie. Posortuj listę po tym numerze, a na górze wylądują krytyczne CVE w obrazach bazowych — często w komponentach, które w danym kontenerze nie są nawet uruchamiane, a sam obraz może w ogóle nie działać w runtime.
Tymczasem realny priorytet to obraz, który jednocześnie: faktycznie działa na wystawionym klastrze, zawiera podatność z publicznym exploitem i odpowiada za istotny dla biznesu serwis. Jego CVSS bywa niższy niż połowy listy. A to nim zajmiesz się najpierw.
Dlatego do samego score warto dołożyć dwa sygnały, które mówią o realnym wykorzystaniu:
- EPSS (Exploit Prediction Scoring System) — szacuje prawdopodobieństwo, że dana podatność będzie wykorzystywana w najbliższym czasie.
- CISA KEV (Known Exploited Vulnerabilities) — katalog podatności, o których wiadomo, że są aktywnie wykorzystywane w atakach.
CVSS mówi „jak bardzo boli". EPSS i KEV mówią „czy ktoś faktycznie w to uderza". Dopiero kontekst zasobu dokłada „i czy to coś, na czym Ci zależy".
Dobre praktyki
- Używaj CVSS jako jednego z wejść do priorytetyzacji, nie jako wyniku końcowego.
- Łącz score z ekspozycją (czy wystawione), wykorzystaniem (EPSS, KEV) i znaczeniem zasobu.
- Tam, gdzie możesz, uzupełniaj metryki środowiskowe CVSS, zamiast patrzeć tylko na Base.
- Priorytetyzuj to, co realnie działa i jest atakowane — nawet jeśli ma niższy numer.
Najczęstsze błędy
- Sortowanie listy malejąco po CVSS i praca „od góry".
- Traktowanie progu (np. wszystko ≥ 9.0) jako jedynej definicji pilności.
- Ignorowanie tego, że CVSS Base z definicji nie zna Twojego środowiska.
- Pomijanie EPSS i KEV, czyli sygnałów o realnym wykorzystaniu.
- Mylenie wysokiego score z wysokim ryzykiem dla organizacji.
Podsumowanie
CVSS jest dobrym punktem wyjścia i złym punktem końcowym. Mówi, jak groźna może być podatność w ogóle — nie jak groźna jest dla Twojego systemu, w Twoim środowisku, przy Twojej ekspozycji. Priorytet powstaje dopiero wtedy, gdy do score dołożysz kontekst: czy to działa, czy jest atakowane i ile dla Ciebie znaczy.