Menedzselt vagy spontán MI?
Először is a legegyszerűbb úton indultak: LLM chatbotoknak adtak MI promptokat, hogy írjanak Nuclei sablonokat. A próbálkozások azonban csalódást keltettek: rengeteg nem létező funkciót említettek, érvénytelen szintaxist, gyenge felismerési szabályokat hoztak létre, legyen szó akár ChatGPT-ről, Claude-ról vagy Geminiről.
Ezért következett az agentikus megközelítés, amelyben az MI nemcsak beszélget, hanem képes eszközöket használni, referenciaanyagot keresni és szabályokat követni. A kezdeti szkepticizmus ellenére az eredmények érezhetően javultak. Minimális feladatspecifikációval már ígéretesek lettek a sablonok.
Az agentikus MI-t tovább trenírozták részletes szabályrendszerrel és példákon alapuló tudásbázissal. Ez stabilizálta a működést, csökkentette a hibákat, és egyre közelebb hozta az eredményeket a tapasztalt fejlesztők által készített ellenőrzésekhez. Fontos megjegyezni: a folyamat nem volt teljesen „önjáró”; emberi beavatkozás az utolsó lépésekig szükséges maradt. Így a hangsúly a teljes automatizációról áttevődött arra, hogy az MI-t produktivitási eszközként használják – gyorsabb fejlesztés, változatlan minőség.
Gyakorlati folyamat és sikerek
A jelenlegi munkafolyamatban a mérnökök központi szerepet játszanak: ők adják meg a céloldalakat, a specifikus felismerési típusokat, illetve a kívánt adatokat. Ezek alapján dolgozik az MI-agent a sablonokon, amivel jelentősen gyorsul a fejlesztés, a mérnökök felszabadított ideje pedig elmélyültebb kutatómunkát tesz lehetővé.
Különösen a nagy, ritkán szabványosított felületek leképezésénél erős az MI. Például az admin felületek nyilvános elérésének tömeges detektálása korábban időigényes volt – most pedig nagyságrendekkel több ilyen ellenőrzést alkothatnak automatizált módon.
Ezzel szemben sok, általános szkennerrel nem észlelt alkalmazás is előkerült, hiszen az MI-alapú folyamat hiánypótló ellenőrzéseket eredményez, amivel az ügyfelek jobb képet kapnak a saját támadási felületükről. Ha a VM-szkenner nem jelez egy elérhető adminpanelt, egy nagyvállalat joggal gondolhatja, hogy az nincs is jelen – pedig ott lehet.
Valódi példák: Elasticsearch és MI együttműködésben
Gyors eredmény volt egy nyitott Elasticsearch detektor, ahol a meglévő Nuclei sablon csak részben fedte le a valódi veszélyt: a publikusan elérhető és olvasható adatbázisokat. Itt a feladat ismertetése, tesztcélpontok, valamint példák nyomán az MI, a szükséges szabályok alkalmazásával, készített egy többlépcsős sablont, amely automatikusan végigpróbálja az endpointokat, és konzisztensen felismeri a veszélyes helyzeteket.
A végső sablon képes volt a szükséges adatok kigyűjtésére és a hozzáférés vizsgálatára. Noha a rutin, monoton munka zömét az MI jelentősen megkönnyítette, maradtak kritikus pontok, amelyeket a szakemberek felügyeltek.
Kihívások: határok és buktatók
Az MI még mindig hajlamos elcsúszni, ha nincsenek megfelelő kontrollok. Például gyenge felismerési szabályokkal is továbbengedi az ellenőrzést admin felületeknél, ami veszélyes lehet. Külön figyelmet érdemel, hogy az ilyen helyzeteket gyors utasítással általában lehet orvosolni (pl. egyedi favicon-felismerés hozzáadásával), de nem szabad automatikusan megbízni az MI döntéseiben.
Technikai nehézséget jelent az is, hogy bizonyos parancsok (pl. a curl válaszlevágás tokenmegtakarítás miatt) fontos azonosító jeleket szűrhetnek ki, ami nehezíti az egyedi felismeréseket. Ugyanígy előfordul, hogy az agent a Nuclei saját paramétereit is elfelejti használni, emiatt kézi hurkokat programoz – ezt folyamatos szabályfrissítéssel kell megelőzni.
Automatika vagy szakértelem?
Ennek alapján megállapítható, hogy a teljesen automatikus MI-alapú sérülékenységkezelés pillanatnyilag inkább marketingfogás, mint valóság. Bár vannak látványos eredmények, a szakértői felügyelet elengedhetetlen. Az MI jóval gyorsabbá teheti a fejlesztést, és segítheti az automatizáció felé vezető utat – de a magas színvonalú, testreszabott ellenőrzési sablonokat továbbra is csak szakértő mérnökök tudják biztosítani.
