Gevinster:
- Evne til at bruge kunstig intelligens som et andet øje og markere sårbarheder i OWASP-klassen (injektion, hård hemmelighed, adgangskontrol) i koden ved at give kontekst
- Evne til at eliminere falske positiver produceret af kunstig intelligens med kontekst og forhindre at behandle hvert fund som en reel sårbarhed uden at validere det
- Evne til at erkende, at rettelsen foreslået af kunstig intelligens kan introducere nye sårbarheder/bugs og sende hver patch gennem gennemgangs- og testporten
Sårbarheder inden for software er blandt de dyreste sårbarheder, fordi de er indlejret i produktet fra begyndelsen og distribueret til millioner af brugere. Sikker kodegennemgang er processen med at læse kildekoden linje for linje og fange sårbarheder - SQL-injektion, autentificeringssårbarhed, hårdkodet adgangskode, forkert godkendelse - før de går i produktion. Når det gøres i hånden, er det langsomt og trættende; Det er nemt at gå glip af en sårbarhed i en stor kodebase.
AI er kraftfuld til kodegennemgang af to grunde: kode er også et sprog, og AI er god til mønstergenkendelse. AI kan hurtigt markere farlige mønstre i et stykke kode (sætte brugerinput direkte i forespørgslen, ukrypteret datalagring, manglende inputvalidering), forklare, hvorfor hver enkelt er risikabelt, og foreslå en rettelse. Men AI ser ikke hele driftskonteksten for koden (inputtet bliver muligvis slettet på et andet lag), det kan opfinde en sårbarhed, der ikke eksisterer (falsk positiv) eller gå glip af en reel sårbarhed (falsk negativ), og vigtigst af alt, den "fix", den foreslår, kan introducere en ny sårbarhed eller fejl. AI er et andet øje og pointer i kodegennemgang; Udvikleren og sikkerhedseksperten afgør, om et fund er en reel sårbarhed, og om rettelsen er korrekt og sikker.
Trin i kodegennemgang
- Giv rammer og sammenhæng. Hvilket sprog, hvilket framework, hvor tager denne kode input, hvor giver det output, på hvilket lag virker det? Kodegennemgang uden kontekst producerer falske positiver.
- Scan for farlige mønstre. Søg efter kendte AI-sårbarhedsklasser (såsom OWASP Top 10): indsprøjtning, autentificering, offentliggørelse af følsomme data, adgangskontrol.
- Få hvert fund begrundet. For hvert flag: hvilken linje, hvilken sårbarhedsklasse, hvordan kan det udnyttes, hvad er beviset. En uberettiget konklusion tages ikke alvorligt.
- Fjern falsk positiv. Bliver input rent faktisk ryddet, er stien virkelig tilgængelig - tjek med kontekst.
- Bekræft rettelsen. Bekræft, at patchen anbefalet af AI faktisk lukker sårbarheden, ikke introducerer nye sårbarheder/fejl og har bestået testen.
- Menneskelig godkendelse. Udvikler + sikkerhedsekspert gennemgår fundet og rettelse; Det er sådan, den kommer ind i kodelageret.
Vilkår: SAST (Static Application Security Testing — statisk sikkerhedstest, der analyserer kildekoden uden at køre den). DAST (Dynamisk — dynamisk test, der tester den kørende applikation eksternt). OWASP Top 10 er standardlisten over de mest almindelige webapplikationssårbarheder. Injektion er en sårbarhed forårsaget af fortolkning af brugerinput som en kommando/forespørgsel (f.eks. SQL-injektion). Parameteriseret forespørgsel er den korrekte metode, der forhindrer injektion ved at adskille input fra koden.
Tabel over almindelige sårbarhedsklasser
Sårbarhedsklasse
Symptom (i kode)
rigtige løsning
AI's fælde
SQL-injektion
Deltager input til forespørgsel
Parametriseret forespørgsel
Kan ignorere desinficering
hårdt kodet hemmelighed
Adgangskode/tast kode ind
Hemmelig pengeskab (hvælving), env
Falsk positiv (prøve/test)
Svag autentificering
Manglende/forkert kontrol
Kraftig, centraliseret kontrol
savner kontekst
Defekt adgangskontrol
Ingen autorisationskontrol
Godkendelse på serversiden
Forstår ikke komplekst flow
Videregivelse af følsomme data
Adgangskodefri lagring/logning
Kryptering, maskering
Kan ikke kende kritikalitet
Usikker serialisering
Deserialiser upålidelige data
Sikker parsing
Savner sjældent mønster
tre minisager
Tilfælde 1 — Fangst selve injektionen. En udvikler får AI'en til at undersøge en dataadgangsfunktion. AI'en markerer linjen, hvor bruger-id-værdien fra brugeren er sammenkædet direkte i SQL-teksten og siger "dette er klassisk SQL-injektion, forvandl det til en parameteriseret forespørgsel"; Giver prøvekorrektion. Udvikleren bekræfter, at inputtet ikke er blevet renset andre steder, verificerer, at det er en reel sårbarhed, implementerer den foreslåede parametriserede forespørgsel og skriver en test. AI fremhævede sårbarheden; verifikation og korrektionstest kom fra udvikleren.
Sag 2 — Falsk positiv fast hemmelighed. AI ser kodeordet = "test1234"-linjen i en fil og siger "kritisk: hårdkodet adgangskode". Udvikleren kontrollerer konteksten: dette er en enhedstestfil, en dummy-testdata, der ikke er frigivet til produktion og ikke porteret til et rigtigt system. Fundet er en falsk positiv. Udvikleren dokumenterer dette, men griber ikke ind, fordi det ikke er en reel hemmelighed. Lektion: AI's "hard secret"-tegn skal elimineres af kontekst; Ikke hver streng er en hemmelighed.
Case 3 — Ny sårbarhedsrettelse. AI foreslår en rettelse af en XSS-sårbarhed (scripting på tværs af websteder); men den kode, han foreslår, rydder input på det forkerte sted og springer output-kodning over i et andet område; Som et resultat lukker hullet ikke helt. Sikkerhedseksperten gennemgår rettelsen, bemærker den manglende kodning og retter den på det korrekte lag. Lektion: Den patch, som AI anbefaler, er ikke automatisk sikker; Hver rettelse bliver gennemgået og testet.
Svag prompt / Stærk prompt
Svag prompt:
Er der et smuthul i denne kode, skal du rette det: [kode]
Denne prompt giver ingen kontekst (sprog, ramme, inputkilde), beder ikke om begrundelse, stiller ikke spørgsmålstegn ved den falske positive og er åben for blindt at acceptere korrektionen produceret af AI. AI blandede tegn på både reel sårbarhed og ikke-eksisterende.
Kraftig prompt:
Din rolle: assistent, der er det ANDET ØJE for udvikleren i sikker kodegennemgang. Beslutningstagning; overveje rettelsen anvendt direkte. Kode: [angiv sprog/ramme].Kontekst: denne funktion [inputkilde: f.eks. modtager [ekstern HTTP-anmodning], skriver til [outputdestination]. Din opgave: (1) marker mulige sårbarheder med OWASP-klassen, giv linjenummer + hvorfor risikabelt + hvordan udnyttes + bevis for hver, (2) skriv mindst 1 falsk positivt scenarie for hvert fund (f.eks. hvis inputtet er renset i et andet lag), (3) foreslå en rettelse, men med tegnet "[review + skrivetest]"; Vurder også om rettelsen introducerer nye sårbarheder/bugs. Tilføjelse af en falsk sårbarhed.[kode]
Stærk prompt giver kontekst, beder om OWASP-klasse og beviser, stiller spørgsmålstegn ved falske positive og risici for afhjælpning, fremtvinger menneskelig gennemgang.
Kopierbare promptskabeloner
SÅRBARHEDSSCANNINGSSKABELON Undersøg [sprog/ramme]-koden for OWASP Top 10. For hvert muligt fund: linjenummer, sårbarhedsklasse, hvorfor det er risikabelt, prøveudnyttelse, bevisstyrke (sikker/sandsynlig/svag). Kontekst: input [kilde], output [mål]. Tilføjelse af opdigtede fund; Hvis du ikke er sikker, skriv "[skal verificeres]". Kode: [indsæt]
FALSKT POSITIVT ELIMINATIONSMØNSTER For følgende kodefinding skal du angive scenarierne, hvor der IKKE er en reel sårbarhed: kunne inputtet ryddes på et andet lag, er denne sti tilgængelig, er denne værdi en test/eksempel, er rammen automatisk beskyttet. Skriv, hvordan du bekræfter for hver enkelt. Finder: [indsæt]
RETT EVALUERINGSSkabelon anbefaler en rettelse til følgende sårbarhed; så kritiser din egen rettelse: (1) lukker den virkelig sårbarheden, (2) introducerer den en ny sårbarhed/fejl, (3) hvilken test skal jeg skrive (positiv og negativ kasus), (4) præstations-/funktionalitetspåvirkning. Jeg vil gennemgå og teste rettelsen. Sårbarhed + kode: [paste]
SIKKER MØNSTER UNDERVISNINGSSKABELON til sårbarhedsklasse [f.eks. SQL-injektion] viser relativt sikkert skrivemønster og almindelige fejlmønstre i dette sprog/dette rammeværk. Generel regel + giv kodeeksempel; men jeg vil have dig til at spørge konteksten, før du implementerer den i min kode. Sprog/ramme: [skriv]
Almindelige fejl
- Anmeldelse uden kontekst. Uden sprog, rammer og input/output kontekst forveksler AI både reelle og falske fund; Sørg for at give kontekst.
- Forveksler hvert tegn med ægte svaghed. AI producerer falske positiver (testdata, input renset på et andet lag); Sigt hvert fund med kontekst.
- Blindt at anvende AI's korrektion. Anbefalet patch kan introducere nye sårbarheder/bugs; gennemgå og skrive prøver.
- At stole på det falske negative. Selvom AI siger "ingen sårbarheder", undersøg selv de kritiske veje; Statisk scanning registrerer ikke enhver sårbarhed.
- Give koden/hemmeligheden til det eksterne værktøj. Privat kode og rigtige hemmeligheder (nøgle, adgangskode) er intellektuel ejendom og sårbarhed; anonymisere eller bruge isolerede virksomheders værktøjer.
Tip: Når du har AI-gennemgangskoden, er det mest effektive filter at bede om "bevisstyrken" (sikker/sandsynlig/svag) for hvert fund. De fleste fund markeret som "svage" er falske positive; du allokerer din energi til de "sikre".
Forsigtig: AI's foreslåede sikkerhedsfix bør ikke komme ind på lageret uden at være testet. En forkert "fix" kan både lade sårbarheden stå åben og føre til en funktionsfejl i produktionen; Hver patch går gennem gennemgangs- og testporten.
Sammenfattende
Sikker kodegennemgang er den billigste måde at fange sårbarheder på, før de går i produktion, og da kode er et sprog, bliver AI et stærkt andet øje her: flager farlige mønstre, forklarer risiko, foreslår rettelser. Men AI ser ikke hele driftskonteksten, producerer falske positive og falske negativer, og den patch, den anbefaler, kan introducere nye sårbarheder. Så gennemgangen har seks trin (kontekst, screening, begrundelse, falsk positiv eliminering, rettelsesbekræftelse, menneskelig godkendelse), og beslutningen ligger hos udvikleren og sikkerhedseksperten. Tre principper: intet fund fortolkes uden kontekst, ethvert tegn er elimineret med kontekst, ingen rettelser lagres uafprøvet. Og koden/hemmeligheden gives aldrig til et eksternt værktøj uden anonymisering.
Ansøgningsopgave
Tag et eksempelkodestykke (enten fjernelse af følsomme dele fra din egen kode eller en prøvekode med sårbarheder). Få AI til at undersøge det med skabelonen "Sårbarhedsscanning"; Anvend skabelonen "Falsk positiv eliminering" for hvert fund og eliminer de rigtige. Tag rettelsen af det mest alvorlige fund med skabelonen "Afhjælpningsevaluering", gennemgå den selv og skriv en positiv + en negativ testcase. Bemærk, hvor mange fund der var falske positive.
tjekliste
- [ ] Jeg gav sproget, rammerne og input/output-konteksten, før jeg gennemgik koden.
- [ ] Jeg bad om linjenummer, sårbarhedsklasse, udnyttelsessti og bevis for hvert fund.
- [ ] Jeg screenede hvert fund for falske positive med kontekst.
- [ ] Jeg anvendte ikke blindt AI's korrektion; Jeg anmeldte og skrev en test.
- [ ] På trods af outputtet "Ingen sårbarheder" undersøgte jeg selv de kritiske veje.
- [ ] Jeg anonymiserede koden/hemmelighederne eller brugte virksomhedsisoleret værktøj.
- [ ] Jeg har bestået opdagelsen og rettelsen gennem udvikler + sikkerhedsgodkendelse.