Bezpieczeństwo AI wymaga drugiej opinii

AI tworzy oprogramowanie szybciej, niż jesteśmy w stanie je zabezpieczać. Czy nadążasz?

Zanim skończysz czytać to zdanie, programiści i ich agenci AI zdążą przesłać kilka tysięcy zmian w kodzie. O tej samej porze w zeszłym roku byłoby ich około 150.

W ciągu ostatniego roku tempo tworzenia oprogramowania generowanego przez AI wzrosło do zdumiewającego poziomu. GitHub odnotował 7,38 miliarda zmian w kodzie we wrześniu 2026 roku, czyli ponad pięć razy więcej niż rok wcześniej. Konsekwencje tego gwałtownego wzrostu dla bezpieczeństwa są ogromne. Każda z tych zmian to kod, który ktoś powinien rozumieć, utrzymywać i zabezpieczać. Cloud Security Alliance ustaliło, że programiści wspierani przez AI w firmach z listy Fortune 50 wprowadzają zmiany w kodzie w tempie od trzech do czterech razy wyższym niż ich odpowiednicy, a liczba wykrywanych u nich co miesiąc problemów z bezpieczeństwem wzrosła mniej więcej dziesięciokrotnie.

Zastanówmy się teraz, kto musi poradzić sobie z tym wzrostem. Zespół CISO jest tak samo liczny jak rok temu, ale zaległości już nie. Zgłoszeń podatności przybywa, liczba poprawek wdrażanych co miesiąc spada, a nierozwiązanych krytycznych problemów jest coraz więcej. Nic dziwnego, że Gartner twierdzi, iż wypalenie zawodowe CISO staje się krytycznym ryzykiem operacyjnym.

Pokusa sięgnięcia po najnowszy model

Gdy liczba jest tak duża, odruchowo chcemy ją jeszcze zwiększyć: znaleźć więcej problemów, objąć analizą większą część kodu, uruchamiać więcej skanów. To jednak jak czerpanie wody z tonącej łodzi i proszenie o większe wiadro, choć tak naprawdę trzeba znaleźć przeciek. Skuteczności programu bezpieczeństwa nie mierzy się tym, ile problemów wykrywa. Liczy się to, jaka część wykrytych problemów jest rzeczywista i ile spośród najpoważniejszych zostaje faktycznie naprawionych.

Zaawansowane modele AI świetnie radzą sobie z wykrywaniem nowych sposobów wykorzystania luk i nieznanych wcześniej podatności dzięki wnioskowaniu probabilistycznemu. Wyniki są jednak zmienne. Zgodnie z badaniem Checkmarx, gdy ten sam kod poddamy temu samemu skanowaniu pięć razy, wyniki będą zgodne tylko w około jednej trzeciej przypadków.

Właśnie dlatego analiza oparta na regułach wciąż ma znaczenie. Jest mniej elastyczna niż zaawansowane modele AI, ale za każdym razem stosuje sprawdzoną logikę w ten sam sposób, dzięki czemu zespoły mogą ufać wynikom i je weryfikować. AI wykrywa to, co umyka regułom, na przykład znane słabości występujące w nieznanej postaci albo wady, które można wykorzystać dopiero wtedy, gdy poszczególne części kodu wchodzą ze sobą w interakcję. Połączenie AI i analizy opartej na regułach pozwala wykryć więcej istotnych problemów i ograniczyć liczbę fałszywych alarmów.

To nie jest argument przeciwko AI. To argument za tym, że bezpieczeństwo wymaga drugiej opinii. Niezależnie od wybranego narzędzia, warto zadać mu trzy pytania.

Pytanie pierwsze: wiarygodność

Gdy skaner zgłasza problem, czy warto poświęcić mu czas?

Wiarygodność oznacza zaufanie. Nieprawdziwe zgłoszenie kosztuje programistę całe popołudnie, a zespół ds. bezpieczeństwa — część zaufania. Przy dużej skali to fałszywe alarmy sprawiają, że zespoły przestają słuchać. Alerty stają się po prostu „alarmami bez powodu” i znikają w tle.

Właśnie tu liczy się powtarzalność. Analiza deterministyczna za każdym razem zwraca tę samą odpowiedź dla tego samego kodu, co buduje zaufanie i pozwala poddawać wyniki audytowi.

Pytanie drugie: dokładność

Czy wykrywasz pełny zestaw najważniejszych problemów?

Wiarygodność mówi, czy warto poświęcić czas na zgłoszony problem, ale nie informuje, co umknęło skanerowi. Wykorzystujemy stosowaną w praktyce miarę, która wywodzi się z nauki o danych — wynik F1. Wynik F1 ocenia skuteczność w skali od 1 do 0, uwzględniając dwa czynniki:

• Precyzja: odsetek zgłoszonych problemów, które są rzeczywiste. Wysoka precyzja oznacza mniej fałszywych alarmów.
• Kompletność: odsetek rzeczywistych podatności, które skaner faktycznie wykrywa. Wysoka kompletność oznacza, że niewiele problemów umyka.

Skaner może sprawiać wrażenie precyzyjnego, jeśli zgłasza niemal nic, albo dokładnego, jeśli zgłasza wszystko — w obu przypadkach wynik F1 będzie niski. Średnia w branży wynosi około 0,20. Intensywnie pracujemy nad tym wyzwaniem i osiągnęliśmy wyniki, które oznaczają dokładność od trzech do czterech razy większą niż w przypadku standardowego skanera.

Większa dokładność ułatwia programistom wszystkie dalsze etapy pracy. Zespół poświęca mniej czasu na weryfikację, a więcej na naprawianie problemów.

Pytanie trzecie: zwrot z inwestycji

Jak najlepiej wykorzystać inwestycje i zasoby?

To pytanie najczęściej pomija się podczas pilotażu, a odpowiedź na nie najbardziej daje się we znaki w środowisku produkcyjnym.

Za korzystanie z zaawansowanych modeli płaci się za tokeny, a zużywa się je niezależnie od tego, czy skanowanie wykryje jakiekolwiek problemy. Skanowanie repozytorium zawierającego milion wierszy kodu kosztuje według obecnie publikowanych cenników ponad tysiąc dolarów. Różnice w zużyciu tokenów przez poszczególne modele są duże; cena się różni w zależności od wybranego modelu i ilości analizowania potrzebnej do wykonania zadania.

Pomnóż te koszty przez każdą zmianę w kodzie, każde żądanie ściągnięcia i każde repozytorium w przedsiębiorstwie. Uber, który wydaje 3,4 miliarda dolarów rocznie na badania i rozwój, podobno wyczerpał cały budżet na AI na 2026 rok w ciągu kilku miesięcy od wdrożenia narzędzi AI do programowania.

Nazywamy to podatkiem od tokenów. To jak jazda Ferrari po zakupy: płacisz za moc, której ta podróż nie wymaga. Twardo zakodowane dane uwierzytelniające i wstrzyknięcia SQL to przewidywalne wzorce, które analiza deterministyczna niezawodnie wykrywa.

Bezpieczeństwo aplikacji musi ewoluować

Takie uzasadnienie stoi za architekturą Checkmarx Fusion. Silniki oparte na regułach pozwalają w sposób powtarzalny ustalić prawdę referencyjną i robią to mniejszym kosztem niż analiza oparta na tokenach. Najnowocześniejsze modele koncentrują się na tym, czego reguły nie są w stanie przewidzieć: nowych wzorcach, złożonej logice i możliwości wykorzystania podatności w danym kontekście. Następnie warstwa analizy ustaleń łączy wyniki w jeden wiarygodny zbiór.

Podejście deterministyczne daje pewność. AI zwiększa zasięg. Zakres wykrywania i zaufanie rosną równocześnie. W porównaniu z samodzielnie działającym LLM osiągamy nawet czterokrotnie większą wierność, od dwóch do czterech razy większą dokładność i koszt wynoszący mniej więcej jedną trzecią.

Wykrywanie problemów to dopiero początek. Ta sama zasada dotyczy zapobiegania. Rozważmy przykład. Umożliwiając programistom działanie już na etapie tworzenia kodu, w środowisku IDE, w którym go piszą, możemy zapobiec problemom, zanim się pojawią. A skoro niektóre podatności mimo wszystko przechodzą przez zabezpieczenia, dlaczego nie dostarczać programistom poprawek gotowych do scalenia, dotyczących tych najważniejszych? Właśnie nad rozwiązaniem tych wyzwań pracujemy, dążąc do stopniowego zmniejszania istniejących zaległości i uzyskania jak najszybszych efektów przy jak najmniejszym wysiłku.

Kod już działa. Czy nadążasz?

AI podarowała atakującym szybkość. Sposobem na zniwelowanie tej luki nie jest kolejne narzędzie. Chodzi o decyzję, jak cała organizacja tworzy i zabezpiecza oprogramowanie. Kod pisany dzisiaj będzie napędzać działalność firmy przez lata. Pytanie, które powinni sobie zadawać liderzy odpowiedzialni za bezpieczeństwo, nie brzmi już: o ile szybciej AI pomaga tworzyć oprogramowanie. Chodzi o to, czy wasze programy nadążą za tym, co AI tworzy.

Nie daj się więc zwieść liczbom. Zadaj każdemu programowi trzy pytania: Czy mogę ufać temu, co wykrywa? Czy wykrywa wystarczająco dużo tego, co istotne? Czy da się go realnie wdrożyć w całej mojej organizacji? Połączenie deterministycznej precyzji z możliwościami wnioskowania najnowocześniejszych modeli daje największą szansę na trzy odpowiedzi twierdzące.

Tempo rozwoju oprogramowania nie słabnie. Naszym zadaniem jest teraz zmniejszenie luki w zakresie ryzyka: różnicy między tempem tworzenia oprogramowania a tempem wykrywania i usuwania zagrożeń.