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

> SecurityBridge Code Risk Analyzer w centralnym ATC na SAP BTP: kontrola bezpieczeństwa kodu ABAP w tym samym przebiegu co gotowość do SAP S/4HANA i clean core.

- Source: https://snok.ai/pl/aktualnosci/blog/central-atc-sap-btp-bezpieczenstwo-kodu-abap/
- Author: Jarosław Zdanowski
- Published: 2026-10-20

---
**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.

![Animacja: zmiana w kodzie przechodzi standardowy przebieg ATC i trafia na produkcję, a w centralnym ATC z kontrolami SecurityBridge jeden wiersz zostaje oznaczony jako brak kontroli uprawnień i transport zatrzymuje się przed systemem QAS](https://snok.ai/images/blog/central-atc-sap-btp-bezpieczenstwo-kodu-abap-anim.gif)

## 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](https://snok.ai/pl/aktualnosci/blog/analiza-gotowosci-s4hana-readiness-check/), a o tym, jak konwersja zmienia powierzchnię ataku - w artykule o [bezpiecznej konwersji do SAP S/4HANA](https://snok.ai/pl/aktualnosci/blog/bezpieczna-konwersja-sap-s4hana-rise/).

## 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.

![Widok wyników SAP Code Inspector z kategoriami kontroli SecurityBridge, takimi jak wstrzyknięcie SQL, wykonanie poleceń systemu operacyjnego, kontrola uprawnień i manipulacja tabelami standardowymi. Źródło: SecurityBridge](https://snok.ai/images/blog/central-atc-sap-btp-securitybridge-code-inspector.webp)

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.

![Podsumowanie skanu kodu ABAP w SecurityBridge: liczba przeskanowanych wierszy i obiektów oraz liczba znalezisk o wysokiej ważności. Źródło: SecurityBridge](https://snok.ai/images/blog/central-atc-sap-btp-securitybridge-scan-summary.webp)

## 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](https://snok.ai/pl/aktualnosci/blog/bezpieczenstwo-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](https://snok.ai/pl/aktualnosci/blog/technologiczny-czwartek-ze-snok-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.

![Diagram: systemy SAP on-premise połączone przez SAP Cloud Connector z centralnym ATC na SAP BTP, w którym jeden przebieg sprawdza kod pod kątem clean core i bezpieczeństwa z kontrolami SecurityBridge](https://snok.ai/images/blog/central-atc-sap-btp-bezpieczenstwo-kodu-abap-diagram.webp)

## 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](https://snok.ai/pl/oferta/bezpieczenstwo-sap/sap-code-vulnerability/) 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](https://snok.ai/pl/oferta/bezpieczenstwo-sap/konwersja-s4hana/) i jak wdrażamy [platformę SecurityBridge](https://snok.ai/pl/oferta/bezpieczenstwo-sap/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](https://www.linkedin.com/posts/securitybridge_securitybridge-cra-central-atc-carousel-5-activity-7516777626431225856-G5JK) (dostęp 19.10.2026)
- SecurityBridge, Code Vulnerability Analysis - [strona produktu](https://securitybridge.com/products/code-vulnerability-analysis/) (dostęp 19.10.2026)
- SAP Help Portal, Custom Code Migration w SAP BTP, ABAP environment - [dokumentacja SAP](https://help.sap.com/docs/sap-btp-abap-environment/abap-environment/custom-code-migration) (dostęp 19.10.2026)