Tekoälyä käytettiin tietoturvaongelmien havaitsemiseen
Muutama päivä sitten, Daniel Stenberg (Curlin kirjoittaja) teki siitä tunnetuksi blogissasi, viesti jossa se ilmaisee paitsi a kritisoi tekoälytyökalujen käyttöä, mutta valituksen muodossa, sen hänelle ja hänen tiimilleen aiheuttama vaiva, tekoälytyökalujen luomat tietoturvaraportit.
Ja julkaisussaan Daniel Stenberg mainitsee, että useiden vuosien ajan kaikkien raporttien tarkistaminen ja hylkääminen "roskan" ja "oikeiden" turvallisuusongelmien välillä, Se ei vaatinut ylimääräistä vaivaa., koska siinä mainitaan, että "roskapostiraportit ovat myös yleensä olleet erittäin helppoja ja nopeita havaita ja hylätä."
Tekoälyn viimeaikaisen nousun myötä, monet tehtävät, jotka aiemmin vaativat monta tuntia ihmisen väliintuloa, ovat mullistaneet. Tämän blogin eniten mainittujen tapausten joukossa olemme käsitelleet ohjelmointiin, kuvien luomiseen ja videoeditointiin omistettuja tekoälyjä, kuten ChatGPT, Copilot, Bard jne.
Tietyllä ohjelmoinnin alueella Copilot aiheutti lukuisia kritiikkiä, joista suurin huolenaihe oli mahdollisuus kohdata oikeusjuttuja. Asteikon toisessa päässä tekoälyn interventio on kuitenkin muuttanut merkittävästi eri alueita. Tekoälyillä on ollut keskeinen rooli esimerkiksi koodin virheiden ja tietoturvaongelmien havaitsemisessa. Monet ihmiset ovat ottaneet käyttöön nämä työkalut tunnistaakseen mahdollisia virheitä ja haavoittuvuuksia koodissa, ja he ovat usein osallistuneet palkkioohjelmiin tietoturvaongelmien havaitsemiseksi.
Curl ei välttänyt tätä suuntausta, Daniel Stenberg sanoi hänen blogissaan, Useiden kuukausien pidättäytymisen jälkeen mielipiteensä hän lopulta räjähti eri mieltä tekoälytyökalujen käytöstä. Syy turhautumisesi takana Se oli kasvava määrä "roska" -raportteja, joita näiden työkalujen käyttö tuottaa.
Julkaisussa korostetaan sitä Näillä raporteilla on yksityiskohtainen ulkoasu, on kirjoitettu normaalilla kielellä ja näyttävät olevan korkealaatuisia. Ilman huolellista analysointia ne osoittautuvat kuitenkin harhaanjohtaviksi, koska ne korvaavat todelliset ongelmat huonolaatuisella sisällöllä, joka näyttää arvokkaalta.
El proyecto Curl, joka tarjoaa palkintoja uusien haavoittuvuuksien tunnistamisesta, on saanut yhteensä 415 ilmoitusta mahdollisista ongelmista. Tästä setistä, vain 64 vahvistettiin todellisiksi haavoittuvuuksiksi, 77 kuvaili ei-turvallisuuteen liittyviä virheitä ja yllättäen 274 (66 %) ei sisältänyt hyödyllistä tietoa, kuluttaa kehittäjien aikaa, jonka olisi voitu käyttää johonkin hyödylliseen.
Kehittäjät joutuvat tuhlaamaan paljon aikaa turhien raporttien analysointiin ja niissä olevien tietojen toistuvaan tarkistamiseen, koska suunnittelun ulkoinen laatu luo lisää luottamusta tietoon ja syntyy tunne, että kehittäjä ei ymmärtänyt jotain.
Toisaalta tällaisen raportin luominen vaatii minimaalista vaivaa pyytäjältä, joka ei vaivaudu tarkistamaan, onko kyseessä todellinen ongelma, vaan kopioi yksinkertaisesti sokeasti tekoälyassistenteilta saadut tiedot toivoen onnensa. taistelussa palkinnon saamiseksi.
Daniel Stenberg, Jaa kaksi esimerkkiä tämäntyyppisestä roskaraportoinnista:
- Ensimmäisessä tapauksessa juuri ennen suunniteltua kriittistä haavoittuvuutta koskevien tietojen julkistamista lokakuussa HackerOne vastaanotti ilmoituksen, joka ilmoitti, että ongelman ratkaisemiseksi oli jo olemassa julkinen korjaustiedosto. Raportti osoittautui kuitenkin "väärennökseksi", koska se sisälsi tietoja samankaltaisista ongelmista ja katkelmia yksityiskohtaisesta tiedosta aiemmista haavoittuvuuksista, jotka Googlen tekoäly-avustaja Bard oli koonnut. Vaikka tieto vaikutti uudelta ja merkitykselliseltä, siltä puuttui yhteyttä todellisuuteen.
- Toisessa tapauksessa saatiin ilmoitus puskurin ylivuodosta WebSocket-käsittelyssä. Tämä raportti tuli käyttäjältä, joka oli jo ilmoittanut haavoittuvuuksista useisiin projekteihin HackerOnen kautta. Ongelman toistamiseksi raportti sisälsi yleiset ohjeet muokatun pyynnön lähettämiseen ja esimerkkikorjauksen.
Huolimatta koodin perusteellisesta kolminkertaisesta tarkistuksesta, kehittäjä ei löytänyt ongelmia. Koska raportti oli kuitenkin kirjoitettu niin, että se herätti "jonkin verran" luottamusta ja esitti jopa ratkaisuehdotuksen, tunne siitä, että jokin ei osunut kohdalleen, säilyi.
Yritetään selventää, kuinka käyttäjä onnistui ohittamaan koon tarkistuksen, mainitaan, että selitykset eivät sisältäneet lisätietoa ja käsittelivät vain ilmeisiä yleisiä puskurin ylivuotojen syitä, jotka eivät liity Curl-koodiin. Vastaukset muistuttivat kommunikointia tekoälyassistentin kanssa, ja turhien yritysten jälkeen selvittää, miten ongelma ilmeni, Daniel Stenberg lopulta vakuuttui, ettei haavoittuvuutta todellisuudessa ollut, ja sulki aiheen "ei soveltuvaksi".
Lopuksi, jos olet kiinnostunut saamaan lisätietoja siitä, voit tutustua yksityiskohtiin osoitteessa seuraava linkki.