AI-kodegennemgang

En typisk AI-reviewer udløses af en webhook for en pull request eller et CI-job. Den samler kontekst fra diffens hunks, den omgivende kode for hver ændret funktion, relaterede filer fundet via et repository-indeks eller embeddings, beskrivelsen af pull requesten og den tilknyttede issue samt eventuelle instruktionsfiler i repositoryet; derefter beder den en model om fund og knytter hvert fund til en fil og et linjeinterval, der postes via kodehostens review-API. Mere avancerede værktøjer kører som agenter, der kan åbne flere filer, køre testsuiten eller kalde statiske analyseværktøjer, før de kommenterer. Nogle teams bruger også samme maskineri til at opsummere ændringen for de menneskelige reviewere, hvilket ofte er mere pålideligt nyttigt end selve fundene.

Det tekniske problem er præcision. En reviewer, der poster ti spekulative kommentarer pr. pull request, lærer udviklerne at ignorere den, så produkterne filtrerer efter sikkerhed og alvor, fjerner dubletter, begrænser kommentarer til ændrede linjer og lader teams slå kategorier fra. LLM-reviewere er forholdsvis gode til lokale fejl, der kan ses i diffen: manglende tjek for null eller grænser, off-by-one-fejl, uescapet input, der når en forespørgsel eller en shell, undertrykte undtagelser og uoverensstemmelser mellem koden og dens docstring eller tests. De er svage, hvor den relevante viden ligger uden for konteksten: forretningsregler, invarianter på tværs af tjenester, autorisation, der afhænger af konfiguration andre steder, samtidighed, og om ændringen overhovedet er det rigtige design. Outputtet er ikke-deterministisk, så samme diff kan give forskellige fund ved en ny kørsel.

AI-kodegennemgang supplerer statisk sikkerhedstest (SAST) frem for at erstatte den. SAST-værktøjer anvender deterministiske regler knyttet til CWE med reproducerbare resultater og SARIF-output, der egner sig til revisionsspor; en LLM-reviewer finder nogle problemer, som regler ikke kan udtrykke, men kan ikke dokumentere dækning. En kendt svaghed er korrelerede blinde vinkler: Når samme modelfamilie, som skrev koden, også gennemgår den, kan begge dele have samme misforståelse.

To styringspunkter er vigtige. For det første er selve pipelinen en angrebsflade: På offentlige repositories er teksten og koden i en pull request styret af angriberen og kan bære prompt injection, der sigter mod at undertrykke fund eller, hvis jobbet har hemmeligheder eller et token med skriveadgang, at lække dem, så revieweren bør køre med læseadgang alene og uden hemmeligheder på bidrag fra forks. For det andet forbliver ansvaret menneskeligt. NIST SP 800-218 (SSDF), praksis PW.7, kræver gennemgang og/eller analyse af menneskelæsbar kode for at finde sårbarheder; en AI-reviewer kan være ét dokumenteret input til den praksis, men branch protection bør stadig kræve en godkendende menneskelig gennemgang, og kommentarer fra bots må aldrig tælle som godkendelse.