Vinster:
- Möjlighet att använda artificiell intelligens som ett andra öga och flagga sårbarheter i OWASP-klassen (injektion, hård hemlighet, åtkomstkontroll) i koden genom att ge sammanhang
- Förmåga att eliminera falska positiva resultat från artificiell intelligens med sammanhang och förhindra att varje fynd behandlas som en verklig sårbarhet utan att validera den
- Förmåga att känna igen att korrigeringen som föreslagits av artificiell intelligens kan introducera nya sårbarheter/buggar och skicka varje patch genom gransknings- och testporten
Sårbarheter inom mjukvara är bland de dyraste sårbarheterna eftersom de är inbäddade i produkten från början och distribueras till miljontals användare. Säker kodgranskning är processen att läsa källkoden rad för rad och fånga upp sårbarheter – SQL-injektion, autentiseringssårbarhet, hårdkodat lösenord, felaktig auktorisering – innan de sätts i produktion. När det görs för hand är det långsamt och tröttsamt; Det är lätt att missa en sårbarhet i en stor kodbas.
AI är kraftfull vid kodgranskning av två skäl: kod är också ett språk och AI är bra på mönsterigenkänning. AI kan snabbt flagga farliga mönster i en kodbit (sätta användarinmatning direkt i frågan, okrypterad datalagring, saknad indatavalidering), förklara varför vart och ett är riskabelt och föreslå en lösning. Men AI ser inte hela driftskontexten för koden (inmatningen kan rensas i ett annat lager), den kan uppfinna en sårbarhet som inte existerar (falsk positiv) eller missa en verklig sårbarhet (falsk negativ), och viktigast av allt, den "fix" den föreslår kan introducera en ny sårbarhet eller bugg. AI är ett andra öga och pekare i kodgranskning; Utvecklaren och säkerhetsexperten avgör om ett fynd är en verklig sårbarhet och om korrigeringen är korrekt och säker.
Steg för kodgranskning
- Ge utrymme och sammanhang. Vilket språk, vilket ramverk, var tar den här koden input, var ger den utdata, vid vilket lager fungerar den? Kodgranskning utan sammanhang ger falska positiva resultat.
- Sök efter farliga mönster. Sök efter kända AI-sårbarhetsklasser (som OWASP Top 10): injektion, autentisering, avslöjande av känslig data, åtkomstkontroll.
- Låt varje fynd motiveras. För varje flagga: vilken linje, vilken sårbarhetsklass, hur kan den utnyttjas, vilka bevis finns det. Ett omotiverat konstaterande tas inte på allvar.
- Eliminera falskt positivt. Rensas indata verkligen, är den vägen verkligen tillgänglig - kontrollera med sammanhang.
- Verifiera korrigeringen. Bekräfta att patchen som rekommenderas av AI faktiskt stänger sårbarheten, inte introducerar nya sårbarheter/buggar och har klarat testet.
- Mänskligt godkännande. Utvecklare + säkerhetsexpert granskar upptäckten och fixar; Det är så den kommer in i kodförrådet.
Villkor: SAST (Static Application Security Testing — statisk säkerhetstestning som analyserar källkoden utan att köra den). DAST (Dynamic — dynamisk testning som testar den körande applikationen externt). OWASP Top 10 är standardlistan över de vanligaste sårbarheterna i webbapplikationer. Injektion är en sårbarhet som orsakas av att användarinmatning tolkas som ett kommando/fråga (t.ex. SQL-injektion). Parameteriserad fråga är den korrekta metoden som förhindrar injektion genom att separera indata från koden.
Tabell över vanliga sårbarhetsklasser
Sårbarhetsklass
Symptom (i kod)
rätt lösning
AI:s fälla
SQL-injektion
Går med input i fråga
Parameteriserad fråga
Kan strunta i sanering
hårdkodad hemlighet
Lösenord/skriv in kod
Hemligt kassaskåp (valv), env
Falskt positivt (prov/test)
Svag autentisering
Saknas/felaktig kontroll
Kraftfull, centraliserad kontroll
missar sammanhanget
Felaktig åtkomstkontroll
Ingen behörighetskontroll
Serversidans auktorisering
Förstår inte komplext flöde
Utlämnande av känsliga uppgifter
Lösenordsfri lagring/loggning
Kryptering, maskering
Kan inte känna kritik
Osäker serialisering
Deserialisera opålitlig data
Säker analys
Saknar sällsynt mönster
tre minifodral
Fall 1 — Att fånga den faktiska injektionen. En utvecklare låter AI undersöka en dataåtkomstfunktion. AI:n markerar raden där userId-värdet från användaren sammanfogas direkt i SQL-texten och säger "det här är klassisk SQL-injektion, förvandla det till en parameteriserad fråga"; Ger provkorrigering. Utvecklaren bekräftar att indata inte har sanerats någon annanstans, verifierar att det är en verklig sårbarhet, implementerar den föreslagna parameteriserade frågan och skriver ett test. AI lyfte fram sårbarheten; verifiering och korrigeringstestning kom från utvecklaren.
Fall 2 — Falsk positiv fast hemlighet. AI:n ser lösenordet = "test1234"-raden i en fil och säger "kritiskt: hårdkodat lösenord". Utvecklaren kontrollerar sammanhanget: det här är en enhetstestfil, en dummytestdata, inte släppt i produktion och inte portad till ett riktigt system. Fyndet är ett falskt positivt. Utvecklaren dokumenterar detta men vidtar inga åtgärder eftersom det inte är en riktig hemlighet. Lektion: AI:s "hard secret"-tecken måste elimineras av sammanhanget; Inte varje sträng är en hemlighet.
Fall 3 – Ny sårbarhetskorrigering. AI föreslår en fix för en XSS-sårbarhet (cross-site scripting); men koden han föreslår rensar indata på fel ställe och hoppar över utdatakodning i ett annat område; Som ett resultat sluter gapet inte helt. Säkerhetsexperten granskar fixen, upptäcker den saknade kodningen och fixar den i rätt lager. Lektion: Patchen som AI rekommenderar är inte automatiskt säker; Varje fix granskas och testas.
Svag prompt / Stark prompt
Svag uppmaning:
Finns det ett kryphål i den här koden, fixa det: [kod]
Den här uppmaningen ger inget sammanhang (språk, ramverk, ingångskälla), ber inte om motivering, ifrågasätter inte det falska positiva och är öppet för att blint acceptera korrigeringen som produceras av AI. AI blandade tecken på både verklig sårbarhet och icke-existerande.
Kraftfull uppmaning:
Din roll: assistent som är det ANDRA ÖGET till utvecklaren i säker kodgranskning.Beslutsfattande; anser att korrigeringen tillämpas direkt. Kod: [ange språk/ramverk].Kontext: denna funktion [indatakälla: t.ex. tar emot [extern HTTP-begäran], skriver till [utgångsdestination]. Din uppgift: (1) flagga möjliga sårbarheter med OWASP-klassen, ge radnummer + varför riskabelt + hur man utnyttjar + bevis för varje fynd, (2) skriv minst 1 falskt positivt scenario för varje fynd (t.ex. om indata saneras i ett annat lager), (3) föreslå en fix men med tecknet "[review + write test]"; Utvärdera även om korrigeringen introducerar nya sårbarheter/buggar. Lägger till en falsk sårbarhet.[kod]
Stark uppmaning ger sammanhang, ber om OWASP-klass och bevis, ifrågasätter falska positiva och risker för åtgärdande, tvingar fram mänsklig granskning.
Kopierbara promptmallar
SÅRBARHETSSCANNINGSMALL Undersök [språk/ramverk]-koden för OWASP Top 10. För varje möjlig fynd: radnummer, sårbarhetsklass, varför det är riskabelt, exempelexploatering, bevisstyrka (säkert/sannolikt/svagt). Sammanhang: input [källa], output [mål]. Lägga till påhittade fynd; Om du inte är säker, skriv "[måste verifieras]". Kod: [klistra in]
FALSKT POSITIVT ELIMINERINGSMÖNSTER För följande kodupptäckning, lista scenarierna där det INTE finns en verklig sårbarhet: kan indata rensas på ett annat lager, är denna sökväg tillgänglig, är detta värde ett test/exempel, är ramverket automatiskt skyddat. Skriv hur du bekräftar för var och en. Hitta: [klistra in]
FIXA UTVÄRDERINGSMALL rekommenderar en korrigering för följande sårbarhet; kritisera sedan din egen fix: (1) stänger den verkligen sårbarheten, (2) introducerar den en ny sårbarhet/bugg, (3) vilket test ska jag skriva (positivt och negativt skiftläge), (4) prestanda/funktionalitetspåverkan. Jag kommer att granska och testa korrigeringen. Sårbarhet + kod: [klistra in]
SÄKER MÖNSTER UNDERVISNINGSMALL för sårbarhetsklass [t.ex. SQL-injektion] visar jämförelsevis säkert skrivmönster och vanliga felaktiga mönster i detta språk/ramverk. Allmän regel + ge kodexempel; men jag vill att du frågar sammanhanget innan du implementerar det i min kod. Språk/ramverk: [skriv]
Vanliga misstag
- Recension utan sammanhang. Utan språk, ramverk och input/output-kontext förväxlar AI både verkliga och falska fynd; Var noga med att ge sammanhang.
- Misstag varje tecken för verklig svaghet. AI producerar falska positiva resultat (testdata, indata rensas i ett annat lager); Sålla varje fynd med sitt sammanhang.
- Blindt tillämpa AI:s korrigering. Rekommenderad patch kan introducera nya sårbarheter/buggar; granska och skriva prov.
- Lita på det falska negativa. Även om AI:n säger "inga sårbarheter", undersök själv de kritiska vägarna; Statisk skanning upptäcker inte alla sårbarheter.
- Ge koden/hemligheten till det externa verktyget. Privat kod och riktiga hemligheter (nyckel, lösenord) är immateriell egendom och sårbarhet; anonymisera eller använda isolerade företagsverktyg.
Tips: När du har AI-granskningskoden är det mest effektiva filtret att fråga efter "bevisets styrka" (visst/sannolikt/svagt) för varje fynd. De flesta fynden markerade som "svaga" är falska positiva; du allokerar din energi till de "säkra".
Varning: AI:s föreslagna säkerhetsfix bör inte komma in i lagret utan att ha testats. En felaktig "fix" kan både lämna sårbarheten öppen och leda till ett funktionsfel i produktionen; Varje patch går igenom gransknings- och testporten.
Sammanfattningsvis
Säker kodgranskning är det billigaste sättet att fånga sårbarheter innan de sätts i produktion, och eftersom kod är ett språk blir AI ett kraftfullt andra öga här: flaggar farliga mönster, förklarar risker, föreslår korrigeringar. Men AI ser inte hela driftssammanhanget, producerar falska positiva och falska negativa resultat, och patchen som den rekommenderar kan introducera nya sårbarheter. Så granskningen har sex steg (sammanhang, screening, motivering, falsk positiv eliminering, fixverifiering, mänskligt godkännande) och beslutet ligger hos utvecklaren och säkerhetsexperten. Tre principer: inget fynd tolkas utan sammanhang, varje tecken elimineras med kontext, ingen fix lagras oprövad. Och koden/hemligheten ges aldrig till ett externt verktyg utan anonymisering.
Applikationsuppgift
Ta ett exempel på kodavsnitt (antingen tar du bort känsliga delar från din egen kod eller en exempelkod med sårbarheter). Låt AI undersöka det med mallen "Vulnerability Scanning"; Använd mallen "Falsk positiv eliminering" för varje fynd och eliminera de riktiga. Ta korrigeringen av det allvarligaste fyndet med mallen "Remediation Evaluation", granska den själv och skriv ett positivt + ett negativt testfall. Notera hur många fynd som var falskt positiva.
checklista
- [ ] Jag gav språket, ramverket och input/output sammanhang innan jag granskade koden.
- [ ] Jag bad om radnummer, sårbarhetsklass, exploateringsväg och bevis för varje fynd.
- [ ] Jag screenade varje fynd för falska positiva resultat med sammanhang.
- [ ] Jag tillämpade inte blint AI:s korrigering; Jag recenserade och skrev ett test.
- [ ] Trots "No vulnerabilities"-utgången undersökte jag själv de kritiska vägarna.
- [ ] Jag anonymiserade koden/hemligheterna eller använde företagsisolerade verktyg.
- [ ] Jag har klarat upptäckten och fixen genom utvecklare + säkerhetsgodkännande.