De siste månedene har vi undret oss over kvaliteten på datamaskingenererte ansikter, kattebilder, videoer, essays og til og med kunst. Kunstig intelligens (AI) og maskinlæring (ML) har også rolig gled inn i programvareutvikling, med verktøy som GitHub Copilot, Tabnine, Polycode, og andre tar det logiske neste trinnet med å sette eksisterende kodeautofullføringsfunksjonalitet på AI-steroider. I motsetning til kattebilder kan imidlertid opprinnelsen, kvaliteten og sikkerheten til applikasjonskoden ha vidtrekkende implikasjoner - og i det minste for sikkerhet viser forskning at risikoen er reell.
Før akademisk forskning har allerede vist at GitHub Copilot ofte genererer kode med sikkerhetssårbarheter. Nylig viste praktisk analyse fra Invicti sikkerhetsingeniør Kadir Arslan det usikre kodeforslag er fortsatt regelen snarere enn unntaket med Copilot. Arslan fant ut at forslag til mange vanlige oppgaver bare inkluderte de absolutte nakne knokler, som ofte tok den mest grunnleggende og minst sikre ruten, og at det å akseptere dem uten endringer kunne resultere i funksjonelle, men sårbare applikasjoner.
Et verktøy som Copilot er (av design) autofullføring skrudd opp et hakk, trent på åpen kildekode for å foreslå utdrag som kan være relevante i en lignende sammenheng. Dette gjør at kvaliteten og sikkerheten til forslagene er nært knyttet til kvaliteten og sikkerheten til opplæringssettet. Så de større spørsmålene handler ikke om Copilot eller noe annet spesifikt verktøy, men om AI-generert programvarekode generelt.
Det er rimelig å anta at Copilot bare er spissen av spydet og at lignende generatorer vil bli vanlig i årene som kommer. Dette betyr at vi, teknologiindustrien, må begynne å spørre hvordan slik kode blir generert, hvordan den brukes, og hvem som tar ansvar når ting går galt.
satnav syndrom
Tradisjonell kodeautofullføring som slår opp funksjonsdefinisjoner for å fullføre funksjonsnavn og minner deg på hvilke argumenter du trenger, er en enorm tidsbesparelse. Fordi disse forslagene bare er en snarvei til å slå opp dokumentene selv, har vi lært å implisitt stole på hva IDE foreslår. Når et AI-drevet verktøy kommer inn, er det ikke lenger garantert at forslagene er korrekte - men de føles fortsatt vennlige og pålitelige, så det er mer sannsynlig at de blir akseptert.
Spesielt for mindre erfarne utviklere oppmuntrer bekvemmeligheten av å få en gratis blokk med kode til et skifte av tankesett fra "Er denne koden nær nok det jeg ville skrevet" til "Hvordan kan jeg justere denne koden slik at den fungerer for meg."
GitHub sier veldig tydelig at Copilot-forslag alltid bør analyseres, gjennomgås og testes nøye, men menneskets natur tilsier at selv underordnede koder av og til kommer i produksjon. Det er litt som å kjøre mens du ser mer på GPS-en din enn på veien.
Sikkerhetsproblemer i forsyningskjeden
De Log4j sikkerhetskrise har flyttet sikkerhet for programvareforsyningskjeden og spesifikt åpen kildekode-sikkerhet inn i rampelyset, med en nylig Memo fra Det hvite hus på sikker programvareutvikling og en ny lovforslag om forbedring av åpen kildekode-sikkerhet. Med disse og andre initiativer, kan det å ha åpen kildekode i applikasjonene dine snart måtte skrives inn i en programvareliste (SBOM), noe som bare er mulig hvis du bevisst inkluderer en spesifikk avhengighet. Verktøy for analyse av programvaresammensetning (SCA) er også avhengig av denne kunnskapen for å oppdage og flagge utdaterte eller sårbare åpen kildekodekomponenter.
Men hva om applikasjonen din inkluderer AI-generert kode som til slutt stammer fra et treningssett med åpen kildekode? Teoretisk sett, hvis til og med ett vesentlig forslag er identisk med eksisterende kode og akseptert som det er, kan du ha åpen kildekode i programvaren din, men ikke i SBOM. Dette kan føre til overholdelsesproblemer, for ikke å snakke om potensialet for ansvar hvis koden viser seg å være usikker og resulterer i et brudd – og SCA vil ikke hjelpe deg, siden den bare kan finne sårbare avhengigheter, ikke sårbarheter i din egen kode .
Lisens- og attribusjonsfeller
For å fortsette denne tankegangen, for å bruke åpen kildekode, må du overholde lisensvilkårene. Avhengig av den spesifikke åpen kildekode-lisensen, må du i det minste oppgi attribusjon eller noen ganger frigi din egen kode som åpen kildekode. Noen lisenser forbyr kommersiell bruk helt. Uansett lisens, må du vite hvor koden kom fra og hvordan den er lisensiert.
Igjen, hva om du har AI-generert kode i applikasjonen din som tilfeldigvis er identisk med eksisterende åpen kildekode? Hvis du hadde en revisjon, ville den funnet ut at du bruker kode uten den nødvendige attribusjonen? Eller kanskje du må åpne kildekode for noe av kommersiell kode for å forbli kompatibel? Kanskje det ennå ikke er en realistisk risiko med dagens verktøy, men dette er den typen spørsmål vi alle burde stille i dag, ikke om 10 år. (Og for å være tydelig, har GitHub Copilot et valgfritt filter for å blokkere forslag som samsvarer med eksisterende kode for å minimere forsyningskjederisikoen.)
Dypere sikkerhetsimplikasjoner
Når vi går tilbake til sikkerhet, er en AI/ML-modell bare så god (og så dårlig) som treningssettet. Det har vi sett tidligere - for eksempel i tilfeller av ansiktsgjenkjenningsalgoritmer som viser rasemessige skjevheter på grunn av dataene de ble trent på. Så hvis vi har forskning som viser at en kodegenerator ofte produserer forslag uten hensyn til sikkerhet, kan vi slutte at dette er hvordan læringssettet (dvs. offentlig tilgjengelig kode) var. Og hva om usikker AI-generert kode deretter feeds tilbake til den kodebasen? Kan forslagene noen gang være sikre?
Sikkerhetsspørsmålene stopper ikke der. Hvis AI-baserte kodegeneratorer vinner popularitet og begynner å stå for en meningsfull andel av ny kode, er det sannsynlig at noen vil prøve å angripe dem. Det er allerede mulig å lure AI-bildegjenkjenning ved å forgifte læringssettet. Før eller siden vil ondsinnede aktører prøve å sette unikt sårbar kode i offentlige depoter i håp om at den kommer opp i forslag og til slutt ender opp i en produksjonsapplikasjon, og åpner den for et enkelt angrep.
Og hva med monokultur? Hvis flere applikasjoner ender opp med å bruke det samme svært sårbare forslaget, uansett opprinnelse, kan vi se på sårbarhetsepidemier eller kanskje til og med AI-spesifikke sårbarheter.
Holde et øye med AI
Noen av disse scenariene kan virke langsøkte i dag, men de er alle ting vi i teknologibransjen trenger å diskutere. Igjen, GitHub Copilot er i søkelyset bare fordi den for øyeblikket leder an, og GitHub gir klare advarsler om forbeholdene til AI-genererte forslag. Som med autofullføring på telefonen eller ruteforslag i satellittnavigasjonen, er de bare hint for å gjøre livene våre enklere, og det er opp til oss å ta dem eller forlate dem.
Med sitt potensial til å eksponentielt forbedre utviklingseffektiviteten, vil AI-baserte kodegeneratorer sannsynligvis bli en permanent del av programvareverdenen. Når det gjelder applikasjonssikkerhet, er dette imidlertid nok en kilde til potensielt sårbar kode som må bestå streng sikkerhetstesting før den slippes ut i produksjon. Vi ser på en helt ny måte å skli sårbarheter (og potensielt ukontrollerte avhengigheter) direkte inn i førstepartskoden din, så det er fornuftig å behandle AI-forsterkede kodebaser som upålitelige før de er testet – og det betyr å teste alt så ofte som du kan.
Selv relativt gjennomsiktige ML-løsninger som Copilot reiser allerede noen juridiske og etiske spørsmål, for ikke å snakke om sikkerhetshensyn. Men bare forestill deg at en dag begynner et nytt verktøy å generere kode som fungerer perfekt og består sikkerhetstester, bortsett fra en liten detalj: Ingen vet hvordan det fungerer. Det er da det er på tide å få panikk.
