Modele AI znajdują dziś podatności szybciej, niż zespoły potrafią je łatać. Cloud Security Alliance opublikowała framework gotowości na tę zmianę. Warto go przeczytać i warto się z nim w kilku miejscach nie zgodzić.
Twój SZBI łata podatności co miesiąc. AI znajduje je co godzinę.
Dlaczego framework AI Threat Readiness dotyczy każdego SZBI?
Framework opisuje problem, z którym mierzy się każdy system zarządzania bezpieczeństwem informacji: tempo wykrywania podatności rośnie szybciej niż tempo ich usuwania. Publikacja „A Framework for AI Threat Readiness”, opracowana przez firmę Wiz i rozpowszechniona przez Cloud Security Alliance (CSA) we wrześniu 2026 r., stawia tezę wprost. Modele frontierowe potrafią dziś samodzielnie znaleźć podatność zero-day, napisać działający exploit i połączyć kilka słabości w łańcuch ataku.
Autorzy nie wieszczą katastrofy. Uważają wręcz, że w dłuższej perspektywie oprogramowanie stanie się bezpieczniejsze niż kiedykolwiek. W krótszej perspektywie diagnoza jest jednak jednoznaczna: „the time between discovery and exploitation will continue to shrink”. Dla pełnomocnika SZBI i audytora oznacza to jedno. Procedury zarządzania podatnościami, projektowane pod miesięczny cykl łatania, testowane są dziś w zupełnie innym rytmie.
Framework proponuje odpowiedź operacyjną. W tym tekście pokazujemy, że jest ona trafna, ale niepełna. Brakujące elementy od lat opisują normy ISO.
AI przyspiesza atak — co dokładnie się zmieniło?
Zmieniła się ekonomia wykrywania. Znalezienie poważnej podatności przestało wymagać miesięcy pracy wyspecjalizowanego zespołu, więc staje się tanie dla obu stron: obrońcy i napastnika.
Wykrycie podatności przestało być kosztowne
Najmocniejszy dowód nie pochodzi od dostawcy narzędzi, lecz od Mozilli. Według danych Mozilli w kwietniu 2026 r. w wydaniach Firefoksa naprawiono 423 błędy bezpieczeństwa. 271 z nich zidentyfikowano z użyciem modelu Claude Mythos Preview firmy Anthropic. W 2025 r. miesięczna średnia wynosiła około dwudziestu. Wśród znalezisk były błędy obecne w kodzie od kilkunastu, a nawet dwudziestu lat, czyli przeoczone przez wszystkie wcześniejsze metody testowania.
Publikacja CSA wyciąga z tego wniosek skalowalny na każdą organizację: skoro obrońca może tak przeskanować własny kod, napastnik może zrobić to samo z cudzym.
Cztery filary gotowości według CSA i Wiz
Framework opiera gotowość na dwóch zmiennych: szybkości działania i szerokości widoczności. Na tej podstawie buduje cztery obszary działań: ograniczenie ekspozycji i ciągłe skanowanie wszystkiego, co jest osiągalne z zewnątrz, przyspieszenie łatania i reakcji na zero-day, głęboką analizę kodu z użyciem modeli AI oraz automatyczną detekcję i reakcję w czasie rzeczywistym. Każdy filar ma przypisane mierniki, głównie czasy naprawy (MTTR) i pokrycie środowiska.
Skala problemu jest mierzalna. Według danych Wiz przywołanych w publikacji 30% środowisk chmurowych ma co najmniej jedną maszynę o wysokim wpływie z oprogramowaniem wystawionym na zewnątrz. W 19% organizacji takie oprogramowanie działa na systemach z uprawnieniami IAM do wrażliwych zasobów wewnętrznych. W 6% istnieje ścieżka do uprawnień administracyjnych. W tym ostatnim przypadku jedna podatność wystarcza do przejęcia kontroli nad całym środowiskiem.
Gdzie framework milknie?
W trzech miejscach, i każde z nich ma znaczenie dla systemu zarządzania.
Po pierwsze, framework mierzy przede wszystkim szybkość. Inżynierowie Mozilli zauważyli jednak rzecz odwrotną: poprosić model o znalezienie problemu jest tanio, a zareagować na znalezisko jest drogo. Wąskim gardłem nie jest więc wykrywanie, lecz proces obsługi zgłoszenia.
Po drugie, framework zaleca automatyczne playbooki. Agenci AI mają izolować obciążenia, odbierać uprawnienia i naprawiać kod u źródła, a zgoda człowieka jest wymagana tylko przy działaniach wrażliwych. Kto zdefiniuje, które działania są wrażliwe, i kto odpowiada za błąd agenta, publikacja nie rozstrzyga.
Po trzecie, framework widzi organizację wyłącznie jako potencjalną ofiarę. Tymczasem każda firma rozwijająca własną aplikację lub usługę SaaS jest też producentem. Musi przyjmować zgłoszenia podatności od innych i informować o nich własnych klientów.
Co normy ISO dodają do frameworku?
Normy ISO nie zastępują czterech filarów. Dodają to, czego framework nie opisuje: proces, rozliczalność i dowód skuteczności.
| Filar frameworku | ISO/IEC 27001:2022 | Uzupełnienie |
|---|---|---|
| Ekspozycja i widoczność | A.5.9, A.8.20–A.8.22 | — |
| Łatanie i zero-day | A.8.8, A.5.7 | ISO/IEC 30111, 7.1.4 i 7.2 |
| Analiza kodu | A.8.25, A.8.28, A.8.29 | ISO/IEC 29147, 6.2.2 |
| Detekcja i reakcja | A.8.16, A.5.24–A.5.26 | ISO/IEC 42001, A.9.3 |
| Program gotowości | 6.1.3, 9.1, 9.3 | — |
ISO/IEC 27001:2022 — z frameworku w system
Publikacja kończy się akapitem o komitecie, SLA i procesie wyjątków. System zarządzania bezpieczeństwem informacji zgodny z ISO/IEC 27001:2022 czyni z tego system. Wyjątek od SLA łatania to w języku normy ryzyko szczątkowe, które właściciel ryzyka świadomie akceptuje (kl. 6.1.3 f). Mierniki MTTR z frameworku stają się wynikami monitorowania z kl. 9.1, a te trafiają do przeglądu zarządzania (kl. 9.3). Zabezpieczenie A.8.8 wymaga zarządzania podatnościami technicznymi, a A.5.7 pozyskiwania informacji o zagrożeniach. Oba muszą dziś działać w rytmie wyznaczanym przez AI, nie przez kalendarz.
Ma to w Polsce konkretny wymiar. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026 r. Podmioty kluczowe i ważne mają czas do 3 kwietnia 2027 r. na wdrożenie SZBI opartego na systematycznym szacowaniu ryzyka (art. 8 ust. 1). Wymagania nowelizacji KSC omawialiśmy szerzej osobno. Szacowanie, które nie uwzględnia skokowo tańszego wykrywania podatności, przestaje być systematyczne w sensie merytorycznym.
ISO/IEC 30111 i ISO/IEC 29147 — proces zamiast pośpiechu
Para norm o obsłudze i ujawnianiu podatności odpowiada wprost na obserwację Mozilli. ISO/IEC 30111:2019 już w fazie weryfikacji (7.1.4) wymaga czegoś więcej niż potwierdzenia błędu. Każe ustalić przyczynę źródłową i poszukać kolejnych wystąpień tej samej klasy podatności. Ostrzega też, że wykonalność ataku zmienia się wraz z nowymi technikami. AI nie stworzyła tego wymogu, tylko przestała tolerować jego ignorowanie.
Najciekawsza polemika dotyczy mierników. Norma w pkt 7.2 każe monitorować nie tylko szybkość, ale też kompletność naprawy (czy usunięto przyczynę) i jej skuteczność po wdrożeniu. Dopuszcza przy tym poprawkę tymczasową przy aktywnej eksploatacji, ale wymaga jej późniejszego domknięcia. Optymalizacja pod samo MTTR to w tym świetle łatanie objawów.
ISO/IEC 29147:2018 uzupełnia obraz o stronę zewnętrzną. Pkt 5.10 wskazuje koszt opracowania exploita jako jeden z czynników decydujących o ataku i zaleca założenie najbardziej konserwatywne: podatność może zostać, a nawet mogła już zostać wykorzystana. Gdy AI obniża ten koszt, konserwatywne założenie przestaje być asekuracją. Staje się realizmem.
Dla producentów to już obowiązek prawny. Od 11 września 2026 r. akt o cyberodporności (rozporządzenie (UE) 2024/2847) wymaga zgłaszania aktywnie wykorzystywanych podatności: wczesnego ostrzeżenia w ciągu 24 godzin i pełnego zgłoszenia w ciągu 72 godzin. Kanał zgłoszeń z pkt 6.2.2 ISO/IEC 29147 przestaje więc być dobrą praktyką i staje się warunkiem dotrzymania terminu.
ISO/IEC 42001:2023 — kto pilnuje agenta, który pilnuje systemów?
Framework każe bronić się autonomicznymi agentami AI. To oznacza, że organizacja staje się użytkownikiem systemów AI z uprawnieniami uprzywilejowanymi. System zarządzania AI zgodny z ISO/IEC 42001:2023 przewiduje taki scenariusz: wytyczne normy (zał. B.6.1.2) wprost wymieniają wykorzystanie AI do wzmacniania zabezpieczeń.
Zabezpieczenie A.9.3 wymaga określenia, na których etapach nadzór człowieka ma być znaczący, łącznie z uprawnieniem do unieważnienia decyzji systemu. A.9.4 wymaga używania systemu zgodnie z zamierzonym zastosowaniem, a A.6.2.6 monitorowania jego działania. Pytanie, które działania agenta są „wrażliwe”, ma w normie gotowe miejsce na odpowiedź i właściciela. Organizacje korzystające z agentów AI w chmurze znajdą uzupełnienie w AI Controls Matrix CSA, katalogu 247 celów kontrolnych mapowanym m.in. na ISO/IEC 42001.
Z praktyki audytora: scenariusz modelowy
Poniższy scenariusz jest modelowy. Zbudowano go na wzorcach typowych niezgodności, nie na konkretnym przypadku.
Organizacja ma certyfikat ISO/IEC 27001 i podlega nowelizacji KSC. Procedura A.8.8 przewiduje comiesięczne okno łatania i przegląd skanów raz na kwartał. Zespół rozwojowy wdrożył narzędzie AI do przeglądu kodu, które w pierwszym tygodniu zgłosiło kilkadziesiąt potencjalnych podatności. Nie ma procedury weryfikacji takich zgłoszeń, więc trafiają do ogólnego backlogu. Organizacja nie ma też publicznego kanału zgłoszeń od badaczy.
Szacowanie ryzyka wykonano raz, przy wdrożeniu SZBI, i nie uwzględnia zmiany tempa wykrywania. Audytor zapyta o rejestr zgłoszeń, kryteria priorytetyzacji i o to, kiedy ostatnio aktualizowano ocenę ryzyka po istotnej zmianie w otoczeniu zagrożeń. Wynik: formalnie zgodna procedura, merytorycznie nieaktualna analiza ryzyka.
Jak przygotować SZBI na zagrożenia przyspieszane przez AI?
Punktem wyjścia jest przegląd, nie zakup narzędzia. Oto pytania, które warto zadać przed najbliższym przeglądem zarządzania:
- Czy procedura zarządzania podatnościami rozróżnia podatność w oprogramowaniu dostawcy, jej wystąpienie w naszym środowisku i podatność we własnym kodzie? Framework słusznie podkreśla, że każda wymaga innej ścieżki.
- Czy mierzymy tylko czas naprawy, czy także jej kompletność i skuteczność?
- Czy mamy kanał przyjmowania zgłoszeń z zewnątrz i czy ktoś faktycznie go monitoruje?
- Czy szacowanie ryzyka uwzględnia spadek kosztu wykrywania podatności i kiedy ostatnio je aktualizowano?
- Jeżeli używamy agentów AI w bezpieczeństwie, czy istnieje lista działań, które mogą wykonać samodzielnie, i czy ta lista ma właściciela? Jak taką listę zbudować, pokazujemy w tekście o governance agentów AI według ISO/IEC 42001.
Dla producentów oprogramowania dochodzi jeszcze jedno pytanie: czy proces obsługi podatności pozwala zgłosić aktywną eksploatację w 24 godziny, także dla produktów sprzedanych przed wrześniem 2026 r.
Podsumowanie
Framework CSA i Wiz trafnie diagnozuje zmianę. AI obniżyła koszt wykrywania podatności, a czas na reakcję się kurczy. Odpowiedź czysto operacyjna, czyli więcej skanowania, więcej automatyzacji i krótsze MTTR, nie wystarczy. Organizacji potrzebny jest proces obsługi podatności, który usuwa przyczyny, a nie objawy. Potrzebna jest też jasna rozliczalność za decyzje agentów AI i szacowanie ryzyka nadążające za tempem zmian.
To właśnie zapewnia system zarządzania bezpieczeństwem informacji zgodny z ISO/IEC 27001:2022, uzupełniony o ISO/IEC 30111, ISO/IEC 29147 i ISO/IEC 42001. Jeśli chcesz sprawdzić, czy Twój SZBI jest gotowy na tempo wyznaczane przez AI, poznaj certyfikację ISO/IEC 27001 w QSCert, prowadzoną przez COE – Centre of Excellence sp. z o.o.
Bibliografia:
- Wiz, A Framework for AI Threat Readiness, Cloud Security Alliance, 18.09.2026 (przedruk; oryginał: Wiz). cloudsecurityalliance.org
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 (akt o cyberodporności) — obowiązki raportowe, Komisja Europejska. digital-strategy.ec.europa.eu
- Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252) — obowiązki podmiotów kluczowych i ważnych, Ministerstwo Cyfryzacji. gov.pl
- ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements
- ISO/IEC 30111:2019 (EN ISO/IEC 30111:2020) Information technology — Security techniques — Vulnerability handling processes
- ISO/IEC 29147:2018 (EN ISO/IEC 29147:2020) Information technology — Security techniques — Vulnerability disclosure
- ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
- Grinstead B., Holler C., Braun F., Behind the Scenes Hardening Firefox with Claude Mythos Preview, Mozilla Hacks, maj 2026. hacks.mozilla.org
- Holley B., The zero-days are numbered, The Mozilla Blog, 21.04.2026. blog.mozilla.org
- Cloud Security Alliance, AI Controls Matrix v1.1, 22.06.2026. cloudsecurityalliance.org
FAQ: AI skraca drogę od podatności do exploita. Co na to ISO 27001?
Nie. ISO/IEC 27001:2022 nie narzuca terminów łatania, lecz wymaga zarządzania podatnościami technicznymi (A.8.8) na podstawie oceny ryzyka. Terminy ustala sama organizacja, a każdy wyjątek od nich jest ryzykiem szczątkowym, które musi zaakceptować właściciel ryzyka. Twarde terminy zewnętrzne mogą natomiast wynikać z przepisów, na przykład z aktu o cyberodporności dla producentów.
Norma jest adresowana do dostawców obsługujących podatności we własnych produktach i usługach. W praktyce dostawcą jest każda organizacja, która rozwija własną aplikację, portal klienta lub usługę SaaS. Firmy, które wyłącznie używają cudzego oprogramowania, opierają się przede wszystkim na zabezpieczeniu A.8.8 z ISO/IEC 27001.
Tak. Obowiązki raportowe z art. 14 aktu o cyberodporności obejmują także produkty z elementami cyfrowymi wprowadzone na rynek przed tą datą. Producent, który dowie się o aktywnie wykorzystywanej podatności, przekazuje wczesne ostrzeżenie w ciągu 24 godzin, a pełne zgłoszenie w ciągu 72 godzin, przez platformę zgłoszeń ENISA.
Nie ma takiego obowiązku, bo ISO/IEC 42001 jest normą dobrowolną. Jeśli jednak organizacja ma system zarządzania AI, taki agent powinien się w nim znaleźć z określonym zamierzonym zastosowaniem i nadzorem człowieka (A.9.3, A.9.4). Bez systemu zarządzania AI ryzyko agenta trzeba co najmniej ująć w szacowaniu ryzyka SZBI.
ISO/IEC 27001:2022 wymaga oceny ryzyka w zaplanowanych odstępach oraz wtedy, gdy zachodzą lub są planowane istotne zmiany (kl. 8.2). Skokowy spadek kosztu wykrywania podatności jest właśnie taką zmianą w otoczeniu zagrożeń. Podmioty kluczowe i ważne muszą ponadto prowadzić systematyczne szacowanie ryzyka na podstawie ustawy o krajowym systemie cyberbezpieczeństwa.
Ekspert w zakresie systemów zarządzania ISO, cyberbezpieczeństwa, compliance i AI governance. Audytor, konsultant, trener.
Ilustracje w tym wpisie zostały wygenerowane przy użyciu narzędzi sztucznej inteligencji. Treść merytoryczna powstała w redakcji COE i jest podpisana imiennie.