CERT-In — indyjski odpowiednik CISA — opublikował 25 maja 38-stronicowy dokument zatytułowany "Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure."
Centralne wymaganie: znane exploitowane podatności w systemach wystawionych na internet — 12 godzin na usunięcie. Tam gdzie natychmiastowa łatka jest niemożliwa: izolacja systemu, ograniczenie dostępu, tymczasowe zabezpieczenie przez WAF. Osobna skala dla pozostałych klas: jeden dzień dla krytycznych podatności wystawionych zewnętrznie, trzy dni dla krytycznych podatności wewnętrznych w systemach wysokiej wartości, pięć dni dla podatności wysokiego ryzyka.
CERT-In wprost opisuje dlaczego: "AI-assisted cyber exploitation reduces the time required for adversaries to identify, weaponize, and exploit vulnerabilities."
To jest pierwsze krajowe wytyczne które wprost nazwały AI jako powód do przepisania kalendarza łatania.
12 godzin i co za tym stoi
Warto zatrzymać się przy tej liczbie i sprawdzić czy jest realistyczna.
Mandiant w M-Trends 2026 dokumentował że mediana time-to-exploit jest ujemna — 28,3% CVE jest eksploitowanych w ciągu 24 godzin od ujawnienia. Marimo: 9h 41min od ujawnienia do pierwszego exploita. LMDeploy: 12h 31min. LiteLLM: 36 godzin.
12 godzin jako cel dla known exploited vulnerabilities (KEV) na systemach publicznych — to jest odpowiedź na Marimo i LMDeploy. Nie na akademicką prognozę, na konkretne incydenty z konkretnym czasem.
Problem operacyjny jest jednak prawdziwy. Change management w dużej organizacji — ocena ryzyka, approval, testowanie, deployment, weryfikacja — standardowo zajmuje dni lub tygodnie. CERT-In dodaje słowo "where feasible" przy 12-godzinnym celu i opisuje to jako "indicative expectations" a nie wiążące wymaganie. To jest realistyczne przyznanie że dla większości organizacji 12 godzin to cel a nie gwarancja.
Infosecurity Magazine ujmuje tę lukę precyzyjnie: dokument jest szczery w tym że tempo łatania które opisuje wymaga fundamentalnej zmiany procesów, nie tylko szybszego klikania przycisków w systemie zarządzania podatnościami.
Nie tylko szybciej — inaczej
Jest jeden element 38-stronicowego dokumentu który zasługuje na więcej uwagi niż nagłówek o 12 godzinach.
CERT-In rekomenduje priorytetyzację przez katalog KEV i EPSS — Exploit Prediction Scoring System — zamiast przez wynik CVSS. To jest istotna zmiana w filozofii.
CVSS to wynik który mówi jak poważna jest podatność technicznie. EPSS to wynik który mówi jak prawdopodobne jest że będzie eksploitowana w ciągu 30 dni. Te dwie liczby często się rozchodzą — podatność z CVSS 9.0 może mieć EPSS 0.1%, a podatność z CVSS 6.5 może mieć EPSS 45%.
Pisaliśmy przy decyzji NIST o ograniczeniu bazy NVD że system zarządzania podatnościami który przez dwie dekady był fundamentem zarządzania ryzykiem nie nadąża za tempem odkrywania. CERT-In rekomenduje KEV i EPSS jako odpowiedź — czyli de facto: zamiast próbować obsłużyć wszystkie podatności, celuj precyzyjnie w te które atakujący faktycznie używają lub najprawdopodobniej użyją.
Dokument który jest mapą maja
CERT-In opublikował ten dokument 25 maja 2026 — po miesiącu który dla cyberflux był serią incydentów ilustrujących dokładnie to co opisuje blueprint.
Sekcja o AI-wspomaganym odkrywaniu podatności: GTIG "to już tutaj", NGINX Rift znaleziony przez AI w sześć godzin, vulnpocalypse.
Sekcja o bezpieczeństwie łańcucha dostaw: TanStack, TeamPCP, TrapDoor, GitHub breach.
Sekcja o bezpieczeństwie agentów AI i prompt injection: Comment and Control, TrustFall, Mitiga, Monterrey.
Sekcja o zarządzaniu tożsamością agentów: Entra Agent ID Administrator.
Każda sekcja blueprintu ma odpowiednik w tym co się naprawdę wydarzyło w maju. CERT-In nie opisuje teoretycznych zagrożeń — opisuje zagrożenia które mają już nazwy, numery CVE i listy ofiar.
Co to oznacza poza Indiami
CERT-In jest indyjską agencją i blueprint jest adresowany do indyjskich organizacji. Ale Indie to 1,4 miliarda ludzi, jeden z największych rynków IT na świecie, i kraj gdzie infrastruktura cyfrowa — UPI, Aadhaar, DigiLocker — obsługuje operacje na skalę której nie ma nigdzie indziej.
Infosecurity Magazine wskazuje szerszy kontekst: to jest kolejny krajowy regulator po CISA który wprost powiązał AI z koniecznością zmiany tempa odpowiedzi na podatności. NSA i CISA w wytycznych dla agentów AI z początku majaopisywały problem architektoniczny — jak projektować agenty bezpiecznie. CERT-In opisuje problem operacyjny — jak reagować gdy coś pójdzie nie tak, teraz gdy okno reakcji liczy się w godzinach.
Dwa dokumenty, dwie perspektywy, jeden problem.
Źródła
The Hacker News — pełne omówienie z cytatami z dokumentu: https://thehackernews.com/2026/05/cert-in-mandates-12-hour-patching-for.html
Infosecurity Magazine — szczegóły hierarchii czasowej i kontekst EPSS vs CVSS: https://www.infosecurity-magazine.com/news/cert-in-12-hour-patch-deadline-ai/
GBHackers — pełne wymagania blueprintu i sekcje AI: https://gbhackers.com/cert-in-mandates-12-hour-patch/
CERT-In — pełny dokument "Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure": https://www.cert-in.org.in/
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł