# Bezpieczny Wtorek: SAP Patch Day vs NIS2. CVE 10.0, 72 godziny i 10 mln EUR kary > SAP CVE-2025-31324 (CVSS 10.0) i NIS2 redefiniują reakcję na podatności. 24h, 72h, 10 mln EUR kary. SecurityBridge + SNOK skracają cykl do godzin. - Source: https://snok.ai/pl/aktualnosci/blog/bezpieczny-wtorek-ze-snok-patch-day-nis2-cve-72h/ - Author: Jacek Bugajski - Published: 2026-05-19 --- 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](https://snok.ai/images/blog/bezpieczny-wtorek-ze-snok-patch-day-nis2-cve-72h.webp) --- ## 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 NIS2 | Co 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 incydentu | Early warning w **24 godziny**, incident notification w **72 godziny**, raport końcowy w **30 dni** do CSIRT NASK / CSIRT GOV | | Art. 20 - odpowiedzialność zarządu | Członkowie zarządu **osobiście odpowiedzialni** za nadzór nad zarządzaniem ryzykiem cyberbezpieczeństwa | | Art. 34 - kary administracyjne | Podmioty 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](https://snok.ai/pl/oferta/bezpieczenstwo-sap/securitybridge/) plus dziennik decyzji pod NIS2 [SecurityBridge](https://snok.ai/pl/oferta/bezpieczenstwo-sap/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](https://snok.ai/pl/oferta/bezpieczenstwo-sap/) 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](https://snok.ai/pl/kontakt/) - odpowiemy w ciągu 48 h.