Bezpieczeństwo kodu z AI w 2026 — liczby, tryby awarii i obrona
Kod generowany przez AI nie jest domyślnie bezpieczny: około 44% zadań generowania wprowadza podatność, a skuteczność modeli w pisaniu bezpiecznego kodu stoi w miejscu, choć adopcja eksplodowała. Bezpieczne użycie to bramki przeglądu, skanowanie, minimalne uprawnienia i testy — nie zaufanie.
Liczby z 2026 roku, ze źródłami
Ilość kodu pisanego przez AI eksplodowała; jego bezpieczeństwo nie poprawiło się w tym samym tempie. Poniższe liczby pochodzą z niezależnych badań i telemetrii dostawców z 2026 roku — i zgadzają się co do kierunku.
| Ustalenie | Liczba | Źródło |
|---|---|---|
| Zadania generowania kodu wprowadzające podatność | ~44% | Veracode GenAI Code Security Report 2026 |
| Średnia skuteczność bezpieczeństwa modeli | 56% — bez zmian rok do roku | Veracode, ten sam raport |
| Próbki AI z potwierdzoną podatnością | 1 na 4 (534 próbki, 6 modeli) | Badanie AppSec Santa 2026 |
| Naruszenia w firmach powiązane z kodem AI | ~1 na 5 | Aikido Security |
| Udział kodu generowanego lub wspieranego przez AI | ~42% | Ankieta Sonar wśród programistów |
| Systemy AI podatne na prompt injection w audytach | ~73% | Zbiorcze audyty bezpieczeństwa 2026 |
Dlaczego modele piszą niebezpieczny kod
Model odtwarza najczęstszy wzorzec ze swoich danych treningowych, a dla wielu zadań najczęstszy wzorzec w publicznym internecie to ten niebezpieczny — SQL sklejany ze stringów, zbyt liberalny CORS, sekrety w plikach konfiguracyjnych. Model nie jest niedbały; jest wierny korpusowi pełnemu niedbałego kodu.
Dwa efekty to pogarszają. Sesje iteracyjne degradują kod: każda runda „wygeneruj i popraw” odsuwa go od przejrzanej bazy. A randomizowane badanie ze Stanforda pokazało, że programiści wspierani przez AI pisali mniej bezpieczny kod, czując większą pewność, że jest bezpieczny — odruch przeglądu rozluźnia się dokładnie wtedy, gdy powinien się zacieśnić.
Tryby awarii, które naprawdę bolą
- Injection i obsługa wejścia — klasyczne kategorie OWASP wracają w tempie AI; wygenerowane handlery ufają wejściu, o ile prompt wprost nie kazał inaczej.
- Zbyt szerokie uprawnienia — około 60% programistów nigdy nie zawęża zakresów uprawnień w wygenerowanym kodzie, a kod infrastrukturalny pisany przez AI podnosi podatności tożsamościowe o około 28%.
- Sekrety w diffie — klucze i tokeny wklejone do przykładów trafiają do repozytorium, bo nikt nie czyta całej wygenerowanej zmiany.
- Zmyślone lub złe zależności — pakiety, które nie istnieją (prezent dla typosquattingu), albo prawdziwe, ale w podatnych wersjach.
- Prompt injection w systemach agentowych — gdy agent czyta zewnętrzny tekst, ten tekst może nim sterować; ekspozycję wykazuje około 73% audytowanych systemów.
Stos obronny, który działa
Nie ma tu nic egzotycznego — to klasyczne bezpieczeństwo aplikacji zastosowane przy nowej prędkości, z bramkami, które nie zależą od tego, czy człowiek przeczyta każdą linijkę.
- Specyfikacja na każdą zmianę z jawnym zakresem plików, żeby agent nie mógł po cichu dotknąć kodu autoryzacji przy okazji naprawiania przycisku.
- Analiza statyczna i skanowanie zależności w CI, ustawione na blokowanie, nie ostrzeganie — ekosystem open-source’owych skanerów pokrywa to dobrze.
- Testy wyprowadzone ze specyfikacji, z przypadkami negatywnymi dla ścieżek obsługi wejścia, które modele psują najczęściej.
- Minimalne uprawnienia dla agentów: tokeny o wąskim zakresie, żadnych kluczy administratora w środowisku, akcje destrukcyjne za potwierdzeniem.
- Ludzki przegląd skupiony tam, gdzie modele zawodzą — autoryzacja, uploady, zapytania, uprawnienia — zamiast rozsmarowany cienko po całym diffie.
Okazja ukryta w problemie
Narzędzia przeglądu, skanowania i barier ochronnych to najszybciej rosnący klaster w programowaniu z AI, bo każda liczba z tabeli wyżej generuje na nie popyt. W odróżnieniu od frameworków agentowych ta przestrzeń nagradza wąską specjalizację: skaner jednej klasy błędów w jednym ekosystemie bije generyczny, który niczego nie łapie dobrze.
Katalog RepoLoot opisuje 27 projektów bezpieczeństwa, przeglądu i skanowania wśród 491 rekordów — każdy z informacją, co robi, co da się na nim zbudować i jak trudno go wdrożyć. To działająca mapa miejsc, w których wciąż są luki.
Najczęstsze pytania
- Czy kod generowany przez AI jest bezpieczny?
- Domyślnie nie. Około 44% zadań generowania kodu wprowadza podatność, a średnia skuteczność modeli w pisaniu bezpiecznego kodu stoi w miejscu mimo wzrostu ich możliwości. Jest bezpieczny tak, jak każdy niezaufany kod: po skanowaniu, testach i przeglądzie — nigdy na zaufanie.
- Jak często kod z AI zawiera podatności?
- Niezależne pomiary z 2026 roku zbiegają się w tym samym przedziale: około 44% zadań generowania wprowadza groźną wadę (Veracode), a mniej więcej jedna na cztery wygenerowane próbki zawiera potwierdzoną podatność (AppSec Santa, 534 próbki z sześciu głównych modeli). Najczęstsze są wady klasy injection.
- Jakie są największe ryzyka kodowania z AI?
- Wady injection w wygenerowanej obsłudze wejścia, zbyt szerokie uprawnienia, których nikt nie zawęża, sekrety commitowane w dużych diffach, zmyślone lub przestarzałe zależności, a w konfiguracjach agentowych — prompt injection, czyli sterowanie agentem przez tekst, który czyta.
- Jak zabezpieczyć kod generowany przez AI?
- Traktuj go jak niezaufaną kontrybucję: specyfikacja z jawnym zakresem plików, analiza statyczna i skanowanie zależności blokujące pipeline, testy z przypadkami negatywnymi, minimalne uprawnienia dla agentów i ludzki przegląd skoncentrowany na autoryzacji, uploadach, zapytaniach i uprawnieniach.