Autonómne OWASP skenovanie zraniteľností: Ako AI nahrádza bezpečnostné testovanie založené na pravidlách
97 % organizácií by zvažovalo AI-poháňané Penetration Testing, podľa prieskumu z roku 2026 medzi 450 CISO, AppSec inžiniermi a vývojármi. Väčšina ho chce najprv vidieť fungovať súbežne s manuálnymi testermi — ale smer je jasný. Éra čisto pravidlami riadeného skenovania zraniteľností sa končí.
Tradičné OWASP skenery fungujú na princípe porovnávania vzorov: pošlú známy škodlivý payload, skontrolujú očakávanú odpoveď, nahlásia nález. Tento prístup po dve desaťročia zachytával „nízko visiace ovocie“. Ale OWASP Top 10 sa vyvinul — vydanie z roku 2025 zahŕňa kategórie ako Insecure Design a Software Supply Chain Failures, ktoré sa v zásade nedajú detekovať porovnávaním vzorov. A útočníci sa tiež vyvinuli, spájajúc mierne zraniteľnosti do kritických exploitačných ciest, ktoré žiadna databáza signatúr nepredvída.
Autonómne OWASP skenovanie zraniteľností mení model. Namiesto opakovania statických payloadov, AI agenti uvažujú o správaní aplikácie, udržiavajú stav naprieč viacstupňovými interakciami, prispôsobujú svoju testovaciu stratégiu na základe odpovedí a overujú, či sú nálezy skutočne zneužiteľné. Výsledkom je menej False Positives, hlbšie pokrytie a schopnosť nájsť triedy zraniteľností, ktoré skenery založené na pravidlách štrukturálne nedokážu detekovať.
Táto príručka pokrýva, čo autonómne OWASP skenovanie zraniteľností znamená v praxi, ako sa líši od tradičných prístupov, čo OWASP Top 10 z roku 2025 vyžaduje od vašej testovacej stratégie a ako ho implementovať.
Penetrify — AI-poháňané Penetration Testing
OWASP Top 10: 2025 — Čo sa zmenilo a prečo je to dôležité pre skenovanie
OWASP Top 10:2025, vydaný v januári 2026, bol zostavený na základe najväčšieho súboru dát v histórii projektu: viac ako 175 000 záznamov CVE, prieskumov medzi odborníkmi v tisíckach organizácií a vstupov od dodávateľov zabezpečenia a programov bug bounty. Každá kategória sa mapuje na špecifické CWE — celkovo 248 — čo poskytuje presnejšie pokyny pre detekciu ako predchádzajúce verzie.
Pochopenie zmien z roku 2025 je nevyhnutné, pretože odhaľujú limity tradičných prístupov skenovania.
A01: Broken Access Control (Stále č. 1)
Nájdené v 3,73 % testovaných aplikácií, Broken Access Control zostáva najrozšírenejšou kategóriou zraniteľností. Toto vydanie absorbovalo Server-Side Request Forgery (SSRF), predtým samostatnú kategóriu, čo odráža, že SSRF je v zásade zlyhanie kontroly prístupu.
Prečo to predstavuje výzvu pre skenery založené na pravidlách: testovanie kontroly prístupu vyžaduje pochopenie autorizačného modelu aplikácie — ktorí používatelia by mali pristupovať ku ktorým zdrojom za akých podmienok. Skenér môže poslať požiadavku s tokenom používateľa A pre dáta používateľa B, ale potrebuje pochopiť vzťah medzi A, B a zdrojom, aby vedel, či odpoveď predstavuje zraniteľnosť alebo zamýšľané správanie.
Autonómne skenovanie to rieši udržiavaním stavu relácie pre viacerých používateľov, učením sa autorizačného modelu prostredníctvom pozorovania a systematickým testovaním prístupových vzorov naprieč používateľmi a rolami.
A02: Security Misconfiguration (Posun z č. 5)
Security Misconfigurations sa posunuli z piateho na druhé miesto, objavujúc sa v šestnástich CWE. To zahŕňa predvolené poverenia, povolené nepotrebné funkcie, príliš zhovievavé CORS politiky, podrobné chybové správy a chýbajúce bezpečnostné hlavičky.
Skenery založené na pravidlách zvládajú túto kategóriu pomerne dobre — kontrola známych vzorov nesprávnej konfigurácie je priame porovnávanie vzorov. Ale posun na druhé miesto signalizuje, že organizácie stále robia základné chyby, čo naznačuje, že existujúce prístupy skenovania nie sú aplikované dostatočne konzistentne alebo komplexne.
A03: Vulnerable and Outdated Components → Software Supply Chain Failures
Táto kategória bola v roku 2025 výrazne rozšírená a premenovaná. Teraz pokrýva nielen zastarané závislosti, ale celý dodávateľský reťazec: systémy zostavovania, distribučnú infraštruktúru a integritu závislostí. Súvisiace CWE nesú najvyššie priemerné skóre zneužiteľnosti a dopadu v celom zozname.
Tu naráža skenovanie založené na pravidlách na svoje limity. Kontrola známych CVE v deklarovaných závislostiach je základ automatizácie. Detekcia kompromitovaných zostavovacích potrubí, manipulovaných artefaktov alebo škodlivého kódu vstreknutého prostredníctvom útokov na dodávateľský reťazec si však vyžaduje uvažovanie o integrite v celom procese dodávky – nie len zhodu so signatúrou.
A04: Kryptografické zlyhania (Premenované)
Predtým „Citlivé údaje vystavené“, táto premenovaná kategória sa zameriava na hlavnú príčinu: zlyhania v kryptografii, ktoré vedú k vystaveniu dát. Testovanie kryptografických slabín si vyžaduje pochopenie toho, ako aplikácia používa šifrovanie, aké dáta sú chránené a či implementácia dodržiava aktuálne štandardy.
A05: Injekcia (Pokles z #3)
Injekcia klesla o dve miesta, čo odráža zlepšené ochrany na úrovni frameworkov. Moderné frameworky parametrizujú dotazy štandardne, čím sa klasická SQL Injection stáva menej rozšírenou. Injekcia však stále existuje v nových formách: NoSQL injection, LDAP injection, injekcia výrazového jazyka a template injection v frameworkoch pre renderovanie na strane servera.
Autonómne skenovanie tu vyniká, pretože generuje kontextovo citlivé záťaže namiesto opakovania statického zoznamu. Keď narazí na koncový bod podporovaný MongoDB, testuje vzory NoSQL injection. Keď nájde šablónu Jinja2, testuje template injection. Tento adaptívny prístup zachytáva varianty injekcie, ktoré generický zoznam záťaží prehliadne.
A06–A10: Celkový obraz
Nebezpečný dizajn (A06) zásadne spochybňuje skenery – chyby dizajnu nemožno nájsť sondovaním bežiacej aplikácie. Zlyhania identifikácie a autentifikácie (A07), Zlyhania bezpečnostného logovania a monitorovania (A08), Zlyhania integrity softvéru a dát (A09) a nové Nesprávne spracovanie výnimočných podmienok (A10) dopĺňajú zoznam. A10 je obzvlášť zaujímavá: jej 24 CWE sa zameriava na nesprávne spracovanie chýb, logické chyby a zlyhanie v otvorenom stave – vzory zraniteľností, ktoré vyplývajú zo spôsobu, akým aplikácie spracovávajú abnormálne podmienky, nie zo špecifických programovacích chýb.
Príručky k bezpečnostnému testovaniu
Ako funguje tradičné OWASP skenovanie – a kde zlyháva
Pochopenie obmedzení skenovania založeného na pravidlách objasňuje, prečo sa priemysel posúva smerom k autonómnym prístupom.
Model porovnávania vzorov
Tradičný OWASP skener funguje v troch krokoch. Po prvé, prehľadáva alebo prijíma zoznam koncových bodov. Po druhé, odosiela testovacie záťaže zo svojej databázy signatúr – reťazce SQL Injection, XSS záťaže, sekvencie prechodu cestou. Po tretie, analyzuje odpovede na vzory indikujúce zraniteľnosť: chybové správy obsahujúce SQL syntax, reflektovaný obsah skriptu alebo obsah súborov, ktoré by nemali byť prístupné.
Tento model je účinný pre dobre definované zraniteľnosti založené na signatúrach. Klasický reflektovaný XSS, kde sa v odpovedi objaví <script>alert(1)</script>, je ľahko detekovateľný. SQL Injection, ktorá produkuje chybovú správu databázy, je jednoznačná.
Kde zlyháva porovnávanie vzorov
Model zlyháva niekoľkými kritickými spôsobmi.
Zraniteľnosti závislé od stavu zostávajú neodhalené. Mnohé zraniteľnosti OWASP Top 10 vyžadujú udržiavanie stavu naprieč viacerými požiadavkami. Chyba v riadení prístupu sa môže prejaviť iba vtedy, ak sa autentifikujete ako používateľ A a potom pristupujete ku koncovému bodu používateľa B. Tradičný skener odosiela jednotlivé požiadavky – neudržiava stav viacstupňovej interakcie potrebný na objavenie týchto chýb.
Obchodná logika je neviditeľná. Skener nemôže vedieť, že API umožňujúce záporné množstvá v objednávke je zraniteľnosť, alebo že preskočenie kroku 3 v 5-krokovom pracovnom postupe odhalí citlivé údaje v kroku 5. Ide o chyby v návrhu a logike, ktoré si vyžadujú pochopenie zámeru, nie zhodu so vzormi.
Adaptívne odpovede obchádzajú statické payloady. Moderné aplikácie implementujú validáciu vstupu, WAF a filtrovanie odpovedí, ktoré blokujú štandardné payloady skenerov. Aplikácia môže sanitizovať tagy <script>, ale prehliadnuť XSS založené na obsluhách udalostí. Zoznam statických payloadov narazí na sanitizátor a pokračuje ďalej, hlásiac „nie je zraniteľné“. Autonómny skener by pozoroval sanitizáciu, prispôsobil svoj payload (prechodom na vektory `onload=` alebo `onerror=`) a objavil obchádzanie.
False Positives narúšajú dôveru. Skenery založené na vzoroch nadmerne hlásia. Odpoveď obsahujúca reťazec „error“ nemusí byť nevyhnutne zraniteľnosťou. Odpoveď 403 na administrátorskom koncovom bode nemusí nevyhnutne znamenať narušenú kontrolu prístupu. Štúdie dôsledne ukazujú mieru False Positive v rozsahu 30–60 % pre tradičné DAST nástroje. Pri takýchto mierach sa vývojári naučia úplne ignorovať výstup skenera.
Medzery v pokrytí sa hromadia. Skener s 10 000 payloadmi vo svojej databáze dokáže nájsť iba zraniteľnosti, ktoré zodpovedajú týmto 10 000 vzorom. Každá nová trieda zraniteľnosti, každé nové kódovanie, každá chyba špecifická pre aplikáciu je neviditeľná, kým niekto nenapíše nové pravidlo. Medzi aktualizáciami pravidiel máte medzeru v pokrytí.
Porovnať prístupy k testovaniu
Čo robí OWASP skenovanie „autonómnym“
Autonómne OWASP skenovanie zraniteľností nie je len rýchlejšie porovnávanie pravidiel. Je to zásadne odlišný prístup k hľadaniu zraniteľností – taký, ktorý zrkadlí, ako uvažujú a fungujú ľudskí Penetration Testeri.
Behaviorálne uvažovanie vs. Porovnávanie signatúr
Tradičné skenery sa pýtajú: „Zodpovedá táto odpoveď známej signatúre zraniteľnosti?“ Autonómne skenery sa pýtajú: „Na základe toho, ako sa táto aplikácia správa, aké zraniteľnosti tu môžu existovať a ako ich môžem potvrdiť?“
Keď autonómny skener narazí na prihlasovací koncový bod, neskúša len predvolené poverenia a SQL Injection payloady. Pozoruje autentifikačný mechanizmus: je založený na reláciách alebo na tokenoch? Ako token vyprší? Čo sa stane s neplatnými tokenmi? Funguje obmedzenie rýchlosti skutočne, alebo sa resetuje na inom koncovom bode? Každé pozorovanie informuje ďalší test, čím sa buduje behaviorálny model, ktorý odhaľuje zraniteľnosti neviditeľné pre porovnávanie vzorov.
Stavové viacstupňové testovanie
Autonómne skenery udržiavajú stav naprieč interakciami – presne ako ľudský tester. Autentifikujú sa, prechádzajú pracovnými postupmi, udržiavajú tokeny relácií, spracovávajú viacfaktorovú autentifikáciu a sledujú, ako sa stav aplikácie mení s každou akciou.
Táto schopnosť je nevyhnutná pre testovanie hlavných kategórií OWASP. Narušená kontrola prístupu vyžaduje autentifikované relácie naprieč viacerými používateľskými rolami. Zlyhania identifikácie a autentifikácie vyžadujú testovanie kompletných autentifikačných tokov, nie jednotlivých koncových bodov. Chyby v neistom návrhu sa často prejavujú len vtedy, keď sú kroky vykonané v neočakávaných sekvenciách.
Adaptívne generovanie payloadov
Namiesto opakovania pevnej databázy payloadov autonómne skenery generujú payloady na základe špecifického technologického stacku aplikácie, vzorov validácie vstupu a pozorovaného správania.
Keď skener identifikuje, že aplikácia používa MongoDB, generuje NoSQL-špecifické injekčné payloady. Keď pozoruje, že uhlové zátvorky sú filtrované, ale spätné apostrofy nie sú, generuje XSS payloady založené na šablónových literáloch. Keď vidí, že WAF blokuje bežné útočné reťazce, generuje kódované alebo fragmentované payloady navrhnuté tak, aby obišli súbor pravidiel tohto konkrétneho WAF.
Tento adaptívny prístup produkuje oveľa menej False Positives (payloady sú prispôsobené, nie generické) a oveľa menej false negatives (obchádzania sú objavené, nie predpokladané ako neexistujúce).
Validácia exploitov
Najdôležitejší rozdiel: autonómne skenery nielenže označujú potenciálne zraniteľnosti — ale validujú ich prostredníctvom skutočnej exploitácie. Zistenie nahlásené ako „potvrdené ako zneužiteľné“ znamená, že skener úspešne zneužil zraniteľnosť a dokáže preukázať dopad.
Tento validačný krok transformuje výstup skenera z "tu je 200 vecí, ktoré môžu byť zraniteľné" na "tu je 15 potvrdených zraniteľností s proof-of-concept exploitmi." Pomer signálu k šumu sa dramaticky zlepšuje a vývojári dôverujú zisteniam, pretože každé z nich obsahuje dôkazy, ktoré si môžu overiť.
Autonómne skenovanie naprieč OWASP Top 10: 2025
Tu je, ako autonómne skenovanie rieši každú kategóriu spôsobmi, ktoré skenery založené na pravidlách nedokážu.
Nefunkčná kontrola prístupu (A01)
Autonómny prístup: vytvára autentifikované relácie pre každú používateľskú rolu, potom systematicky testuje, či každá rola môže pristupovať k zdrojom patriacim iným rolám. Udržiava stav relácie na testovanie viacstupňových autorizačných tokov. Objavuje zraniteľnosti BOLA, BFLA a eskalácie privilégií prostredníctvom testovania prístupu k zdrojom naprieč rolami.
Obmedzenie založené na pravidlách: môže testovať kontrolu prístupu iba vtedy, ak je vopred nakonfigurovaný s testovacími účtami a explicitnými pravidlami o tom, kto by mal k čomu pristupovať. Nedokáže odvodiť autorizačný model zo správania.
Nesprávna konfigurácia zabezpečenia (A02)
Autonómny prístup: testuje proti komplexným základným líniám zabezpečenia, ale ide ďalej identifikáciou nesprávnych konfigurácií špecifických pre aplikáciu. Objavuje konfigurácie, ktoré sú technicky platné, ale vytvárajú bezpečnostné riziko v špecifickom kontexte nasadenia — ako napríklad politika CORS, ktorá je príliš permisívna pre skutočné klientske pôvody aplikácie.
Obmedzenie založené na pravidlách: kontroluje proti generickému kontrolnému zoznamu nesprávnych konfigurácií. Nedokáže posúdiť, či je konfigurácia vhodná pre architektúru a nasadenie konkrétnej aplikácie.
Zlyhania dodávateľského reťazca (A03)
Autonómny prístup: skenuje deklarované a tranzitívne závislosti na známe CVE, ale tiež validuje, že integrita závislostí je zachovaná — kontroluje, či nainštalované balíky zodpovedajú očakávaným kontrolným súčtom, či sa s artefaktmi zostavenia nemanipulovalo a či riešenie závislostí neťahá z neočakávaných zdrojov.
Obmedzenie založené na pravidlách: kontroluje deklarované závislosti proti databázam CVE. Nedokáže validovať integritu dodávateľského reťazca nad rámec zhody so známymi zraniteľnosťami.
Injekcia (A05)
Autonómny prístup: generuje kontextovo-citlivé injekčné payloady na základe detekovaného technologického stacku. Prispôsobuje payloady, keď sú počiatočné pokusy filtrované. Testuje varianty NoSQL, LDAP, expression language a template injection — nielen SQL a XSS. Validuje úspešnú injekciu prostredníctvom pozorovateľných zmien správania, nielen zhody vzorov odpovedí.
Obmedzenie založené na pravidlách: posiela payloady zo statického zoznamu. Zastaví sa pri prvom filtri alebo bloku WAF. Chýbajú mu varianty injekcie, ktoré nie sú v databáze.
Nesprávne spracovanie výnimočných podmienok (A10 — New)
Autonómny prístup: zámerne spúšťa výnimočné podmienky — nesprávne formátovaný vstup, vyčerpanie zdrojov, súbežné požiadavky, neočakávané prechody stavov — a pozoruje, či aplikácia zlyhá otvorene, uniká informácie prostredníctvom chybových odpovedí, alebo prechádza do nekonzistentných stavov. Táto kategória je jedinečne vhodná pre autonómne testovanie, pretože si vyžaduje kreatívne, behaviorálne sondovanie namiesto porovnávania signatúr.
Obmedzenie založené na pravidlách: môže testovať podrobné chybové správy a niektoré vzory súvisiace s výnimkami, ale nedokáže usúdiť, či spracovanie chýb aplikácie vytvára zneužiteľné podmienky.
Štatistiky zabezpečenia platformy
Implementácia autonómneho skenovania zraniteľností OWASP
Prechod od skenovania založeného na pravidlách k autonómnemu skenovaniu predstavuje praktický pokrok, ktorý stavia na vašej existujúcej bezpečnostnej infraštruktúre.
Fáza 1: Rozšírte, nenahrádzajte
Začnite spustením autonómneho skenovania popri vašich existujúcich nástrojoch. Tento paralelný prístup vám umožní porovnať zistenia, kalibrovať dôveru a identifikovať rozdiel medzi tým, čo zachytia vaše súčasné nástroje a čo objaví autonómne skenovanie. Väčšina tímov zistí, že autonómne skenovanie odhalí o 15 – 30 % viac validovaných zistení, sústredených v kategóriách riadenia prístupu, obchodnej logiky a nových typov injekcií.
Fáza 2: Integrácia do CI/CD
Akonáhle ste kalibrovali autonómne skenovanie pre vašu aplikáciu, integrujte ho do vášho nasadzovacieho pipeline. Rýchle skeny (2 – 5 minút) sa spúšťajú pri každom PR, testujúc zmenené koncové body s adaptívnymi dátovými balíkmi a kontrolami riadenia prístupu pre viaceré roly. Komplexné skeny (30 – 90 minút) sa spúšťajú každú noc, pokrývajúc celý OWASP Top 10 naprieč celým povrchom vašej aplikácie.
Nakonfigurujte brány kvality na základe potvrdených zistení, ktoré sú zneužiteľné, nie potenciálnych zraniteľností. Pretože autonómne skenovanie validuje zistenia prostredníctvom skutočného zneužitia, miera False Positives je dramaticky nižšia ako pri nástrojoch založených na pravidlách – typicky pod 10 % oproti 30 – 60 % pre tradičné DAST.
Fáza 3: Nepretržité autonómne testovanie
Povoľte nepretržité skenovanie na pozadí, ktoré funguje medzi nasadeniami. Tento režim testuje s nižšou intenzitou ako pipeline skeny, ale nepretržite pokrýva celý povrch aplikácie – objavuje zraniteľnosti, ktoré vyžadujú rozšírené sondovanie, zachytáva posun konfigurácie a identifikuje novo zverejnené CVEs vo vašom strome závislostí.
Fáza 4: Využitie behaviorálneho modelu
Postupom času autonómne skenovanie vytvára čoraz podrobnejší behaviorálny model vašej aplikácie. Tento model informuje nielen o objavovaní zraniteľností, ale aj o rozhodnutiach v oblasti bezpečnostnej architektúry: ktoré koncové body spracúvajú najcitlivejšie údaje, kde zložitosť autorizácie vytvára najvyššie riziko a ako sa útočná plocha aplikácie vyvíjala v priebehu času.
Meranie prechodu od skenovania založeného na pravidlách k autonómnemu
Sledujte tieto metriky počas prechodu, aby ste kvantifikovali zlepšenie, ktoré prináša autonómne skenovanie.
Miera validovaných zistení meria, aké percento nahlásených zistení je potvrdených ako zneužiteľných. Skenery založené na pravidlách typicky dosahujú 40 – 70 % (zvyšok sú False Positives). Autonómne skenovanie by malo presiahnuť 90 %, pretože každé zistenie je validované prostredníctvom skutočného zneužitia.
Pokrytie podľa kategórie OWASP sleduje, ktoré kategórie vaše skenovanie efektívne pokrýva. Nástroje založené na pravidlách typicky dobre pokrývajú injekcie, nesprávne konfigurácie a známe CVEs, ale majú problémy s riadením prístupu, chybami v návrhu a logickými problémami. Autonómne skenovanie by malo tieto medzery vyplniť.
Priemerný čas do detekcie meria, ako rýchlo sa nájdu nové zraniteľnosti po ich zavedení. S autonómnym skenovaním integrovaným do CI/CD by to mali byť hodiny – dĺžka času medzi zmenou kódu a ďalším pipeline skenom.
Skóre dôvery vývojárov sleduje, či vývojári reagujú na zistenia. Ak je vaša miera opráv pod 50 %, vaše nástroje majú problém s dôverou – pravdepodobne spôsobený False Positives. Prístup autonómneho skenovania založený na validovaných zisteniach by mal posunúť mieru opráv nad 80 %.
Miera úniku zraniteľností meria, koľko problémov sa dostane do produkcie. Toto je konečná metrika: zachytávate zraniteľnosti predtým, ako sú nasadené? Klesajúca miera úniku v priebehu štvrťrokov potvrdzuje, že autonómne skenovanie funguje.
Často kladené otázky
Ako sa autonómne skenovanie zraniteľností OWASP líši od spustenia OWASP ZAP?
OWASP ZAP odosiela preddefinované užitočné zaťaženia a kontroluje odpovede na základe vzorov. Autonómne skenovanie využíva AI na posudzovanie správania aplikácie, generovanie kontextovo citlivých užitočných zaťažení, udržiavanie stavu naprieč viacstupňovými interakciami a validáciu zistení prostredníctvom skutočnej exploatácie. ZAP vám povie, čo môže byť zraniteľné. Autonómne skenovanie vám povie, čo je potvrdené ako zneužiteľné, a dokáže to.
Pokrýva autonómne skenovanie celý OWASP Top 10?
Áno — vrátane kategórií, s ktorými majú skenery založené na pravidlách problémy. Nefunkčná kontrola prístupu, Nezabezpečený dizajn a nové Nesprávne spracovanie výnimočných stavov, všetky výrazne profitujú z behaviorálneho, adaptívneho testovania namiesto porovnávania signatúr. Zlyhania dodávateľského reťazca sú riešené validáciou integrity nad rámec vyhľadávania v databázach CVE.
Ako dlho trvá autonómne OWASP skenovanie?
Rýchle skeny zamerané na zmenené koncové body sa dokončia za 2–5 minút — vhodné pre každý PR. Komplexné skeny pokrývajúce celý OWASP Top 10 naprieč celou vašou aplikáciou trvajú 30–90 minút a spúšťajú sa podľa nočného plánu. Nepretržité skenovanie na pozadí prebieha medzi nasadeniami s nižšou intenzitou.
Bude autonómne skenovanie generovať viac False Positives ako moje súčasné nástroje?
Menej — výrazne. Pretože autonómne skenovanie validuje zistenia prostredníctvom skutočnej exploatácie namiesto porovnávania vzorov, miera potvrdených zneužiteľných zraniteľností typicky presahuje 90 %. Tradičné DAST nástroje typicky produkujú 30–60 % False Positives. Zníženie „šumu“ je jedným z hlavných hnacích motorov prijatia.
Dokáže autonómne skenovanie nájsť Zero Day zraniteľnosti?
Áno. Pretože autonómne skenovanie posudzuje správanie namiesto porovnávania známych signatúr, dokáže objaviť vzory zraniteľností, ktoré neboli katalogizované v žiadnej databáze CVE ani v súbore pravidiel skenera. Nachádza zraniteľnosti na základe toho, čo robia (odhaľujú dáta, obchádzajú kontroly, umožňujú injekciu), nie na základe toho, či pre ne niekto napísal detekčné pravidlo.