AI förändrar vem som bestämmer vilken programvara som kommer in i din organisation

AI har blivit en del av den vardagliga programvaruutvecklingen. Från att generera API:er och skriva tester till att skapa hela applikationer, hjälper kodassistenter utvecklingsteam att lösa problem och leverera programvara snabbare än någonsin tidigare. Produktivitetsvinster är obestridliga, och organisationer omfamnar snabbt AI över hela programvaruutvecklingslivscykeln.

Mycket av diskussionen har fokuserat på den kod som AI genererar. Kan utvecklare lita på AI-genererad kod? Introducerar den sårbarheter? Hur bör säkerhetsteam granska den? Dessa frågor är viktiga, men de är inte den största förändringen som AI för med sig till programvaruutveckling. AI har gått utöver att bara kunna generera kod, och det påverkar alltmer de första programvaruvalen som formar vilken programvara som kommer in i en organisation.

AI-kodassistenter bygger sällan applikationer från scratch, och de komponerar lösningar med hjälp av befintliga ramverk, öppen källkod, SDK:er, containerbilder och paketekosystem. Varje rekommendation formar den programvarubas som en applikation byggs på, ofta innan en utvecklare granskar den första raden med genererad kod.

Under decennier har det första förtroendebeslutet i programvaruutveckling tillhört utvecklare nästan helt och hållet, men nu börjar den antagandet att förändras. Alltmer är det AI som gör den första rekommendationen, medan utvecklare validerar resultatet efteråt. Den subtila förändringen har betydande konsekvenser för programvaruförsörjningskedjens säkerhet, eftersom varje rekommendation bär på ett implicit förtroendebeslut.

Organisationer har tillbringat år med att styra hur programvara byggs, testas och distribueras. Nästa utmaning är att styra hur programvara väljs i en AI-nativ utvecklingsmiljö.

Det första förtroendebeslutet

Varje applikation är beroende av programvara skapad av tusentals bidragsgivare över otaliga öppen källkodsprojekt. Innan en ny beroende introduceras, utvärderade utvecklare vanligtvis dokumentation, jämförde ramverk, granskade communityadoptionsgrad, undersökte släppfrekvens och övervägde om ett projekt var moget nog för produktion. Utvecklare gjorde inte alltid rätt val, men varje beroende introducerades medvetet.

Idag kan en utvecklare enkelt be en AI-assistent att “bygga en säker REST-API med autentisering och PostgreSQL-stöd.” Inom några sekunder genererar AI en fungerande projekt. Under tiden rekommenderar den en körning, väljer ett ramverk, hänvisar till en bascontainerbild, importerar autentiseringsbibliotek, väljer SDK:er, och genererar beroendemanifest som package.json, requirements.txt eller pom.xml. Pakethanterare löser sedan dessa beroenden och deras transitiva beroenden under byggprocessen.

De flesta utvecklare granskar den applikation som AI genererar, men bara några stannar upp för att undersöka varje programvarubeslut som AI fattar under resans gång. AI har komprimerat programvaruvalet som tidigare tog timmar av forskning till sekunder och gör alltmer den första rekommendationen på utvecklares vägnar.

Varje rekommendation är ett förtroendebeslut

Varje programvaruartifact bär på sin egen förtroendekedja. En bibliotek har underhållare, bidragsgivare, släppprocesser, signeringssätt, beroenden och ursprung. En containerbild ärver programvara från uppströmsdistributioner, och en SDK introducerar ytterligare paket, vilket förlänger den kedjan av förtroende.

En enda AI-rekommendation kan snabbt expandera till hundratals programvaruartifact som blir en del av en applikation. Öppen källkod har alltid fungerat på det här sättet. Vad som förändras är vem som fattar dessa förtroendebeslut först. Historiskt sett utvärderade och valde utvecklare komponenterna de litade på. Alltmer är det AI-system som gör den initiala rekommendationen, medan utvecklare validerar resultatet senare.

Det låter som en liten förändring, men det förändrar fundamentalt hur organisationer bör tänka kring programvaruförsörjningskedjens säkerhet.

AI optimerar för fungerande programvara, inte organisatoriskt förtroende

Inget av detta betyder att AI gör dåliga rekommendationer. Tvärtom.

AI-kodassistenter är bra på att rekommendera programvara eftersom de har lärt sig från miljontals exempel på hur utvecklare löser liknande problem. Som ett resultat dyker populära ramverk, välunderhållna bibliotek och bekanta implementeringsmönster naturligt upp i deras förslag, och det är precis vad gör dessa verktyg så värdefulla.

Men dessa optimeringsmål är fundamentalt olika från de frågor som företags säkerhetsteam behöver få svar på. AI utvärderar inte om ett paket stämmer överens med en organisations programvarupolicy, om en containerbild byggdes om från källan, om programvaruursprung har verifierats eller om ett beroende kommer från en godkänd programvarukälla.

Funktionalitet, popularitet och sannolikhet är användbara signaler för att generera kod, men de bör aldrig användas som ersättning för verifiering.

Varför vi behöver integrera åt vänster

Under många år har programvaruförsörjningskedjens säkerhet fokuserat på att identifiera risk efter att programvara har kommit in i utvecklingsprocessen. Sårbarhetsskannrar, programvaru sammansättningsanalys och SBOM:er har dramatiskt förbättrat synligheten i den programvara som applikationer innehåller.

Dessa verktyg förblir essentiella, men de hanterar en annan del av problemet.

AI flyttar programvaruvalet mycket tidigare i utvecklingslivscykeln, så när traditionella säkerhetskontroller börjar sin analys, kan det genererade projektet redan referera till dussintals beroenden som nu kräver utvärdering, åtgärd eller ersättning. Organisationer reagerar fortfarande på programvaruval som redan har kommit in i utvecklingsflödet.

Det är därför jag tror att organisationer behöver integrera åt vänster.

Idén bakom att integrera åt vänster är enkel: förtroende bör etableras innan programvara blir en del av en applikation, inte efter. När AI blir en aktiv deltagare i programvaruutveckling, blir den principen ännu viktigare. Styrning måste flytta till den punkt där programvara väljs, inte där den slutligen skannas.

Organisationer behöver definiera betrodda programvarukällor, etablera vilken programvara som AI får rekommendera och verifiera dessa artifact innan de blir en del av utvecklingsflödet. Målet är att säkerställa att AI accelererar programvarudistribution inom ramar som reflekterar organisationens säkerhets-, efterlevnads- och ingenjörsmässiga standarder.

Att styra programvaruvalet i AI-eran

Organisationer definierar redan var programvara kan köras, hur den distribueras och vem som är auktoriserad att släppa den. Alltmer kommer de också att behöva definiera vilken programvara som AI får rekommendera.

Här blir programvaruförsörjningskedjans hållning alltmer viktig. Organisationer behöver förtroende inte bara för den programvara de bygger, utan också för den programvara som AI rekommenderar på deras vägnar. Det förtroendet kommer från verifiering, betrodda programvarukällor och styrning som börjar innan programvara kommer in i utvecklingspipelinen.

AI kommer att fortsätta att förändra programvaruutveckling, och rätteligen så. Produktivitetsvinster är för stora för att ignorera, men när organisationer omfamnar AI-nativ utveckling, måste de erkänna att programvaruvalet blir alltmer automatiserat.

De organisationer som lyckas kommer att vara de som etablerar betrodda programvarukällor, verifierar de programvaruartifact som AI rekommenderar och integrerar styrning i programvaruvalet från början.

AI förändrar hur programvara skrivs, men nu, viktigare, förändrar det hur programvara väljs. Eftersom i AI-eran, den programvara du litar på beror alltmer på den programvara som din AI väljer först.