AI naudojamas saugumo problemoms aptikti
Prieš kelias dienas, Danielius Stenbergas (Garbanos autorius) paviešino savo dienoraštyje, įrašą kurioje ji išreiškia ne tik kaip a kritikuoja dirbtinio intelekto priemonių naudojimą, bet skundo forma, nepatogumai, kuriuos tai sukelia jam ir jo komandai, saugos ataskaitas, kurias generuoja dirbtinio intelekto įrankiai.
Ir savo publikacijoje Danielis Stenbergas mini, kad daugelį metų buvo tikrinamos visos ataskaitos ir išmetamos tarp „šiukšlių“ ir „tikrųjų“ saugumo problemų, Tai nereikėjo papildomų pastangų., nes jame minima, kad „nemokamų pranešimų taip pat paprastai buvo labai lengva ir greitai aptikti ir išmesti“.
Neseniai išpopuliarėjus dirbtiniam intelektui, daugelis užduočių, kurioms anksčiau reikėjo daug valandų žmogaus įsikišimo, buvo pakeistos. Tarp dažniausiai minimų atvejų šiame tinklaraštyje nagrinėjome AI, skirtų programavimui, vaizdų generavimui ir vaizdo redagavimui, temas, tokias kaip ChatGPT, Copilot, Bard ir kt.
Konkrečioje programavimo srityje „Copilot“ sulaukė daug kritikos, o pagrindinis rūpestis buvo galimybė susidurti su teisiniais ieškiniais. Tačiau kitame skalės gale dirbtinio intelekto įsikišimas gerokai pakeitė įvairias sritis. Pavyzdžiui, aptinkant klaidas ir saugos problemas kode, AI atliko lemiamą vaidmenį. Daugelis žmonių naudoja šias priemones, kad nustatytų galimas kodo klaidas ir pažeidžiamumą, dažnai dalyvaudami premijų programose, skirtose saugumo problemoms aptikti.
Curl neišvengė šios tendencijos, – išreiškė Danielis Stenbergas savo dienoraštyje, kad Po kelių mėnesių susilaikymo nuo savo nuomonės jis pagaliau sprogo nesutinka su dirbtinio intelekto priemonių naudojimu. Jūsų nusivylimo priežastis buvo didėjantis „šiukšlių“ ataskaitų, sugeneruotų naudojant šias priemones, skaičius.
Leidinyje pabrėžiama, kad Šios ataskaitos turi išsamią išvaizdą, yra parašyti įprasta kalba ir atrodo aukštos kokybės. Tačiau be kruopštaus tyrimo paaiškėja, kad jie yra klaidinantys, nes tikros problemos pakeičiamos žemos kokybės turiniu, kuris atrodo vertingas.
El proyecto Curl, kuri siūlo atlygį už naujų pažeidžiamumų nustatymą, iš viso gavo 415 pranešimų apie galimas problemas. Iš šio rinkinio tik 64 buvo patvirtinti kaip tikri pažeidžiamumai, 77 aprašytos su saugumu nesusijusios klaidos ir, stebėtinai, 274 (66 proc. nebuvo naudingos informacijos, eikvoja kūrėjų laiką, kurį būtų galima skirti kažkam naudingam.
Kūrėjai yra priversti gaišti daug laiko analizuodami nenaudingas ataskaitas ir pakartotinai tikrindami jose esančią informaciją, nes išorinė dizaino kokybė sukuria papildomą pasitikėjimą informacija ir kyla jausmas, kad kūrėjas kažko nesuprato.
Kita vertus, tokios ataskaitos sukūrimas reikalauja minimalių pastangų iš užklausančiojo, kuris nesivargina patikrinti, ar tikrai problema, o tiesiog aklai kopijuoja iš AI padėjėjų gautus duomenis, tikėdamasis, kad pasiseks. kovoje gauti atlygį.
Danielis Stenbergas, Pasidalykite dviem šio tipo šiukšlių ataskaitų teikimo pavyzdžiais:
- Pirmuoju atveju, prieš pat planuojamą informacijos apie kritinį pažeidžiamumą paskelbimą spalio mėn., per „HackerOne“ buvo gautas pranešimas, nurodantis, kad problemai išspręsti jau yra vieša pataisa. Tačiau pranešimas pasirodė esąs „netikras“, nes joje buvo duomenų apie panašias problemas ir išsamios informacijos apie praeities pažeidžiamumą fragmentai, kuriuos surinko „Google“ dirbtinio intelekto asistentas Bardas. Nors informacija atrodė nauja ir aktuali, ji neturėjo ryšio su realybe.
- Antruoju atveju buvo gautas pranešimas apie buferio perpildymą tvarkant WebSocket. Šią ataskaitą pateikė vartotojas, kuris per „HackerOne“ jau pranešė apie kelių projektų pažeidžiamumą. Siekiant atkurti problemą, ataskaitoje buvo pateiktos bendros instrukcijos, kaip pateikti pakeistą užklausą, ir pataisymo pavyzdys.
Nepaisant kruopštaus kodo patikrinimo tris kartus, kūrėjas nerado jokių problemų. Tačiau kadangi ataskaita buvo parašyta taip, kad sukeltų „šiek tiek“ pasitikėjimo ir net buvo pasiūlytas sprendimas, jausmas, kad kažkas ne taip, liko.
Siekiant išsiaiškinti, kaip vartotojui pavyko apeiti dydžio patikrą, minima, kad paaiškinimuose nebuvo papildomos informacijos ir aptariamos tik akivaizdžios dažniausios buferio perpildymo priežastys, nesusijusios su Curl kodu. Atsakymai priminė bendravimą su dirbtinio intelekto asistentu, o po bergždžių bandymų išsiaiškinti, kaip ši problema išryškėjo, Danielis Stenbergas galiausiai įsitikino, kad pažeidžiamumo iš tikrųjų nėra, ir uždarė temą kaip „netaikoma“.
Galiausiai, jei jus domina galimybė apie tai sužinoti daugiau, išsamią informaciją galite rasti sekanti nuoroda.