Ali smo pripravljeni na kodo, ki jo ustvari umetna inteligenca?

V zadnjih mesecih smo se čudili kakovosti računalniško ustvarjenih obrazov, mačjih slik, videov, esejev in celo umetnosti. Umetna inteligenca (AI) in strojno učenje (ML) sta prav tako tiho zdrsnila v razvoj programske opreme z orodji, kot so GitHub Copilot, Tabnine, Polycode, in drugi naredili logični naslednji korak in postavili obstoječo funkcijo samodokončanja kode na AI steroide. Za razliko od mačjih slik pa imajo lahko izvor, kakovost in varnost aplikacijske kode obsežne posledice – vsaj kar zadeva varnost, raziskave kažejo, da je tveganje resnično.

Predhodna akademske raziskave je že pokazal, da GitHub Copilot pogosto ustvari kodo z varnostnimi ranljivostmi. Pred kratkim je to pokazala praktična analiza varnostnega inženirja Invicti Kadirja Arslana predlogi nevarne kode so pri Copilotu še vedno prej pravilo kot izjema. Arslan je ugotovil, da so predlogi za mnoga običajna opravila vključevali le absolutno golo kost, pogosto po najosnovnejši in najmanj varni poti, in da bi lahko njihovo sprejemanje brez sprememb povzročilo funkcionalne, a ranljive aplikacije.

Orodje, kot je Copilot, je (po zasnovi) samodokončanje, obrnjeno na višji nivo, usposobljeno na odprtokodni kodi, da predlaga izrezke, ki bi lahko bili pomembni v podobnem kontekstu. Zaradi tega sta kakovost in varnost predlogov tesno povezani s kakovostjo in varnostjo nabora za usposabljanje. Večja vprašanja se torej ne nanašajo na Copilot ali katero koli drugo specifično orodje, ampak na splošno o programski kodi, ki jo ustvari umetna inteligenca.

Razumno je domnevati, da je Copilot le konica kopja in da bodo podobni generatorji v prihodnjih letih postali običajni. To pomeni, da se moramo mi, tehnološka industrija, začeti spraševati, kako se taka koda generira, kako se uporablja in kdo bo prevzel odgovornost, ko gre kaj narobe.

Satnav sindrom

Tradicionalno samodejno dokončanje kode, ki poišče definicije funkcij za dokončanje imen funkcij in vas opomni, katere argumente potrebujete, je velik prihranek časa. Ker so ti predlogi le bližnjica do samega iskanja dokumentov, smo se naučili implicitno zaupati vsemu, kar predlaga IDE. Ko pride orodje, ki ga poganja umetna inteligenca, ni več zagotovljeno, da bodo njegovi predlogi pravilni - vendar se še vedno zdijo prijazni in vredni zaupanja, zato je večja verjetnost, da bodo sprejeti.

Predvsem za manj izkušene razvijalce udobje brezplačnega bloka kode spodbuja spremembo miselnosti od: »Ali je ta koda dovolj blizu tistemu, kar bi jaz napisal«, k »Kako lahko prilagodim to kodo, da bo delovala zame«.

GitHub zelo jasno navaja, da je treba predloge Copilot vedno skrbno analizirati, pregledati in preizkusiti, vendar človeška narava narekuje, da bo celo podparitetna koda občasno prišla v proizvodnjo. To je podobno vožnji, medtem ko bolj gledate na GPS kot na cesto.

Težave z varnostjo dobavne verige

O Varnostna kriza Log4j je varnost dobavne verige programske opreme in še posebej odprtokodno varnost postavila v središče pozornosti, z nedavnim Obvestilo Bele hiše o varnem razvoju programske opreme in nov predlog zakona o izboljšanju odprtokodne varnosti. S temi in drugimi pobudami bo morda treba imeti kakršno koli odprtokodno kodo v svojih aplikacijah kmalu zapisano v popis materiala programske opreme (SBOM), kar je mogoče le, če zavestno vključite določeno odvisnost. Orodja za analizo sestave programske opreme (SCA) se prav tako zanašajo na to znanje za odkrivanje in označevanje zastarelih ali ranljivih odprtokodnih komponent.

Kaj pa, če vaša aplikacija vključuje kodo, ustvarjeno z umetno inteligenco, ki na koncu izvira iz odprtokodnega nabora za usposabljanje? Teoretično bi lahko imeli odprtokodno kodo v svoji programski opremi, ne pa tudi v svojem SBOM, če je vsaj en pomemben predlog enak obstoječi kodi in sprejet tak, kot je. To lahko privede do težav s skladnostjo, da ne omenjamo možnosti odgovornosti, če se izkaže, da koda ni varna in povzroči kršitev – in SCA vam ne bo pomagal, saj lahko najde samo ranljive odvisnosti, ne pa tudi ranljivosti v vaši kodi .

Pasti licenciranja in dodeljevanja avtorstva

Če nadaljujemo s tem potekom misli, če želite uporabljati odprtokodno kodo, morate upoštevati njene licenčne pogoje. Odvisno od določene odprtokodne licence boste morali vsaj navesti avtorstvo ali včasih izdati svojo kodo kot odprtokodno. Nekatere licence v celoti prepovedujejo komercialno uporabo. Ne glede na licenco morate vedeti, od kod je koda in kako je licencirana.

Še enkrat, kaj, če imate v svoji aplikaciji kodo, ustvarjeno z umetno inteligenco, ki je slučajno enaka obstoječi odprtokodni kodi? Če bi imeli revizijo, ali bi ugotovili, da uporabljate kodo brez zahtevanega pripisa? Ali pa morate morda del svoje komercialne kode odpreti, da ostanete skladni? Morda to še ni realistično tveganje s sedanjimi orodji, toda to so vprašanja, ki bi si jih morali vsi zastaviti danes, ne čez 10 let. (In da bo jasno, GitHub Copilot ima izbirni filter za blokiranje predlogov, ki se ujemajo z obstoječo kodo, da zmanjša tveganja dobavne verige.)

Globlje varnostne posledice

Če se vrnemo k varnosti, je model AI/ML tako dober (in tako slab) kot njegov nabor za usposabljanje. To smo videli v preteklosti - na primer v primerih algoritmi za prepoznavanje obrazov, ki kažejo rasne pristranskosti zaradi podatkov, na katerih so bili usposobljeni. Torej, če imamo raziskavo, ki kaže, da generator kode pogosto ustvarja predloge brez upoštevanja varnosti, lahko sklepamo, da je bil takšen njegov učni niz (tj. javno dostopna koda). In kaj, če se nevarna koda, ki jo ustvari umetna inteligenca, vrne nazaj v to kodno bazo? Ali so lahko predlogi kdaj varni?

Varnostna vprašanja se tu ne končajo. Če generatorji kode, ki temeljijo na AI, pridobijo popularnost in začnejo predstavljati pomemben delež nove kode, jih bo verjetno nekdo poskušal napasti. Prepoznavanje slik z umetno inteligenco je že mogoče preslepiti z zastrupitvijo njegovega učnega niza. Prej ali slej bodo zlonamerni akterji poskušali postaviti edinstveno ranljivo kodo v javne repozitorije v upanju, da se bo pojavila med predlogi in sčasoma končala v produkcijski aplikaciji, kar jo bo odprlo za preprost napad.

Kaj pa monokultura? Če več aplikacij na koncu uporabi isti zelo ranljiv predlog, ne glede na njegov izvor, lahko iščemo epidemije ranljivosti ali morda celo ranljivosti, specifične za AI.

Pozornost na AI

Nekateri od teh scenarijev se danes morda zdijo namišljeni, a o vseh teh stvareh moramo v tehnološki industriji razpravljati. Ponovno je GitHub Copilot v središču pozornosti samo zato, ker je trenutno vodilni, GitHub pa zagotavlja jasna opozorila o opozorilih predlogov, ki jih ustvari umetna inteligenca. Tako kot pri samodokončanju v vašem telefonu ali predlogih poti v vaši satelitski navigaciji so le namigi, ki nam olajšajo življenje, od nas pa je odvisno, ali jih sprejmemo ali pustimo.

S svojim potencialom eksponentnega izboljšanja razvojne učinkovitosti bodo generatorji kode, ki temeljijo na AI, verjetno postali stalni del sveta programske opreme. Z vidika varnosti aplikacij pa je to še en vir potencialno ranljive kode, ki mora prestati stroge varnostne preizkuse, preden se dovoli v proizvodnjo. Iščemo povsem nov način za vstavljanje ranljivosti (in morebitnih nepreverjenih odvisnosti) neposredno v vašo lastno kodo, zato je smiselno kodne baze, razširjene z umetno inteligenco, obravnavati kot nezaupljive, dokler niso preizkušene – kar pomeni, da vse testirate tako pogosto, kot lahko.

Tudi razmeroma pregledne rešitve ML, kot je Copilot, že odpirajo nekatera pravna in etična vprašanja, da ne omenjamo varnostnih pomislekov. Toda predstavljajte si, da nekega dne neko novo orodje začne generirati kodo, ki deluje brezhibno in prestane varnostne teste, razen ene majhne podrobnosti: Nihče ne ve, kako deluje. Takrat je čas za paniko.