Przejdź do treści

Bezpieczny Wtorek: SAP Patch Day vs NIS2. CVE 10.0, 72 godziny i 10 mln EUR kary

Drugi wtorek maja 2026 minął tydzień temu. Państwa zespół Basis dostał kolejną listę not bezpieczeństwa SAP. Jeśli wciąż obowiązuje cykl reakcji liczony w tygodniach, NIS2 i KSC zmieniają to równanie - wraz z karami do 10 mln EUR.

Drugi wtorek maja 2026 roku - 12 maja - minął tydzień temu. Państwa zespół Basis otrzymał kolejną listę SAP Security Notes do przeanalizowania, ocenienia i wdrożenia. W typowym polskim landscape SAP średni czas od publikacji noty do wdrożenia patcha w środowisku produkcyjnym wynosi od 45 do 90 dni. Okno, w którym aktorzy ransomware potrzebują na zbudowanie działającego eksploitu, liczy się obecnie w godzinach. Tydzień temu, gdy publikowano majowe noty, w internecie wciąż aktywnie wykorzystywano podatność opublikowaną rok wcześniej - CVE-2025-31324 o najwyższym możliwym wyniku CVSS 10.0.

To nie jest artykuł o tym, że “trzeba szybciej patchować”. To artykuł o tym, że od momentu transpozycji dyrektywy NIS2 do polskiego porządku prawnego - nie patchować szybko = ryzykować karą do 10 mln EUR i osobistą odpowiedzialnością członków zarządu.

SAP Security Patch Day visualization with red CVE alerts on dark terminal background, NIS2 compliance overlay, cinematic macro photography


1. Smaczki, czyli co naprawdę dzieje się z CVE ≥ 9.5 w SAP

Krytyczne podatności w SAP przestały być teoretycznym zagrożeniem akademickim. Trzy konkretne przypadki z ostatnich dwunastu miesięcy pokazują skalę problemu:

CVE-2025-31324 - SAP NetWeaver Visual Composer, CVSS 10.0 (najwyższy możliwy wynik). Niezautentykowana podatność typu deserialization w endpoincie /developmentserver/metadatauploader. Atakujący wysyła spreparowany pakiet HTTP i uzyskuje zdalne wykonanie kodu z uprawnieniami użytkownika serwisowego SAP. SAP opublikowało notę w kwietniu 2025, eksploit pojawił się w dziką naturę w ciągu 72 godzin. CISA dodała podatność do katalogu Known Exploited Vulnerabilities (KEV) w maju 2025. Grupy ransomware BianLian i RansomEXX potwierdzone w atakach.

CVE-2025-42999 - łańcuch eksploitacji z CVE-2025-31324, CVSS 9.1. Pozwala na privilege escalation już po uzyskaniu wstępnego dostępu. Razem oba CVE tworzą gotowy łańcuch initial access → full compromise na warstwie aplikacyjnej SAP.

Kontekst dla polskiego rynku. Visual Composer to komponent obecny w SAP NetWeaver 7.0-7.5 - czyli w landscape’ach, które nie są jeszcze na S/4HANA. To większość polskiego rynku ERP poza pierwszą dwudziestką największych wdrożeń. Innymi słowy: jeśli Państwa firma korzysta jeszcze z klasycznego ECC, prawdopodobieństwo posiadania tego komponentu w środowisku jest wysokie. Prawdopodobieństwo świadomości, że jest on tam zainstalowany, jest znacznie niższe.

To jest właśnie istota problemu. Klasyczny cykl reakcji na podatność SAP wygląda następująco:

  1. SAP publikuje notę (drugi wtorek miesiąca)
  2. Bazis czyta notę, ocenia wpływ “z głowy” lub przez ręczny przegląd komponentów
  3. Wymagane okno serwisowe (najczęściej 4-6 tygodni do przodu)
  4. Testy w QA
  5. Wdrożenie produkcyjne

Średni czas: 45-90 dni. Realne okno eksploitacji: 24-72 godziny.

2. NIS2 + KSC - twarda prawda regulacyjna

Drugi wymiar tego problemu - i powód, dla którego ten artykuł nazywa się “Patch Day vs NIS2” - jest regulacyjny.

Dyrektywa NIS2 (2022/2555) została przyjęta na poziomie unijnym i podlega obowiązkowej transpozycji do prawa krajowego. W Polsce odbywa się to przez nowelizację ustawy o krajowym systemie cyberbezpieczeństwa (UoKSC) - projekt UD68. Termin transpozycji minął 17 października 2024 roku; Polska wciąż finalizuje proces legislacyjny, jednak obowiązki materialne i kary obowiązywać będą od momentu wejścia ustawy w życie.

Kto podlega NIS2/KSC w sektorach wykorzystujących SAP:

  • energetyka (elektroenergetyka, gaz, ropa, ciepłownictwo, wodór)
  • transport (lotniczy, kolejowy, drogowy, wodny)
  • bankowość i infrastruktura rynków finansowych
  • ochrona zdrowia
  • woda pitna i ścieki
  • infrastruktura cyfrowa
  • administracja publiczna
  • produkcja krytyczna (chemikalia, wyroby medyczne, motoryzacja, urządzenia elektryczne)
  • żywność (przetwórstwo, dystrybucja)
  • przesyłki (Poczta i kurierzy)

Większość przedsiębiorstw z tych branż prowadzi rdzeń procesów na SAP. To znaczy: SAP nie jest “tylko aplikacją ERP” - jest systemem, którego kompromitacja może być przesłanką do uznania incydentu za znaczący w rozumieniu art. 23 NIS2.

Konkretne obowiązki, które dotykają codziennej pracy z SAP:

Wymóg NIS2Co to oznacza w praktyce dla SAP
Art. 21 - środki techniczne i organizacyjne (10 obszarów)Vulnerability handling, kontrola dostępu, MFA, kryptografia, łańcuch dostaw - wszystko mierzone w landscape SAP
Art. 23 - zgłoszenie incydentuEarly warning w 24 godziny, incident notification w 72 godziny, raport końcowy w 30 dni do CSIRT NASK / CSIRT GOV
Art. 20 - odpowiedzialność zarząduCzłonkowie zarządu osobiście odpowiedzialni za nadzór nad zarządzaniem ryzykiem cyberbezpieczeństwa
Art. 34 - kary administracyjnePodmioty kluczowe: do 10 mln EUR lub 2% obrotu rocznego. Podmioty ważne: do 7 mln EUR lub 1,4% obrotu

To, co regulator zapyta w toku kontroli, brzmi mniej więcej tak:

“Państwa system SAP ECC zawierał komponent Visual Composer z podatnością CVE-2025-31324 o wyniku CVSS 10.0. Nota SAP została opublikowana 24 kwietnia 2025. Eksploit publiczny pojawił się 28 kwietnia 2025. CISA wpisała podatność do KEV 8 maja 2025. Proszę przedstawić dokumentację potwierdzającą, kiedy Państwa organizacja dowiedziała się o tej podatności, jakie środki kompensacyjne wdrożono przed instalacją patcha, oraz kiedy patch został wdrożony w środowisku produkcyjnym.”

Bez audit trailu - dziennika decyzji, alertów, action items, timestampów - odpowiedź na takie pytanie nie istnieje. A brak odpowiedzi to potencjalne stwierdzenie naruszenia obowiązków z art. 21 oraz - co istotniejsze - osobistej odpowiedzialności członków zarządu z art. 20.

Warto podkreślić jeszcze jeden aspekt łańcucha dostaw (art. 21 ust. 2 lit. d NIS2). Jeśli SAP jest serwisowany przez zewnętrznego dostawcę, regulator oczekuje, że Państwo - jako podmiot kluczowy lub ważny - zweryfikowali poziom dojrzałości tego dostawcy w zakresie zarządzania podatnościami. SLA na uptime to za mało. Potrzebne są SLA na czas reakcji na CVE z określonym CVSS.

3. Jak to robimy w SNOK - SecurityBridge plus dziennik decyzji pod NIS2

SecurityBridge to platforma natywna dla SAP - jedyna, która jednocześnie pokrywa cztery obszary istotne pod NIS2:

Vulnerability management. Platforma mapuje konkretną notę SAP do konkretnych systemów SID w Państwa landscape - i odpowiada na pytanie “czy ten patch w ogóle nas dotyczy”. Bez SecurityBridge ta odpowiedź to praca jednego specjalisty Basis przez 4-8 godzin miesięcznie. Z platformą: 5 minut, automatyczny raport, ze stempelem czasu - czyli gotowy element dokumentacji audit trail.

Threat detection. SIEM operujący na warstwie aplikacyjnej SAP - czyli tam, gdzie klasyczne narzędzia cyberbezpieczeństwa nie sięgają. Wykrywa próby eksploitacji w czasie rzeczywistym (w tym próby wykorzystania CVE-2025-31324). Generuje alerty, które trafiają do dziennika incydentów - i są dowodem reakcji na potrzeby art. 23 NIS2.

Wirtualne patchowanie. Najważniejszy element z perspektywy realiów biznesowych. Gdy podatność jest krytyczna, ale produkcja musi działać i okno serwisowe wypada za 6 tygodni - SecurityBridge potrafi zablokować wektor ataku na poziomie monitoringu i bramki komunikacyjnej, nie czekając na faktyczny patch w kernelu. To różnica między “byliśmy podatni przez 6 tygodni” a “byliśmy podatni przez 6 godzin, potem zamknięci kompensacją, potem zapatchowani”.

Code security i patch management automation. Statyczna analiza własnego kodu ABAP/Java pod kątem podatności wprowadzonych przez deweloperów wewnętrznych. To istotne w kontekście art. 21 NIS2 dot. bezpieczeństwa rozwoju oprogramowania.

Rola SNOK jako partnera SecurityBridge w Polsce:

  • implementacja platformy w landscape klienta (typowo 6-10 tygodni)
  • 24/7 monitoring przez nasze Security Operations Center
  • comiesięczna analiza po Patch Day - rekomendacja działań w 24h od publikacji not
  • prowadzenie pełnego audit trail w formacie kompatybilnym z wymogami art. 23 NIS2
  • gotowy zestaw dokumentów dla regulatora w razie kontroli

To, co dostarczamy w praktyce, to skrócenie cyklu reakcji z 45-90 dni do 24-72 godzin - czyli zmieszczenie się w oknie egzekwowanym przez NIS2.


Co dalej

Jeśli Państwa firma podlega NIS2 (lub będzie podlegać po wejściu w życie znowelizowanej UoKSC) i prowadzi krytyczne procesy na SAP - rekomendowane minimum to dwa działania w najbliższych 30 dniach:

  1. Inwentaryzacja podatności w obecnym landscape SAP - czyli odpowiedź na pytanie “ile CVE z wynikiem CVSS ≥ 9.0 mamy w tej chwili niezamkniętych w produkcji”. Bez tej odpowiedzi nie da się ustalić, czy obecna postawa jest zgodna z art. 21 NIS2.
  2. Ocena gotowości audit trail - czy w razie kontroli regulatora jesteście Państwo w stanie udokumentować reakcję na konkretną notę SAP z konkretnej daty.

Oferujemy w SNOK bezpłatny SAP Security Health Check - jeden dzień pracy naszego konsultanta w Państwa środowisku, raport gotowy w ciągu tygodnia. Wynik to mapa podatności w landscape, ocena ryzyka pod kątem NIS2 oraz rekomendacja kolejnych kroków - z lub bez SecurityBridge, w zależności od skali.

Niniejszy artykuł nie zastępuje wiążącej interpretacji prawnej dyrektywy NIS2 ani znowelizowanej UoKSC. Konkretne obowiązki Państwa organizacji jako podmiotu kluczowego lub ważnego wymagają indywidualnej oceny prawnej.


Chcesz zobaczyć to w praktyce lub omówić wdrożenie w swojej firmie? Napisz do nas - odpowiemy w ciągu 48 h.

Skontaktuj się z nami