AI endrer hvem som bestemmer hva slags programvare som kommer inn i din organisasjon

AI har blitt en del av hverdags programvareutvikling. Fra å generere API-er og skrive tester til å bygge hele applikasjoner, hjelper kodehjelpere utviklingsteamer med å løse problemer og levere programvare raskere enn noen gang før. Produktivitetsgevinstene er ubestridelige, og organisasjoner omfavner raskt AI over hele programvareutviklingslivssyklusen.

Mye av samtalen har fokusert på koden AI genererer. Kan utviklere stole på AI-generert kode? Innfører den sårbarheter? Hvordan bør sikkerhetsteamene gjennomgå den? Disse spørsmålene er viktige, men de er ikke den største endringen AI bringer til programvareutvikling. AI har gått langt utenfor å bare kunne generere kode, og det påvirker stadig mer de første programvarevalgene som former hva slags programvare som kommer inn i en organisasjon.

AI-kodehjelpere bygger sjelden applikasjoner fra bunnen av, og de komponerer løsninger ved å bruke eksisterende rammeverk, åpne kildebiblioteker, SDK-er, containerbilder, og pakkeøkosystemer. Hver anbefaling former programvaregrunnlaget en applikasjon bygges på, ofte før en utvikler gjennomgår den første linjen med generert kode.

I årevis har den første tillitsbeslutningen i programvareutvikling tilhørt nesten utelukkende utviklere, men nå begynner den antagelsen å endre seg. Stadig oftere gjør AI den første anbefalingen, mens utviklere validerer resultatet etterpå. Den subtile skiftet har betydelige implikasjoner for programvareforsyningskjedens sikkerhet, fordi hver anbefaling bærer en implisitt tillitsbeslutning.

Organisasjoner har brukt år på å styre hvordan programvare bygges, testes og distribueres. Den neste utfordringen er å styre hvordan programvare velges i en AI-nativ utviklingsmiljø.

Den første tillitsbeslutningen

Hver applikasjon avhenger av programvare skapt av tusenvis av bidragsytere over talløse åpne kildeprosjekter. Før en ny avhengighet introduseres, evaluerte utviklere vanligvis dokumentasjon, sammenlignet rammeverk, gjennomgikk samfunnets tilpasning, undersøkte utgivelseshyppighet og vurderte om et prosjekt var modent nok for produksjon. Utviklere valgte ikke alltid riktig, men hver avhengighet ble introdusert med overlating.

I dag kan en utvikler enkelt be en AI-hjelper om å “bygge en sikker REST-API med autentisering og PostgreSQL-støtte.” Innen sekunder genererer AI en fungerende prosjekt. Underveis anbefaler den en kjøretid, velger et rammeverk, refererer til et basis-containerbilde, importerer autentiseringsbiblioteker, velger SDK-er, og genererer avhengighetsmanifest som package.json, requirements.txt, eller pom.xml. Pakkehåndterere løser deretter disse avhengighetene og deres transitive avhengigheter under byggeprosessen.

De fleste utviklere gjennomgår applikasjonen AI produserer, men bare noen stopper for å undersøke hver enkelt programvarebeslutning AI tar underveis. AI har komprimert programvarevalg som en gang tok timer med forskning til sekunder og øker stadig anbefalingen på vegne av utviklere.

Hver anbefaling er en tillitsbeslutning

Hver programvareartefakt bærer sin egen tillitskjede. En bibliotek har vedlikeholdere, bidragsytere, utgivelsesprosesser, signeringssammenhenger, avhengigheter og proveniens. Et containerbilde arver programvare fra oppstrømsdistribusjoner, og en SDK introduserer ytterligere pakker, hver av dem utvider tillitskjeden.

En enkelt AI-anbefaling kan raskt utvide til hundredvis av programvareartefakter som blir en del av en applikasjon. Åpne kildekoder har alltid fungert på denne måten. Hva som endrer seg, er hvem som tar disse tillitsbeslutningene først. Historisk sett evaluerte og valgte utviklere komponentene de stolte på. Stadig oftere gjør AI-systemer den initielle anbefalingen, mens utviklere validerer resultatet senere.

Det høres ut som en liten endring, men det endrer fundamentalt hvordan organisasjoner bør tenke om programvareforsyningskjedens sikkerhet.

AI optimaliserer for fungerende programvare, ikke organisatorisk tillit

Dette betyr ikke at AI tar dårlige anbefalinger. Tvert imot.

AI-kodehjelpere er gode til å anbefale programvare fordi de har lært fra millioner av eksempler på hvordan utviklere løser lignende problemer. Som et resultat, populære rammeverk, veldokumenterte biblioteker og kjente implementeringsmønster dukker naturlig opp i deres forslag, og det er nettopp det som gjør disse verktøyene så verdifulle.

Men disse optimaliseringsmålene er fundamentalt forskjellige fra spørsmålene bedriftssikkerhetsteamene må ha besvart. AI vurderer ikke om en pakke samsvarer med en organisasjonens programvarepolitikk, om et containerbilde ble bygget fra kilde, om programvareproveniens er verifisert eller om en avhengighet stammer fra en godkjent programvarekilde.

Funksjonalitet, popularitet og sannsynlighet er nyttige signaler for å generere kode, men de bør aldri brukes som erstatninger for verifisering.

Hvorfor vi må integrere til venstre

I årevis har programvareforsyningskjedens sikkerhet fokusert på å identifisere risiko etter at programvaren har kommet inn i utviklingsprosessen. Sårbarhetsskannere, programvarekomposisjonsanalyse og SBOM-er har dramatisk forbedret synligheten i programvaren som applikasjonene inneholder.

Disse verktøyene er fortsatt essensielle, men de addreserer en annen del av problemet.

AI flytter programvarevalg mye tidligere i utviklingslivssyklusen, så når tradisjonelle sikkerhetskontroller begynner sin analyse, kan det genererte prosjektet allerede referere til dusinvis av avhengigheter som nå krever vurdering, retting eller erstattning. Organisasjoner reagerer fortsatt på programvarevalg som allerede har kommet inn i utviklingsarbeidsflyten.

Dette er hvorfor jeg mener organisasjoner må integrere til venstre.

Idéen bak å integrere til venstre er enkel: tillit bør etableres før programvare blir en del av en applikasjon, ikke etter. Når AI blir en aktiv deltaker i programvareutvikling, blir dette prinsippet enda viktigere. Styring må flyttes til punktet hvor programvare velges, ikke hvor den til slutt skannes.

Organisasjoner må definere pålitelige programvarekilder, etablere hvilke programvareartefakter AI er tillatt å anbefale og verifisere disse artefaktene før de blir en del av utviklingsarbeidsflyten. Målet er å sikre at AI akselerer programvarelevering innenfor rammer som reflekterer organisasjonens sikkerhets-, etterlevelse- og ingeniørstandarder.

Styring av programvarevalg i AI-æraen

Organisasjoner definerer allerede hvor programvare kan kjøres, hvordan den distribueres og hvem som er autorisert til å frigi den. Stadig oftere vil de også måtte definere hva slags programvare AI er tillatt å anbefale.

Dette er hvor programvareforsyningskjedens holdning blir stadig viktigere. Organisasjoner må ha tillit ikke bare til programvaren de bygger, men også til programvaren AI anbefaler på deres vegne. Den tilliten kommer fra verifisering, pålitelige programvarekilder og styring som begynner før programvare kommer inn i utviklingspipelinen.

AI vil fortsette å transformere programvareutvikling, og rettferdig så. Produktivitetsgevinstene er for store til å ignorere, men når organisasjoner omfavner AI-nativ utvikling, må de erkjenne at programvarevalg blir stadig mer automatisert. 

Organisasjonene som lykkes vil være de som etablerer pålitelige programvarekilder, verifiserer programvareartefaktene AI anbefaler og integrerer styring i programvarevalg fra meget begynnelsen.

AI endrer hvordan programvare skrives, men nå, viktigere, endrer det hvordan programvare velges. Fordi i AI-æraen, avhenger programvaren du stoler på stadig mer av programvaren din AI velger først.