Kiedy zespół bezpieczeństwa patrzy na krajobraz SAP, widzi listę systemów. SAPMAP patrzy na to samo i widzi drogę. To publicznie dostępne, otwarte narzędzie na licencji GPL robi dla SAP dokładnie to, co jego autorzy sami deklarują w opisie - „jak BloodHound dla Active Directory, tylko dla SAP”: nie wylicza pojedynczych podatności, tylko rysuje ścieżkę - od jednego wystawionego systemu, przez połączenia zaufania, aż do miejsca, w którym stoją Wasze pieniądze.
Autorstwo narzędzia SecurityBridge, z którym SNOK współpracuje, przypisuje swojemu dyrektorowi badań bezpieczeństwa, Jorisowi van de Vis. Kod jest dziś otwarty i dostępny dla każdego. To zmienia nie tyle technikę, ile symetrię: mapę, którą do tej pory rysował ekspert w autoryzowanym teście, ma teraz również ten, kto autoryzacji nie ma.
W skrócie:
1/ SAPMAP odkrywa systemy SAP w sieci, mapuje połączenia RFC (techniczne kanały, którymi systemy SAP rozmawiają ze sobą i przekazują sobie zaufanie) i relacje zaufania, a następnie renderuje interaktywny graf - od pierwszego wejścia do pełnej kontroli nad procesem biznesowym,
2/ narzędzie zawiera realne, działające exploity znanych podatności SAP, w tym CVE-2025-31324, i obejmuje zarówno systemy lokalne, jak i SAP BTP,
3/ modeluje scenariusze wpływu na biznes - od wycieku danych klientów, przez listę płac, po łańcuch dostaw - czyli pokazuje nie „który system padł”, tylko „co realnie tracicie”,
4/ dostęp jest otwarty, ale użycie wyłącznie za pisemną zgodą właściciela systemu - poza autoryzowanym testem jest nielegalne.
Czym jest BloodHound i dlaczego to porównanie ma znaczenie
Krótkie wyjaśnienie, bo nie każdy pracuje w cyberbezpieczeństwie na co dzień. BloodHound to narzędzie, które od lat jest standardem w pracy zespołów ofensywnych. W sieci opartej na Windowsie i Active Directory pokazuje najkrótszą drogę od zwykłego konta pracownika do konta administratora całej domeny - nie jako listę błędów, tylko jako graf połączeń. Zmieniło sposób, w jaki firmy patrzą na własną sieć: przestały pytać „które konto ma za dużo uprawnień”, a zaczęły pytać „którędy ktoś przejdzie od dowolnego pracownika do pełnej kontroli”. SAPMAP przenosi dokładnie tę ideę do świata SAP.
Dlaczego to moment BloodHound, a nie kolejny skaner
Skanery bezpieczeństwa SAP istnieją od lat i robią rzecz cenną: mówią, że system X ma otwarty gateway, a rola Y ma za szerokie uprawnienia. Odpowiadają na pytanie „co jest nie tak”. Nie odpowiadają na pytanie, które zadaje sobie napastnik: „którędy stąd dojdę do celu”.
Krajobraz SAP to nie zbiór osobnych systemów, tylko sieć zaufania. Połączenia RFC, konta techniczne o wysokich uprawnieniach, integracje między produkcją a rozwojem, mosty do chmury - każde z nich jest krawędzią w grafie. Atakujący nie potrzebuje włamać się wszędzie. Potrzebuje jednego wejścia i drogi, która stamtąd prowadzi. SAPMAP tę drogę rysuje, a scenariusze biznesowe pokazują, co czeka na jej końcu. Nie „system produkcyjny został skompromitowany”, tylko „przelew do dostawcy trafił na inny rachunek”.
To jest różnica między raportem, który zarząd odkłada, a raportem, który zarząd czyta do końca.
Pisaliśmy niedawno, że agent AI potrafi stanąć po obu stronach ataku i że najgroźniejsze bywa martwe pole, którego nikt nie monitoruje. SAPMAP jest tego samego rzędu: nie dokłada nowej podatności, tylko czyni widoczną drogę, która była tam od zawsze.
Co to znaczy dla obrony
Jest prosta zasada, którą powtarzamy klientom: kontroli nie mierzy się tym, że narzędzia atakującego są trudno dostępne. Mierzy się tym, czy przeszliście tę samą ścieżkę pierwsi. Skoro mapa jest publiczna, jedyna sensowna odpowiedź to zejść z poziomu „które systemy mają luki” na poziom „którędy biegnie najkrótsza droga do naszych pieniędzy - i czy ją widzimy, gdy ktoś nią idzie”.
W SNOK robimy to jako autoryzowany SAP attack-path assessment, spinając trzy warstwy.
Mapowanie ścieżki. Tę samą klasę narzędzi, którą teraz ma napastnik, uruchamiamy w kontrolowanym labie, na Waszym krajobrazie, w reżimie autoryzowanego testu. Efektem nie jest lista podatności, tylko graf: skąd, którędy, dokąd i co jest na końcu.
Detekcja. SAPMAP wizualizuje ścieżkę, a SecurityBridge - platforma, z którą pracujemy - tę ścieżkę widzi w czasie rzeczywistym i alarmuje. Mapa bez czujnika mówi, gdzie jest ryzyko. Czujnik bez mapy mówi, że coś się dzieje, ale nie wie, dokąd to prowadzi. Dopiero razem dają obraz, który da się obronić przed audytorem.
Red team z lokalnymi modelami AI. Fazę ofensywną prowadzimy na stacjach z nieograniczonymi, lokalnymi modelami AI, uruchomionymi w izolowanym środowisku. Ma to dwie konsekwencje, które w tego typu pracy są nienegocjowalne. Po pierwsze, dane z Waszego SAP nie opuszczają labu - nie trafiają do żadnego zewnętrznego API, bo model działa na miejscu. Po drugie, modele komercyjne odmawiają współpracy przy analizie działających exploitów, a analiza exploitu to sedno pracy red teamu; model lokalny bez tych ograniczeń pozwala tę pracę wykonać, nie wynosząc niczego na zewnątrz. Całość idzie pod umową o poufności i w ramach naszego systemu zarządzania bezpieczeństwem informacji zgodnego z ISO 27001.
Co konkretnie robimy dla bezpieczeństwa SAP
Attack-path assessment to jeden element. Bezpieczeństwo SAP układamy u Was w dwie ręce, które muszą pracować razem: rękę ofensywną, która szuka drogi, i rękę obronną, która tę drogę zamyka i pilnuje.
Po stronie ofensywnej:
1/ attack-path assessment - mapowanie ścieżek eskalacji w całym krajobrazie SAP, od wystawionego systemu do procesu biznesowego,
2/ pentesty SAP - testy penetracyjne systemów, interfejsów RFC, bram i integracji, zakończone dowodem możliwości, nie samą listą podatności,
3/ red team - symulacja realnego napastnika na Waszym krajobrazie, z fazą ofensywną na lokalnych modelach AI, których dane nie opuszczają labu.
Po stronie obronnej:
4/ utwardzanie konfiguracji i ról - domknięcie tego, co assessment odsłonił: bramy, konta techniczne, uprawnienia, granice zaufania między systemami,
5/ monitoring i detekcja z SecurityBridge - stały nadzór nad tym, co dzieje się w SAP w czasie rzeczywistym, z alarmem na ruch po ścieżce ataku,
6/ zarządzanie łatkami i SAP Security Patch Day - od oceny nowych not po wdrożenie, żeby okno między publikacją a naprawą było jak najkrótsze,
7/ bezpieczna konwersja do SAP S/4HANA i RISE - pilnowanie powierzchni ataku w trakcie migracji, gdy krajobraz jest najbardziej odsłonięty,
8/ audyt i zgodność - przygotowanie do wymagań NIS2, DORA oraz normy ISO 27001, z dowodami wytworzonymi zanim padnie pytanie audytora, nie po nim.
Jedno pytanie na ten tydzień
Nie „czy mamy luki w SAP”, bo je macie, wszyscy je mają. Pytanie brzmi: gdyby ktoś pobrał dziś publiczną mapę i wskazał palcem najkrótszą drogę od Waszego najbardziej wystawionego systemu do listy płac - potrafilibyście narysować tę samą drogę wcześniej i zobaczyć ją, gdy ktoś nią idzie? Jeśli odpowiedź nie jest pewna, to jest dokładnie ta rozmowa, którą warto odbyć, zanim odbędzie ją za Was ktoś inny.
Napiszcie do nas - pokażemy, jak wygląda attack-path assessment na realnym krajobrazie SAP.
Źródła
- SAPMAP, repozytorium SecuritySilverbacks/SAPMAP, licencja GPL-3.0 (dostęp 21.09.2026).
- SecurityBridge, materiały prasowe o SAPMAP oraz relacje branżowe (securitybrief.com.au, itbrief), lipiec 2026.