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 MI-eszközöket hívnak segítségül egy-egy fejlesztési feladathoz (kódolás, hibakeresés, sérülékenységkutatás stb.), különösen hajlamosak arra, hogy ne vegyenek tudomást az MI korlátairól. Persze az is elképzelhető, hogy nagyon is tisztán látják, csak egy felületes költség/haszon elemzés után könnyedén átsiklanak a problémán.
Ésszel alkalmazva hasznosak is lehetnének
Azt ma már senki sem vonja kétségbe, hogy ha szerzői jogi szempontból problémásak is a fejlesztéshez készített segédeszközök, mint a GitHub Copilotja, a napi munkához nagyon hasznosak. Már ha a fejlesztő hajlandó figyelembe venni az LLM-ek hiányosságait. Ha azonban nem, akkor bekövetkezik, ami ellen egy ismert szabad szoftveres fejlesztő, a curl és libcurl projektet elindító és irányító Daniel Stenberg kikelt egy blogbejegyzésében: elárasztja a nyílt forráskódú projekteket a "szemét" többek között fals biztonsági hibajelentések formájában.
Mint írja, ezek "a jelentések első ránézésre potenciálisan legitimnek tűnnek, és így időt igényel a cáfolatuk". Ez a nyílt forráskódú projektek esetében különösen nagy gond, mert azok nagyban támaszkodik a közösség önkéntes alapon felkínált erőforrásaira. Önkéntes munkát pedig az emberek akkor szeretnek végezni, ha látják az értelmét, és visszakapnak valamit.
De a csábítás nyilván nagy, hogy az etikus hekkerek bevessenek nem igazán etikus módszereket, hiszen a curl projekt is működtet ún. bug bounty programot (eddig több mint 70 ezer dollár jutalmat fizetett ki). Ugyanakkor a program hatékonyságát jelentősen gyengíti, hogy a beküldött sebezhetőségeknek már a kétharmada volt fals riasztás.
A hibajelentéseket ellenőrzők számára alaptétel, írja Stenberg, hogy minden riasztást valós, tehát ki kell vizsgálni. Ám ez súlyos aszimmetriát eredményez: a bugvadászok MI-vel akarják növelni a hatékonyságukat, és lényegében felelősség nélkül tolják befelé az MI generálta bugreportokat, melyeket az LLM-ek ma már jól olvasható, tagolt szövegek kíséretében képesek előállítani, míg a jelentések ellenőrzését továbbra is emberek végzik, jobbára aprólékos kézműves módszerekkel.
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.
Azt Stenberg is elismeri, hogy az generatív MI sokat javíthat a biztonságon (ahogy persze – elvben – a hekkereket is segítheti). Ehhez azonban ésszel kellene használni, és nem csak a vak tyúk szemtalálási metódusát követve.
Az ilyen hozzáállás azt eredményezi, hogy a beküldött riportokat vizsgáló szakemberek, akinek a feladata lenne a kód karbantartása, gyorsan kiégnek a folyamatos frusztráció és stressz miatt. "Sok szempontból ezeket a gyenge [ti. MI-vel generált] jelentéseket úgy kell kezelni, mintha rosszindulatúak lennének. Még ha nem is ez a szándékuk…" – fogalmaz Stenberg, aki a hibavadászok korábbinál sokkal szigorúbb szűrését és különböző biztonsági intézkedések bevezetését javasolja.
Bár a svéd fejlesztő bejegyzésében az LLM hatását saját szűkebb területén, az open source projekteknél vizsgálta, a problémát könnyű extrapolálni a nagy szoftvergyártó cégek bug bounty programjaira. Nem lenne meglepő, ha hamarosan jelentős módosításokat eszközölnének az olyan hibabejelentő platformok is, mint a HackerOne, a Bugcrowd vagy az Open Bug Bounty.
Felhőbe vezető út hazai szakértelemmel
Robusztus műszaki háttér, korszerű technológia és a felhasználóbarát kezelhetőség. A Flex Cloudhoz nem kell nagy IT-csapat, csak egy elhatározás és pár kattintás.
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak