AI írja a kódot – de ki garantálja a biztonságát?

2026.10.27

Az AI ma már a fejlesztők napi eszköze, az ellenőrzés viszont sok helyen nem tartott vele lépést. A válasz nem az AI tiltása, hanem a struktúra és a független ellenőrzés.

Ez volt a fő üzenete annak az előadásnak, amelyet Dr. Kabai Márton Tamás, a Szitár-Net Kft. ügyvezetője tartott 2026. október 26-án a VISZ Kiberbiztonsági Szakmai Fórumon. Az előadás címe egy kérdés volt: AI írja a kódot – de ki garantálja a biztonságát? Ebben a cikkben összefoglaljuk a legfontosabb gondolatokat, a cikk végén pedig letölthető a teljes prezentáció.

Az AI már napi gyakorlat – az ellenőrzés még nem

A Stack Overflow 2025-ös fejlesztői felmérése szerint a fejlesztők 84%-a használ vagy tervez használni AI-eszközt, a hivatásos fejlesztők 51%-a már naponta. Egy évvel korábban ez az arány még 76% volt.

A bizalom viszont nem nőtt ilyen ütemben. A Sonar 2026. januári felmérése (több mint 1100 fejlesztő) szerint 96%-uk nem bízik teljesen az AI által írt kód helyességében, mégis csak 48% ellenőrzi mindig, mielőtt beküldi. A beküldött kód 42%-a már AI-val készül, és a fejlesztők 2027-re 65%-ot várnak.

A következtetés egyszerű: az AI alkalmazásával együtt az ellenőrzési gyakorlatot is fejleszteni kell.

A működő kód még nem biztonságos kód

Az újabb modellek pontosabban kódolnak, de ettől még nem biztonságosabban. A Sonar saját mérésében 4444 Java-feladaton hasonlította össze a GPT-5.5 és a GPT-5.6 Sol modellt. A funkcionális tesztek sikeressége 78,66%-ról 81,99%-ra javult, közben azonban a sérülékenységi találatok sűrűsége millió kódsoronként 68-ról 197-re nőtt, ami körülbelül 2,9-szeres. A blokkoló súlyosságú sérülékenységek száma ugyanakkor 18-ról 9-re csökkent: a kockázat nem eltűnt, hanem átkerült olyan területekre, amelyeket az emberi átnézés könnyebben elnéz.

A tanulság: modellfrissítés után a kód biztonsági profilját újra kell mérni, mégpedig a modelltől független eszközzel.

Két független kutatás is hasonló képet mutat:

Egy 2026. januári tanulmány szerint a GPT-4o és az o3-mini strukturált biztonsági útmutatás nélkül írt PowerShell-szkriptjeinek több mint 60%-a nem biztonságos.
A USENIX Security 2025 konferencia díjazott vizsgálata szerint a nyílt modellek által ajánlott szoftvercsomagok átlagosan 21,7%-a nem is létezik. Ha egy támadó ilyen néven feltölt egy csomagot, a gyanútlanul telepített függőség kártékony kódot hozhat a rendszerbe.

Az előadásban bemutatott tíz kockázat Shaked Reiner előadására épült, köztük a modellváltás hatása, a gyengülő emberi kontroll és az érdekellentét, amikor ugyanaz a szolgáltató írja, ellenőrzi és javítja a kódot.

A kontroll ott vész el, ahol a mennyiség átnézhetetlen

Az AI több kódot termel, mint amennyit ember érdemben át tud nézni. Shaked Reiner szavaival: gyorsabban halmozzuk fel a kódot, mint ahogyan képesek vagyunk megérteni. Ahol a mennyiség már túl nagy, ott a kézi átnézés mellé automatizált ellenőrzési pontok kellenek.

Az ellenőrzésnek ugyanakkor függetlennek kell lennie a kód szerzőjétől. Reiner másik mondata az előadás egyik központi gondolata lett: ne ugyanaz a szolgáltató ellenőrizze a kódot, amelyik megírta. A felelősség az AI használatával sem kerül át az eszközre: a döntés emberi marad.

SonarQube és a DORA

A pénzügyi szektorban a forráskód-ellenőrzés már nem csak jó gyakorlat, hanem elvárás. A DORA 2025. január 17. óta alkalmazandó, a fejlesztésre vonatkozó részletes szabályokat pedig a 2024/1774-es felhatalmazáson alapuló bizottsági rendelet írja le. A SonarQube ezek közül több elvárás teljesítését is támogatja:

DORA-elvárás	Hivatkozás	SonarQube-támogatás
Statikus forráskód-vizsgálat; a sérülékenységek elemzése, cselekvési terv, követés	16. cikk (3)	Statikus elemzés és hibakezelés
Biztonsági tesztelés legkésőbb az integrációs fázisban	16. cikk (4)	Elemzés minden pull requesten és a CI-ban
Minden változásnál a biztonsági követelmények ellenőrzése	17. cikk (1) a)	Quality gate (minőségi kapu)
Külső és nyílt forrású kód tesztelése, a könyvtárak nyomon követése	16. cikk (8), 10. cikk (2) d)	Advanced Security: SCA, SBOM
A követés igazolása	16. cikk (3)	Megfelelési és PDF-riportok (Enterprise edíciótól)

A dinamikus tesztelést, a forráskód sértetlenségének védelmét és az incidenskezelést nem a SonarQube fedi le. A megfelelésért a pénzügyi intézmény felel: a SonarQube eszköz, nem tanúsítvány.

Advanced Security: a kód alatti rétegek

A saját kód csak a felső réteg. Alatta ott vannak a projektbe behúzott könyvtárak, és azok függőségei is, az úgynevezett tranzitív függőségek. A SonarQube Advanced Security fizetős kiegészítő az Enterprise edíciótól, és ezt a réteget teszi láthatóvá:

SCA (függőségelemzés): ismert sérülékenységek a direkt és a tranzitív függőségekben, kártékony csomagok, a szervezet licencszabályait sértő licencek. Az elérhetőség-elemzés azt is megmutatja, meghívja-e a kódunk a sérülékeny függvényt.
SBOM (szoftver-anyagjegyzék): a teljes függőségkészlet exportja CycloneDX vagy SPDX formátumban.
Intelligens SAST: a taint-elemzés a saját kódból a külső könyvtárak kódjába is követi a felhasználói bemenetet.

Banki és közigazgatási ügyfeleknél az első kérdés mindig az, hogy kimegy-e a forráskód. Az SCA alapértelmezett működésében a manifest- és lockfájlokat a bank saját SonarQube Servere dolgozza fel, a Sonar felé csak a sérülékenység- és licencadat lekérdezése megy, forráskód nem. Az új sérülékenységek naponta, újraelemzés nélkül is megjelennek.

A SonarQube AI-eszközei

A SonarQube Server 2026.5-ben hat AI-eszköz segíti a fejlesztést, mindegyik a folyamat más pontján. Az alap mindenhol a SonarQube független, determinisztikus elemzése: az AI-eszközök erre épülnek, nem helyettesítik.

Eszköz	Mit csinál?	Hol lép be?
AI Code Assurance	Megjelöli az AI-kódot tartalmazó projektet, és AI-ra szabott minőségi kaput ad rá	Quality gate, pull request
AI CodeFix	Egy hibára javítást javasol; a modell választható, akár saját, internet nélkül is	Fejlesztői környezet, SonarQube felület
Remediation Agent	Kijavítja a hibát, és pull requestet nyit; beolvasztani csak ember fog	Bukott quality gate, backlog
Hunter Agent	Logikai és jogosultsági hibákat keres, amelyeket a statikus elemzés nem lát	Fő ág
Sonar Vortex	Az AI-ügynöknek írás előtt irányt ad, írás után ellenőriz	Kódolás, az ügynökön belül
MCP Server	Összeköti az AI-ügynököt a SonarQube-bal; csak olvasás módban is futtatható	Kódolás

A Hunter Agent, a Remediation Agent és a Sonar Vortex külön előfizetés az Enterprise vagy Data Center edíció mellé, és a bank saját infrastruktúráján futnak.

Mit érdemes hazavinni?

Az előadás öt javaslattal zárult, amellyel bármelyik fejlesztő csapat már holnap elindulhat:

Strukturált AI-használat: le kell írni, milyen eszközt, mire és milyen adattal használunk, és ki felel érte.
Ellenőrzés minden AI-eredményre: a mennyiséget gép ellenőrzi, a döntés emberi marad.
Más modellel ellenőriztessünk: ne ugyanaz a modell vagy szolgáltató nézze át a kódot, amelyik írta.
Statikus kódelemzés AI-támogatással: a független elemzés adja az alapot, erre épülnek az AI-képességek.
Mérjünk és kövessünk: modellváltás után mérjük újra a kódot, és tartsuk naprakészen a függőségek listáját.

Az előadás üzenete egy mondatban: Struktúra + független ellenőrzés = biztonságos AI-fejlesztés – úgy, hogy a forráskód bent marad.

A prezentáció letöltése

AI írja a kódot – de ki garantálja a biztonságát? (PDF, 2,7 MB)