Legacy przestaje być długiem
List EBC, rekomendacje UKNF i SAP ECC

W latach 2018-2019 od ujawnienia podatności do jej wykorzystania przez atakujących mijały średnio 63 dni. Tak liczył Mandiant, zespół reagowania na incydenty należący dziś do Google. W raporcie M-Trends 2026 Mandiant szacuje ten czas na minus siedem dni: atakujący zaczynają średnio tydzień wcześniej, niż producent udostępni poprawkę. VulnCheck, firma śledząca wykorzystywane podatności, podaje, że w pierwszym półroczu 2026 roku prawie co czwarta znana wykorzystywana podatność była atakowana najpóźniej w dniu publikacji jej opisu.

Europejski Bank Centralny (EBC) wyciągnął z tego wniosek dla banków, które nadzoruje bezpośrednio: do 31 października każdy z nich składa plan działania, a w tym planie są systemy przestarzałe i pozbawione wsparcia producenta. Dla firm pracujących na SAP ECC, czyli poprzedniej generacji systemu ERP od SAP, to pytanie ma już swój kalendarz, bo podstawowe utrzymanie kończy się w 2027 roku.

Piszemy z pozycji, która nie jest neutralna. SNOK zarabia na bezpieczeństwie SAP, comiesięcznej obsłudze SAP Security Patch Day i konwersjach do SAP S/4HANA. Bronimy jednak tezy, która nie sprzedaje żadnej z tych usług wprost: data konwersji nie jest planem ochrony. Plan mówi, co chroni system do dnia, w którym go wyłączymy.

Okładkę wygenerowała AI.

List EBC o systemach przestarzałych

List o sygnaturze SSM-2026-0301 z 7 lipca 2026 roku podpisała Claudia Buch, przewodnicząca Rady ds. Nadzoru EBC. Trafił do prezesów wszystkich instytucji istotnych, czyli największych banków strefy euro, które EBC nadzoruje bezpośrednio. Diagnoza zajmuje jeden akapit: najbardziej zaawansowane modele AI (określane jako Frontier AI) znajdują podatności i piszą działające exploity, czyli kod wykorzystujący lukę, w niespotykanym dotąd tempie. EBC uznaje to za trwałą zmianę krajobrazu zagrożeń, a nie za chwilowe zjawisko czy ryzyko związane z jednym narzędziem. Odpowiedzialność przypisuje zarządom banków.

Plan trafia do wspólnego zespołu nadzorczego (Joint Supervisory Team, JST), który prowadzi nadzór nad danym bankiem, i ma opisywać konkretne środki, zasoby, role i harmonogram. W krótkim terminie EBC wskazuje łatanie podatności na dużą skalę, monitorowanie i wykrywanie ataków, przegląd ryzyka dostawców technologii informacyjno-komunikacyjnych (ICT) oraz ochronę wszystkiego, co jest wystawione do internetu. Systemy przestarzałe znalazły się w części strukturalnej, długoterminowej. Aneks do listu precyzuje oczekiwanie: wymiana albo aktualizacja takich systemów, a tam, gdzie wymiana nie jest wykonalna, kompleksowa ochrona za pomocą dodatkowych kontroli.

To ostatnie zdanie uważamy za najważniejsze w całym liście. EBC nie zakłada, że bank wymieni wszystko w kwartał. Pyta, czym system będzie chroniony, zanim zostanie wymieniony.

Drugi fragment, który czytamy przez pryzmat SAP, dotyczy samego łatania. EBC spodziewa się więcej i częstszych poprawek - od producentów, od społeczności open source i we własnym oprogramowaniu banku. Oczekuje zarządzania zmianą, które pozwala szybko wdrażać pilne poprawki bez utraty stabilności, zapisania tego w umowach i umowach o poziomie usług (SLA) z dostawcami ICT oraz obsady zespołów adekwatnej do nowego tempa. Żeby banki miały na plan czas i ludzi, przesunął termin rocznego kwestionariusza ryzyka IT z września 2026 roku na luty 2027.

Rekomendacje UKNF dla całego rynku finansowego

Polska nie należy do strefy euro, więc polskie banki nie są adresatami listu EBC. Część z nich należy jednak do grup bankowych, które nimi są, i zakładamy, że pytania o systemy przestarzałe dotrą z centrali także do polskich spółek zależnych.

Ważniejsze jest to, co zrobił polski nadzór. Latem Urząd Komisji Nadzoru Finansowego (UKNF) opublikował rekomendacje dla podmiotów rynku finansowego dotyczące wpływu modeli Frontier AI na cyberbezpieczeństwo. Adresatem są wszystkie podmioty rynku finansowego, nie tylko banki. Dokument w dużej części powtarza strukturę listu EBC: plan działań ze środkami, zasobami, odpowiedzialnościami i harmonogramem, te same obszary krótkoterminowe oraz modernizację przez wymianę lub aktualizację technologii przestarzałych, nieobsługiwanych lub wycofanych z eksploatacji.

Terminu UKNF nie wyznaczył. Zapowiedział za to, że adekwatność i skuteczność wdrożonych rozwiązań sprawdzi zarówno w nadzorze bieżącym, jak i podczas kontroli. Dwa zdania z tego dokumentu uważamy za kluczowe dla zarządów. Pierwsze: rozporządzenie DORA, czyli unijne przepisy o operacyjnej odporności cyfrowej sektora finansowego, nie wymaga jedynie posiadania strategii, polityk i instrukcji, ale także dowodów na ich działanie. Drugie: priorytety w zarządzaniu podatnościami mają wynikać z rzeczywistego ryzyka, nie wyłącznie z oceny w skali CVSS, która mierzy techniczną wagę podatności.

Legacy w SAP to więcej niż numer wydania

W świecie SAP rozmowa o systemach przestarzałych zaczyna się zwykle od kalendarza. Podstawowe utrzymanie SAP ECC kończy się w 2027 roku, rozszerzone za dopłatą trwa do 2030. Lata 2031-2033 są dostępne wyłącznie dla systemów przeniesionych przed końcem 2030 roku do SAP ERP, private edition, czyli w praktyce w ramach RISE with SAP, oferty SAP łączącej licencję z utrzymaniem w chmurze. Szerzej pisaliśmy o tym w tekście o uzależnieniu od dostawcy. Dla instalacji utrzymywanych we własnej infrastrukturze granicą pozostaje rok 2030.

Kalendarz to jednak tylko część obrazu. Brytyjskie Narodowe Centrum Cyberbezpieczeństwa (NCSC) ujęło problem najprościej: technologia bez wsparcia nie może otrzymać aktualizacji. W krajobrazie SAP przestarzałe bywa również to, co przez lata narosło wokół samego wydania ERP: własny kod w języku ABAP, którego nikt nie przeglądał pod kątem bezpieczeństwa, interfejsy RFC (zdalne wywołania funkcji między systemami) zestawione dla dawno zamkniętych projektów, starsze jądra systemu i rozwiązania firm trzecich, których nikt już nie rozwija.

Do tego dochodzi tempo. SAP publikuje poprawki bezpieczeństwa co miesiąc, w drugi wtorek, w ramach SAP Security Patch Day - w październiku omawialiśmy pełną listę pozycji. Jeżeli poprawek będzie więcej, czego spodziewają się i EBC, i NCSC, wąskim gardłem przestanie być wiedza o tym, co załatać. Stanie się nim zdolność do wdrożenia zmiany w systemie produkcyjnym: okna serwisowe, testy regresji, zgoda właściciela procesu i umowa z dostawcą utrzymania.

Data konwersji nie jest planem ochrony

Plan, który dla SAP ECC podaje wyłącznie datę konwersji do SAP S/4HANA, odpowiada na połowę pytania EBC. Druga połowa brzmi: co chroni ten system przez lata, które zostały do tej daty. Naszym zdaniem odpowiedź powinna zawierać co najmniej cztery elementy.

• Inwentarz z właścicielem. Wydania, jądra, interfejsy, własny kod i rozwiązania firm trzecich, z osobą odpowiedzialną za każdy element. EBC i UKNF zaczynają od identyfikacji zasobów, bo bez niej każda lista priorytetów jest zgadywaniem.
• Rytm łatania, który da się udowodnić. Czas od publikacji noty bezpieczeństwa SAP do wdrożenia na produkcji, mierzony co miesiąc, oraz zapis w umowie z dostawcą utrzymania, który ten czas gwarantuje. To jest dokładnie ten dowód działania, o który pyta UKNF.
• Kontrole zastępcze tam, gdzie poprawki nie będzie. Segmentacja sieci, ograniczenie interfejsów do niezbędnych, monitorowanie dzienników bezpieczeństwa SAP i regularny przegląd uprawnień.
• Przegląd kodu przed konwersją. Przejście na SAP S/4HANA przenosi własny kod ABAP razem z jego podatnościami. Kontrola bezpieczeństwa kodu może iść w tym samym przebiegu co kontrola gotowości - opisaliśmy to niedawno przy okazji centralnego ATC na SAP BTP, a o granicach samej kontroli gotowości pisaliśmy w analizie gotowości do SAP S/4HANA.

Daty konwersji nie warto przesuwać pod presją listu. Warto ją natomiast uczciwie policzyć razem z kosztem utrzymania kontroli zastępczych do dnia przełączenia. Może się okazać, że wcześniejsza konwersja jest tańsza, niż wynikało z pierwszego biznesplanu. Jeśli nie jest, plan ochrony staje się główną częścią dokumentu, nie załącznikiem.

Banki z grup nadzorowanych przez EBC składają swój plan do 31 października. Pozostała część rynku finansowego ma rekomendacje UKNF bez terminu, ale z zapowiedzią kontroli. W SNOK przygotowujemy taki plan dla krajobrazu SAP w ramach audytu NIS2 i DORA, comiesięcznej obsługi SAP Security Patch Day i konwersji do SAP S/4HANA.

Źródła

• Europejski Bank Centralny, Claudia Buch, „Addressing AI-enabled cybersecurity threats”, SSM-2026-0301, 7.07.2026 - list EBC w PDF (dostęp 21.10.2026)
• Urząd Komisji Nadzoru Finansowego, „Rekomendacje dla podmiotów rynku finansowego dotyczące wpływu modeli Frontier AI na cyberbezpieczeństwo”, strona aktualizowana 22.07.2026 - dokument UKNF w PDF (dostęp 21.10.2026)
• Google Cloud, Mandiant, M-Trends 2026, 23.03.2026 - zapowiedź raportu (dostęp 21.10.2026)
• Google Cloud, Mandiant, Casey Charrier, Jared Semrau, „Analysis of Time-to-Exploit Trends: 2021-2022”, 28.09.2023 - analiza Mandiant (dostęp 21.10.2026)
• VulnCheck, Patrick Garrity, „State of Exploitation 1H 2026”, 28.07.2026 - raport VulnCheck (dostęp 21.10.2026)
• NCSC, Ollie Whitehouse, „Preparing for a »vulnerability patch wave«”, 1.05.2026 - wpis NCSC (dostęp 21.10.2026)
• CERT-EU, „AI is changing the economics of vulnerability discovery. Defenders should adapt now”, 21.04.2026 - wpis CERT-EU (dostęp 21.10.2026)
• SAP News, utrzymanie SAP S/4HANA do 2040 roku i SAP Business Suite 7 do 2027 roku, 4.02.2020 - komunikat SAP (dostęp 21.10.2026)
• SAP News, Stefan Steinle, SAP ERP, private edition, transition option, 4.08.2025 - komunikat SAP (dostęp 4.10.2026)