A számla képlete
A „45%" önmagában ijesztő, de nem használható. Számoljuk ki, mit jelent egy valódi csapatnál.
Tegyük fel, hogy havonta 200 olyan kódegységet mergeltek be, aminek érdemi biztonsági felülete van: bemenetkezelés, kimenet-renderelés, adatbázis-lekérdezés, naplózás. Ebből 60% készül AI-asszisztenssel. A 45% generálási feladatokra mért arány, a számolás pedig azt teszi fel, hogy egy ilyen kódegység nagyjából egy generálási feladatnak felel meg.
AI-val készült egység: 200 × 0,60 = 120
Ebből sebezhető (45%): 120 × 0,45 = 54 / hó
Ha a review + a statikus elemzés együtt 80%-ot megfog
(ez nagyvonalú feltevés):
Átcsúszik: 54 × 0,20 = ~11 / hó
Egy év alatt: ~130
(Saját számítás, a feltevések fent. A 45% forrása egy 150-nél több modellen, 80 feladaton végzett longitudinális mérés.)
Havi tizenegy átcsúszó sérülékenység. Ez a számla — és nem az eszköz árában jelenik meg.
De a legfontosabb rész nem a szorzás. Hanem hogy nem a 45% dönt, hanem az, hogy a kódod melyik sérülékenységosztályba esik. Ugyanabban a mérésben a paraméterezett lekérdezésnél 82%, a kriptónál 86% a biztonságos arány — az XSS-nél viszont 15%, a log-injectionnél 13%. Aki HTML-t renderel és naplóz, az a rossz felén van. Aki adatbázissal dolgozik, a jón.
A kockázat súlypontja elmozdult
A terület legismertebb kockázati listája 2026 augusztusában frissült, és a változás beszédesebb, mint a lista maga.
Két mozgás emelkedik ki:
- A túl széles hatáskör („excessive agency") a hatodik helyről a harmadikra jött fel.
- A kimenet helytelen kezelése az ötödikről a tizedikre esett.
Vagyis a szakma szerint a kockázat súlypontja a modell kimenetéről az agent jogosultságaira tolódott. Nem az a fő kérdés többé, mit ír a modell — hanem hogy mit tud megcsinálni vele.
Két dolog, amit érdemes tudni a listáról:
Az évszámok csúsznak. A most aktuális kiadás 2026 augusztusában jelent meg. Az előző, amit mindenki „2025-ösként" idéz, valójában 2024 novemberében készült. Ha valaki „a 2025-ös listára" hivatkozik, jó eséllyel kétéves dokumentumot idéz.
És először van mögötte incidensadat. A mostani kiadásnál a szakértői szavazás 75%-os súlyt kapott, a maradék 25%-ot 6 639 valódi incidens adata adta nyilvános sebezhetőségi adatbázisokból.
A lista keretmondata pedig az egész téma legjobb összefoglalása:
„Ne olyan modellt próbálj építeni, amit nem lehet becsapni. Építsd köré a rendszert úgy, hogy amikor becsapják — és be fogják —, semmi fontos ne törjön el."
Két eset, ami megtörtént
Az elméleti kockázat helyett érdemes két dokumentált esetet megnézni.
A fájl, ami átvette az irányítást
2025 nyarán egy kutató olyan sérülékenységet jelentett be egy népszerű fejlesztői környezet AI-kiegészítőjében, ami tankönyvi példa.
A támadás menete: egy forrásfájlba, weboldalra, hibajegybe vagy eszközválaszba elhelyezett utasítás — akár láthatatlan szövegként — ráveszi az asszisztenst, hogy írja át a projekt beállításfájlját, és kapcsolja be benne az automatikus jóváhagyást. Ez a beállítás a felfedező szavaival „kikapcsol minden felhasználói megerősítést, és onnantól futtathatunk shell-parancsokat, böngészhetünk, és így tovább".
Innen tetszőleges parancs futtatható a fejlesztő gépén. És azért nevezik férgezőnek, mert a kód, amit így ír, tovább is viheti az utasítást.
A gyártó megerősítette és 2025 augusztusában javította. A tanulság viszont nem múlt el: egy repóban lévő fájl szövege utasítás is lehet.
Amikor az agent lett a fegyver
2025 augusztusában egy nagy nyílt forrású csomagcsalád telepítőjébe rosszindulatú kód került. A módszer az, ami miatt ez a cikk gerince lehet.
A kártevő magukat a telepített AI parancssori eszközöket hívta meg — jogosultság-kihagyó kapcsolókkal —, hogy azok keressék meg és olvassák ki a titkokat a fájlrendszerről. Nem sérülékenységet használt ki bennük. Használta őket, rendeltetésszerűen.
A mérleg: több mint ezer érvényes hozzáférési token, több tucat felhőbeli és csomagkezelői kulcs, nagyjából húszezer kiszivárgott fájl, és a második hullámban több mint 5 500 privát repó vált nyilvánossá. A kitettségi ablak az első fázisban nagyjából nyolc óra volt.
Ez a „túl széles hatáskör" tankönyvi esete. A fejlesztői gépen futó agent nem csak hibázhat — eszköz is lehet valaki más kezében.
A határidő, ami már fut
Ez a cikk aktualitása, és 2026 szeptemberében lépett életbe.
Az uniós kiberrezilienciáról szóló rendelet szerint 2026. szeptember 11-től a digitális elemet tartalmazó termékek gyártóinak jelenteniük kell az aktívan kihasznált sebezhetőségeket és a súlyos incidenseket:
| Határidő | Mit kell |
|---|---|
| 24 óra | korai figyelmeztetés, a tudomásszerzéstől |
| 72 óra | teljes bejelentés |
| 14 nap | végleges jelentés aktívan kihasznált sebezhetőségnél, a javítás elérhetővé válása után |
| 1 hónap | végleges jelentés súlyos incidensnél, a 72 órás bejelentéstől |
A bejelentés egy közös platformon keresztül, egyszeri beküldéssel megy. A nyílt forráskódú szoftver-gondnokokra 2027. december 11-től terjed ki.
Fontos: ez rendelet, nem irányelv. Közvetlenül alkalmazandó minden tagállamban, nincs átültetési mozgástér és nincs saját nemzeti határidő. Amit viszont a tagállamnak ki kell jelölnie: hova megy a bejelentés, és ki a piacfelügyeleti hatóság — és ebben nem tart mindenki ugyanott. Nyisd le, amelyik érint:
Magyarország — a kijelölés megvan, a cím is
A bejelentés a Nemzeti Kiberbiztonsági Intézethez megy, amely a Nemzetbiztonsági Szakszolgálat szervezetén belül működik, és amelyet az uniós ügynökség koordinátor CSIRT-ként tart nyilván. A rendelethez tartozó bejelentési cím külön e-mail-cím, nem az általános ügyfélszolgálat.
A nemzeti végrehajtás is megvan: a 2025. évi CXXXV. törvényt az Országgyűlés 2025. december 10-én fogadta el, és december 29-én hirdették ki. A törvény a bejelentő hatósági és piacfelügyeleti hatósági feladatot a Szabályozott Tevékenységek Felügyeleti Hatóságához telepíti — vagyis nem az adatvédelmi hatósághoz és nem is a kiberbiztonsági intézethez.
Kkv-nak ebből annyi számít, hogy a két szerep szét van választva: az incidenst a kiberbiztonsági intézetnek jelented, a termékmegfelelésért viszont egy másik hatóság előtt felelsz.
Spanyolország — a bejelentési kötelezettség fut, a hatóságkijelölés még nem
A bejelentés a spanyol nemzeti kiberbiztonsági intézet vészhelyzeti csoportjához, az INCIBE-CERT-hez megy; ez a koordinátor CSIRT. Ez a rész tehát működik.
A nemzeti kijelölő rendelet viszont 2026 szeptemberében még tervezet. A szöveg a bejelentő hatóság szerepét a Centro Criptológico Nacionalhoz, a piacfelügyeletet a távközlési és digitális infrastruktúráért felelős államtitkársághoz telepítené; a spanyol versenyhatóság 2026. május 13-án véleményezte, de a hivatalos lapban máig nem jelent meg.
Vagyis Spanyolországban a 2026. szeptember 11-i bejelentési kötelezettség élesben fut, miközben a piacfelügyeleti hatóság formálisan nincs kijelölve. Ez nem jelent mentességet: a rendelet kötelezettségei közvetlenül alkalmazandók, csak a hazai végrehajtási oldal késik.
Ennek a gyakorlati következménye nem a jogi megfelelés, hanem a készenlét: huszonnégy óra alatt akkor tudsz jelenteni, ha tudod, mi fut nálad, milyen verzióban, és ki felel érte.
A minimális védelmi rutin
1. AZ AGENT NE KAPJON TÖBBET, MINT AMENNYI KELL.
Ez lett a 3. legmagasabbra sorolt kockázat. Alapértelmezésben
szigorú jóváhagyás, hálózat nélkül, konténerben vagy VM-ben,
ha kockázatos a feladat.
2. A JOGOSULTSÁG-KIHAGYÓ KAPCSOLÓ NEM KÉNYELEM, HANEM DÖNTÉS.
A dokumentált támadás pontosan ezeket használta fel.
3. MINDEN ÚJ IMPORT ELLENŐRZÉSE a csomagregiszterben,
lockfile és hash-ellenőrzés a build-ben.
4. AZ OUTPUT-ENCODING ÉS A NAPLÓZÁS KAP KÜLÖN KÖRT.
15% és 13% a biztonságos arány. Itt a legnagyobb a rés.
5. TITOKKERESÉS A CI-BEN, nem a code review-ban.
Az ember ezt nem fogja megtalálni több száz soros PR-ban.
6. AMI A REPÓBAN VAN, AZ BEMENET.
Issue-szöveg, komment, dokumentáció, eszközválasz - mindegyik
tartalmazhat utasítást. Ne feltételezd, hogy a szöveg adat.
7. LEGYEN TUDOTT, MI FUT NÁLAD ÉS MILYEN VERZIÓBAN.
24 óra alatt jelenteni csak akkor tudsz, ha ez megvan.
Amit ne higgy el magadról
Egy 2023-as felmérésben 404 IT-szakember közül 77% gondolta, hogy az AI-eszközök javítják a kód biztonságát.
Ugyanabban az évben egy kontrollált kísérletben az AI-t használók kevésbé biztonságos kódot írtak — és nagyobb eséllyel hitték, hogy biztonságos kódot írtak.
Ebben a kísérletben volt egy mellékeredmény is, ami a legpraktikusabb tanács az egész témában: akik kevésbé bíztak az AI-ban, és többet foglalkoztak a saját kérésük megfogalmazásával, kevesebb sérülékenységet hagytak a kódban.
Tipikus félreértések
- „A modern modellek már biztonságos kódot írnak." A fordíthatóság sokat javult, a biztonsági arány 2023 óta lényegében lapos.
- „Nagyobb modell, biztonságosabb kód." A modellméretnek nagyon kis hatása van rá.
- „Az AI-kód kockázata elméleti." Két dokumentált eset van: az egyikben egy fájl szövege vette át az irányítást, a másikban a telepített agenteket használták adatlopásra.
- „A prompt injection a chatbotok problémája." A dokumentált eseteknél a hordozó forrásfájl, hibajegy és eszközválasz volt.
- „A CRA majd később jön." A bejelentési kötelezettségek 2026. szeptember 11. óta futnak, és rendeletről van szó — nincs átültetési haladék.
Amit érdemes elvinni
A biztonsági számla nem az eszköz árában van, hanem a havi tizenegy körüli átcsúszó sérülékenységben — és abban, hogy melyik sérülékenységosztályban dolgozol. A kockázat súlypontja a modell kimenetéről az agent jogosultságaira tolódott: a legfontosabb beállítás ma az, hogy mit nem tud megcsinálni az eszköz. És 2026 szeptembere óta a jelentési óra is ketyeg.
Az átvizsgálás konkrét lépéseiről a generált kód átnézése poszt szól; a kitalált csomagnevek külön támadási felületéről pedig a slopsquatting poszt.