De afgelopen maanden hebben we ons verbaasd over de kwaliteit van computergegenereerde gezichten, kattenfoto's, video's, essays en zelfs kunst. Kunstmatige intelligentie (AI) en machinaal leren (ML) zijn ook stilletjes in de softwareontwikkeling terechtgekomen, met tools als GitHub Copilot, Tabnine, Polycode, en anderen het nemen van de logische volgende stap door de bestaande functionaliteit voor het automatisch aanvullen van code op AI-steroïden te zetten. In tegenstelling tot kattenfoto's kunnen de oorsprong, kwaliteit en veiligheid van applicatiecode echter verstrekkende gevolgen hebben - en in ieder geval voor de veiligheid toont onderzoek aan dat het risico reëel is.
Voorafgaand academisch onderzoek heeft al aangetoond dat GitHub Copilot vaak code genereert met beveiligingskwetsbaarheden. Meer recentelijk bleek dat uit praktijkanalyse van Invicti-beveiligingsingenieur Kadir Arslan onveilige codesuggesties zijn bij Copilot nog steeds eerder regel dan uitzondering. Arslan ontdekte dat suggesties voor veel veelvoorkomende taken alleen maar de absolute kern betroffen, waarbij vaak de meest basale en minst veilige route werd gevolgd, en dat het accepteren ervan zonder aanpassingen kon resulteren in functionele maar kwetsbare toepassingen.
Een tool als Copilot is (door het ontwerp) automatisch aanvullen op een hoger niveau gezet, getraind op open source-code om fragmenten voor te stellen die in een vergelijkbare context relevant kunnen zijn. Hierdoor zijn de kwaliteit en veiligheid van suggesties nauw verbonden met de kwaliteit en veiligheid van het trainingspakket. De grotere vragen gaan dus niet over Copilot of een ander specifiek hulpmiddel, maar over door AI gegenereerde softwarecode in het algemeen.
Het is redelijk om aan te nemen dat Copilot slechts het topje van de speer is en dat soortgelijke generatoren de komende jaren gemeengoed zullen worden. Dit betekent dat wij, de technologie-industrie, ons moeten gaan afvragen hoe dergelijke code wordt gegenereerd, hoe deze wordt gebruikt en wie de verantwoordelijkheid op zich neemt als er iets misgaat.
Satnav-syndroom
Traditionele automatische aanvulling van code, waarbij functiedefinities worden opgezocht om functienamen te voltooien en u eraan wordt herinnerd welke argumenten u nodig heeft, bespaart enorm veel tijd. Omdat deze suggesties slechts een kortere weg zijn om de documenten zelf op te zoeken, hebben we geleerd impliciet te vertrouwen op wat de IDE suggereert. Zodra er een AI-aangedreven tool binnenkomt, zijn de suggesties niet langer gegarandeerd correct, maar ze voelen nog steeds vriendelijk en betrouwbaar aan, waardoor de kans groter is dat ze worden geaccepteerd.
Vooral voor minder ervaren ontwikkelaars stimuleert het gemak van het krijgen van een gratis codeblok een mentaliteitsverandering van: “Is deze code dicht genoeg bij wat ik zou schrijven” naar “Hoe kan ik deze code aanpassen zodat deze voor mij werkt.”
GitHub stelt heel duidelijk dat Copilot-suggesties altijd zorgvuldig moeten worden geanalyseerd, beoordeeld en getest, maar de menselijke natuur dicteert dat zelfs ondermaatse code af en toe in productie zal komen. Het lijkt een beetje op autorijden terwijl je meer naar je GPS kijkt dan naar de weg.
Beveiligingsproblemen met de toeleveringsketen
De Log4j-veiligheidscrisis heeft de beveiliging van de toeleveringsketen van software en, in het bijzonder, open source-beveiliging in de schijnwerpers gezet met een recente Memo van het Witte Huis over veilige softwareontwikkeling en een nieuw wetsvoorstel over het verbeteren van open source-beveiliging. Met deze en andere initiatieven zou het binnenkort nodig kunnen zijn om open source-code in uw applicaties in een software bill of materials (SBOM) te hebben, wat alleen mogelijk is als u willens en wetens een specifieke afhankelijkheid opneemt. Tools voor softwarecompositieanalyse (SCA) vertrouwen ook op die kennis om verouderde of kwetsbare open source-componenten te detecteren en te markeren.
Maar wat als uw applicatie door AI gegenereerde code bevat die uiteindelijk afkomstig is van een open source trainingsset? Theoretisch gezien, als zelfs maar één substantiële suggestie identiek is aan de bestaande code en wordt geaccepteerd zoals het is, zou je open source-code in je software kunnen hebben, maar niet in je SBOM. Dit kan leiden tot nalevingsproblemen, om nog maar te zwijgen van de kans op aansprakelijkheid als de code onveilig blijkt te zijn en tot een inbreuk leidt. SCA zal u niet helpen, omdat het alleen kwetsbare afhankelijkheden kan vinden en geen kwetsbaarheden in uw eigen code. .
Valkuilen op het gebied van licentieverlening en toeschrijving
Als we die gedachtegang voortzetten, moet je, om open source-code te gebruiken, voldoen aan de licentievoorwaarden ervan. Afhankelijk van de specifieke open source-licentie zul je in ieder geval bronvermelding moeten geven of soms je eigen code als open source vrijgeven. Sommige licenties verbieden commercieel gebruik helemaal. Wat de licentie ook is, u moet weten waar de code vandaan komt en hoe deze is gelicentieerd.
Nogmaals, wat als u door AI gegenereerde code in uw toepassing heeft die identiek is aan de bestaande open source-code? Zou bij een audit blijken dat u code gebruikt zonder de vereiste attributie? Of moet u misschien een deel van uw commerciële code open source maken om aan de regelgeving te blijven voldoen? Misschien is dat met de huidige instrumenten nog geen realistisch risico, maar dit zijn het soort vragen die we ons vandaag allemaal zouden moeten stellen, en niet over tien jaar. (En voor alle duidelijkheid: GitHub Copilot heeft een optioneel filter om suggesties te blokkeren die overeenkomen met bestaande code om de risico's voor de toeleveringsketen te minimaliseren.)
Diepere beveiligingsimplicaties
Terugkomend op de beveiliging: een AI/ML-model is slechts zo goed (en zo slecht) als zijn trainingsset. Dat hebben we in het verleden gezien - bijvoorbeeld in gevallen van gezichtsherkenningsalgoritmen die raciale vooroordelen tonen vanwege de gegevens waarop ze zijn getraind. Dus als uit onderzoek blijkt dat een codegenerator vaak suggesties produceert zonder rekening te houden met de beveiliging, kunnen we concluderen dat dit de leerset (dwz de publiekelijk beschikbare code) was. En wat als onveilige, door AI gegenereerde code vervolgens wordt teruggekoppeld naar die codebasis? Kunnen de suggesties ooit veilig zijn?
De veiligheidsvragen houden daar niet op. Als op AI gebaseerde codegeneratoren aan populariteit winnen en een aanzienlijk deel van de nieuwe code voor hun rekening gaan nemen, is de kans groot dat iemand ze zal proberen aan te vallen. Het is al mogelijk om AI-beeldherkenning voor de gek te houden door de leerset ervan te vergiftigen. Vroeg of laat zullen kwaadwillende actoren proberen unieke, kwetsbare code in openbare opslagplaatsen te plaatsen, in de hoop dat deze in suggesties terechtkomt en uiteindelijk in een productietoepassing terechtkomt, waardoor deze gemakkelijk kan worden aangevallen.
En hoe zit het met de monocultuur? Als meerdere applicaties uiteindelijk dezelfde zeer kwetsbare suggestie gebruiken, ongeacht de oorsprong ervan, kunnen we te maken krijgen met kwetsbaarheidsepidemieën of misschien zelfs AI-specifieke kwetsbaarheden.
AI in de gaten houden
Sommige van deze scenario’s lijken tegenwoordig misschien vergezocht, maar het zijn allemaal zaken die wij in de technologie-industrie moeten bespreken. Nogmaals, GitHub Copilot staat alleen in de schijnwerpers omdat het momenteel voorop loopt, en GitHub geeft duidelijke waarschuwingen over de kanttekeningen bij door AI gegenereerde suggesties. Net als bij automatisch aanvullen op je telefoon of routesuggesties in je navigatiesysteem zijn het slechts tips om ons leven gemakkelijker te maken, en het is aan ons om ze te aanvaarden of te laten.
Met hun potentieel om de ontwikkelingsefficiëntie exponentieel te verbeteren, zullen op AI gebaseerde codegeneratoren waarschijnlijk een permanent onderdeel van de softwarewereld worden. In termen van applicatiebeveiliging is dit echter nog een andere bron van potentieel kwetsbare code die strenge beveiligingstests moet doorstaan voordat deze in productie mag worden genomen. We kijken naar een geheel nieuwe manier om kwetsbaarheden (en mogelijk niet-gecontroleerde afhankelijkheden) rechtstreeks in uw eigen code te plaatsen. Het is dus logisch om met AI verbeterde codebases als niet-vertrouwd te behandelen totdat ze worden getest – en dat betekent dat u alles net zo vaak moet testen als u. kan.
Zelfs relatief transparante ML-oplossingen zoals Copilot roepen al enkele juridische en ethische vragen op, om nog maar te zwijgen van veiligheidsproblemen. Maar stel je eens voor dat op een dag een nieuwe tool code begint te genereren die perfect werkt en de beveiligingstests doorstaat, op één klein detail na: niemand weet hoe het werkt. Dan is het tijd voor paniek.
