Ha a sebezhetőségek bejelentése és a tényleges védelem közé időrés kerül, azt a támadók szeretik a legjobban. Az AWS most azt mutatja meg, hogyan próbálja ezt a rést ügynök-alapú (agentic) AI-val bezárni — nem szlogenekkel, hanem szabálygenerálással és teszteléssel.

Mi történt

Az Amazon Science cikke szerint 2025-ben a National Vulnerability Database (NVD) több mint 48 000 új CVE-t (Common Vulnerabilities and Exposures – egységes azonosítóval ellátott nyilvános sebezhetőséget) publikált. A háttérben az áll, hogy az automatizált és AI-támogatott eszközök felgyorsították a sebezhetőségek felfedezését. A biztonsági csapatoknak viszont nem elég „értesülni” róluk: minden egyes hibát le kell fordítani detektálási logikára (azaz olyan szabályokra, amelyek felismerik a kihasználási kísérleteket) — mégpedig elég gyorsan ahhoz, hogy nagy és összetett rendszereket is megvédjenek.

Az AWS erre építette a RuleForge-ot, amit a cikk agentic-AI rendszerként ír le. Gondolj rá úgy, mint egy „szakértői csapatra” bontott AI-munkafolyamatra: nem egyetlen modell próbál mindent megoldani, hanem több, specializált ügynök dolgozik együtt. A cél: példakódokból (proof-of-concept exploitokból) automatikusan detektálási szabályokat generálni. Az Amazon állítása szerint a RuleForge így 336%-os produktivitási előnyt hozott a manuális szabálykészítéshez képest, miközben megtartja a produkciós környezetben szükséges pontosságot.

A cikkből az is kiderül, hogy az Amazonnál a detektálási szabályok JSON formátumban vannak (ez egy gép által könnyen olvasható, strukturált „adatleíró” formátum), és olyan adatokra futnak rá, mint például a MadPot (globális „honeypot”, vagyis digitális csali-rendszer, ami szándékosan kitesz csábító célpontokat, hogy megfigyelje a támadói viselkedést), illetve a belső detekciós rendszerük, a Sonaris által jelzett valószínű exploitkísérletek.

A korábbi, manuális folyamat tipikusan így nézett ki: a biztonsági elemző letöltötte és elemezte a nyilvános exploit mintakódot, megírta a szabályt, lekérdezésekkel mérte a pontosságot forgalmi naplókon, iterált a téves riasztások csökkentésére, majd peer review után élesítette. Ez jó minőségű szabályokat adott, de drága volt időben — ezért priorizálni kellett, mely CVE-k kapjanak védelmet először.

A RuleForge ezt a munkát egy ügynök-alapú pipeline-ná szervezi:

  1. Automatikus begyűjtés és priorizálás: nyilvános proof-of-concept exploitokat tölt le, majd tartalomelemzés és fenyegetettségi információk alapján pontozza őket, hogy a „fontos” esetekre fókuszáljon.
  2. Párhuzamos szabálygenerálás: egy generáló ügynök (AWS Fargate-en futtatva, Amazon Bedrockkel) több jelölt szabályt készít párhuzamosan, és több iterációban finomíthatók.
  3. AI-alapú értékelés külön „bíró” modellel: nem a generáló modell pontozza saját magát, hanem egy külön értékelő ügynök. Két dimenzió mentén vizsgál:
- Sensitivity (érzékenység): mekkora eséllyel nem jelzi a szabály a CVE-ben leírt rosszindulatú kéréseket. - Specificity (specificitás): mekkora eséllyel „mellélő” jellegzetességet céloz (ami csak együtt jár a hibával), nem pedig magát a sebezhetőség kihasználását.
  1. Többlépcsős validáció: szintetikus tesztek (jó- és rosszindulatú minták generálása) után forgalmi naplókon (például MadPot adatokon) ellenőrzik, hogyan viselkedik a szabály. Ami elbukik, visszamegy a generálásba konkrét feedbackkel.
  2. Emberi review és élesítés: a legjobb szabály továbbra is kódreview-n megy át, és az emberi visszajelzés is visszacsatolható a generáló ügynöknek.

Miért fontos

A sebezhetőségek számának növekedése (különösen a magas súlyosságúaké) azt jelenti, hogy a „kézzel mindent lefedünk” megközelítés egyre kevésbé reális. A RuleForge üzenete nem az, hogy az AI kiváltja a security mérnököt, hanem hogy a szabályírást ipari folyamattá lehet szervezni: gép generál és szűr, ember dönt arról, mi mehet produkcióba.

A cikkben külön érdekes a külön bíró modell és a többlépcsős tesztelés hangsúlya. Ez gyakorlatilag annak beismerése, hogy a generatív modellek hajlamosak „hihető” válaszokat adni, de a detekcióban a hihetőség kevés: mérhetően alacsony téves riasztás és jó lefedettség kell. Gondolj rá úgy, mint egy gyártósorra: nem elég, hogy a gép gyorsan önti a darabokat, kell minőségellenőrzés több állomáson.

Mire figyelj

  1. Mit tekintenek „validált” szabálynak a gyakorlatban: a cikk említi a szintetikus teszteket és a naplókon futtatást, de érdemes követni, milyen küszöbök mellett engednek át egy szabályt produkcióba (és hogyan kezelik a ritka, de kritikus false negative eseteket).
  2. A priorizálás minősége: ha a rendszer a nyilvános exploitok alapján dolgozik, kulcskérdés, mennyire jól találja el, mi a valóban releváns fenyegetés — és mi az, ami csak „hangos” a neten.
  3. A specifitás gyakorlati ára: a túl általános szabály sok téves riasztást hoz, a túl szűk pedig könnyen megkerülhető. Érdemes figyelni, hogyan egyensúlyozzák ezt, és mennyi emberi finomhangolás marad a végén.
  4. Mennyire általánosítható a megközelítés: a RuleForge AWS-es környezetben, AWS-es eszközökkel (Fargate, Bedrock) fut. A kérdés az, hogy a módszertan (ügynökök, külön judge, zárt visszacsatolás) mennyire vihető át más szervezetekhez és más detektálási stackekhez.