Ufasz swojemu asystentowi AI do kodowania. Pisze czyste funkcje, obsługuje edge case'y, wstawia pomocne komentarze. Kod się kompiluje, testy przechodzą, pull request — propozycja wrzucenia nowego kodu do głównego projektu — dostaje kciuka w górę. Trzy miesiące później pentester znajduje dziurę w funkcji, którą twój agent napisał o drugiej w nocy. Nikt tego nie zakwestionował, bo "wyglądało ok."
To nie jest eksperyment myślowy. To jest zwykły wtorek.
Przepaść między pewnością siebie a kompetencją
Kod generowany przez AI stanowi już mniej więcej 46% nowego kodu w wielu firmach. Nie uciekniesz od tego. Ale gdzieś między "AI to napisał" a "wrzuciliśmy na produkcję" wkradło się niebezpieczne założenie: że maszyna wie, co robi. Nie wie. To bardzo szybka maszynistka, która nie ma pojęcia o atakujących.
Potrzebujesz instrukcji polowej. Oto ona.
Jeden na cztery fragmenty kodu ma dziurę
W lutym 2026 roku grupa badawcza AppSecSanta przetestowała sześć dużych LLM-ów — wielkich modeli językowych, mózgów stojących za ChatGPT, Claude, Gemini i przyjaciółmi — na 89 promptach skoncentrowanych na bezpieczeństwie. Python i JavaScript. Realne zadania zmapowane na OWASP Top 10 — powszechnie uznawaną listę najkrytyczniejszych zagrożeń bezpieczeństwa aplikacji webowych.
Wynik: 25,1% wygenerowanego kodu zawierało potwierdzone podatności. Jeden na cztery fragmenty. Twoje AI produkuje bugi na skalę przemysłową, i robi to ze spokojem kogoś, kto nigdy nie został zhackowany.
Wskaźniki podatności według modelu:
| Model | Wskaźnik |
|---|---|
| GPT-5.2 | 19,1% (najlepszy) |
| Gemini 2.5 Pro | 22,4% |
| Grok 4 | 23,7% |
| Claude Opus 4.6 | 29,2% |
| DeepSeek V3 | 29,2% |
| Llama 4 Maverick | 29,2% |
Te 10 punktów procentowych różnicy oznacza, że wybór modelu ma znaczenie. Ale nawet najlepszy model wsadza podatność w prawie co piąty output. Wybranie GPT-5.2 zamiast Llamy 4 pomaga. Nie zbawia.
Gdzie modele sypią się najczęściej:
- SSRF (Server-Side Request Forgery — kiedy twój serwer daje się nabrać na wywoływanie wewnętrznych URL-i w imieniu atakującego): 32 znaleziska. Największa pojedyncza kategoria.
- Injection (SQL injection, command injection — kiedy dane od użytkownika wślizgują się do zapytań bazodanowych albo komend systemowych): 30 znalezisk, 33,1% wszystkich problemów.
- Błędy konfiguracji bezpieczeństwa: 25 znalezisk — zahardkodowane sekrety, tryb debug zostawiony na produkcji.
- Broken access control (pozwalanie użytkownikom robić rzeczy, do których nie powinni mieć dostępu): obecne u każdego testowanego modelu.
Oddzielne badanie Help Net Security z marca 2026 przetestowało Claude Code, OpenAI Codex i Google Gemini w trybie agentowym — nie samo autouzupełnianie, lecz w pełni autonomiczne kodowanie. Agenty wyprodukowały 143 problemy bezpieczeństwa w 38 skanach obejmujących 30 pull requestów. 87% tych PR-ów zawierało co najmniej jedną podatność. Broken access control pojawił się w outputcie każdego agenta. Każdego. Jednego.
Dlaczego maszyna pisze niebezpieczny kod
Modele nie są złośliwe. To maszyny probabilistyczne wytrenowane na GitHubie, a GitHub jest pełen niebezpiecznego kodu. Odpowiedzi ze Stack Overflow z 2015, które hardkodują sekrety JWT (JWT — JSON Web Token, cyfrowy przepust udowadniający, że jesteś zalogowany). Tutorialowy kod, który pomija walidację inputu, bo "to tylko demo." Produkcyjny kod od firm, które nigdy nie przeszły audytu bezpieczeństwa.
Trzy wzorce pojawiają się w kółko:
1. Brak walidacji po stronie serwera. Agenty AI akceptują wartości po stronie klienta — punkty, salda, role użytkowników — bez weryfikacji na serwerze. Model nauczył się z tysięcy tutoriali, które "walidację zostawiały jako ćwiczenie dla czytelnika." Czytelnik nigdy tego ćwiczenia nie zrobił. AI też nie.
2. Niebezpieczne domyślne ustawienia. Tokeny JWT bez daty wygaśnięcia. Implementacje OAuth (OAuth — protokół, który pozwala ci kliknąć "Zaloguj się przez Google" zamiast tworzenia kolejnego hasła) bez parametru state chroniącego przed przejęciem. Refresh tokeny, których nie da się unieważnić. Modele generują kod, który działa, ale wybiera leniwe domyślne ustawienie, nie bezpieczne.
3. SSRF wszędzie. Kiedy model pisze kod pobierający URL, prawie nigdy nie sprawdza, dokąd ten URL prowadzi. Żadnych allowlist, żadnego blokowania wewnętrznych adresów IP, żadnych ograniczeń protokołu. Po prostu wywołuje requests.get(user_input) i puszcza na prod. Atakujący podsuwa http://169.254.169.254/ i nagle ma twoje credentiale do chmury.
Twój pięciowarstwowy stos obronny
Przestań czekać, aż modele staną się mądrzejsze w kwestii bezpieczeństwa. Zbuduj pipeline — zautomatyzowaną sekwencję sprawdzeń — który łapie problemy niezależnie od tego, kto lub co napisało kod.
Warstwa 1: Prompty nakierowane na bezpieczeństwo
Najprostszy fix nic nie kosztuje. Badanie Veracode wykazało, że dodanie generycznego przypomnienia o bezpieczeństwie do promptu poprawiło wskaźnik bezpiecznego kodu z 56% do 66% dla Claude Opus 4.6. Dziesięć procent poprawy za jedno zdanie. Nie magia. Ale za darmo.
Dodaj to do swojego system promptu, reguł Cursora albo pliku CLAUDE.md:
When writing code: validate all inputs server-side. Never trust
client data. Use parameterized queries. Set secure defaults for
auth tokens (expiration, rotation). Block SSRF by validating URLs
against allowlists. Never hardcode secrets.
Dla agentów AI takich jak Claude Code, Codex czy Copilot w trybie agentowym — wrzuć te instrukcje do plików konfiguracyjnych projektu. Agent czyta je przy każdym zadaniu.
Warstwa 2: SAST w twoim edytorze
SAST — Static Application Security Testing — skanuje twój kod w poszukiwaniu podatności bez uruchamiania go, jak korektor ortograficzny, ale dla dziur w bezpieczeństwie. Kluczowe odkrycie AppSecSanta: tylko jedno narzędzie SAST wykryło 78% podatności generowanych przez AI. Uruchomienie wielu skanerów dramatycznie poprawia pokrycie.
Zalecany setup:
- Semgrep — darmowy, szybki, 3000+ reguł. Działa w VS Code, JetBrains i CI. Łapie injection, SSRF, zahardkodowane sekrety.
- Bandit (Python) — wyłapuje typowe problemy bezpieczeństwa w Pythonie. Zero konfiguracji.
- Pluginy bezpieczeństwa ESLint (JavaScript) —
eslint-plugin-securityieslint-plugin-no-unsanitized.
Zainstaluj Semgrep jako pre-commit hook — skrypt uruchamiany automatycznie przed każdym commitem, blokujący zły kod przed wejściem do repozytorium:
pip install semgrep
semgrep --config auto --error .
Teraz każdy commit jest skanowany. AI pisze kod, Semgrep daje mu w łapę zanim pushnesz.
Warstwa 3: Skanowanie w pipeline CI
Twój pre-commit hook łapie oczywiste rzeczy. Twój pipeline CI — zautomatyzowany system budowania i testowania uruchamiany przy pushu kodu — powinien przeprowadzać głębszą analizę:
# Przykład GitHub Actions
- name: Semgrep SAST
uses: semgrep/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/cwe-top-25
p/python-security
p/javascript-security
- name: Dependency check
uses: dependency-check/dependency-check-action@v1
Skup reguły na kategoriach, w których AI sypie się najczęściej: SSRF (CWE-918), injection (CWE-89, CWE-78), niebezpieczna deserializacja (CWE-502 — kiedy złośliwe dane są rozpakowywane do wykonywalnych obiektów) i path traversal (CWE-22 — kiedy atakujący używa ../../ żeby uciec z katalogu i czytać pliki, do których nie powinien mieć dostępu).
Warstwa 4: Code review z perspektywą bezpieczeństwa
Code review kodu generowanego przez AI różni się od normalnego review. Nie szukasz błędów logicznych — AI radzi sobie z nimi względnie dobrze. Szukasz:
- Endpointów bez sprawdzania autoryzacji. AI pisze route handler, ale zapomina o middleware — strażniku, który sprawdza "czy masz prawo tu być?"
- Danych użytkownika trafiających w niebezpieczne miejsca. Zapytania do bazy, operacje na plikach, requesty HTTP, komendy shell. Jeśli input użytkownika dotyka czegokolwiek z tego bez sanityzacji, masz problem.
- Brak rate limitingu. AI nigdy nie dodaje rate limitingu, chyba że wyraźnie poprosisz. Każdy publiczny endpoint go potrzebuje, bo inaczej ktoś wali w niego 10 000 requestów na sekundę.
- Sekrety w kodzie. Model czasem generuje placeholderowe klucze API, które wyglądają wystarczająco prawdziwie, żeby je shiponąć. Potem lądują na GitHubie. Potem lądują w cudzych rękach.
Wytrenuj swój zespół, żeby przy każdej funkcji napisanej przez AI zadawał jedno pytanie: "Co się stanie, jeśli input jest wrogi?"
Warstwa 5: Plik reguł OpenSSF
OpenSSF — Open Source Security Foundation — opublikował zestandaryzowany przewodnik bezpieczeństwa dla instrukcji asystentów AI do kodowania. To plik reguł, który wrzucasz do roota projektu. Każde narzędzie AI do kodowania obsługujące instrukcje na poziomie projektu czyta go automatycznie.
Plik obejmuje walidację inputu, kodowanie outputu, uwierzytelnianie, zarządzanie sesjami, kryptografię, obsługę błędów i logowanie. Zamiast pisać własne reguły bezpieczeństwa od zera, użyj ich — utrzymywane przez specjalistów od bezpieczeństwa, regularnie aktualizowane i darmowe.
Ile cię to kosztuje
Czas. Każda warstwa dodaje tarcie. Pre-commit hooki dodają 5–15 sekund na commit. Skany CI dodają minuty do twojego pipeline'u. Code review wymaga ludzi, którzy wiedzą, jak wygląda SSRF. Plik OpenSSF wymaga przeczytania go raz i zrozumienia, co robi.
False positive'y będą cię wkurzać. Semgrep oflaguje kod, który jest w porządku. Będziesz tracić czas na sprawdzanie nieistniejących problemów. To podatek, który płacisz za łapanie prawdziwych.
I nic z tego nie jest niezawodne. Badanie AppSecSanta wykazało, że 22% podatności przeszło przez wszystkie testowane narzędzia SAST. Niektóre dziury wymagają testów dynamicznych — faktycznego uruchomienia kodu i atakowania go — żeby je znaleźć. Analiza statyczna jest konieczna, ale niewystarczająca.
Co zrobić w poniedziałek rano
Nie musisz wdrażać wszystkich pięciu warstw do przyszłego tygodnia. Zacznij od dwóch:
- Dodaj instrukcje bezpieczeństwa do konfiguracji AI. Skopiuj blok promptu z Warstwy 1. Wklej do projektu. Pięć minut.
- Zainstaluj Semgrep jako pre-commit hook. Dwie komendy. Zrobione zanim twoja kawa ostygnie.
To samo stawia cię przed większością zespołów shipujących kod generowany przez AI. Dodaj skanowanie CI, kiedy będziesz mieć sprint z miejscem na oddech. Dodaj plik OpenSSF, kiedy ktoś z zespołu go przeczyta i zrozumie. Trenuj reviewerów z czasem.
Nowa normalność
Wskaźnik podatności w kodzie generowanym przez AI spadł z około 40% w 2024 do 25% w 2026. Postęp, jasne. W tym tempie "akceptowalny" poziom osiągniemy gdzieś koło 2030. Nie możesz czekać czterech lat.
Traktuj kod generowany przez AI jak output juniora, który pisze 500 słów na minutę, emanuje pewnością siebie i nigdy nie słyszał o OWASP. Reviewuj go. Skanuj. Testuj. Dopiero potem shipuj.
AI pisze kod 10x szybciej. Twoje narzędzia bezpieczeństwa muszą nadążyć. Narzędzia istnieją. Jedynym brakującym elementem jest nawyk ich używania.
