Central ATC na SAP BTP - czy jeden przebieg sprawdza też bezpieczeństwo kodu ABAP?

SecurityBridge ogłosił 16 października 2026 roku, że jego moduł Code Risk Analyzer integruje się bezpośrednio z centralnym ABAP Test Cockpit (ATC) na SAP BTP. Do tej pory kontrole bezpieczeństwa SecurityBridge działały w ATC uruchamianym w systemie on-premise. Teraz mogą działać także w centralnym systemie kontroli, którego SAP używa do analizy własnego kodu klienta przed konwersją do SAP S/4HANA i do oceny gotowości na clean core.

Ta zmiana ma znaczenie praktyczne. Zespół, który prowadzi konwersję, i tak uruchamia przebieg ATC na SAP BTP, żeby sprawdzić, co w kodzie Z blokuje przejście do SAP S/4HANA. Jeśli kontrola bezpieczeństwa zostaje w osobnym narzędziu i osobnym harmonogramie, ten sam kod przechodzi bramkę jakości, a bramkę bezpieczeństwa omija albo przechodzi ją kilka tygodni później.

W skrócie:

1/ centralny ATC na SAP BTP sprawdza kod w systemach on-premise zdalnie, przez SAP Cloud Connector - to ten sam mechanizm, którego SAP używa do analizy gotowości kodu na SAP S/4HANA,

2/ kontrole SecurityBridge mogą wejść do tego samego przebiegu, więc wyniki dotyczące clean core i bezpieczeństwa trafiają do jednej listy i jednego procesu wyjątków,

3/ centralna kontrola otwiera połączenie RFC z SAP BTP do Waszych systemów, a to połączenie samo wymaga zabezpieczenia,

4/ w planie konwersji kontrolę bezpieczeństwa warto włączyć już w analizie gotowości, długo przed uruchomieniem produkcji.

Centralny ATC na SAP BTP przy konwersji do SAP S/4HANA

SAP udostępnia w SAP BTP, ABAP environment aplikacje do analizy własnego kodu klienta: Custom Code Migration do przygotowania konwersji i osobną aplikację do analizy kodu pod kątem gotowości na chmurę. Środowisko ABAP na SAP BTP pełni wtedy rolę centralnego systemu kontroli, a systemy SAP ERP i SAP S/4HANA w Waszym centrum danych są systemami sprawdzanymi. Połączenie biegnie przez SAP Cloud Connector i RFC, a w systemie sprawdzanym trzeba zainstalować tak zwane remote stubs, przez które centralny ATC odczytuje kod.

Dla zespołu konwersji to wygodne: jeden przebieg obejmuje wiele systemów, wyniki są w jednym miejscu, a wyjątki zatwierdzacie w standardowym procesie ATC. Pisaliśmy o tym, czego analiza gotowości nie pokazuje, we wpisie o granicach SAP Readiness Check, a o tym, jak konwersja zmienia powierzchnię ataku - w artykule o bezpiecznej konwersji do SAP S/4HANA.

Co dokłada SecurityBridge Code Risk Analyzer

Code Risk Analyzer to moduł platformy SecurityBridge do statycznej analizy bezpieczeństwa kodu ABAP. Na stronie produktu SecurityBridge opisuje go pod nazwą Code Vulnerability Analyzer - to ten sam moduł. Nie należy go mylić z SAP Code Vulnerability Analyzer, osobnym produktem SAP o podobnej nazwie.

Według producenta moduł wykrywa między innymi:

• wstrzyknięcia SQL w Open SQL, w dynamicznych klauzulach i w ADBC,
• brakujące kontrole uprawnień, w tym w modułach funkcyjnych dostępnych przez RFC,
• bezpośrednie zmiany w tabelach standardowych SAP,
• manipulację ścieżkami plików (directory traversal),
• konstrukcje, które mogą służyć jako tylna furtka w kodzie.

Kontrole działają w narzędziach, których deweloperzy ABAP już używają: w SAP Code Inspector, w ATC oraz w ABAP Development Tools dla Eclipse. Poniżej widok wyników SAP Code Inspector, w którym kategorie SecurityBridge stoją na jednej liście ze standardowymi kontrolami SAP.

Zgodnie z dokumentacją producenta integracja z centralnym ATC na SAP BTP korzysta z platformy SecurityBridge zainstalowanej on-premise: środowisko ABAP na SAP BTP komunikuje się z kontrolerem SecurityBridge, a ten dostarcza reguły i wyniki. Nie jest to więc samodzielny skaner w chmurze, tylko rozszerzenie istniejącej platformy na nowe miejsce kontroli.

Jeden przebieg zamiast dwóch narzędzi

Kod ABAP coraz częściej powstaje z pomocą asystentów AI. Jak opisywaliśmy we wpisie o bezpieczeństwie kodu ABAP generowanego przez AI, taki kod zwykle się kompiluje i spełnia wymagania funkcjonalne, ale łatwo pomija kontrolę uprawnień albo buduje zapytanie z danych wejściowych użytkownika. Kontrola gotowości na clean core tego nie wychwyci, bo sprawdza co innego: użycie zwolnionych interfejsów i zgodność z modelem rozszerzeń, który opisywaliśmy przy okazji clean core w SAP BTP.

Dwie bramki w dwóch narzędziach dają w praktyce dwa harmonogramy. Wyniki bezpieczeństwa trafiają do innego zespołu, w innym formacie i zwykle później. Gdy obie kontrole działają w jednym przebiegu centralnego ATC:

• jedna lista poprawek - deweloper widzi znaleziska clean core i bezpieczeństwa w tym samym widoku i poprawia obiekt raz,
• jeden proces wyjątków - odstępstwo od reguły bezpieczeństwa przechodzi przez ten sam mechanizm zatwierdzania co pozostałe wyjątki ATC i zostaje udokumentowane,
• jeden dowód dla audytu - wynik przebiegu pokazuje, że kod przed transportem przeszedł obie kontrole, co przydaje się przy audycie NIS2 i DORA.

Nowa bramka otwiera nowe połączenie

Centralna kontrola ma swoją cenę po stronie bezpieczeństwa. Żeby ATC na SAP BTP mógł odczytać kod, potrzebuje:

• połączenia RFC i użytkownika technicznego w każdym systemie sprawdzanym,
• remote stubs zainstalowanych w systemie sprawdzanym,
• listy dozwolonych zasobów w SAP Cloud Connector, czyli modułów funkcyjnych, które środowisko na SAP BTP może wywołać.

To połączenie z chmury do systemów, w których działają finanse, logistyka i kadry. Traktujemy je tak samo jak każdy uprzywilejowany kanał RFC. Lista zasobów w Cloud Connector obejmuje tylko to, czego wymaga scenariusz SAP i SecurityBridge. Użytkownik techniczny ma uprawnienia wyłącznie do odczytu kodu. Wywołania monitorujemy tak, jak pozostałe połączenia RFC. Jeśli platforma SecurityBridge już monitoruje Wasze systemy, ten kanał powinien znaleźć się w zakresie monitoringu od pierwszego dnia działania integracji.

Gdzie kontrola bezpieczeństwa wchodzi w plan konwersji

W projektach konwersji do SAP S/4HANA włączamy kontrolę bezpieczeństwa kodu w czterech miejscach:

1. W analizie gotowości. Pierwszy przebieg centralnego ATC obejmuje od razu kontrole bezpieczeństwa. Dzięki temu zakres poprawek kodu jest znany w całości, zanim powstanie harmonogram i budżet prac.
2. W porządkowaniu kodu. Obiekty z krytycznymi znaleziskami bezpieczeństwa poprawiamy razem z obiektami, które blokują konwersję. Kod, którego nikt nie używa, usuwamy, zamiast go naprawiać.
3. W zasadach wyjątków. Wyjątek od reguły bezpieczeństwa zatwierdza osoba odpowiedzialna za bezpieczeństwo SAP, a nie lider zespołu deweloperskiego, który zgłasza wyjątek.
4. Po uruchomieniu produkcji. Ten sam wariant kontroli zostaje jako bramka przed transportem, więc nowy kod, także pisany z pomocą AI, przechodzi obie kontrole przy każdej zmianie.

Jeśli planujecie konwersję albo już ją prowadzicie, zacznijmy od przeglądu Waszego kodu ABAP: w ramach usługi SAP Code Vulnerability Analyzer i custom code review sprawdzamy kod Z pod kątem podatności i przygotowujemy plan poprawek uporządkowany według krytyczności. Szerzej o tym, jak prowadzimy konwersję do SAP S/4HANA i jak wdrażamy platformę SecurityBridge, piszemy na stronach oferty.

Źródła

• SecurityBridge, „Product Update: SecurityBridge Code Risk Analyzer Now Integrates with Central ATC on SAP BTP”, LinkedIn, 16.10.2026 - post SecurityBridge (dostęp 19.10.2026)
• SecurityBridge, Code Vulnerability Analysis - strona produktu (dostęp 19.10.2026)
• SAP Help Portal, Custom Code Migration w SAP BTP, ABAP environment - dokumentacja SAP (dostęp 19.10.2026)