Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Wdrażanie kodu ze znanymi podatnościami oznacza świadome publikowanie do środowiska produkcyjnego komponentów, bibliotek lub fragmentów aplikacji, które zawierają nierozwiązane luki bezpieczeństwa. Problem ten nasila się wraz z rosnącą presją na szybkie dostarczanie nowych funkcji, upowszechnieniem praktyk DevOps oraz wzrostem wykorzystania narzędzi AI do generowania kodu.
W praktyce wiele organizacji zaczyna traktować ryzyko bezpieczeństwa jako koszt uboczny tempa wytwarzania oprogramowania. To niebezpieczna zmiana, ponieważ współczesne zagrożenia rozwijają się szybciej niż tradycyjne procesy testów i remediacji.
W skrócie
Najnowsze dane pokazują, że znacząca część organizacji nadal wdraża kod, o którym wie, że zawiera podatności. Według przywoływanych wyników badania Checkmarx robi to często lub przynajmniej od czasu do czasu około 75% firm, a inne źródła branżowe wskazują nawet wyższy odsetek w organizacjach szeroko korzystających z asystentów AI.
Jednocześnie raport Verizon DBIR wskazuje, że wykorzystanie podatności odpowiada za istotną część początkowych wektorów dostępu do naruszeń. Oznacza to, że skracanie czasu dostarczania oprogramowania bez równoległego wzmocnienia kontroli bezpieczeństwa tworzy coraz bardziej ryzykowne środowisko operacyjne.
Kontekst / historia
Jeszcze kilka lat temu wiele zespołów zakładało, że luka wykryta po wdrożeniu może zostać usunięta w kolejnym cyklu aktualizacji. Taki model był częściowo możliwy, ponieważ czas między ujawnieniem podatności a jej powszechnym wykorzystaniem bywał dłuższy niż obecnie.
Dziś organizacje tworzą i publikują aplikacje znacznie szybciej, opierając się na rozbudowanych łańcuchach zależności, kontenerach, API, środowiskach chmurowych i automatyzacji CI/CD. Dodatkowo kod generowany przez AI zwiększa tempo developmentu, ale jednocześnie podnosi liczbę zmian, które trzeba zweryfikować pod kątem bezpieczeństwa.
W efekcie bezpieczeństwo aplikacyjne często nie nadąża za tempem produkcji. Świadome wdrażanie podatnych wersji przestaje być wyjątkiem, a zaczyna funkcjonować jako operacyjny kompromis między presją biznesową a ograniczeniami zespołów deweloperskich i AppSec.
Analiza techniczna
Źródłem problemu nie są wyłącznie pojedyncze błędy programistyczne, lecz połączenie czynników technicznych i organizacyjnych. W wielu pipeline’ach CI/CD narzędzia SAST, SCA, DAST czy skanery IaC generują dużą liczbę alertów, ale organizacje nie mają dojrzałego procesu triage’u i priorytetyzacji. W rezultacie część wykrytych podatności zostaje oznaczona jako możliwa do naprawy później, mimo że kod trafia już do produkcji.
Duży udział w ryzyku mają także zależności zewnętrzne. Biblioteki open source, frameworki i pakiety pośrednie mogą zawierać luki, które nie są widoczne na poziomie logiki biznesowej aplikacji. Jeśli organizacja nie utrzymuje aktualnego SBOM i nie monitoruje zależności tranzytywnych, podatny komponent może przejść przez proces wdrożeniowy bez realnej kontroli.
Istotnym czynnikiem jest również wykorzystanie AI do tworzenia kodu. Narzędzia tego typu przyspieszają development, ale nie eliminują potrzeby przeglądu bezpieczeństwa. Kod generowany automatycznie może powielać słabą walidację danych wejściowych, niebezpieczne wzorce uwierzytelniania, błędne konfiguracje lub nadmierne uprawnienia. Jeśli zespół uznaje taki kod za wystarczający bez dodatkowej analizy, skala ryzyka rośnie szybciej niż możliwości jego ograniczania.
Problem pogłębia także zbyt szeroko stosowana akceptacja ryzyka. Nie każda podatność wymaga natychmiastowej blokady wdrożenia, ale decyzja o publikacji kodu nie powinna zapadać bez oceny kontekstu, takiego jak ekspozycja usługi do internetu, dostępność publicznego exploitu, typ przetwarzanych danych czy możliwość ruchu bocznego po kompromitacji.
- nadmiar alertów i brak skutecznego triage’u,
- niewystarczająca widoczność zależności bezpośrednich i tranzytywnych,
- zbyt szybkie wdrażanie kodu generowanego przez AI bez kontroli jakości,
- nadużywanie wyjątków od polityk bezpieczeństwa,
- brak kontekstowej priorytetyzacji podatności.
Konsekwencje / ryzyko
Najbardziej bezpośrednią konsekwencją jest wzrost prawdopodobieństwa skutecznego włamania. Jeśli podatny kod zostaje wdrożony świadomie, organizacja utrzymuje w środowisku produkcyjnym słabości, które są znane zarówno obrońcom, jak i napastnikom.
W praktyce może to prowadzić do przejęcia aplikacji internetowej, zdalnego wykonania kodu, eskalacji uprawnień w środowiskach chmurowych i kontenerowych, wycieku danych klientów, naruszenia tajemnicy przedsiębiorstwa lub kompromitacji łańcucha dostaw. Jeżeli dla luki istnieje już gotowy exploit albo publiczny proof of concept, okno na reakcję znacząco się skraca.
Dodatkowym problemem jest efekt skali. Pojedyncza akceptacja ryzyka w jednym mikroserwisie może wydawać się uzasadniona, ale dziesiątki lub setki podobnych wyjątków tworzą systemowe zadłużenie bezpieczeństwa. Wtedy nawet organizacje posiadające zestaw nowoczesnych narzędzi tracą realną kontrolę nad ryzykiem wdrożeniowym.
- wyższe ryzyko naruszeń i ransomware,
- większa powierzchnia ataku dla usług internet-facing,
- konsekwencje regulacyjne, audytowe i kontraktowe,
- utrata ciągłości działania i kosztowne przestoje,
- narastające zadłużenie bezpieczeństwa w skali całej organizacji.
Rekomendacje
Ograniczenie zjawiska świadomego wdrażania podatnego kodu wymaga zmian procesowych, technicznych i organizacyjnych. Kluczowe jest przesunięcie kontroli bezpieczeństwa bliżej momentu tworzenia kodu, tak aby problemy były wykrywane już w IDE, pull requeście lub podczas buildu, a nie dopiero po publikacji aplikacji.
Firmy powinny wdrażać twarde polityki bezpieczeństwa w CI/CD dla podatności krytycznych i wysokich, zwłaszcza tych powiązanych z publicznymi exploitami lub usługami wystawionymi do internetu. Równie ważne jest prowadzenie kontekstowej priorytetyzacji, która uwzględnia nie tylko ocenę CVSS, ale także rzeczywistą ekspozycję systemu i znaczenie biznesowe zasobu.
- wymuszanie security gates dla podatności krytycznych i wysokich,
- utrzymywanie aktualnego SBOM oraz pełnej widoczności zależności,
- integracja SAST, SCA, DAST, skanowania sekretów i IaC w jednym procesie,
- obowiązkowy review bezpieczeństwa dla kodu generowanego przez AI,
- automatyzacja remediacji i aktualizacji bibliotek,
- ograniczanie wyjątków od polityk bezpieczeństwa oraz nadawanie im terminów wygaśnięcia,
- stosowanie mechanizmów kompensacyjnych, takich jak WAF, segmentacja, least privilege i monitoring runtime,
- regularne mierzenie wskaźników AppSec, w tym czasu naprawy i liczby podatności obecnych przy wdrożeniu.
Podsumowanie
Świadome wdrażanie podatnego kodu przestaje być pojedynczym odstępstwem od polityki i staje się objawem głębszego problemu w nowoczesnym wytwarzaniu oprogramowania. Presja na szybkość, złożoność łańcucha dostaw, nadmiar alertów oraz rosnąca rola AI powodują, że wiele organizacji akceptuje poziom ryzyka, który coraz trudniej uzasadnić.
W realiach, w których wykorzystanie podatności należy do głównych wektorów początkowego dostępu, taka strategia jest coraz mniej opłacalna. Skuteczna odpowiedź wymaga nie tylko większej liczby narzędzi, ale przede wszystkim lepszej priorytetyzacji, automatyzacji i konsekwentnych polityk wdrożeniowych na całej ścieżce code-to-cloud.
Źródła
- https://www.infosecurity-magazine.com/news/threequarters-knowingly-ship/
- https://www.techradar.com/pro/security/ai-generated-code-is-outpacing-every-manual-remediation-model-in-existence-nearly-all-firms-admit-they-have-shipped-code-they-know-is-vulnerable
- https://checkmarx.com/press-releases/ai-coding-becomes-risky-norm-as-use-of-ai-coding-assistants-takes-off/
- https://www.verizon.com/about/news/breach-industry-wide-dbir-finds
- https://www.verizon.com/business/resources/T1e0/reports/2026-dbir-data-breach-investigations-report.pdf