A mesterséges intelligencia egy hatalmas lendületet adott a biztonsági hibajelentések kezelésének, mintegy forradalmasítva a folyamatot.

A nyílt forráskódú projektek világában, ahol a kód karbantartását gyakran lelkes önkéntesek végzik, különösen kiéleződnek az új kihívások árnyoldalai.

Nap mint nap bebizonyosodik, hogy a generatív mesterséges intelligencia algoritmusok alkalmatlanok az önálló munkára, mert egy kifliről sem képesek megbízhatatóan dönteni. Mégis nagy a csábítás, hogy csak úgy szabadjára engedjük, hogy helyettünk - és nélkülünk - dolgozzanak. Mivel az LLM-ek (large language model) képesek nyelvi értelemben koherens (sőt koherensebb!) szöveget létrehozni, ebből sokan arra következtetnek, hogy ezek az algoritmusok vas logikával és csakis a tényekre támaszkodva gondolkodnak. Pedig valójában ez még azokra a modellekre sem igaz, melyek formális nyelvekkel, például matematikai alapműveletekből és logikai kapcsolatokból építkező programozási nyelvekkel operálnak.

Azok, akik mesterséges intelligencia eszközöket alkalmaznak különböző fejlesztési feladatokhoz, például kódoláshoz, hibakereséshez vagy sérülékenységkutatáshoz, gyakran hajlamosak figyelmen kívül hagyni az MI általános korlátait. Elképzelhető, hogy tisztában vannak ezekkel a határokkal, azonban egy felületes költség- és haszonelemzés után könnyedén átsiklanak a felmerülő problémák felett. Ez a megközelítés ugyanakkor súlyos következményekkel járhat, hiszen a technológia valódi potenciálját csak akkor tudjuk kihasználni, ha reálisan felmérjük a lehetőségeit és a gyengeségeit is.

Ha okosan használjuk őket, valóban értékes eszközökké válhatnak.

Manapság már senki sem kétséges abban, hogy bár a fejlesztéshez készült segédeszközök, mint például a GitHub Copilot, szerzői jogi szempontból problémásnak tűnhetnek, a mindennapi munka során rendkívül hasznosak. Persze ez csak akkor igaz, ha a fejlesztő figyelembe veszi az LLM-ek (nagy nyelvi modellek) korlátait is. Ha viszont figyelmen kívül hagyja ezeket, akkor bekövetkezhet az, amire Daniel Stenberg, a curl és libcurl projekt alapítója és vezetője figyelmeztetett egy blogbejegyzésében: a nyílt forráskódú projekteket elárasztja a "szemét", amelynek részeként hamis biztonsági hibajelentések is megjelenhetnek.

Ahogy említette, ezek a jelentések első pillantásra akár hitelesnek is tűnhetnek, ami miatt időt vesz igénybe, hogy megcáfoljuk őket. Ez különösen aggasztó a nyílt forráskódú projektek szempontjából, hiszen ezek nagymértékben függenek a közösség önkéntes alapon nyújtott erőforrásaitól. Az emberek pedig általában akkor hajlandók önkéntes munkát vállalni, ha érzik, hogy tevékenységüknek van értelme, és valamilyen módon viszonzást kapnak érte.

A csábítás nyilvánvalóan erős, amikor az etikus hekkerek esetleg nem éppen etikus megoldásokhoz nyúlnak, hiszen a curl projekt is működtet egy bug bounty programot, amely eddig több mint 70 ezer dollár jutalommal jutalmazta a felfedezett hibákat. Ugyanakkor a program hatékonyságát jelentősen csökkenti, hogy a beérkezett sebezhetőségek körülbelül kétharmada valójában hamis riasztásnak bizonyult.

A hibajelentések ellenőrzésének alapelve, ahogy azt Stenberg megfogalmazza, hogy minden egyes riasztást alaposan meg kell vizsgálni, hiszen mindegyik mögött valós probléma rejlik. Ez azonban jelentős aszimmetriát teremt a folyamatban: a hibakeresők mesterséges intelligenciát alkalmaznak a hatékonyságuk növelésére, miközben szinte felelőtlenséggel terhelve a rendszert, az MI által generált hibajelentéseket zúdítják a rendszerbe. Ezeket a jelentéseket az LLM-ek már olyan jól strukturált és érthető formában tudják előállítani, hogy szinte maguktól értetődővé válnak. Ezzel szemben a jelentések ellenőrzését továbbra is emberek végzik, akik a részletekre odafigyelve, hagyományos, aprólékos módszerekkel dolgoznak.

Ez a projektet tapodtat sem viszi előre, ám a kontribútorok idejét és energiáját elveszi a produktív feladatoktól. A bejelentések ellenőrzését akkor is el kell végezni, ha ordít róla, hogy nem igaz. Az open source projekteknél ugyanis a bizalom mindig kulcskérdés - és a bizalom talál legfontosabb forrása, hogy egy adott projekt körül kialakuló közösség kiemelten kezeli a biztonságot.

A vehemensebb hibavadászok még vitáznak is - chatbottal

Azok, akinek nagyobb tapasztalata az ilyen hibajelentések ellenőrzésében, viszonylag gyorsan kiszúrják, ha valami kamu. Jellemző például, hogy az MI régi biztonsági problémák leírásaiból kiindulva kompilál valami új jelentést, ami köszönő viszonyban sincs a valósággal. A hibát ellenőrző azonban nem mehet el mellette szó nélkül, azaz csekkolja, hogy valóban nem létezik a bug, és reagálnia is kell. Ám a bejelentők ilyenkor sokszor beizzítanak valami MI-alapú chatbotot, amely szájkaratéba kezd a hiba ellenőrzőjével, akinek így még több ideje megy el fölöslegesen.

Stenberg is elismeri, hogy a generatív mesterséges intelligencia jelentős mértékben hozzájárulhat a biztonsági intézkedések javításához, ugyanakkor nem elhanyagolható az a tény sem, hogy a hekkerek számára is hasznos eszközzé válhat. Ahhoz, hogy valóban előnyünkre váljon, tudatos és átgondolt módon kell alkalmaznunk, elkerülve a véletlenszerű és céltalan próbálkozásokat.

Ez a hozzáállás oda vezet, hogy a riportokat ellenőrző szakemberek, akiknek az lenne a feladatuk, hogy a kódot karbantartsák, gyorsan kiégnek a folyamatos frusztráció és stressz következtében. "Sok szempontból ezeket a gyenge [ti. MI-vel generált] jelentéseket úgy kellene kezelni, mintha szándékosan rosszindulatúak lennének. Még ha nem is ez a céljuk..." - emeli ki Stenberg, aki sürgeti a hibavadászok szigorúbb szűrését és különféle biztonsági intézkedések bevezetését.

Bár a svéd fejlesztő írása főként az LLM hatását a saját szakterületén, az open source projekteknél elemezte, a felvetett problémát könnyedén kiterjeszthetjük a nagy szoftvervállalatok bug bounty programjaira is. Nem lenne meglepő, ha a közeljövőben jelentős változtatásokat látnánk olyan hibabejelentő platformokon, mint a HackerOne, a Bugcrowd vagy az Open Bug Bounty.