AI-herstel van kwetsbaarheden: wat AI-fix-pull requests kunnen

Wat AI-herstel is

Bij AI-herstel van kwetsbaarheden schrijft een taalmodel de oplossing voor een bekende kwetsbaarheid. Dat gebeurt in drie vormen:

• Suggesties voor codefixes. Een model stelt een patch voor naast een melding uit statische analyse. GitHub Copilot Autofix bijvoorbeeld "genereert automatisch suggesties voor codewijzigingen voor CodeQL-meldingen die in pull requests en op de standaardbranch worden gevonden."
• Upgrades van afhankelijkheden die de code aanpassen. Een versie ophogen is eenvoudig. Het lastige deel is de hernoemde functie of de gewijzigde standaardwaarde die de nieuwe versie meebrengt. Een model kan die vervolgwijzigingen in dezelfde pull request doorvoeren.
• Agentisch herstel. Een agent loodst de oplossing zelfstandig door meerdere stappen: de code aanpassen, de build en de tests draaien, de fouten lezen, opnieuw proberen, en pas een pull request openen als de checks slagen.

Waar AI-fixes hun waarde bewijzen

Updatebots op basis van regels openen nu al pull requests die een kwetsbaar pakket naar een gerepareerde versie ophogen. Ze lopen vast wanneer de upgrade iets breekt, omdat het aanpassen van de aanroepende code geen regel is. Daar stapelt de achterstand zich op: de beveiligingsupdate die maandenlang openstaat omdat niemand tijd heeft om de wijziging van de hoofdversie door te werken.

Een changelog lezen, de aanroepplaatsen vinden en die herschrijven, is precies het soort werk waarin taalmodellen goed zijn. Een AI-fix die met de upgrade én de codewijzigingen komt, gebouwd en getest, maakt van een week van iemands aandacht een review.

Waar AI-fixes misgaan

De duidelijkste beschrijvingen van de grenzen komen van de leveranciers zelf. Over Copilot Autofix schrijft GitHub:

• Het "gebruikt een generatief model dat niet-deterministisch is. Zelfs met dezelfde melding en code kan het er niet in slagen een bruikbare suggestie te doen, of kan de suggestie per poging verschillen."
• "Het systeem weet niet welke versies van afhankelijkheden worden ondersteund of veilig zijn, en kan verzonnen afhankelijkheden voorstellen die onder statistisch waarschijnlijke namen zijn gepubliceerd."

Het tweede punt is niet hypothetisch. Onderzoek naar codegenererende modellen heeft gemeten hoe vaak ze pakketten aanraden die niet bestaan: namen die een aanvaller kan registreren en met malware kan vullen. Een fix die een gehallucineerd pakket installeert, vervangt de ene kwetsbaarheid door een ergere.

Drie vangrails dekken het grootste deel van het risico:

1. Bouw en test elke fix voordat een mens hem beoordeelt, zodat reviewtijd naar fixes gaat die werken.
2. Controleer elk toegevoegd of gewijzigd pakket tegen de registry en de versie die u verwacht.
3. Houd een mens bij de merge. Een AI-fix is de pull request van een bijdrager, geen beslissing.

Garbage in, pull requests out

Een AI-hersteltool lost de kwetsbaarheden op die hij krijgt aangereikt. Als die lijst is gereconstrueerd uit lockfiles of een gescande image, erft hij elk gat in die reconstructie: tools die de build downloadt maar die geen manifest declareert, versies die afwijken van wat de build heeft geresolved, pakketten die uit caches zijn teruggezet. De tool opent dan zelfverzekerde pull requests voor sommige kwetsbaarheden en hoort nooit van andere.

Sommige teams gaan nog verder en laten een model de afhankelijkheden zelf uitzoeken. Dan wordt ook de inventaris niet-deterministisch, terwijl juist dat het ene deel van het proces is dat elke keer hetzelfde moet uitkomen. Door AI gegenereerde SBOM's legt uit waarom een geraden inventaris geen bewijs is.

Het patroon dat werkt: deterministische gegevens als basis en AI-oordeel daarbovenop. Een vastgelegde lijst van wat elke build werkelijk bevat, door opzoeken gematcht tegen advisories, en AI die de fix schrijft.

Waar CRACI past

CRACI is de deterministische laag. Het draait uw GitHub Actions-jobs op zijn eigen runners en legt de pakketten vast die elke job werkelijk heeft opgehaald, inclusief transitieve afhankelijkheden en pakketten die uit caches zijn teruggezet, met een volledigheidsstatus voor elke job. Het beoordeelt gemonitorde SBOM's continu opnieuw, zodat een nieuwe advisory verschijnt bij de builds die erdoor worden getroffen. Securityteams beoordelen elke bevinding en sturen die door naar het team dat verantwoordelijk is voor de oplossing.

Dat is de lijst waarmee een AI-fix zou moeten beginnen, en nadat de fix is gemerged, laat de SBOM van de volgende build zien of de gerepareerde versie ook echt is wat de build gebruikte. Zie kwetsbaarheden volgen voor de volledige functionaliteit, en AI versus deterministische beveiliging voor waar elke aanpak thuishoort.

AI-herstel van kwetsbaarheden: veelgestelde vragen

Wat is AI-gestuurd herstel van kwetsbaarheden?

Bij AI-gestuurd herstel van kwetsbaarheden schrijft een taalmodel de oplossing voor een kwetsbaarheid: een codewijziging voor een bevinding uit statische analyse, of een upgrade van een afhankelijkheid plus de codewijzigingen die die upgrade vraagt. Het resultaat is meestal een suggestie of een pull request die een mens beoordeelt.

Wat is agentisch herstel?

Bij agentisch herstel krijgt een AI-agent de tools om een oplossing zelfstandig door meerdere stappen te loodsen: de bevinding lezen, de code aanpassen, de build en de tests draaien en herhalen tot ze slagen, en dan een pull request openen. Het verschil met een eenmalige suggestie is dat de agent zijn eigen werk controleert voordat een mens het ziet.

Kunt u door AI gegenereerde beveiligingsfixes veilig mergen?

Behandel ze als de pull request van elke andere bijdrager. GitHub noemt Copilot Autofix niet-deterministisch en waarschuwt dat het verzonnen afhankelijkheden kan voorstellen. Beoordeel dus de wijziging, draai de tests en controleer of elk pakket dat wordt toegevoegd bestaat en het pakket is dat u verwacht.

Kan AI kwetsbaarheden in afhankelijkheden vinden?

Voor dat deel is het de verkeerde tool. Of een pakketversie wordt getroffen door een bekende advisory, is een kwestie van opzoeken, en het antwoord moet elke keer hetzelfde uitkomen. Laat deterministische tooling de lijst met kwetsbare pakketten opstellen uit een vastgelegde SBOM, en zet AI in waar oordeelsvermogen helpt: de oplossing schrijven en aanpassen.

Wat heeft een AI-hersteltool nodig om goed te werken?

Een nauwkeurige lijst van wat werkelijk kwetsbaar is, een build en een testsuite waartegen de oplossing kan draaien, en een mens bij de merge. Het eerste ontbreekt het vaakst: een fix-pull request voor een pakket dat het product niet levert, is ruis, en een kwetsbaar pakket dat de inventaris miste, krijgt er nooit een.