Olemmeko valmiita tekoälyn luomaan koodiin?

Viime kuukausina olemme ihmetelleet tietokoneella luotujen kasvojen, kissakuvien, videoiden, esseiden ja jopa taiteen laatua. Tekoäly (AI) ja koneoppiminen (ML) ovat myös hiljaa livahtaneet ohjelmistokehitykseen työkaluilla, kuten GitHub Copilot, Tabnine, Polycode, ja muut ottaa loogisen seuraavan askeleen ja ottaa olemassa olevan koodin automaattisen täydennystoiminnon AI-steroideihin. Toisin kuin kissakuvissa, sovelluskoodin alkuperällä, laadulla ja turvallisuudella voi olla laajakantoisia vaikutuksia – ja ainakin turvallisuuden kannalta tutkimukset osoittavat, että riski on todellinen.

Aikaisempi akateeminen tutkimus on jo osoittanut, että GitHub Copilot luo usein koodia, jossa on tietoturva-aukkoja. Äskettäin Invictin turvallisuusinsinöörin Kadir Arslanin käytännön analyysi osoitti sen epävarmat koodiehdotukset ovat edelleen sääntö kuin poikkeus Copilotissa. Arslan havaitsi, että ehdotukset moniin yleisiin tehtäviin sisälsivät vain ehdottoman paljaat luut, jotka usein valitsivat alkeellisinta ja vähiten turvallisinta reittiä, ja että niiden hyväksyminen ilman muutoksia voisi johtaa toimiviin, mutta haavoittuviin sovelluksiin.

Copilotin kaltainen työkalu on (suunniteltu) automaattinen täydennys, joka on opetettu avoimeen lähdekoodiin ehdottamaan katkelmia, jotka voivat olla merkityksellisiä samanlaisessa kontekstissa. Tämä tekee ehdotusten laadun ja turvallisuuden tiiviisti sidoksissa koulutuskokonaisuuden laatuun ja turvallisuuteen. Suuremmat kysymykset eivät siis koske Copilotia tai muita erityisiä työkaluja, vaan tekoälyn luomaa ohjelmistokoodia yleensä.

On järkevää olettaa, että Copilot on vain keihään kärki ja että samankaltaisista generaattoreista tulee yleisiä tulevina vuosina. Tämä tarkoittaa, että meidän, teknologiateollisuuden, on alettava kysyä, kuinka tällaista koodia luodaan, miten sitä käytetään ja kuka ottaa vastuun, kun asiat menevät pieleen.

Satnav-syndrooma

Perinteinen koodin automaattinen täydennys, joka etsii funktiomäärityksiä täydentääkseen funktioiden nimiä ja muistuttaakseen tarvitsemasi argumenteista, säästää valtavasti aikaa. Koska nämä ehdotukset ovat vain oikoteitä asiakirjojen etsimiseen itse, olemme oppineet luottamaan implisiittisesti IDE:n ehdotuksiin. Kun tekoälykäyttöinen työkalu tulee käyttöön, sen ehdotukset eivät enää ole oikeita – mutta ne silti tuntuvat ystävällisiltä ja luotettavilta, joten ne hyväksytään todennäköisemmin.

Varsinkin vähemmän kokeneille kehittäjille ilmaisen koodilohkon hankkiminen kannustaa ajattelutapaa muuttamaan "onko tämä koodi tarpeeksi lähellä sitä, mitä kirjoittaisin" kohtaan "Kuinka voin muokata tätä koodia niin, että se toimii minulle."

GitHub sanoo erittäin selvästi, että Copilot-ehdotukset tulee aina analysoida, tarkistaa ja testata huolellisesti, mutta ihmisluonto sanelee, että jopa alikoodi joutuu toisinaan tuotantoon. Se on vähän kuin ajaisi ja katsoisi enemmän GPS:ää kuin tietä.

Toimitusketjun turvallisuusongelmat

- Log4j-tietoturvakriisi on nostanut ohjelmistojen toimitusketjun turvallisuuden ja erityisesti avoimen lähdekoodin tietoturvan parrasvaloihin äskettäin Valkoisen talon muistio turvallisesta ohjelmistokehityksestä ja uudesta lakiesitys avoimen lähdekoodin tietoturvan parantamisesta. Näiden ja muiden aloitteiden ansiosta avoimen lähdekoodin käyttäminen sovelluksissasi voidaan pian joutua kirjoittamaan ohjelmiston materiaaliluetteloon (SBOM), mikä on mahdollista vain, jos tietoisesti sisällytät tietyn riippuvuuden. Ohjelmiston koostumuksen analysointityökalut (SCA) luottavat myös tähän tietoon vanhentuneiden tai haavoittuvien avoimen lähdekoodin komponenttien havaitsemiseksi ja merkitsemiseksi.

Mutta entä jos sovelluksesi sisältää tekoälyn luomaa koodia, joka lopulta on peräisin avoimen lähdekoodin harjoitussarjasta? Teoriassa, jos edes yksi olennainen ehdotus on identtinen olemassa olevan koodin kanssa ja hyväksytään sellaisenaan, ohjelmistossasi voi olla avoin lähdekoodi, mutta ei SBOM:ssa. Tämä voi johtaa vaatimustenmukaisuusongelmiin, puhumattakaan mahdollisesta vastuusta, jos koodi osoittautuu epävarmaksi ja johtaa rikkomukseen – eikä SCA auta sinua, sillä se voi löytää vain haavoittuvia riippuvuuksia, ei haavoittuvuuksia omasta koodistasi. .

Lisenssien ja nimeämisen sudenkuopat

Jatkamalla tätä ajatuskulkua, avoimen lähdekoodin käyttäminen edellyttää sen lisenssiehtojen noudattamista. Tietystä avoimen lähdekoodin lisenssistä riippuen sinun on ainakin annettava attribuutio tai joskus julkaistava oma koodi avoimena lähdekoodina. Jotkut lisenssit kieltävät kaupallisen käytön kokonaan. Olipa lisenssi mikä tahansa, sinun on tiedettävä, mistä koodi on peräisin ja miten se on lisensoitu.

Entä jos sovelluksessasi on tekoälyn luomaa koodia, joka sattuu olemaan identtinen olemassa olevan avoimen lähdekoodin kanssa? Jos sinulla olisi tarkastus, havaitsiko se, että käytät koodia ilman vaadittua attribuutiota? Tai ehkä sinun on avattava osa kaupallisesta koodistasi, jotta se pysyy yhteensopivana? Ehkä se ei ole vielä realistinen riski nykyisillä työkaluilla, mutta tällaisia ​​kysymyksiä meidän kaikkien pitäisi kysyä tänään, ei 10 vuoden kuluttua. (Ja selvyyden vuoksi GitHub Copilotissa on valinnainen suodatin, joka estää ehdotukset, jotka vastaavat olemassa olevaa koodia toimitusketjun riskien minimoimiseksi.)

Syvempiä turvallisuusvaikutuksia

Palatakseni turvallisuuteen, AI/ML-malli on vain yhtä hyvä (ja yhtä huono) kuin sen koulutussarja. Olemme nähneet sen aiemmin - esimerkiksi tapauksissa kasvojentunnistusalgoritmit, jotka osoittavat rodullisia ennakkoluuloja heidän koulutettujen tietojen vuoksi. Joten jos meillä on tutkimusta, joka osoittaa, että koodigeneraattori tuottaa usein ehdotuksia ottamatta huomioon turvallisuutta, voimme päätellä, että tämä on sen oppimisjoukko (eli julkisesti saatavilla oleva koodi) oli. Entä jos turvaton tekoälyn luoma koodi syöttyy takaisin kyseiseen koodikantaan? Voivatko ehdotukset koskaan olla turvallisia?

Turvakysymykset eivät lopu tähän. Jos tekoälypohjaiset koodigeneraattorit saavat suosiota ja alkavat muodostaa merkittävän osan uudesta koodista, on todennäköistä, että joku yrittää hyökätä niiden kimppuun. Tekoälykuvantunnistusta on jo mahdollista huijata myrkyttämällä sen oppimissarja. Ennemmin tai myöhemmin haitalliset toimijat yrittävät laittaa ainutlaatuisen haavoittuvan koodin julkisiin tietovarastoihin siinä toivossa, että se tulee esiin ehdotuksissa ja päätyy lopulta tuotantosovellukseen, mikä avaa sen helpolle hyökkäykselle.

Entä monokulttuuri? Jos useat sovellukset päätyvät käyttämään samaa erittäin haavoittuvaa ehdotusta sen alkuperästä riippumatta, voimme tarkastella haavoittuvuusepidemioita tai ehkä jopa tekoälykohtaisia ​​haavoittuvuuksia.

Pidä tekoälyä silmällä

Jotkut näistä skenaarioista saattavat tuntua kaukaa haetuilta tänään, mutta ne ovat kaikki asioita, joista meidän teknologia-alan on keskusteltava. Jälleen GitHub Copilot on valokeilassa vain siksi, että se näyttää tällä hetkellä tietä, ja GitHub tarjoaa selkeät varoitukset tekoälyn luomien ehdotusten varoituksista. Kuten puhelimesi automaattinen täydennys tai satelliittinavigaattorisi reittiehdotukset, ne ovat vain vihjeitä elämämme helpottamiseksi, ja meidän on otettava ne käyttöön vai jätetäänkö ne.

Tekoälypohjaisista koodigeneraattoreista tulee todennäköisesti pysyvä osa ohjelmistomaailmaa, koska niillä on mahdollisuus parantaa kehitystehokkuutta eksponentiaalisesti. Sovellusturvallisuuden kannalta tämä on kuitenkin jälleen yksi mahdollisesti haavoittuvan koodin lähde, jonka on läpäistävä tiukat turvallisuustestit ennen tuotantoon pääsyä. Etsimme aivan uutta tapaa pudottaa haavoittuvuuksia (ja mahdollisesti tarkistamattomia riippuvuuksia) suoraan ensimmäisen osapuolen koodiisi, joten on järkevää käsitellä tekoälyllä täydennettyjä koodikantoja epäluotettavina, kunnes ne testataan – ja tämä tarkoittaa, että kaikkea testataan niin usein kuin sinäkin. voi.

Jopa suhteellisen läpinäkyvät ML-ratkaisut, kuten Copilot, herättävät jo joitain juridisia ja eettisiä kysymyksiä, turvallisuudesta puhumattakaan. Mutta kuvittele, että jonain päivänä jokin uusi työkalu alkaa tuottaa koodia, joka toimii täydellisesti ja läpäisee tietoturvatestit, lukuun ottamatta yhtä pientä yksityiskohtaa: Kukaan ei tiedä, miten se toimii. Silloin on aika panikoida.