Sikker kodegjennomgang og statisk analyse: Finne sårbarheter med kunstig intelligens

Gevinster:

• Evne til å bruke kunstig intelligens som et andre øye og flagge sårbarheter i OWASP-klassen (injeksjon, hard hemmelighet, tilgangskontroll) i koden ved å gi kontekst
• Evne til å eliminere falske positiver produsert av kunstig intelligens med kontekst og forhindre å behandle hvert funn som en reell sårbarhet uten å validere det
• Evne til å gjenkjenne at rettelsen foreslått av kunstig intelligens kan introdusere nye sårbarheter/bugs og sende hver patch gjennom gjennomgangs- og testporten

Sårbarheter innen programvare er blant de dyreste sårbarhetene fordi de er innebygd i produktet fra begynnelsen og distribuert til millioner av brukere. Sikker kodegjennomgang er prosessen med å lese kildekoden linje for linje og fange opp sårbarheter – SQL-injeksjon, autentiseringssårbarhet, hardkodet passord, feil autorisasjon – før de settes i produksjon. Når det gjøres for hånd, er det tregt og slitsomt; Det er lett å gå glipp av en sårbarhet i en stor kodebase.

AI er kraftig på kodegjennomgang av to grunner: kode er også et språk, og AI er god på mønstergjenkjenning. AI kan raskt flagge farlige mønstre i et stykke kode (legge brukerinndata direkte inn i spørringen, ukryptert datalagring, manglende inndatavalidering), forklare hvorfor hvert enkelt mønster er risikabelt, og foreslå en løsning. Men AI ser ikke hele driftskonteksten til koden (inngangen kan bli slettet på et annet lag), den kan finne opp en sårbarhet som ikke eksisterer (falsk positiv) eller gå glipp av en reell sårbarhet (falsk negativ), og viktigst av alt, "fiksen" den foreslår kan introdusere en ny sårbarhet eller feil. AI er et andre øye og peker i kodegjennomgang; Utvikleren og sikkerhetseksperten avgjør om et funn er en reell sårbarhet og om løsningen er riktig og sikker.

Trinn for kodegjennomgang

1. Gi omfang og kontekst. Hvilket språk, hvilket rammeverk, hvor tar denne koden input, hvor gir den utdata, på hvilket lag fungerer den? Kodegjennomgang uten kontekst gir falske positiver.
2. Skann etter farlige mønstre. Søk etter kjente AI-sårbarhetsklasser (som OWASP Topp 10): injeksjon, autentisering, avsløring av sensitive data, tilgangskontroll.
3. Få hvert funn begrunnet. For hvert flagg: hvilken linje, hvilken sårbarhetsklasse, hvordan kan den utnyttes, hva er bevisene. Et uberettiget funn tas ikke på alvor.
4. Eliminer falsk positiv. Blir inndataene faktisk slettet, er den banen virkelig tilgjengelig – sjekk med kontekst.
5. Bekreft rettelsen. Bekreft at oppdateringen anbefalt av AI faktisk lukker sårbarheten, ikke introduserer nye sårbarheter/feil og har bestått testing.
6. Menneskelig godkjenning. Utvikler + sikkerhetsekspert vurderer funnet og fikser; Det er slik den kommer inn i kodelageret.

Vilkår: SAST (Static Application Security Testing — statisk sikkerhetstesting som analyserer kildekoden uten å kjøre den). DAST (Dynamisk — dynamisk testing som tester den kjørende applikasjonen eksternt). OWASP Topp 10 er standardlisten over de vanligste sårbarhetene i nettapplikasjoner. Injeksjon er en sårbarhet forårsaket av å tolke brukerinndata som en kommando/spørring (f.eks. SQL-injeksjon). Parameterisert spørring er den riktige metoden som forhindrer injeksjon ved å skille input fra koden.

Tabell over vanlige sårbarhetsklasser

Sårbarhetsklasse

Symptom (i kode)

riktig løsning

AI sin felle

SQL-injeksjon

Blir med innspill i spørringen

Parameterisert spørring

Kan ignorere sanering

hardkodet hemmelighet

Passord/tast inn kode

Hemmelig safe (hvelv), env

Falsk positiv (prøve/test)

Svak autentisering

Manglende/feil kontroll

Kraftig, sentralisert kontroll

savner kontekst

Feil tilgangskontroll

Ingen autorisasjonssjekk

Godkjenning på serversiden

Forstår ikke kompleks flyt

Utlevering av sensitive data

Passordfri lagring/logging

Kryptering, maskering

Kan ikke vite kritikk

Usikker serialisering

Deserialiser upålitelige data

Sikker parsing

Savner sjeldent mønster

tre minisaker

Tilfelle 1 — Å fange opp selve injeksjonen. En utvikler lar AI undersøke en datatilgangsfunksjon. AI-en markerer linjen der userId-verdien fra brukeren er koblet sammen direkte inn i SQL-teksten og sier "dette er klassisk SQL-injeksjon, gjør det til en parameterisert spørring"; Gir prøvekorreksjon. Utvikleren bekrefter at inndataene ikke har blitt renset andre steder, verifiserer at det er en reell sårbarhet, implementerer den foreslåtte parameteriserte spørringen og skriver en test. AI fremhevet sårbarheten; verifisering og korreksjonstesting kom fra utvikleren.

Sak 2 — Falsk positiv fast hemmelighet. AI ser passordet = "test1234"-linjen i en fil og sier "kritisk: hardkodet passord". Utvikleren sjekker konteksten: dette er en enhetstestfil, en dummy-testdata, ikke utgitt i produksjon og ikke portert til et ekte system. Funnet er falskt positivt. Utvikleren dokumenterer dette, men iverksetter ikke tiltak fordi det ikke er en reell hemmelighet. Leksjon: AIs "hard secret"-tegn må elimineres av kontekst; Ikke hver streng er en hemmelighet.

Tilfelle 3 – Ny sårbarhetsretting. AI foreslår en løsning for en XSS (cross-site scripting)-sårbarhet; men koden han foreslår sletter inndata på feil sted og hopper over utdatakoding i et annet område; Som et resultat lukkes ikke gapet helt. Sikkerhetseksperten vurderer rettelsen, legger merke til den manglende kodingen og fikser den på riktig lag. Leksjon: Patchen som AI anbefaler er ikke automatisk sikker; Hver reparasjon blir gjennomgått og testet.

Svak forespørsel / Sterk forespørsel

Svak melding:

Er det et smutthull i denne koden, fiks det: [kode]

Denne oppfordringen gir ingen kontekst (språk, rammeverk, inputkilde), ber ikke om begrunnelse, stiller ikke spørsmål ved det falske positive, og er åpen for blindt å akseptere korreksjonen produsert av AI. AI blandet tegn på både reell sårbarhet og ikke-eksisterende.

Kraftig ledetekst:

Din rolle: assistent som er ANDRE ØYE til utvikleren i sikker kodegjennomgang. Beslutningstaking; vurdere rettelsen direkte brukt. Kode: [spesifiser språk/rammeverk].Kontekst: denne funksjonen [inndatakilde: f.eks. mottar [ekstern HTTP-forespørsel], skriver til [utdatadestinasjon]. Din oppgave: (1) flagg mulige sårbarheter med OWASP-klassen, gi linjenummer + hvorfor risikabelt + hvordan utnyttes + bevis for hvert funn, (2) skriv minst 1 falskt positivt scenario for hvert funn (f.eks. hvis inngangen er renset i et annet lag), (3) foreslå en løsning, men med tegnet "[review + write test]"; Vurder også om reparasjonen introduserer nye sårbarheter/bugs. Legger til en falsk sårbarhet.[kode]

Sterk melding gir kontekst, ber om OWASP-klasse og bevis, stiller spørsmål ved falske positive og risikoer for utbedring, tvinger menneskelig vurdering.

Kopierbare spørsmålsmaler

SÅRBARHETSSKANNEMAL Undersøk [språk/rammeverk]-koden for OWASP Topp 10. For hvert mulig funn: linjenummer, sårbarhetsklasse, hvorfor det er risikabelt, prøveutnyttelse, bevisstyrke (sikker/sannsynlig/svak). Kontekst: input [kilde], utgang [mål]. Legge til fabrikkerte funn; Hvis du ikke er sikker, skriv "[må verifiseres]". Kode: [lim inn]

FALSKT POSITIVT ELIMINERINGSMØNSTER For følgende kodefunn, oppgi scenariene der det IKKE er en reell sårbarhet: kan inndata fjernes på et annet lag, er denne banen tilgjengelig, er denne verdien en test/eksempel, er rammeverket automatisk beskyttet. Skriv hvordan du bekrefter for hver enkelt. Finner: [lim inn]

LØS EVALUERINGSMAL anbefaler en løsning for følgende sårbarhet; så kritiser din egen løsning: (1) lukker den virkelig sårbarheten, (2) introduserer den en ny sårbarhet/feil, (3) hvilken test skal jeg skrive (positiv og negativ kasus), (4) ytelse/funksjonalitet. Jeg skal gjennomgå og teste løsningen. Sårbarhet + kode: [lim inn]

SIKKER MØNSTER UNDERVISNINGSMAL for sårbarhetsklasse [f.eks. SQL-injeksjon] viser relativt sikkert skrivemønster og vanlige feilmønstre i dette språket/rammen. Generell regel + gi kodeeksempel; men jeg vil at du spør konteksten før du implementerer den i koden min. Språk/rammeverk: [skriv]

Vanlige feil

• Gjennomgå uten kontekst. Uten språk, rammeverk og input/output kontekst, forvirrer AI både ekte og falske funn; Sørg for å gi kontekst.
• Forveksler hvert tegn med ekte svakhet. AI produserer falske positiver (testdata, inndata renset i et annet lag); Sil hvert funn med kontekst.
• Bruker blindt AIs korreksjon. Anbefalt oppdatering kan introdusere nye sårbarheter/feil; gjennomgå og skrive tester.
• Stoler på det falske negative. Selv om AI sier "ingen sårbarheter", undersøk de kritiske banene selv; Statisk skanning oppdager ikke alle sårbarheter.
• Gi koden/hemmeligheten til det eksterne verktøyet. Privat kode og ekte hemmeligheter (nøkkel, passord) er intellektuell eiendom og sårbarhet; anonymisere eller bruke bedriftens, isolerte verktøy.

Tips: Når du har AI-gjennomgangskoden, er det mest effektive filteret å spørre etter "bevisstyrken" (sikker/sannsynlig/svak) for hvert funn. De fleste funn merket som "svake" er falske positive; du allokerer energien din til de "sikre".

Forsiktig: AIs foreslåtte sikkerhetsløsning bør ikke komme inn i lageret uten å bli testet. En feil "fix" kan både la sårbarheten stå åpen og føre til en funksjonsfeil i produksjonen; Hver patch går gjennom gjennomgangs- og testporten.

Oppsummert

Sikker kodegjennomgang er den billigste måten å fange opp sårbarheter før de går i produksjon, og siden kode er et språk, blir AI et kraftig andre øye her: flagger farlige mønstre, forklarer risiko, foreslår rettinger. Men AI ser ikke hele driftskonteksten, produserer falske positive og falske negativer, og oppdateringen den anbefaler kan introdusere nye sårbarheter. Så gjennomgangen har seks trinn (kontekst, screening, begrunnelse, falsk positiv eliminering, rettelsesverifisering, menneskelig godkjenning) og avgjørelsen ligger hos utvikleren og sikkerhetseksperten. Tre prinsipper: ingen funn tolkes uten kontekst, hvert tegn blir eliminert med kontekst, ingen fiks blir lagret uprøvd. Og koden/hemmeligheten blir aldri gitt til et eksternt verktøy uten anonymisering.

Søknadsoppgave

Ta en prøvekodebit (enten fjerner du sensitive deler fra din egen kode eller en prøvekode med sårbarheter). Få AI til å undersøke det med malen "Sårbarhetsskanning"; Bruk malen "Falsk positiv eliminering" for hvert funn og eliminer de virkelige. Ta korrigeringen av det mest alvorlige funnet med malen "Remediation Evaluation", se gjennom den selv og skriv en positiv + en negativ testsak. Legg merke til hvor mange funn som var falske positive.

sjekkliste

• [ ] Jeg ga språket, rammeverket og input/output-konteksten før jeg gjennomgikk koden.
• [ ] Jeg ba om linjenummer, sårbarhetsklasse, utnyttelsesvei og bevis for hvert funn.
• [ ] Jeg screenet hvert funn for falske positiver med kontekst.
• [ ] Jeg brukte ikke blindt AIs korreksjon; Jeg anmeldte og skrev en test.
• [ ] Til tross for "No vulnerabilities"-utgangen, undersøkte jeg de kritiske banene selv.
• [ ] Jeg anonymiserte koden/hemmelighetene eller brukte bedriftsisolert verktøy.
• [ ] Jeg har bestått oppdagelsen og fikset gjennom utvikler + sikkerhetsgodkjenning.