Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
AI er på rekordtid blevet en del af softwareudviklingen.
Udviklere bruger teknologien til at generere kode, finde fejl, skrive tests og dokumentere løsninger. Det kan øge udviklingshastigheden markant og frigøre tid til andre opgaver.
Men den udvikling skaber også et nyt sikkerhedsproblem: AI kan producere mere kode, end mennesker realistisk kan nå at læse og forstå.
Vi kan derfor ikke hægte AI på udviklingsprocessen og samtidig fastholde en sikkerhedsmodel, der er designet til menneskelig udviklingshastighed.
Det betyder dog ikke, at vi skal bremse AI-assisteret softwareudvikling. Men sikkerhedsarbejdet skal ændre sig i takt med udviklingsarbejdet.
AI-genereret kode skal behandles som ikke-betroet input
AI kan producere velfungerende kode på få sekunder.
Men den kan også videreføre usikre kodemønstre, introducere sårbarheder eller foreslå komponenter og afhængigheder, som udvikleren ikke nødvendigvis har det fulde overblik over.
Derfor bør udgangspunktet være enkelt: AI-genereret kode skal behandles som ikke-betroet input. Ikke fordi AI nødvendigvis skriver dårligere kode end mennesker.
Mennesker laver også fejl. Men fordi vi ikke må forveksle et overbevisende output med et sikkert output.
Når mængden af genereret kode samtidig vokser, bliver det stadig mindre realistisk at forvente, at menneskelig gennemlæsning alene kan udgøre sikkerhedsnettet. Vi er nødt til at automatisere en større del af kontrollen.
Sikkerheden skal følge koden
Det gør DevSecOps endnu vigtigere.
Sikkerhed kan ikke være et kontrolpunkt til sidst i udviklingsprocessen, når koden allerede er skrevet og løsningen står foran produktion. Kontrollen skal ligge så tæt på udviklingen, at eventuelle problemer bliver opdaget, mens de bliver skabt.
Det betyder blandt andet, at sikkerhedskontrollen i højere grad skal automatiseres. Kode og tredjepartskomponenter skal analyseres løbende, der skal scannes for adgangsnøgler og andre følsomme oplysninger, som ved en fejl kan være havnet i koden, og containere skal kontrolleres for sårbarheder.
Samtidig bliver det vigtigere at vide præcist, hvad en løsning består af. En Software Bill of Materials – en slags indholdsfortegnelse over software – kan skabe overblik over de komponenter og afhængigheder, der indgår i løsningen. På samme måde kan det blive nødvendigt at dokumentere, hvilke AI-modeller og AI-komponenter der indgår, efterhånden som de bliver en fast del af moderne softwareløsninger.
Derudover bør der sættes klare rammer for, hvordan AI-værktøjer må bruges i udviklingsarbejdet. Og når der opstår sikkerhedsfund, skal de risikovurderes, så den menneskelige opmærksomhed bruges dér, hvor en fejl kan få de største konsekvenser.
Det afgørende er ikke det enkelte værktøj – det er princippet om, at når produktionen af kode automatiseres, skal kontrollen kunne følge med.
100 sikkerhedsfund er ikke 100 lige store problemer
Automatisering skaber imidlertid sin egen udfordring. Flere scanninger kan også betyde flere fund.
Hvis udviklere og sikkerhedsfolk bliver præsenteret for hundredvis af advarsler uden mulighed for at prioritere dem, har vi ikke nødvendigvis gjort organisationen mere sikker. Vi har blot skabt en ny flaskehals. Derfor skal sikkerhedsarbejdet i højere grad være risikobaseret.
Den samme sårbarhed kan have vidt forskellig betydning afhængigt af, hvor den findes. Der er stor forskel på en fejl i kode, som ingen udefra kan nå, og en fejl i en internetvendt cloud-løsning med adgang til følsomme data.
Det bliver derfor stadig vigtigere at forbinde det, vi finder i koden, med den kontekst, løsningen faktisk kører i: Er systemet eksponeret? Hvilke data har det adgang til? Findes der en realistisk angrebsvej? Og hvad vil konsekvensen være, hvis sårbarheden udnyttes?
Derfor bliver det afgørende at se sikkerheden i udviklingen, cloud-miljøet og den faktiske drift i sammenhæng.
Mennesket skal ikke kontrollere alt – men det vigtigste
AI ændrer derfor også sikkerhedsmedarbejderens og udviklerens rolle.
Målet er ikke, at mennesker manuelt skal kontrollere alt det, AI producerer. Det vil hurtigt eliminere en stor del af produktivitetsgevinsten. Opgaven bliver i stedet at etablere automatiserede kontroller, der kan håndtere volumen, og sikre menneskelig vurdering dér, hvor risikoen kræver det.
Det kræver både teknologi og governance. Organisationen skal beslutte, hvilke AI-værktøjer der må anvendes, hvilke kontroller der er obligatoriske, hvilke fund der stopper en release, og hvornår et menneske skal involveres.
Det er ikke et argument imod AI-assisteret udvikling. Tværtimod. AI kan give os mulighed for at udvikle bedre software hurtigere. Men så skal sikkerheden designes til den samme virkelighed.
For hvis AI kan skrive kode hurtigere, end mennesker kan kontrollere den, er svaret ikke at bede menneskerne om at læse hurtigere. Vi skal derimod bygge sikkerhedskontrollen designet til hastigheden på AI.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
