AI používaná k detekci bezpečnostních problémů
Před pár dny, Daniel Stenberg (autor Curl) oznámil to na svém blogu, příspěvek ve kterém se vyjadřuje nejen jako a kritizuje používání nástrojů umělé inteligence, ale ve formě stížnosti, nepříjemnosti, které to pro něj a jeho tým generuje, bezpečnostní zprávy generované nástroji umělé inteligence.
A ve své publikaci Daniel Stenberg uvádí, že po mnoho let probíhá proces ověřování všech hlášení a vyřazování mezi „nevyžádanými“ a „skutečnými“ bezpečnostními problémy, Nebylo to nic, co by vyžadovalo extra úsilí., protože zmiňuje, že „nevyžádaná hlášení se také obvykle velmi snadno a rychle odhalují a zahazují.“
S nedávným vzestupem umělé inteligenceMnoho úkolů, které dříve vyžadovaly mnoho hodin lidského zásahu, přineslo revoluci. Mezi nejčastěji zmiňovanými případy v tomto blogu jsme se zabývali tématy AI věnovaných programování, generování obrázků a editaci videa, jako jsou mimo jiné ChatGPT, Copilot, Bard.
Ve specifické oblasti programování vyvolal Copilot četné kritiky, přičemž hlavním problémem byla možnost čelit soudním sporům. Na druhém konci žebříčku však zásah umělé inteligence výrazně proměnil různé oblasti. Například při odhalování chyb a bezpečnostních problémů v kódu hrály AI klíčovou roli. Mnoho lidí přijalo tyto nástroje k identifikaci potenciálních chyb a zranitelností v kódu, často se účastní programů odměn pro zjišťování bezpečnostních problémů.
Curl se tomuto trendu nevyhnul a vyjádřil se Daniel Stenberg na svém blogu, Po několika měsících zadržování svého názoru konečně explodoval nesouhlasí s používáním nástrojů umělé inteligence. Důvod vaší frustrace Bylo to rostoucí počet „nevyžádaných“ zpráv generovaných používáním těchto nástrojů.
V publikaci je zdůrazněno, že Tyto zprávy mají podrobný vzhled, jsou psány normálním jazykem a zdají se být vysoce kvalitní. Bez pečlivé analýzy se však ukáže, že jsou zavádějící, protože skutečné problémy nahrazují nekvalitním obsahem, který se jeví jako hodnotný.
El Proyecto Curl, který nabízí odměny za identifikaci nových zranitelností, obdržela celkem 415 hlášení o potenciálních problémech. Z této sady, pouze 64 bylo potvrzeno jako skutečná zranitelnost, 77 popsal chyby nesouvisející se zabezpečením a překvapivě 274 (66 %) neobsahovalo užitečné informace, žrát čas vývojářů, který mohli věnovat něčemu užitečnému.
Vývojáři jsou nuceni ztrácet spoustu času analýzou zbytečných zpráv a opakovanou kontrolou informací v nich obsažených, protože externí kvalita návrhu vytváří další důvěru v informace a existuje pocit, že vývojář něčemu nerozuměl.
Na druhou stranu generování takové zprávy vyžaduje minimální úsilí ze strany žadatele, který se neobtěžuje zkontrolovat, zda existuje skutečný problém, ale jednoduše slepě zkopíruje data obdržená od asistentů AI v naději, že bude mít štěstí. v boji o odměnu.
Daniel Stenberg, Podělte se o dva příklady tohoto typu hlášení odpadu:
- V prvním případě, těsně před plánovaným vydáním informací o kritické zranitelnosti v říjnu, byla prostřednictvím HackerOne přijata zpráva, že již existuje veřejná oprava k vyřešení problému. Zpráva se však ukázala jako „falešná“, protože obsahovala údaje o podobných problémech a úryvky podrobných informací o minulých zranitelnostech, které sestavil asistent umělé inteligence Googlu Bard. Přestože se informace zdály neotřelé a relevantní, postrádaly souvislost s realitou.
- Ve druhém případě byla přijata zpráva o přetečení vyrovnávací paměti při zpracování WebSocket. Tato zpráva přišla od uživatele, který již prostřednictvím HackerOne nahlásil zranitelnosti několika projektům. Aby byl problém reprodukován, zpráva obsahovala obecné pokyny, jak odeslat upravenou žádost, a příklad opravy.
Navzdory důkladné trojité kontrole kódu vývojář nenašel žádné problémy. Vzhledem k tomu, že zpráva byla napsána tak, aby vzbudila „nějakou“ důvěru, a dokonce předložila navrhované řešení, přetrvával pocit, že něco nesedí.
Ve snaze objasnit, jak se uživateli podařilo obejít kontrolu velikosti, je zmíněno, že vysvětlení neobsahovalo žádné další informace a diskutovalo pouze o zjevných běžných příčinách přetečení vyrovnávací paměti, které nesouvisí s kódem Curl. Odpovědi připomínaly komunikaci s asistentem AI a po marných pokusech zjistit, jak přesně se problém projevuje, byl Daniel Stenberg nakonec přesvědčen, že žádná zranitelnost ve skutečnosti neexistuje, a uzavřel téma jako „nepoužitelné“.
A konečně, pokud máte zájem dozvědět se o tom více, můžete se podívat na podrobnosti v následující odkaz.