AI ændrer, hvem der bestemmer, hvilket software kommer ind i din organisation

AI er blevet en del af den daglige softwareudvikling. Fra generering af API’er og skrivning af tests til opførelse af hele applikationer, hjælper kodningsassistenter udviklingsteams med at løse problemer og udgive software hurtigere end nogensinde før. Produktivitetsgevinsterne er uafviselige, og organisationer omfatter hurtigt AI på tværs af softwareudviklingslivscyklussen.

Meget af samtalen har fokuseret på den kode, AI genererer. Kan udviklere stole på AI-genereret kode? Introducerer den sårbarheder? Hvordan skal sikkerhedsteams gennemgå den? Disse spørgsmål er vigtige, men de er ikke den største ændring, AI bringer til softwareudvikling. AI er gået ud over bare at kunne generere kode og påvirker nu også de første softwarevalg, der former, hvilket software kommer ind i en organisation.

AI-kodningsassistenter bygger sjældent applikationer fra bunden, og de komponerer løsninger ved hjælp af eksisterende rammer, open-source-biblioteker, SDK’er, containerimages og pakkeøkosystemer. Hver anbefaling former softwaregrundlaget, en applikation er bygget på, ofte før en udvikler gennemgår den første linje af genereret kode.

I årtier har den første tillidsbeslutning i softwareudvikling næsten udelukkende tilhørt udviklere, men nu begynder den antagelse at ændre sig. AI anbefaler mere og mere, mens udviklere validerer resultatet herefter. Denne subtile ændring har betydelige implikationer for softwareforsyningskædesikkerhed, fordi hver anbefaling medfører en implicit tillidsbeslutning.

Organisationer har brugt år på at styre, hvordan software bygges, testes og udgives. Den næste udfordring er at styre, hvordan software vælges i en AI-naturlig udviklingsmiljø.

Den Første Tillidsbeslutning

Hver applikation afhænger af software skabt af tusinder af bidragydere på tværs af utallige open-source-projekter. Før introduktion af en ny afhængighed, vurderede udviklere typisk dokumentation, sammenlignede rammer, gennemgik fællesskabsadoption, undersøgte udgivelseshyppighed og overvejede, om et projekt var modent nok til produktion. Udviklere valgte ikke altid det rigtige, men hver afhængighed blev introduceret bevidst.

I dag kan en udvikler blot bede en AI-assistent om at “bygge en sikker REST-API med godkendelse og PostgreSQL-understøttelse.” Inden for sekunder genererer AI en fungerende projekt. Undervejs anbefaler den en runtime, vælger en ramme, henviser til en basiscontainerbillede, importerer godkendelsesbiblioteker, vælger SDK’er og genererer afhængighedsmanifest som package.json, requirements.txt eller pom.xml. Pakkeledere løser derefter disse afhængigheder og deres transitivt afhængigheder under byggeprocessen.

De fleste udviklere gennemgår den applikation, AI producerer, men kun få standser for at undersøge hver softwarebeslutning, AI træffer undervejs. AI har komprimeret softwarevalg, der tidligere tog timer af research, til sekunder og anbefaler mere og mere på vegne af udviklere.

Hver Anbefaling Er En Tillidsbeslutning

Hver softwaregenstand bærer sin egen tilladskæde. En bibliotek har vedligeholdere, bidragydere, udgivelsesprocesser, signaturpraksis, afhængigheder og proveniens. En containerbillede arver software fra upstream-distributioner, og en SDK introducerer yderligere pakker, hver af dem udvider tilladskæden.

En enkelt AI-anbefaling kan hurtigt udvide til hundredvis af softwaregenstande, der bliver en del af en applikation. Open source har altid fungeret på denne måde. Hvad der ændrer sig, er, hvem der træffer disse tillidsbeslutninger først. Historisk set vurderede og valgte udviklere de komponenter, de stolede på. AI-systemer anbefaler mere og mere, mens udviklere validerer resultatet herefter.

Det lyder som en lille ændring, men det ændrer fundamentalt, hvordan organisationer skal tænke om softwareforsyningskædesikkerhed.

AI Optimerer For Arbejdende Software, Ikke Organisatorisk Tillid

Ingenting af dette betyder, at AI træffer dårlige anbefalinger. Tværtimod.

AI-kodningsassistenter er gode til at anbefale software, fordi de har lært af millioner af eksempler på, hvordan udviklere løser lignende problemer. Som resultat af dette fremstår populære rammer, velunderstøttede biblioteker og kendte implementeringsmønstre naturligt i deres forslag, og det er præcis det, der gør disse værktøjer så værdifulde.

Men disse optimeringsmål er fundamentalt forskellige fra de spørgsmål, enterprise-sikkerhedsteams behøver at få besvaret. AI vurderer ikke, om en pakke er i overensstemmelse med en organisations softwarepolitik, om en containerbillede er genopbygget fra kilde, om softwareproveniens er verificeret eller om en afhængighed stammer fra en godkendt softwarekilde.

Funktionalitet, popularitet og sandsynlighed er nyttige signaler til kodegenerering, men de bør aldrig bruges som erstatning for verificering.

Hvorfor Vi Har Brug For At Integrere Til Venstre

I årevis har softwareforsyningskædesikkerhed fokuseret på at identificere risiko efter, at software er kommet ind i udviklingsprocessen. Sårbarhedsscannere, Software Composition Analysis og SBOM’er har dramatisk forbedret synligheden i den software, applikationer indeholder.

Disse værktøjer er stadig essentielle, men de adresserer en anden del af problemet.

AI flytter softwarevalg meget tidligere i udviklingslivscyklussen, så når traditionelle sikkerhedscontroller begynder deres analyse, kan det genererede projekt allerede henviser til dusinvis af afhængigheder, der nu kræver vurdering, afhjælpning eller erstatning. Organisationer reagerer stadig på softwarevalg, der allerede er kommet ind i udviklingsarbejdsprocessen.

Det er derfor, jeg mener, organisationer har brug for at integrere til venstre.

Idéen bag at integrere til venstre er enkel: Tillid skal etableres, før software bliver en del af en applikation, ikke efter. Da AI bliver en aktiv deltager i softwareudvikling, bliver denne princip endnu vigtigere. Styring skal flyttes til det punkt, hvor software vælges, ikke hvor den til sidst scannes.

Organisationer har brug for at definere tilladte softwarekilder, etablere, hvilke softwaregenstande AI er tilladt at anbefale, og verificere disse genstande, før de bliver en del af udviklingsarbejdsprocessen. Målet er at sikre, at AI accelererer softwarelevering inden for rammer, der afspejler organisationens sikkerheds-, overholdelses- og ingeniørstandarder.

At Styre Softwarevalg I AI-Æraen

Organisationer definerer allerede, hvor software kan køre, hvordan den udgives og hvem der er autoriseret til at udgive den. I stigende grad vil de også have brug for at definere, hvilket software AI er tilladt at anbefale.

Det er her, softwareforsyningskædeholdning bliver stadig vigtigere. Organisationer har brug for tillid ikke kun til den software, de bygger, men også til den software, AI anbefaler på deres vegne. Denne tillid kommer fra verificering, tilladte softwarekilder og styring, der begynder, før software kommer ind i udviklingsprocessen.

AI vil fortsætte med at transformere softwareudvikling, og det er rigtigt nok. Produktivitetsgevinsterne er for store til at ignorere, men da organisationer omfatter AI-naturlig udvikling, må de erkende, at softwarevalg bliver mere og mere automatiseret.

De organisationer, der lykkes, vil være de, der etablerer tilladte softwarekilder, verificerer de softwaregenstande, AI anbefaler, og integrerer styring i softwarevalg fra begyndelsen.

AI ændrer, hvordan software skrives, men nu, endnu vigtigere, ændrer det, hvordan software vælges. For i AI-æraen afhænger den software, du stoler på, mere og mere af den software, din AI vælger først.