I de seneste måneder har vi undret os over kvaliteten af computergenererede ansigter, kattebilleder, videoer, essays og endda kunst. Kunstig intelligens (AI) og machine learning (ML) er også stille og roligt glidet ind i softwareudvikling med værktøjer som GitHub Copilot, Tabnine, Polycode, og andre tager det logiske næste skridt med at sætte eksisterende kodeautofuldførelsesfunktionalitet på AI-steroider. I modsætning til kattebilleder kan oprindelsen, kvaliteten og sikkerheden af applikationskoden dog have vidtrækkende konsekvenser - og i det mindste for sikkerheden viser forskning, at risikoen er reel.
Forud akademisk forskning har allerede vist, at GitHub Copilot ofte genererer kode med sikkerhedssårbarheder. For nylig viste praktisk analyse fra Invictis sikkerhedsingeniør Kadir Arslan det usikre kodeforslag er stadig reglen snarere end undtagelsen med Copilot. Arslan fandt ud af, at forslag til mange almindelige opgaver kun omfattede de absolutte bare knogler, som ofte tog den mest basale og mindst sikre vej, og at accept af dem uden ændringer kunne resultere i funktionelle, men sårbare applikationer.
Et værktøj som Copilot er (ved design) autofuldførelse skruet et hak op, trænet på åben kildekode for at foreslå uddrag, der kunne være relevante i en lignende sammenhæng. Dette gør kvaliteten og sikkerheden af forslag tæt knyttet til kvaliteten og sikkerheden af træningssættet. Så de større spørgsmål handler ikke om Copilot eller noget andet specifikt værktøj, men om AI-genereret softwarekode generelt.
Det er rimeligt at antage, at Copilot kun er spidsen af spydet, og at lignende generatorer vil blive almindelige i de kommende år. Det betyder, at vi, teknologiindustrien, skal begynde at spørge, hvordan sådan kode bliver genereret, hvordan den bruges, og hvem der vil tage ansvar, når tingene går galt.
satnav syndrom
Traditionel kodeautofuldførelse, der slår funktionsdefinitioner op for at udfylde funktionsnavne og minde dig om, hvilke argumenter du har brug for, er en enorm tidsbesparelse. Fordi disse forslag blot er en genvej til at slå dokumenterne op for dig selv, har vi lært at implicit stole på, hvad IDE foreslår. Når først et AI-drevet værktøj kommer ind, er dets forslag ikke længere garanteret at være korrekte - men de føles stadig venlige og troværdige, så de er mere tilbøjelige til at blive accepteret.
Især for mindre erfarne udviklere tilskynder bekvemmeligheden ved at få en gratis blok kode til et skift af tankegang fra "Er denne kode tæt nok på det, jeg ville skrive" til "Hvordan kan jeg justere denne kode, så den virker for mig."
GitHub siger meget tydeligt, at Copilot-forslag altid bør analyseres, gennemgås og testes omhyggeligt, men den menneskelige natur dikterer, at selv subpar-kode lejlighedsvis vil gøre det i produktion. Det er lidt ligesom at køre, mens du ser mere på din GPS end på vejen.
Supply Chain Sikkerhedsproblemer
Log4j sikkerhedskrise har flyttet softwareforsyningskædesikkerhed og specifikt open source-sikkerhed frem i rampelyset med en nylig Memo fra Det Hvide Hus på sikker softwareudvikling og en ny lovforslag om forbedring af open source-sikkerhed. Med disse og andre initiativer kan det snart være nødvendigt at skrive åben kildekode i dine applikationer ind i en softwarestykliste (SBOM), hvilket kun er muligt, hvis du bevidst inkluderer en specifik afhængighed. Softwaresammensætningsanalyseværktøjer (SCA) er også afhængige af denne viden til at opdage og markere forældede eller sårbare open source-komponenter.
Men hvad nu hvis din applikation indeholder AI-genereret kode, der i sidste ende stammer fra et open source-træningssæt? Teoretisk set, hvis selv et væsentligt forslag er identisk med eksisterende kode og accepteret som det er, kunne du have åben kildekode i din software, men ikke i din SBOM. Dette kan føre til compliance-problemer, for ikke at nævne potentialet for ansvar, hvis koden viser sig at være usikker og resulterer i et brud - og SCA hjælper dig ikke, da den kun kan finde sårbare afhængigheder, ikke sårbarheder i din egen kode .
Licens- og tilskrivningsfælder
For at fortsætte den tankegang, for at bruge åben kildekode, skal du overholde dens licensbetingelser. Afhængigt af den specifikke open source-licens skal du i det mindste angive tilskrivning eller nogle gange frigive din egen kode som open source. Nogle licenser forbyder fuldstændig kommerciel brug. Uanset licensen, skal du vide, hvor koden kom fra, og hvordan den er licenseret.
Igen, hvad hvis du har AI-genereret kode i din applikation, der tilfældigvis er identisk med eksisterende åben kildekode? Hvis du havde en revision, ville den så konstatere, at du bruger kode uden den påkrævede tilskrivning? Eller måske er du nødt til at open source noget af din kommercielle kode for at forblive kompatibel? Måske er det endnu ikke en realistisk risiko med de nuværende værktøjer, men det er den slags spørgsmål, vi alle burde stille i dag, ikke om 10 år. (Og for at være klar, har GitHub Copilot et valgfrit filter til at blokere forslag, der matcher eksisterende kode for at minimere forsyningskæderisici.)
Dybere sikkerhedsimplikationer
Når vi vender tilbage til sikkerheden, er en AI/ML-model kun så god (og så dårlig) som dens træningssæt. Det har vi set tidligere — for eksempel i tilfælde af ansigtsgenkendelsesalgoritmer, der viser racemæssige skævheder på grund af de data, de blev trænet på. Så hvis vi har forskning, der viser, at en kodegenerator ofte producerer forslag uden hensyntagen til sikkerhed, kan vi udlede, at det er sådan dens læringssæt (dvs. offentligt tilgængelig kode) var. Og hvad hvis usikker AI-genereret kode derefter feeds tilbage til den kodebase? Kan forslagene nogensinde være sikre?
Sikkerhedsspørgsmålene stopper ikke der. Hvis AI-baserede kodegeneratorer vinder popularitet og begynder at stå for en meningsfuld andel af ny kode, er det sandsynligt, at nogen vil forsøge at angribe dem. Det er allerede muligt at narre AI-billedgenkendelse ved at forgifte dets læringssæt. Før eller siden vil ondsindede aktører forsøge at lægge unikt sårbar kode i offentlige arkiver i håb om, at det kommer op i forslag og til sidst ender i en produktionsapplikation, der åbner op for et let angreb.
Og hvad med monokultur? Hvis flere applikationer ender med at bruge det samme meget sårbare forslag, uanset dets oprindelse, kan vi se på sårbarhedsepidemier eller måske endda AI-specifikke sårbarheder.
Hold øje med AI
Nogle af disse scenarier kan virke langt ude i dag, men de er alle ting, som vi i teknologiindustrien skal diskutere. Igen er GitHub Copilot kun i søgelyset, fordi den i øjeblikket viser vejen, og GitHub giver klare advarsler om forbeholdene ved AI-genererede forslag. Som med autofuldførelse på din telefon eller ruteforslag i din satellitnavigation, er de kun hints til at gøre vores liv lettere, og det er op til os at tage dem eller forlade dem.
Med deres potentiale til eksponentielt at forbedre udviklingseffektiviteten, vil AI-baserede kodegeneratorer sandsynligvis blive en permanent del af softwareverdenen. Med hensyn til applikationssikkerhed er dette dog endnu en kilde til potentielt sårbar kode, der skal bestå strenge sikkerhedstests, før de bliver tilladt i produktion. Vi ser på en helt ny måde at glide sårbarheder (og potentielt ukontrollerede afhængigheder) direkte ind i din førstepartskode, så det giver mening at behandle AI-forstærkede kodebaser som upålidelige, indtil de er testet - og det betyder, at du skal teste alt lige så ofte, som du kan.
Selv relativt gennemsigtige ML-løsninger som Copilot rejser allerede nogle juridiske og etiske spørgsmål, for ikke at nævne sikkerhedsproblemer. Men forestil dig bare, at et nyt værktøj en dag begynder at generere kode, der fungerer perfekt og består sikkerhedstests, bortset fra en lille detalje: Ingen ved, hvordan det fungerer. Det er, når det er tid til panik.
