Viimastel kuudel oleme imetlenud arvutiga loodud nägude, kassipiltide, videote, esseede ja isegi kunsti kvaliteeti. Tehisintellekt (AI) ja masinõpe (ML) on ka vaikselt tarkvaraarendusse libisenud, kasutades selliseid tööriistu nagu GitHub Copilot, Tabnine, Polycode, ja teised astudes loogilise järgmise sammu, lisades AI steroididele olemasoleva koodi automaatse täitmise funktsiooni. Erinevalt kassipiltidest võivad rakenduskoodi päritolul, kvaliteedil ja turvalisusel olla laiaulatuslikud tagajärjed – ja vähemalt turvalisuse osas näitavad uuringud, et risk on reaalne.
Eelnev akadeemilised uuringud on juba näidanud, et GitHub Copilot genereerib sageli turvaaukudega koodi. Hiljuti näitas seda Invicti turvainseneri Kadir Arslani praktiline analüüs ebaturvalised koodisoovitused on Copiloti puhul ikka pigem reegel kui erand. Arslan leidis, et soovitused paljude tavaliste ülesannete jaoks hõlmasid ainult absoluutseid paljaid konte, valides sageli kõige elementaarsema ja kõige ebaturvalisema marsruudi, ning et nende muutmata jätmine võib kaasa tuua funktsionaalsed, kuid haavatavad rakendused.
Selline tööriist nagu Copilot on (kujunduselt) automaatne lõpetamine, mis on avatud lähtekoodiga koolitatud, et soovitada väljavõtteid, mis võiksid olla sarnases kontekstis asjakohased. See muudab soovituste kvaliteedi ja turvalisuse tihedalt seotud koolituskomplekti kvaliteedi ja turvalisusega. Seega pole suuremad küsimused Copiloti või mõne muu konkreetse tööriista kohta, vaid AI-ga loodud tarkvarakoodi kohta üldiselt.
On mõistlik eeldada, et Copilot on vaid oda ots ja sarnased generaatorid muutuvad lähiaastatel tavapäraseks. See tähendab, et meie, tehnoloogiatööstus, peame hakkama küsima, kuidas sellist koodi genereeritakse, kuidas seda kasutatakse ja kes võtab vastutuse, kui asjad lähevad valesti.
Satnavi sündroom
Traditsiooniline koodi automaatne täitmine, mis otsib funktsioonide definitsioone funktsioonide nimede lõpuleviimiseks ja tuletab meelde, milliseid argumente vajate, on tohutu aja kokkuhoid. Kuna need soovitused on vaid otsetee enda jaoks dokumentide otsimiseks, oleme õppinud kaudselt usaldama kõike, mida IDE soovitab. Kui tehisintellektil töötav tööriist kasutusele tuleb, ei ole selle soovituste õigsus enam garanteeritud, kuid need tunduvad siiski sõbralikud ja usaldusväärsed, seega võetakse neid tõenäolisemalt vastu.
Eriti vähem kogenud arendajate jaoks julgustab tasuta koodiploki hankimise mugavus nihkuma mõtteviisilt "kas see kood on piisavalt lähedane sellele, mida ma kirjutaksin" küsimusele "Kuidas ma saan seda koodi muuta nii, et see minu jaoks töötaks".
GitHub ütleb väga selgelt, et Copiloti soovitusi tuleks alati hoolikalt analüüsida, üle vaadata ja testida, kuid inimloomus nõuab, et isegi alamkood jõuab aeg-ajalt tootmisse. See on natuke nagu sõitmine, vaadates rohkem GPS-i kui teed.
Tarneahela turvaprobleemid
. Log4j turvakriis on viinud tarkvara tarneahela turvalisuse ja eriti avatud lähtekoodiga turbe rambivalgusesse hiljutise versiooniga Valge Maja memo turvalise tarkvaraarenduse ja uue avatud lähtekoodiga turvalisuse parandamise eelnõu. Nende ja muude algatustega võib teie rakendustes mis tahes avatud lähtekoodi olemasolu peagi olla vaja kirjutada tarkvara materjalide arvele (SBOM), mis on võimalik ainult siis, kui lisate teadlikult konkreetse sõltuvuse. Tarkvara koostise analüüsi (SCA) tööriistad tuginevad neile teadmistele ka aegunud või haavatavate avatud lähtekoodiga komponentide tuvastamiseks ja märgistamiseks.
Aga mis siis, kui teie rakendus sisaldab AI-ga loodud koodi, mis lõpuks pärineb avatud lähtekoodiga koolituskomplektist? Teoreetiliselt, kui isegi üks oluline soovitus on identne olemasoleva koodiga ja aktsepteeritakse sellisel kujul, võib teie tarkvaras olla avatud lähtekoodi, kuid mitte SBOM-is. See võib põhjustada vastavusprobleeme, rääkimata võimalikust vastutusest, kui kood osutub ebaturvaliseks ja selle tulemuseks on rikkumine – ja SCA ei aita teid, sest see võib leida ainult haavatavaid sõltuvusi, mitte teie enda koodi haavatavusi. .
Litsentsimise ja omistamise lõksud
Seda mõttekäiku jätkates peate avatud lähtekoodi kasutamiseks järgima selle litsentsimise tingimusi. Sõltuvalt konkreetsest avatud lähtekoodiga litsentsist peate vähemalt esitama omistamise või mõnikord vabastama oma koodi avatud lähtekoodiga. Mõned litsentsid keelavad ärilise kasutamise täielikult. Olenemata litsentsist peate teadma, kust kood pärineb ja kuidas see on litsentsitud.
Mis siis, kui teie rakenduses on AI-ga loodud kood, mis juhtub olema identne olemasoleva avatud lähtekoodiga? Kui teil oleks audit, kas see leiaks, et kasutate koodi ilma nõutava omistamiseta? Või võib-olla peate mõne oma kaubandusliku koodi avama avatud lähtekoodiga, et järgida? Võib-olla ei ole see praeguste tööriistade puhul veel realistlik risk, kuid just selliseid küsimusi peaksime esitama täna, mitte 10 aasta pärast. (Ja selgesõnaliselt on GitHub Copilotil valikuline filter, mis blokeerib olemasolevale koodile vastavad soovitused, et minimeerida tarneahela riske.)
Sügavamad tagajärjed turvalisusele
Turvalisuse juurde tagasi tulles on AI/ML-mudel sama hea (ja sama halb) kui selle koolituskomplekt. Oleme seda varem näinud - näiteks juhtudel näotuvastusalgoritmid, mis näitavad rassilisi eelarvamusi nende väljaõppe saanud andmete tõttu. Nii et kui meil on uuringud, mis näitavad, et koodigeneraator annab sageli soovitusi ilma turvalisusega arvestamata, võime järeldada, et just selline oli selle õppekomplekt (st avalikult kättesaadav kood). Ja mis siis, kui ebaturvaline tehisintellekti loodud kood saab sellesse koodibaasi tagasi? Kas soovitused võivad kunagi olla turvalised?
Turvaküsimused sellega ei lõpe. Kui AI-põhised koodigeneraatorid koguvad populaarsust ja hakkavad arvestama olulise osa uuest koodist, siis tõenäoliselt proovib keegi neid rünnata. AI-pildituvastust on juba võimalik petta, mürgitades selle õppekomplekti. Varem või hiljem püüavad pahatahtlikud osalised panna unikaalselt haavatavat koodi avalikesse hoidlatesse lootuses, et see ilmub soovituste kujul ja jõuab lõpuks tootmisrakendusse, avades selle hõlpsaks rünnakuks.
Ja kuidas on lood monokultuuriga? Kui mitu rakendust kasutavad sama väga haavatavat soovitust, olenemata selle päritolust, võime vaadelda haavatavuse epideemiaid või võib-olla isegi AI-spetsiifilisi haavatavusi.
AI-l silma peal hoidmine
Mõned neist stsenaariumidest võivad tänapäeval tunduda kaugeleulatuvad, kuid need on kõik asjad, mida me tehnoloogiatööstuses peame arutama. Jällegi on GitHub Copilot tähelepanu keskpunktis ainult seetõttu, et see juhib praegu teed ja GitHub annab selgeid hoiatusi tehisintellekti loodud soovituste hoiatuste kohta. Nagu ka telefoni automaatse täitmise või satnavi marsruudisoovituste puhul, on need vaid vihjed meie elu lihtsamaks muutmiseks ja meie otsustada, kas need võtta või jätta.
Tehisintellektil põhinevad koodigeneraatorid võivad arenduse tõhusust eksponentsiaalselt parandada, kuna neist saavad tõenäoliselt tarkvaramaailma alaline osa. Rakenduste turvalisuse osas on see aga veel üks potentsiaalselt haavatava koodi allikas, mis peab enne tootmisse lubamist läbima range turvatesti. Otsime uhiuut viisi, kuidas turvaauke (ja potentsiaalselt kontrollimata sõltuvusi) otse teie esimese osapoole koodi sisse libistada, seega on mõttekas käsitleda tehisintellektiga täiendatud koodibaase kuni testimiseni ebausaldusväärsetena – ja see tähendab, et peate kõike testima sama sageli kui teie. saab.
Isegi suhteliselt läbipaistvad ML-lahendused nagu Copilot tõstatavad juba mõningaid juriidilisi ja eetilisi küsimusi, rääkimata turvaprobleemidest. Kuid kujutage ette, et ühel päeval hakkab mõni uus tööriist genereerima koodi, mis töötab ideaalselt ja läbib turvatestid, välja arvatud üks pisike detail: keegi ei tea, kuidas see töötab. See on siis, kui on aeg paanikaks.
