Under de senaste månaderna har vi förundrats över kvaliteten på datorgenererade ansikten, kattbilder, videor, uppsatser och till och med konst. Artificiell intelligens (AI) och maskininlärning (ML) har också tyst glidit in i mjukvaruutveckling, med verktyg som GitHub Copilot, Tabnine, Polycode, och andra ta det logiska nästa steget att sätta befintlig kod autoslutförande funktionalitet på AI steroider. Till skillnad från kattbilder kan dock ursprunget, kvaliteten och säkerheten för applikationskoden ha omfattande konsekvenser - och åtminstone för säkerheten visar forskning att risken är verklig.
Innan akademisk forskning har redan visat att GitHub Copilot ofta genererar kod med säkerhetsbrister. På senare tid visade praktisk analys från Invictis säkerhetsingenjör Kadir Arslan det osäkra kodförslag är fortfarande regel snarare än undantag med Copilot. Arslan fann att förslag på många vanliga uppgifter endast inkluderade de absoluta nakna benen, ofta på den mest grundläggande och minst säkra vägen, och att acceptera dem utan modifiering kan resultera i funktionella men sårbara applikationer.
Ett verktyg som Copilot är (genom design) autokomplettering ökat ett snäpp, tränat på öppen källkod för att föreslå utdrag som kan vara relevanta i liknande sammanhang. Detta gör att förslagens kvalitet och säkerhet är nära knuten till utbildningsuppsättningens kvalitet och säkerhet. Så de större frågorna handlar inte om Copilot eller något annat specifikt verktyg utan om AI-genererad mjukvarukod i allmänhet.
Det är rimligt att anta att Copilot bara är spjutspetsen och att liknande generatorer kommer att bli vanliga under de kommande åren. Det betyder att vi, teknikindustrin, måste börja fråga hur sådan kod genereras, hur den används och vem som tar ansvar när det går fel.
satnav syndrom
Traditionell kod autokomplettering som slår upp funktionsdefinitioner för att komplettera funktionsnamn och påminna dig om vilka argument du behöver är en enorm tidsbesparare. Eftersom dessa förslag bara är en genväg till att leta upp dokumenten själv, har vi lärt oss att implicit lita på vad IDE föreslår. När ett AI-drivet verktyg väl kommer in är det inte längre garanterat att dess förslag är korrekta – men de känns fortfarande vänliga och pålitliga, så det är mer sannolikt att de accepteras.
Speciellt för mindre erfarna utvecklare uppmuntrar bekvämligheten med att få ett gratis kodblock en förändring av tankesätt från "Är den här koden tillräckligt nära vad jag skulle skriva" till "Hur kan jag justera den här koden så att den fungerar för mig."
GitHub säger mycket tydligt att Copilot-förslag alltid bör analyseras noggrant, granskas och testas, men den mänskliga naturen dikterar att även subpar-kod ibland kommer att produceras. Det är lite som att köra medan du tittar mer på din GPS än på vägen.
Säkerhetsproblem i försörjningskedjan
Smakämnen Log4j säkerhetskris har flyttat säkerheten för mjukvaruförsörjningskedjan och, specifikt, säkerhet med öppen källkod i rampljuset, med en nyligen Memo från Vita huset på säker mjukvaruutveckling och en ny proposition om att förbättra säkerheten med öppen källkod. Med dessa och andra initiativ kan det snart behöva skrivas in öppen källkod i dina applikationer i en mjukvaruförteckning (SBOM), vilket bara är möjligt om du medvetet inkluderar ett specifikt beroende. Verktyg för analys av mjukvarusammansättning (SCA) förlitar sig också på den kunskapen för att upptäcka och flagga föråldrade eller sårbara komponenter med öppen källkod.
Men vad händer om din applikation innehåller AI-genererad kod som i slutändan kommer från en utbildningsuppsättning med öppen källkod? Teoretiskt, om ens ett väsentligt förslag är identiskt med befintlig kod och accepteras som det är, kan du ha öppen källkod i din programvara men inte i din SBOM. Detta kan leda till efterlevnadsproblem, för att inte tala om risken för ansvar om koden visar sig vara osäker och resulterar i ett brott – och SCA hjälper dig inte, eftersom det bara kan hitta sårbara beroenden, inte sårbarheter i din egen kod .
Fallgropar för licensiering och tillskrivning
Om du fortsätter med den tankegången, för att använda öppen källkod, måste du följa dess licensvillkor. Beroende på den specifika licensen för öppen källkod måste du åtminstone tillhandahålla attribution eller ibland släppa din egen kod som öppen källkod. Vissa licenser förbjuder kommersiell användning helt och hållet. Oavsett licens måste du veta var koden kom ifrån och hur den är licensierad.
Återigen, vad händer om du har AI-genererad kod i din applikation som råkar vara identisk med befintlig öppen källkod? Om du hade en revision, skulle den upptäcka att du använder kod utan den erforderliga tillskrivningen? Eller kanske du behöver öppna en del av din kommersiella kod för att förbli kompatibel? Kanske är det ännu inte en realistisk risk med nuvarande verktyg, men det är den här typen av frågor vi alla borde ställa idag, inte om tio år. (Och för att vara tydlig har GitHub Copilot ett valfritt filter för att blockera förslag som matchar befintlig kod för att minimera riskerna i leveranskedjan.)
Djupare säkerhetskonsekvenser
Om vi går tillbaka till säkerheten är en AI/ML-modell bara lika bra (och lika dålig) som dess träningsuppsättning. Det har vi sett tidigare - till exempel i fall av ansiktsigenkänningsalgoritmer som visar rasistiska fördomar på grund av de uppgifter som de utbildats på. Så om vi har forskning som visar att en kodgenerator ofta ger förslag utan hänsyn till säkerhet, kan vi dra slutsatsen att det är så dess inlärningsuppsättning (dvs. allmänt tillgänglig kod) var. Och vad händer om osäker AI-genererad kod sedan matas tillbaka till den kodbasen? Kan förslagen någonsin vara säkra?
Säkerhetsfrågorna slutar inte där. Om AI-baserade kodgeneratorer vinner popularitet och börjar stå för en meningsfull andel ny kod, är det troligt att någon kommer att försöka attackera dem. Det är redan möjligt att lura AI-bildigenkänning genom att förgifta dess inlärningsuppsättning. Förr eller senare kommer illvilliga aktörer att försöka placera unikt sårbar kod i offentliga arkiv i hopp om att den kommer upp i förslag och så småningom hamnar i en produktionsapplikation, vilket öppnar upp för en enkel attack.
Och hur är det med monokultur? Om flera applikationer slutar använda samma mycket sårbara förslag, oavsett ursprung, kan vi titta på sårbarhetsepidemier eller kanske till och med AI-specifika sårbarheter.
Hålla ett öga på AI
Vissa av dessa scenarier kan tyckas långsökta idag, men de är alla saker som vi inom teknikbranschen behöver diskutera. Återigen, GitHub Copilot är i rampljuset bara för att den för närvarande leder vägen, och GitHub ger tydliga varningar om varningarna för AI-genererade förslag. Precis som med autoslutförande på din telefon eller ruttförslag i din satellitnavigator, är de bara tips för att göra våra liv enklare, och det är upp till oss att ta dem eller lämna dem.
Med sin potential att exponentiellt förbättra utvecklingseffektiviteten kommer AI-baserade kodgeneratorer sannolikt att bli en permanent del av mjukvaruvärlden. När det gäller applikationssäkerhet är detta dock ännu en källa till potentiellt sårbar kod som måste klara rigorösa säkerhetstester innan de släpps in i produktion. Vi tittar på ett helt nytt sätt att glida in sårbarheter (och potentiellt okontrollerade beroenden) direkt i din förstapartskod, så det är vettigt att behandla AI-förstärkta kodbaser som opålitliga tills de testas – och det innebär att testa allt så ofta som du burk.
Även relativt transparenta ML-lösningar som Copilot väcker redan några juridiska och etiska frågor, för att inte tala om säkerhetsproblem. Men föreställ dig bara att en dag börjar något nytt verktyg generera kod som fungerar perfekt och klarar säkerhetstester, förutom en liten detalj: Ingen vet hur det fungerar. Det är då det är dags att få panik.
