Din skanner läser syntax. En granskare läser avsikt.
AI-driven kodgranskning vs. SAST: varför regler som matchar mönster missar buggarna som faktiskt utnyttjas — och var skannern ändå gör nytta.
Ett SAST-verktyg levereras med en regelbok. Någon har skrivit ner de farliga mönstren — eval(, en saknad CSRF-token, en hårdkodad nyckel som ser ut som en känd molnuppgift — och skannern går igenom din kod och stämmer av varje rad mot listan. Den är snabb, deterministisk och fullkomligt bokstavlig.
Den bokstavligheten är både dess styrka och dess tak.
Regler matchar. De läser inte.
En regel vet hur en sårbarhet ser ut. Den vet inte vad din kod försöker göra.
Så den flaggar SQL-strängen som är parametriserad en funktion bort. Den missar behörighetskontrollen som saknas helt, eftersom det inte finns något mönster för en frånvaro. Den kan inte följa ett förorenat värde genom tre filer, en kö och ett deserialiseringssteg. Och den har aldrig hört talas om ramverket ni började använda förra månaden, så den är antingen tyst eller dränker dig i gissningar.
Regelboken ruttnar dessutom. Varje ny språkfunktion, varje ramverk, varje sätt att skriva samma bugg är en regel som någon måste författa och underhålla. Glappet mellan "det skannern kan" och "hur ditt team faktiskt skriver kod" blir bara större.
En granskare läser avsikt
En senior utvecklare som granskar en pull request mönstermatchar inte. Hen frågar vad koden är till för, spårar var otillförlitlig indata tar vägen, lägger märke till kontrollen som borde finnas och resonerar kring vad en angripare skulle testa.
Det är det jobbet AI-driven kodgranskning äntligen kan göra i stor skala. Istället för att jämföra rader mot en lista läser den koden som en människa gör — över filgränser, med ramverkets semantik i åtanke, och följer data dit den faktiskt hamnar.
Skillnaden syns där den betyder mest:
- Logik- och behörighetsfel. Den saknade kundkontrollen, endpointen som litar på ett klientskickat ID — buggar utan syntaktisk signatur, vilket är just därför regler inte ser dem.
- Verkligt dataflöde. Ett fynd är nåbart och exploaterbart, inte bara format som ett problem.
- Förklaringar, inte radnummer. Varje fynd kommer med vägen en angripare skulle ta och varför det spelar roll — så att utvecklare åtgärdar det istället för att bråka med det.
Där SAST fortfarande gör nytta
Det här handlar inte om att slänga skannern. SAST är snabb, billig att köra på varje commit och deterministisk — användbar som ett grovt första svep och för efterlevnadskrav som kräver ett namngivet verktyg. Behåll den för det den är bra på.
Men i samma stund som ett fynd kräver förståelse för varför koden finns tar reglerna slut på väg. Det är där lagret som resonerar tar vid — och det är där buggarna som faktiskt utnyttjas brukar bo.
Det verkliga måttet är åtgärdade fynd
En skanner som spottar ur sig femhundra fynd som ingen triagerar har inte producerat någonting. Siffran som räknas är hur många fynd en utvecklare läser, tror på och åtgärdar.
Att resonera om kod istället för att matcha den mot en lista är så du flyttar den siffran — färre larm, fler av dem sanna, vart och ett förklarat väl nog att agera på.