Winst:
- Mogelijkheid om kunstmatige intelligentie als tweede oog te gebruiken en kwetsbaarheden in de OWASP-klasse (injectie, hard geheim, toegangscontrole) in de code te signaleren door context te geven
- Mogelijkheid om valse positieven geproduceerd door kunstmatige intelligentie met context te elimineren en te voorkomen dat elke bevinding als een echte kwetsbaarheid wordt behandeld zonder deze te valideren
- Mogelijkheid om te onderkennen dat de door kunstmatige intelligentie voorgestelde oplossing nieuwe kwetsbaarheden/bugs kan introduceren en elke patch door de beoordelings- en testpoort kan laten gaan
Kwetsbaarheden in software behoren tot de duurste kwetsbaarheden omdat ze vanaf het begin in het product zijn ingebed en onder miljoenen gebruikers zijn verspreid. Veilige codebeoordeling is het proces waarbij broncode regel voor regel wordt gelezen en kwetsbaarheden worden opgespoord (SQL-injectie, authenticatiekwetsbaarheid, hardgecodeerd wachtwoord, onjuiste autorisatie) voordat deze in productie gaan. Als het met de hand wordt gedaan, is het langzaam en vermoeiend; Het is gemakkelijk om een kwetsbaarheid in een grote codebasis over het hoofd te zien.
AI is om twee redenen krachtig in het beoordelen van codes: code is ook een taal, en AI is goed in patroonherkenning. AI kan snel gevaarlijke patronen in een stukje code signaleren (gebruikersinvoer rechtstreeks in de query plaatsen, niet-versleutelde gegevensopslag, ontbrekende invoervalidatie), uitleggen waarom elk risico riskant is en een oplossing voorstellen. Maar de AI ziet niet de volledige operationele context van de code (de invoer wordt mogelijk op een andere laag gewist), kan een kwetsbaarheid verzinnen die niet bestaat (vals-positief) of een echte kwetsbaarheid over het hoofd zien (vals-negatief), en het allerbelangrijkste: de ‘oplossing’ die het voorstelt, kan een nieuwe kwetsbaarheid of bug introduceren. AI is een tweede oog en wijzer bij codebeoordeling; De ontwikkelaar en beveiligingsexpert beslissen of een bevinding een echte kwetsbaarheid is en of de oplossing correct en veilig is.
Stappen voor codebeoordeling
- Geef reikwijdte en context. Welke taal, welk raamwerk, waar krijgt deze code input, waar geeft hij output, op welke laag werkt hij? Codebeoordeling zonder context levert valse positieven op.
- Scannen op gevaarlijke patronen. Zoek naar bekende AI-kwetsbaarheidsklassen (zoals OWASP Top 10): injectie, authenticatie, openbaarmaking van gevoelige gegevens, toegangscontrole.
- Zorg ervoor dat elke bevinding gerechtvaardigd is. Voor elke vlag: welke lijn, welke kwetsbaarheidsklasse, hoe kan deze worden uitgebuit, wat is het bewijsmateriaal. Een ongerechtvaardigde bevinding wordt niet serieus genomen.
- Elimineer valse positieven. Wordt de invoer daadwerkelijk gewist, is dat pad echt toegankelijk – controleer de context.
- Controleer de oplossing. Bevestig dat de door AI aanbevolen patch de kwetsbaarheid daadwerkelijk sluit, geen nieuwe kwetsbaarheden/bugs introduceert en de tests heeft doorstaan.
- Menselijke goedkeuring. Ontwikkelaar + beveiligingsexpert beoordeelt de bevinding en oplossing; Zo komt het in de coderepository terecht.
Termen: SAST (Static Application Security Testing – statische beveiligingstests die de broncode analyseren zonder deze uit te voeren). DAST (Dynamisch: dynamisch testen waarbij de actieve applicatie extern wordt getest). OWASP Top 10 is de standaardlijst met de meest voorkomende kwetsbaarheden in webapplicaties. Injectie is een kwetsbaarheid die wordt veroorzaakt door het interpreteren van gebruikersinvoer als een opdracht/query (bijvoorbeeld SQL-injectie). Geparametriseerde query's zijn de juiste methode die injectie voorkomt door de invoer van de code te scheiden.
Tabel met veelvoorkomende kwetsbaarheidsklassen
Kwetsbaarheid klasse
Symptoom (in code)
juiste oplossing
De val van AI
SQL-injectie
Invoer samenvoegen in query
Geparametriseerde vraag
Kan desinfectie negeren
hardgecodeerd geheim
Wachtwoord/sleutelcode
Geheime kluis (kluis), env
Vals positief (monster/test)
Zwakke authenticatie
Ontbrekende/onjuiste bediening
Krachtige, gecentraliseerde controle
mist context
Defecte toegangscontrole
Geen autorisatiecontrole
Autorisatie aan de serverzijde
Begrijpt complexe stromingen niet
Openbaarmaking van gevoelige gegevens
Wachtwoordvrije opslag/loggen
Encryptie, maskering
Kan de kritiek niet kennen
Onveilige serialisatie
Deserialiseer onbetrouwbare gegevens
Veilig parseren
Mist zeldzaam patroon
drie minikoffers
Geval 1 — Het vangen van de daadwerkelijke injectie. Een ontwikkelaar laat de AI een datatoegangsfunctie onderzoeken. De AI markeert de regel waar de userId-waarde van de gebruiker rechtstreeks in de SQL-tekst wordt samengevoegd en zegt "dit is klassieke SQL-injectie, verander het in een geparametriseerde query"; Biedt voorbeeldcorrectie. De ontwikkelaar bevestigt dat de invoer niet elders is opgeschoond, verifieert dat het een echte kwetsbaarheid is, implementeert de voorgestelde geparameteriseerde query en schrijft een test. AI benadrukte de kwetsbaarheid; verificatie- en correctietests kwamen van de ontwikkelaar.
Geval 2 – Vals positief vast geheim. De AI ziet de regel wachtwoord = "test1234" in een bestand en zegt "kritiek: hardgecodeerd wachtwoord". De ontwikkelaar controleert de context: dit is een unit-testbestand, een dummy-testgegevens, niet vrijgegeven voor productie en niet geporteerd naar een echt systeem. De bevinding is vals positief. De ontwikkelaar documenteert dit maar onderneemt geen actie omdat het geen echt geheim is. Les: het ‘harde geheim’-teken van AI moet door de context worden geëlimineerd; Niet elke string is een geheim.
Geval 3 – Nieuwe oplossing voor kwetsbaarheid. AI stelt een oplossing voor voor een XSS-kwetsbaarheid (cross-site scripting); maar de code die hij voorstelt, wist de invoer op de verkeerde plaats en slaat de uitvoercodering in een ander gebied over; Hierdoor wordt de kloof niet volledig gedicht. De beveiligingsexpert beoordeelt de oplossing, merkt de ontbrekende codering op en herstelt deze op de juiste laag. Les: de patch die AI aanbeveelt, is niet automatisch veilig; Elke oplossing wordt beoordeeld en getest.
Zwakke prompt/sterke prompt
Zwakke prompt:
Is er een maas in deze code, repareer deze: [code]
Deze prompt geeft geen context (taal, raamwerk, invoerbron), vraagt niet om rechtvaardiging, stelt de valse positieven niet in twijfel en staat open voor het blindelings accepteren van de correctie die door de AI wordt geproduceerd. AI mengde tekenen van zowel echte als niet-bestaande kwetsbaarheid.
Krachtige prompt:
Jouw rol: assistent die het TWEEDE OOG is voor de ontwikkelaar bij het beoordelen van veilige code. Besluitvorming; beschouw de oplossing die direct wordt toegepast. Code: [specificeer taal/framework].Context: deze functie [invoerbron: b.v. ontvangt [extern HTTP-verzoek], schrijft naar [uitvoerbestemming]. Jouw taak: (1) markeer mogelijke kwetsbaarheden met de OWASP-klasse, geef regelnummer + waarom riskant + hoe te exploiteren + bewijs voor elk, (2) schrijf ten minste één vals-positief scenario voor elke bevinding (bijvoorbeeld als de invoer in een andere laag wordt opgeschoond), (3) stel een oplossing voor, maar met het teken "[review + write test]"; Evalueer ook of de oplossing nieuwe kwetsbaarheden/bugs introduceert. Een nep-kwetsbaarheid toevoegen.[code]
Sterke prompt geeft context, vraagt om OWASP-klasse en bewijsmateriaal, stelt vals-positieve resultaten en risico's van herstel in vraag, dwingt menselijke beoordeling af.
Kopieerbare promptsjablonen
KWETSBAARHEIDSSCAN-SJABLOON Onderzoek [taal/framework]-code voor OWASP Top 10. Voor elke mogelijke bevinding: regelnummer, kwetsbaarheidsklasse, waarom het riskant is, voorbeeld van exploit, sterkte van bewijs (zeker/waarschijnlijk/zwak). Context: invoer [bron], uitvoer [doel]. Verzonnen bevindingen toevoegen; Als u het niet zeker weet, typt u '[moet worden geverifieerd]'. Code: [plakken]
FALSE POSITIEF ELIMINATIEPATROON Geef voor de volgende codevinding de scenario's op waarin er GEEN echte kwetsbaarheid is: kan de invoer op een andere laag worden gewist, is dit pad toegankelijk, is deze waarde een test/voorbeeld, wordt het raamwerk automatisch beschermd. Schrijf voor elk op hoe u dit kunt bevestigen. Zoeken: [plakken]
FIX-EVALUATIESJABLOONBeveel een oplossing aan voor de volgende kwetsbaarheid; bekritiseer vervolgens uw eigen oplossing: (1) sluit het de kwetsbaarheid echt af, (2) introduceert het een nieuwe kwetsbaarheid/bug, (3) welke test moet ik schrijven (positief en negatief), (4) impact op de prestaties/functionaliteit. Ik zal de oplossing bekijken en testen. Kwetsbaarheid + code: [plakken]
VEILIG PATROON ONDERWIJS SJABLOON voor kwetsbaarheidsklasse [bijv. SQL-injectie] laten relatief veilige typpatronen en veelvoorkomende foutieve patronen in deze taal/framework zien. Algemene regel + geef codevoorbeeld; maar ik wil dat je de context vraagt voordat je deze in mijn code implementeert. Taal/framework: [schrijven]
Veel voorkomende fouten
- Recensie zonder context. Zonder taal, raamwerk en input/output-context verwart AI zowel echte als valse bevindingen; Zorg ervoor dat u context geeft.
- Elk teken voor echte zwakte aanzien. AI produceert valse positieven (testgegevens, invoer opgeschoond op een andere laag); Sorteer elke bevinding met context.
- Blindelings de correctie van de AI toepassen. Aanbevolen patch kan nieuwe kwetsbaarheden/bugs introduceren; toetsen beoordelen en schrijven.
- Vertrouwen op het vals-negatieve. Zelfs als de AI zegt "geen kwetsbaarheden", onderzoek dan zelf de kritieke paden; Statisch scannen detecteert niet elke kwetsbaarheid.
- De code/het geheim doorgeven aan de externe tool. Privécode en echte geheimen (sleutel, wachtwoord) zijn intellectueel eigendom en kwetsbaarheid; anonimiseer of gebruik geïsoleerde zakelijke tools.
Tip: Als je over de AI-beoordelingscode beschikt, is het meest efficiënte filter het vragen naar de ‘sterkte van het bewijs’ (zeker/waarschijnlijk/zwak) voor elke bevinding. De meeste bevindingen die als ‘zwak’ zijn gemarkeerd, zijn vals-positieven; je wijst je energie toe aan de ‘zekere’ mensen.
Let op: de door AI voorgestelde beveiligingsoplossing mag het magazijn niet binnenkomen zonder te zijn getest. Een onjuiste "fix" kan zowel de kwetsbaarheid open laten als leiden tot een functionele fout in de productie; Elke patch gaat door de beoordelings- en testpoort.
Samengevat
Veilige codebeoordeling is de goedkoopste manier om kwetsbaarheden op te sporen voordat ze in productie gaan, en aangezien code een taal is, wordt AI hier een krachtig tweede oog: signaleert gevaarlijke patronen, legt risico's uit en stelt oplossingen voor. Maar de AI ziet niet de hele operationele context, produceert valse positieven en valse negatieven, en de patch die zij aanbeveelt kan nieuwe kwetsbaarheden introduceren. De beoordeling bestaat dus uit zes stappen (context, screening, rechtvaardiging, eliminatie van valse positieven, verificatie van de oplossing, menselijke goedkeuring) en de beslissing ligt bij de ontwikkelaar en de beveiligingsexpert. Drie principes: geen enkele bevinding wordt geïnterpreteerd zonder context, elk teken wordt geëlimineerd met context, geen enkele oplossing wordt ongetest opgeslagen. En de code/het geheim wordt nooit zonder anonimisering aan een externe tool doorgegeven.
Applicatie taak
Neem een voorbeeldcodefragment (waarbij u gevoelige delen uit uw eigen code verwijdert of een voorbeeldcode met kwetsbaarheden). Laat AI het onderzoeken met de sjabloon ‘Kwetsbaarheidsscannen’; Pas voor elke bevinding het sjabloon 'False Positive Elimination' toe en elimineer de echte. Neem de correctie van de ernstigste bevinding met het sjabloon "Remediation Evaluation", bekijk het zelf en schrijf één positieve + één negatieve testcase. Merk op hoeveel bevindingen vals-positief waren.
controlelijst
- [ ] Ik gaf de taal, het raamwerk en de input/output-context voordat ik de code beoordeelde.
- [ ] Ik vroeg voor elke bevinding om het regelnummer, de kwetsbaarheidsklasse, het exploitpad en het bewijsmateriaal.
- [ ] Ik heb elke bevinding gescreend op valse positieven met context.
- [ ] Ik heb de correctie van de AI niet blindelings toegepast; Ik heb een test beoordeeld en geschreven.
- [ ] Ondanks de melding 'Geen kwetsbaarheden' heb ik zelf de kritieke paden onderzocht.
- [ ] Ik heb de code/geheimen geanonimiseerd of geïsoleerde bedrijfstools gebruikt.
- [ ] Ik heb de ontdekking en oplossing doorstaan via goedkeuring van ontwikkelaar en beveiliging.