W większości systemów SAP, które audytujemy, kod własny powstawał przez lata i miał jedną wspólną cechę: dało się wskazać autora. Był człowiek, który go napisał, i człowiek, który go przejrzał, zanim paczka pojechała dalej.
Ta oczywistość właśnie przestała obowiązywać. Asystenci AI weszli do narzędzi deweloperskich SAP na dobre, a wraz z nimi do systemów zaczął napływać kod, którego w klasycznym sensie nikt nie napisał. Ktoś go zamówił, ktoś zaakceptował, ktoś zwolnił transport. Napisała go maszyna.
Ten artykuł jest o tym, co z takim kodem zrobić. Bez postulatu, żeby przestać używać AI, bo to postulat nierealny i szkodliwy. Za to z konkretną architekturą kontroli: gdzie postawić bramki, które z nich muszą blokować, a które tylko ostrzegać, i kto w tym układzie podpisuje się pod wynikiem.
Co dokładnie się zmieniło
Zmiana ma trzy warstwy i każda z nich osobno byłaby do opanowania. Problem robi się z ich nałożenia.
Warstwa narzędziowa. SAP udostępnił SAP-ABAP-1, model fundamentalny wyszkolony na milionach linii kodu ABAP: obiektach standardowych, rozszerzeniach klientów, implementacjach BAdI i wzorcach ABAP Cloud. W materiałach SAP Community pada liczba ponad 250 milionów linii. Zasila on wyjaśnianie i generowanie kodu w Joule for Developers, obecnym w narzędziach deweloperskich w Eclipse i w SAP Business Application Studio. W 2026 doszło rozszerzenie ABAP dla Visual Studio Code. Do tego dochodzą asystenci ogólnego przeznaczenia, których deweloperzy używają niezależnie od tego, czy ktokolwiek to zatwierdził.
Warstwa ludzka. Skoro do napisania raportu nie trzeba już znać składni ani struktur, autorami kodu Z zostają osoby spoza zespołu deweloperskiego: konsultanci funkcjonalni, analitycy, juniorzy, użytkownicy biznesowi. Kompetencja procesowa jest tu często wyższa niż w zespole ABAP. Kompetencja bezpieczeństwa jest zerowa, i nie jest to zarzut wobec tych osób, tylko opis stanu.
Warstwa architektoniczna. Clean Core wypycha rozszerzenia z rdzenia na SAP BTP. Kierunek jest słuszny, ale skutek uboczny jest twardy: kod, który wcześniej siedział za zaporą sieciową, staje się aplikacją wystawioną w chmurze. Wniosek, który przewijał się przez wspólny webinar Deloitte i Onapsis o ryzykach kodu SAP tworzonego z AI, brzmi tu jednoznacznie: Clean Core bez przesunięcia kontroli bezpieczeństwa na początek procesu jest półśrodkiem.
Skala jest już policzona. Według badania Onapsis z czerwca 2026 na próbie 204 liderów bezpieczeństwa w firmach zatrudniających ponad tysiąc osób, 86 procent organizacji zintegrowało albo właśnie integruje AI bezpośrednio z kodem systemów ERP, a 69 procent przyznaje, że obecne zabezpieczenia nie wykryją niezawodnie ataku prowadzonego przez AI.
Siedem mechanizmów, przez które asystent psuje kod ABAP
To nie jest lista hipotez. Sześć pierwszych punktów pochodzi wprost z analizy Deloitte i Onapsis, siódmy dokładamy z własnych audytów.
1. Brak kontroli uprawnień. Model generuje poprawną logikę biznesową i pomija AUTHORITY-CHECK, bo nie ma dostępu do Waszej koncepcji uprawnień. Nie wie, jakie obiekty autoryzacyjne obowiązują w tym module, ani że dostęp do konkretnej tabeli był decyzją, a nie przypadkiem. Efekt: raport działa i pokazuje dane każdemu, kto potrafi go uruchomić.
2. Wstrzyknięcia w zapytaniach. Zapytanie zbudowane dynamicznie z wartości podanej przez użytkownika to wzorzec, który w publicznym kodzie występuje setki tysięcy razy. Model odtwarza go razem z brakiem walidacji wejścia. Dotyczy to Open SQL, ADBC i wywołań natywnych.
3. Podatności w warstwie interfejsu. Poproszenie asystenta o dodanie nagłówka do funkcji renderującej daje kod, który wygląda i działa poprawnie, ale pomija kodowanie i sanityzację danych. Tak powstaje XSS w aplikacjach UI5 i Fiori. W demonstracji pokazanej na webinarze dokładnie ten scenariusz wychwycił dopiero skaner wpięty w edytor.
4. Powielanie przestarzałych wad. Model uczył się na kodzie historycznym, wraz z praktykami z czasów, gdy nikt nie myślał o wstrzyknięciach ani o bezpośredniej manipulacji tabelami. Wzorzec, który był normą piętnaście lat temu, wraca dziś jako świeżo wygenerowany kod.
5. Halucynacje i widmowe zależności. Odwołania do obiektów, parametrów i struktur, których w Waszym systemie nie ma. Część z nich wychodzi przy aktywacji. Część przechodzi dalej i ujawnia się dopiero na ścieżce, której nikt nie przetestował.
6. Niekontrolowane operacje na danych. Agent działający bez twardych ograniczeń potrafi wygenerować operację masową na tabelach bazodanowych. Bez wymuszonej akceptacji człowieka przed wykonaniem takiej operacji nie ma mechanizmu, który by ją zatrzymał.
7. Rozjazd z rozdziałem obowiązków. To dokładamy od siebie. Kod wygenerowany „przy okazji” przez osobę spoza zespołu deweloperskiego często omija ustalony proces: powstaje w systemie deweloperskim na cudzym koncie, trafia do transportu zbiorczego i przechodzi przez akceptację, która nigdy nie była projektowana pod ten scenariusz. Macierz SoD pozostaje formalnie poprawna, a praktyka rozjeżdża się z nią bezgłośnie.
Wspólny mianownik: żaden z tych błędów nie zatrzymuje kompilacji i żaden nie oblewa testu funkcjonalnego.
Dlaczego dotychczasowe bramki tego nie łapią
Organizacje, z którymi pracujemy, zwykle mają jakąś formę kontroli kodu. Problem polega na tym, że wszystkie trzy klasyczne bramki zostały zaprojektowane pod inny rozkład ruchu.
Przegląd kodu przez człowieka zakłada, że kodu jest tyle, ile człowiek zdąży przeczytać. Apiiro policzył we wrześniu 2025, że deweloperzy korzystający z asystentów oddają kod trzy do czterech razy szybciej, a liczba znalezisk bezpieczeństwa w ich repozytoriach wzrosła w pół roku dziesięciokrotnie. Do tego dochodzi jakość: w badaniu CodeRabbit z grudnia 2025 na 470 pull requestach te współtworzone z AI miały nawet 2,74 raza więcej znalezisk bezpieczeństwa i 1,7 raza więcej problemów ogółem. Rosnący wolumen razy rosnący odsetek błędów, przy niezmienionej liczbie recenzentów, daje wynik możliwy do przewidzenia bez żadnego badania.
ATC i Code Inspector działają, ale w domyślnych wariantach sprawdzają przede wszystkim jakość i zgodność ze standardem, a nie bezpieczeństwo. Pełna analiza podatności to osobno licencjonowana funkcja, w wielu systemach nieaktywna. Do tego uruchamiana bywa na żądanie, a nie jako warunek przejścia dalej.
Testy funkcjonalne i UAT weryfikują, czy program robi to, co miał robić. Nie weryfikują, czego jeszcze przy okazji nie robi. Brak kontroli uprawnień jest niewidoczny dla testera, który ma pełne uprawnienia.
Do tego dochodzi presja czasu. Rola dewelopera przesuwa się z pisania na walidację, ale liczba etatów na walidację się nie zmienia. Wąskie gardło nie znika, tylko przesuwa się w miejsce, w którym nikt go nie mierzy.
Trzy warstwy obrony
Nasze podejście opiera się na jednej zasadzie: kontrola, której obejście nie kosztuje, nie jest kontrolą. Dlatego bramki muszą stać w miejscach, przez które kod i tak musi przejść. W systemach SAP takich miejsc jest dokładnie trzy.
Warstwa pierwsza: edytor dewelopera
Podatność wykryta w edytorze kosztuje minutę. Ta sama podatność wykryta w UAT kosztuje przesunięcie wdrożenia. Wykryta na produkcji kosztuje incydent.
SecurityBridge Code Vulnerability Analysis daje deweloperowi wynik skanu tam, gdzie pracuje: w ABAP Development Workbench i w narzędziach ABAP dla Eclipse, z natywną integracją z SAP Code Inspector i ABAP Test Cockpit. Zestaw wykrywanych klas obejmuje dokładnie to, co produkuje asystent: wstrzyknięcia SQL, Open SQL i ADBC, brak kontroli uprawnień w modułach RFC, bezpośrednią manipulację tabelami, directory traversal i backdoory.
Dwie funkcje mają tu szczególne znaczenie przy kodzie generowanym maszynowo. Explain ABAP Code tłumaczy, co dany fragment realnie robi, czego najbardziej potrzebuje osoba, która tego kodu nie napisała, a ma go zaakceptować. Describe Vulnerabilities opisuje wykrytą podatność wraz ze sposobem naprawy, zamiast zostawiać deweloperowi numer reguły do wygooglowania.
To jest odpowiednik autokorekty: pisze się dalej, tylko z podkreśleniem tam, gdzie coś jest nie tak.
Warstwa druga: transport
Tu zapada rozstrzygnięcie, bo transport to jedyne miejsce, którego w SAP nie da się ominąć.
SecurityBridge Transport Center dokłada do systemu transportów to, czego w standardzie nie ma. Skan zawartości paczki jest warunkiem wstępnym importu, więc transport z podatnością, której nikt nie naprawił, nie wjeżdża na kolejny system. Obieg akceptacji wymusza rozdział obowiązków i dokumentuje zatwierdzenie „na cztery oczy” w formie, którą da się pokazać audytorowi. Dochodzi do tego ochrona przed konfliktami wersji i wdrożeniem starszej wersji obiektu, przewidywanie brakujących zależności oraz porządkowanie list importowych przy złożonych przełączeniach produkcyjnych. Zakres funkcji potwierdzamy z producentem przed każdym wdrożeniem, bo portfolio zmienia się szybciej niż materiały informacyjne.
Ten sam mechanizm obsługuje przypadek, o którym mało kto myśli w kontekście AI: kod od dostawców zewnętrznych. Paczka od integratora albo od producenta dodatku przechodzi przez identyczną bramkę co kod własny.
Warstwa trzecia: działający system
Skan statyczny nie wykryje nadużycia kodu, który przeszedł kontrolę. Dlatego warstwę trzecią stanowi ciągła detekcja: SecurityBridge Threat Detection monitoruje zachowanie systemu w czasie rzeczywistym, a zdarzenia trafiają do Waszego SIEM: Microsoft Sentinel, Splunk, QRadar albo innego narzędzia używanego w organizacji. Interface Traffic Monitor pilnuje warstwy interfejsów, przez którą kod niestandardowy zwykle rozmawia ze światem.
Dzięki temu wykrycie próby wykorzystania podatności może automatycznie uruchomić analizę kodu, który za nią odpowiada. Pętla się domyka: to, co dzieje się na produkcji, wraca informacją do warstwy pierwszej.
Kto się podpisuje
Warstwa techniczna rozwiązuje problem wykrywania. Nie rozwiązuje problemu odpowiedzialności, a to on wraca na każdym spotkaniu zarządu.
Punktem wyjścia jest model współdzielonej odpowiedzialności, którego wciąż nie wszyscy przyjęli do wiadomości: dostawca chmury odpowiada za platformę, a za własny kod i własne rozszerzenia odpowiadacie Wy. W badaniu przywołanym na webinarze 13 procent uczestników sądziło, że po migracji do chmury odpowiedzialność za bezpieczeństwo przechodzi na SAP. Nie przechodzi. Nie przechodzi też na dostawcę modelu AI.
Cztery rzeczy, które ustawiamy u klientów po stronie ładu.
Polityka użycia asystentów w wytwarzaniu. Które narzędzia są dopuszczone, do jakich systemów, jakie dane wolno wkleić w prompt. Bez tego dokumentu każda dalsza kontrola jest uznaniowa.
Oznaczanie kodu wspieranego przez AI. Prosty atrybut przy obiekcie albo konwencja w opisie transportu. Nie po to, żeby kogokolwiek piętnować, tylko po to, żeby przegląd i późniejsza analiza incydentu miały punkt zaczepienia.
Jednoznaczne znaczenie podpisu pod transportem. Zwolnienie transportu musi znaczyć albo „przeczytałem i rozumiem kod”, albo „potwierdzam odbiór funkcjonalny”, i wszyscy muszą wiedzieć, które z tych dwóch. Dziś w większości organizacji nie wie tego nikt, łącznie z osobą podpisującą.
Twarde bramki dla operacji nieodwracalnych. Operacja masowa na danych, zmiana w obiekcie krytycznym, wdrożenie poza oknem serwisowym: to są przypadki, w których akceptacja człowieka musi być wymuszona technicznie, a nie oczekiwana proceduralnie.
Warstwa regulacyjna tylko to potwierdza. Dyrektywa NIS2 wymaga w art. 21 ust. 2 lit. e środków obejmujących bezpieczeństwo w procesie nabywania, rozwoju i utrzymania systemów, wraz z obsługą podatności. O sztucznej inteligencji przepis nie mówi ani słowa, ale kod własny powstaje właśnie w tym procesie, więc obowiązek bezpiecznego wytwarzania obejmuje go niezależnie od tego, kto trzymał klawiaturę. Udokumentowany proces skanowania i akceptacji jest najprostszym dowodem, że taki środek istnieje. Dla podmiotów finansowych analogiczne wymagania w zakresie zarządzania zmianą i testowania niesie DORA.
Jak pracujemy w SNOK
Jesteśmy partnerem SecurityBridge w Polsce i prowadzimy ten temat od strony SAP Basis i bezpieczeństwa, a nie wyłącznie od strony licencji.
Ocena stanu. Zaczynamy od skanu istniejącej bazy kodu Z i od inwentaryzacji autorów obiektów z ostatnich miesięcy. Ta druga część bywa dla klientów najbardziej pouczająca, bo pokazuje, ile kodu powstaje poza zespołem deweloperskim. Wynikiem jest lista podatności uszeregowana według ryzyka biznesowego, nie według liczby trafień.
Wdrożenie warstwy kontroli. Uruchomienie analizy kodu w narzędziach deweloperskich, wpięcie skanu w proces transportowy jako warunku importu, konfiguracja progów blokowania oraz integracja zdarzeń z SIEM. Progi trzeba wykalibrować na Waszych danych. Bramka, która blokuje wszystko, zostaje wyłączona w trzecim tygodniu.
Ład i kompetencje. Polityka użycia AI w wytwarzaniu, model akceptacji transportów, warsztat dla zespołu deweloperskiego i konsultantów funkcjonalnych o tym, co konkretnie sprawdzać w kodzie, którego się nie napisało.
Utrzymanie. Cykliczny przegląd wyników, obsługa nowych podatności, wsparcie przy audycie oraz, dla organizacji bez własnego zespołu bezpieczeństwa SAP, model dyżurnego eksperta zamiast etatu.
Plan na 30, 60 i 90 dni
Do 30 dni. Inwentaryzacja autorów obiektów Z za ostatnie półrocze. Skan istniejącej bazy kodu z raportem uszeregowanym według ryzyka. Jednozdaniowa decyzja o tym, co znaczy podpis pod transportem.
Do 60 dni. Analiza kodu dostępna w narzędziach deweloperskich. Skan jako warunek importu dla transportów na system testowy, na razie w trybie ostrzeżenia. Polityka użycia asystentów przyjęta i zakomunikowana.
Do 90 dni. Bramka blokująca dla systemu produkcyjnego, z progami skalibrowanymi na realnych danych z poprzedniego etapu. Zdarzenia z działającego systemu w SIEM. Udokumentowana akceptacja „na cztery oczy” gotowa do pokazania audytorowi.
Na koniec
Kod generowany przez AI nie jest problemem sam w sobie. Problemem jest to, że powstaje szybciej, niż organizacja potrafi go przeczytać, i że w niczym nie różni się z wyglądu od kodu, który ktoś przemyślał.
Odpowiedzią nie jest zakaz, bo zakaz w tej sprawie oznacza po prostu przeniesienie tego samego zjawiska poza zasięg wzroku. Odpowiedzią jest przesunięcie kontroli do miejsc, których nie da się ominąć: do edytora, do transportu i do działającego systemu. Wtedy podpis pod transportem znów zaczyna coś znaczyć.
Jeśli chcecie sprawdzić, jak to wygląda w Waszym systemie, odezwijcie się do nas. Zaczynamy zwykle od skanu istniejącej bazy kodu, bo to jedyna rozmowa o bezpieczeństwie, w której po tygodniu ma się na stole liczby zamiast opinii.
Kontekst i szerszy obraz zmiany w zawodzie: Kompiluje się, więc działa. ABAP w czasach, gdy kod pisze asystent, felieton Jacka Bugajskiego.
Źródła: Onapsis, State of AI, Security and ERP, badanie z czerwca 2026 na próbie 204 liderów bezpieczeństwa · CodeRabbit, State of AI vs Human Code Generation Report, 17.12.2025 (470 pull requestów; badanie dostawcy) · Apiiro, wrzesień 2025 · Veracode, GenAI Code Security Report, 2025 · dokumentacja produktowa SecurityBridge (Code Vulnerability Analysis, Transport Center, Threat Detection, Interface Traffic Monitor) · webinar Deloitte i Onapsis „The Hidden Risks of AI-Generated SAP Custom Code” · SAP i SAP Community, materiały o modelu SAP-ABAP-1 oraz Joule for Developers · dyrektywa NIS2, art. 21.
Powiązane wpisy: Kod ABAP jako nieoczywiste zagrożenie bezpieczeństwa · KSC, NIS2 i SecurityBridge · Agent AI po obu stronach ataku