Ha minden a mesterséges intelligenciáról szól, miért ne kerülne elő a téma a biztonsággal kapcsolatban? Ma már nincs olyan kiberbiztonsági terület, ahol valamilyen összefüggésben – akár támadási vektorként, akár védelmi lehetőségként – ne merülne fel. Megjelenése különösen érzékenyen érint olyan területeket, melyeken a vállalatok amúgy is bizonytalanul járnak. Az egyik legnagyobb figyelmet igénylő ezek közül az alkalmazásbiztonság.

Az okra a Gartner egy tavaly ősszel publikált tanulmánya (Application Security Strategy 2026: AI, DevSecOps and Platform Consolidation) ad egy magyarázatot: a szervezetek 43 százalékánál az alkalmazásbiztonság épp hogy elérte az alap érettségi szintet.

Miközben a szervezetek lépésről lépésre, de meglehetősen lassan haladnak előre ezen a területen, az MI – ahogy a BSIMM16 jelentésből kiderül – villámgyorsan és alapjaiban írja át az alkalmazásbiztonság szabályait. Az alkalmazásbiztonság már nem fejlődik, legalábbis az, amit eddig a fogalom alatt értettünk, mert az LLM-ek megjelenése újraírta – fogalmaz sarkosan a kutatás.

CISO és CIO azonos platformon

Az új helyzetre a Gartner szerint akkor lehet hatékonyan reagálni, ha az IT-vezetők figyelembe vesznek három alapvető változást. Először is elfogadják az MI kettős hatását: egyszerre gyorsítja a fejlesztést, és jelent új – talán minden korábbinál veszélyesebb – fenyegetésvektort. Másodszor: a DevSecOps nem csupán a fejlesztés, a biztonság és az üzemeltetés integrált működését írja le, hanem a jobb fejlesztői élmény alapja is lett. Végül, de nem utolsósorban: biztonsági területen is elkerülhetetlen a platformkonszolidáció, aminek eredményeként egy platformba integrálódik az alkalmazásbiztonság és a CNAPP (Cloud-Native Application Protection Platform).

Az MI kettős hatása könnyen belátható: ha a kódolóasszisztensek rövidítik a time-to-marketet, miért lenne ez másként a fenyegetések esetében? De más veszélyforrás is van, a vezető LLM-fejlesztők hájpolta vibe coding (lásd a Gartner vonatkozó hype cycle ábráját) miatt az alkalmazások ellenőrzés nélkül és ezáltal egyre több sebezhetőséggel kerülnek át élesbe, ezt a kódolási módszert ugyanis azok vagy főleg azok használják, akik nem jártasak a kódolásban (mint azzal korábban foglalkoztunk, épp a tapasztalt fejlesztők azok, akinek a kezében a kódolást támogató megoldások valóban hasznos eszközök lesznek). Ezzel függ össze az MI ügynökökkel kapcsolatos problémák, melyek a hozzáférés-vezérlési problémák miatt szinte hívogatják majd a támadókat – lásd az OpenClaw esetét.
 

(Kattints a képre a nagyobb mérethez! Forrás: Gartner)

Az rossz taktika, ha ez ellen az MI tiltásával védekezik egy cég, mert azzal csak fokozza a kockázatokat az árnyék MI terjedése miatt. Megoldás lehet az MI kódbiztonsági asszisztensek  (AI Code Security Assistants – ACSA) bevezetése, melyek automatikusan javaslatot tesznek a sebezhetőségek javítására.

Változik a DevSecOps szerepe. Megmarad az a szemlélet, hogy a biztonság a kódolásnál kezdődik, de annak a felelőssége már nem csak a fejlesztőt terheli. Megelőzendő a túlterhelést (és az emiatt figyelmen kívül hagyott sebezhetőségeket) be kell vezetni valamilyen ASPM (Application Security Posture Management – alkalmazásbiztonsági állapotkezelés) megoldást. Az ASPM segít azonosítani a valós sebezhetőségeket, és automatizált ellenőrzéseket épít a CI/CD folyamatokba.

Végül, de nem utolsósorban: el kell felejteni az elszigetelt biztonsági megoldásokat, javasolja a Gartner. A piac is ezt követi: a gyártók igyekeznek a funkciókat egységes alkalmazásbiztonsági platformokba integrálni. De nem csak a funkciók integrálódnak, egyre inkább elmosódik a kód és az infrastruktúra közötti határvonal, aminek eredményeként az alkalmazásbiztonsági platformok is részeivé válnak a CNAPP-nak.

Voltaképpen ez teremti meg annak a keretét, hogy a kódtól a munkaterhelésig maximális védelmet kapjanak a rendszerek. Ez egyszerűsíti a felügyeletet, és csökkenti a védelmi eszközök fenntartási költségeit.

Szaporodnak a jó gyakorlatok

A BSIMM (Building Security in Maturity Model) jelentésekből jó nyomon követhető, miként alakul át az alkalmazásbiztonságról való gondolkodás az elmúlt másfél évtizedben. Az éve elején megjelent 16. kiadás (PDF) a Gartner megállapításaival összhangban a vállalatok jó gyakorlatait elemezve szűri le: a mesterséges intelligencia legalább akkora változásokat hoz az alkalmazásbiztonságban, mint bő másfél évtizede a felhőalapú architektúrákra való áttérés az általános vállalati IT-ban.

A technológia kétarcúsága is megjelenik. A jelentés egyfelől hatalmas lehetőségként írja le, amellyel egyszerre gyorsítható az innováció, és csökkenthetők a kockázatok. Másfelől a helytelen hozzáállás rejtett sebezhetőség tömegét hozhatja a rendszerekbe, azaz a mesterséges intelligencia válhat a legnagyobb támadási felületté.

Az LLM-alapú kódolástámogató asszisztensek generálta kód ugyanis alapértelmezés szerint nem biztonságos – még akkor sem, ha tisztának és professzionálisnak tűnik. Gyakori, hogy a kódolási segéd kihagy kulcsfontosságú biztonsági ellenőrzéseket, vagy olyan rejtett logikai hibákat vét, amiket az automatizált szkennelés nem szűr ki, ám később sérülékenységgé válhatnak. Magyarán: miközben szédületes tempóra vált a fejlesztés, ugyanilyen tempóban érkeznek az egyre nehezebben azonosítható sebezhetőségek.

Eezt csak úgy lehet kezelni, ha a szervezeteknek fenyegetési modelljeiket új elemekkel bővítik. Fel kell készülniük például prompt injekciós és modellmanipulációs támadásokra, az MI-támogatással létrehozott támadó kódok kivédésére, valamit az olyan sérülékenységek kezelésére, melyek számát a fejlesztők mellett most már az MI-asszisztensek is gyarapítják.

Governance és compliance

A mesterséges intelligencia mellett az irányítással kapcsolatos elvárások és szabályozói környezet – részben az MI miatt – szintén jelentős hatást gyakorol a védelmi rendszerekkel szemben támasztott követelményekre. A szabályzó hatóságok folyamatosan szigorítják a szoftverbiztonsági előírásokat, gondoljunk csak a NIS2-re vagy a DORA-ra. Ezek mindegyike afelé tolja a szervezeteket, hogy a korábbinál nagyobb figyelmet fordítsanak a fejlesztési végpontok, valamint a build és deployment eszközök és folyamatok védelmére. Vagy: kulcskérdéssé válik a szoftver megfelelőségének dokumentálása, hogy egy másik következményt említsük.

Ebben a kontextusban különösen érdekes az automatizálás. Az ugyanis – épp a fentiek következményeként – nem opcionális, hanem az alkalmazásbiztonság gerince. A szervezetek érzékelhetően mozdulnak ebbe az irányba, mert felismerték, hogy a manuális ellenőrzés nem tud lépést tartani az MI-támogatott fejlesztés sebességével. Az MI gépi sebességgel ír kódot – amihez automatizált, gépi sebességű biztonsági kontrollokat kell alkalmazni.

Felértékelődött az SBOM (software bill of materials) leltárak használata. A fejlesztés ugyanis egyre nagyobb mértékben támaszkodik előre elkészített, harmadik féltől származó (gyakran nyílt forráskódú) komponensekre, melyek egyben sebezhetőségeket, potenciális belépési pontokat kínálnak a kiberbűnözőknek.

Az SBOM a szoftverkomponensek átláthatóságának és a függőségeknek a kezelését támogatja, kódszinten javítva az alkalmazásbiztonságot. (Sok helyütt ezt megfejelik azzal, hogy az MI generálta kódokra szofisztikált egyéni biztonsági szabályokat vezetnek be.) Ezzel párhuzamosan az automatizált infrastruktúra-biztonsági kontrollokat, valamint a CI/CD pipelinba ágyazott ún. governance‑as‑code irányítási megközelítést is egyre több szervezet alkalmazza.

És a tanulság? Ahogy egy gyártói útmutató fogalmaz: az alkalmazásbiztonság a részletekben rejlik. Ezt annyival egészíthetnénk ki, hogy ezeket a részleteket egységben kell látni és kezelni. Nem feltételzeni kell a biztonságot, hanem bizonyítani.

Ez a cikk független szerkesztőségi tartalom, mely a Clico Hungary támogatásával készült. Részletek »