Przez trzydzieści lat ABAP bronił się sam. Nie składnią, bo ta akurat wybacza wiele. Bronił się progiem wejścia.
Żeby napisać cokolwiek sensownego w systemie SAP, trzeba było najpierw zrozumieć słownik danych, koncepcję uprawnień, obiekty autoryzacyjne, logikę modułu, w którym się grzebie, i cały rytuał transportów przez trzy systemy. Ta wiedza nie leżała w dokumentacji. Leżała w głowach ludzi, którzy przeszli przez kilka wdrożeń i kilka nieudanych go-live. Przekazywało się ją przy biurku, nie z kursu.
I właśnie ten próg zniknął. Nie stopniowo, przez dekadę. W kilkanaście miesięcy.
Co się zmieniło pod maską
SAP udostępnił model wyszkolony wyłącznie na ABAP-ie. SAP-ABAP-1 uczył się 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 wyjaśnianie i generowanie kodu w Joule for Developers, wbudowanym w narzędzia deweloperskie w Eclipse i w SAP Business Application Studio. W 2026 doszło rozszerzenie ABAP dla Visual Studio Code, czyli dla edytora, w którym siedzi dziś połowa świata programistów spoza SAP.
Zwróćcie uwagę na kierunek tej zmiany. To nie jest tylko historia o szybszym narzędziu dla ABAPera. Żeby napisać w SAP coś, co się kompiluje i przechodzi test funkcjonalny, nie trzeba już być ABAPerem.
Raport napisze dziś konsultant funkcjonalny, który od piętnastu lat konfiguruje MM i nigdy wcześniej nie napisał ani linijki. Napisze go analityk z zespołu danych. Napisze go junior po trzech tygodniach w projekcie. Napisze go osoba z biznesu, która zna proces lepiej niż ktokolwiek w IT. Nie mam z tym najmniejszego problemu. Uważam nawet, że to dobra wiadomość, bo najlepsze rozszerzenia zawsze powstawały blisko procesu, a nie blisko kompilatora.
Problem jest gdzie indziej. Próg wejścia zniknął szybciej niż bramki, które sprawdzają, co przez ten próg przechodzi.
Kompilacja nigdy nie była testem bezpieczeństwa
Kod, który wychodzi z asystenta, ma jedną cechę, która usypia czujność najskuteczniej ze wszystkich: on działa. Kompiluje się za pierwszym razem, przechodzi test funkcjonalny, robi dokładnie to, o co poprosiliście. Odbiór przez biznes wypada świetnie.
Tyle że kompilator w SAP nigdy nie sprawdzał tego, co w tym systemie naprawdę groźne.
Nie sprawdzał, czy przed odczytem danych kadrowych stoi AUTHORITY-CHECK. Nie sprawdzał, czy zapytanie zbudowane dynamicznie z wartości podanej przez użytkownika da się rozmontować wstrzyknięciem. Nie sprawdzał, czy moduł RFC, który właśnie udostępniliście, weryfikuje uprawnienia wywołującego. Nie sprawdzał, czy zapis idzie przez logikę aplikacji, czy prosto do tabeli, z pominięciem wszystkiego, co ktoś kiedyś zaprojektował. I na pewno nie sprawdzał, czy pole, które wyświetlacie w interfejsie, jest kodowane, zanim trafi do przeglądarki.
Model tych rzeczy nie pominął złośliwie. On ich po prostu nie wie. Nie zna Waszej koncepcji uprawnień, bo jej nigdzie nie widział. Nie zna Waszej macierzy rozdziału obowiązków. Nie wie, że akurat w tej spółce dostęp do tabeli płacowej ma osiem osób i że to była decyzja zarządu, a nie przypadek. Widzi wzorzec z milionów linii cudzego kodu i odtwarza go z pełnym przekonaniem.
Wraz z tym wzorcem odtwarza też jego wady. Model uczył się na kodzie historycznym, razem z praktykami z czasów, gdy nikt nie myślał o wstrzyknięciach. Bywa też, że wymyśla obiekty, których nie ma, i parametry, których nigdy nie było. Kod wygląda wtedy dokładnie tak samo jak dobry. To jest właśnie ta część, która niepokoi mnie najbardziej: różnicy nie widać z zewnątrz.
Liczby, które warto mieć w głowie
CodeRabbit przejrzał w grudniu 2025 470 pull requestów z projektów otwartych: 320 współtworzonych z AI i 150 pisanych wyłącznie przez ludzi. Te pierwsze miały nawet 2,74 raza więcej znalezisk bezpieczeństwa i 1,7 raza więcej problemów w ogóle: logiki, wydajności, utrzymywalności. To badanie dostawcy narzędzia do przeglądu kodu, na projektach otwartych, więc traktujcie je jak wskazówkę, nie jak wyrok.
Kierunek potwierdzają jednak inni. Veracode przebadał ponad 100 modeli na 80 zadaniach programistycznych: kod z podatnością wychodził w 45 procentach przypadków, a w Javie w 72. Apiiro policzył w firmowych repozytoriach coś jeszcze wymowniejszego: deweloperzy z asystentem oddają kod trzy do czterech razy szybciej, a liczba znalezisk bezpieczeństwa w tych repozytoriach wzrosła w pół roku dziesięciokrotnie.
Tu leży sedno. Asystent nie pisze gorzej od człowieka. Pisze znacznie więcej, a liczba osób, które ten kod czytają, nie zmieniła się o jedną.
Onapsis, pytając w czerwcu ponad dwustu liderów bezpieczeństwa, usłyszał z kolei, że 86 procent firm wpuszcza albo właśnie wpuszcza AI bezpośrednio w kod systemów ERP, i jednocześnie 69 procent przyznaje, że ich obecne zabezpieczenia nie wykryją niezawodnie ataku prowadzonego przez AI.
Na koniec liczba, która robi z tego temat operacyjny, a nie akademicki. Onapsis w badaniach nad atakami na systemy SAP mierzył, ile czasu mija od wystawienia niezabezpieczonej aplikacji SAP w chmurze do jej wykrycia i zaatakowania. Poniżej trzech godzin.
Clean Core podniósł stawkę
Tu dochodzimy do rzeczy, która w tej układance często umyka.
Przez lata kod Z siedział wewnątrz Waszych czterech ścian. Napisany byle jak, ale za zaporą sieciową, w systemie, do którego dostęp miało kilkadziesiąt osób. Podatność w takim raporcie była realna, tylko trudno osiągalna.
Clean Core zmienił geografię. Rozszerzenia wychodzą z rdzenia na BTP i stają się aplikacjami w chmurze. To jest słuszny kierunek architektoniczny i sam go klientom rekomenduję. Ale jego skutkiem ubocznym jest to, że ten sam kod, napisany z tą samą starannością, wisi teraz w internecie. Ten sam wniosek przewijał się przez wspólny webinar Deloitte i Onapsis o ryzykach kodu SAP tworzonego z AI: Clean Core bez przesunięcia kontroli bezpieczeństwa na początek procesu jest półśrodkiem.
Zestawcie to z trzema godzinami z akapitu wyżej.
Kto się podpisze
I tak dochodzimy do jedynego pytania, które naprawdę mnie w tej sprawie interesuje.
W SAP mamy coś, czego nie ma większość świata IT: fizyczny, imienny moment odpowiedzialności. Ktoś zwalnia transport. Ktoś inny importuje go na produkcję. Oba nazwiska zostają w logu i nie da się ich z tego logu wyjąć. Ten mechanizm powstał w czasach, gdy zwolnienie transportu znaczyło: przeczytałem, rozumiem, biorę to na siebie.
Dziś coraz częściej znaczy: zaakceptowałem propozycję, której nie przeczytałem, bo było jej za dużo i wyglądała rozsądnie.
Podpis się nie zmienił. Zmieniło się jego pokrycie.
Rola ABAPera przesuwa się przy tym z pisania na walidację i to jest zmiana zdrowa. Kłopot w tym, że gdy zespoły oddawały pisanie maszynie, nikt nie dołożył im etatów na czytanie. Wąskie gardło się nie rozpuściło, tylko przesunęło o jeden krok w prawo, tam, gdzie akurat nikt nie patrzy. A pod presją terminu odpuszcza się zawsze to, czego brak nie boli od razu. Bezpieczeństwo jest w tej konkurencji bez szans, bo jego brak zaczyna boleć średnio kilka miesięcy później.
Karanie kogokolwiek za to niczego nie zmieni. Zmieni to dopiero sytuacja, w której podpisujący wie, co podpisuje.
Da się to opanować
Piszę o tym spokojnie, bo znam drugą stronę tej historii. Skan kodu wpięty w transport zatrzymuje paczkę z brakiem kontroli uprawnień albo ze wstrzyknięciem, zanim ta ruszy na kolejny system. Deweloper widzi podatność w edytorze, w tej samej minucie, w której powstała, a nie na trzy dni przed wdrożeniem.
W SNOK opieramy to na SecurityBridge. Obserwuję ten produkt praktycznie od początku istnienia firmy i to jeden z niewielu przypadków, gdy narzędzie bezpieczeństwa dla SAP rośnie razem z platformą, zamiast dreptać rok za nią. Dobre oprogramowanie, robione przez ludzi, którzy rozumieją SAP od środka. Jak to poukładać warstwa po warstwie, opisaliśmy osobno.
Trzy rzeczy na poniedziałek
Nie mam dla Was manifestu, mam trzy rzeczy do zrobienia od razu.
Sprawdźcie, kto dziś pisze u Was kod w SAP. Nie w strukturze organizacyjnej, tylko w systemie. Lista autorów obiektów Z za ostatnie półrocze potrafi być zaskakująca i to jest najtańsza diagnoza, jaką znam.
Wpiszcie skan bezpieczeństwa w transport, nie w kalendarz. Kontrola, która odbywa się „raz na kwartał”, w praktyce nie odbywa się wcale. Kontrola, bez której paczka nie wjedzie na kolejny system, odbywa się zawsze.
Ustalcie, co znaczy Wasz podpis pod transportem. Jedno zdanie w polityce, po którym każdy zwalniający wie, czy potwierdza przeczytanie kodu, czy tylko odbiór funkcjonalny. Dziś w większości firm nie wie tego nikt, łącznie z tym, kto podpisuje.
Bo asystent nie stanie przed audytorem. Nie odbierze telefonu w niedzielę, gdy okaże się, że raport, który miał pokazywać stany magazynowe, przy okazji czytał całą tabelę kadrową bez jednej kontroli uprawnień.
Odbierzecie go Wy.
Pobierzcie felieton w PDF
Felieton Jacka Bugajskiego · sierpień 2026
Kompiluje się, więc działa
PDF, 11 stron, ok. 6,5 MB - wersja do czytania offline, bez formularza i bez podawania danych. Możecie ją swobodnie przekazać dalej w zespole.
Pobierz felieton (PDF)Jak to zabezpieczyć warstwowo, gdzie postawić bramki i jak wygląda to w praktyce z SecurityBridge, opisaliśmy szczegółowo w osobnym artykule: Kod, którego nikt nie napisał. Jak zabezpieczyć ABAP w epoce asystentów AI.
Źródła: CodeRabbit, State of AI vs Human Code Generation Report, 17.12.2025 (470 pull requestów; badanie dostawcy) · Veracode, GenAI Code Security Report, 2025 · Apiiro, wrzesień 2025 · Onapsis, State of AI, Security and ERP, badanie z czerwca 2026 na próbie 204 liderów bezpieczeństwa · Onapsis Threat Research, badania nad atakami na aplikacje SAP · 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.
Warto przeczytać u nas także: Kod ABAP jako nieoczywiste zagrożenie bezpieczeństwa · Trzy akty SAP AI i pytanie, którego nie było na slajdach · Testowanie SAP i problem zaufania do release