Câștiguri:
- Abilitatea de a utiliza inteligența artificială ca al doilea ochi și de a semnala vulnerabilitățile clasei OWASP (injecție, secret dur, control acces) în cod, dând context
- Capacitatea de a elimina fals pozitive produse de inteligența artificială cu context și de a preveni tratarea fiecărei descoperiri ca pe o vulnerabilitate reală fără a o valida
- Capacitatea de a recunoaște că remedierea sugerată de inteligența artificială poate introduce noi vulnerabilități/ erori și poate trece fiecare patch prin poarta de revizuire și testare
Vulnerabilitățile din software sunt printre cele mai scumpe vulnerabilități, deoarece sunt încorporate în produs de la început și distribuite milioanelor de utilizatori. Revizuirea securizată a codului este procesul de citire a codului sursă linie cu linie și de detectare a vulnerabilităților — injecție SQL, vulnerabilitate de autentificare, parolă codificată, autorizare incorectă — înainte de a intra în producție. Când este făcut manual, este lent și obositor; Este ușor să ratezi o vulnerabilitate într-o bază de cod mare.
AI este puternic la revizuirea codului din două motive: codul este, de asemenea, un limbaj, iar AI este bun la recunoașterea modelelor. AI poate semnala rapid modele periculoase într-o bucată de cod (introducerea intrării utilizatorului direct în interogare, stocarea datelor necriptate, validarea intrărilor lipsă), explica de ce fiecare este riscant și sugerează o remediere. Dar AI nu vede întregul context de operare al codului (intrarea poate fi ștearsă la alt strat), poate inventa o vulnerabilitate care nu există (fals pozitiv) sau poate pierde o vulnerabilitate reală (fals negativ) și, cel mai important, „remedierea” pe care o propune poate introduce o nouă vulnerabilitate sau bug. AI este un al doilea ochi și indicator în revizuirea codului; Dezvoltatorul și expertul în securitate decid dacă o constatare este o vulnerabilitate reală și dacă remedierea este corectă și sigură.
Etapele revizuirii codului
- Dați sferă și context. Ce limbă, ce cadru, unde primește acest cod de intrare, unde dă rezultate, la ce strat funcționează? Revizuirea codului fără context produce false pozitive.
- Scanați modele periculoase. Căutați clase cunoscute de vulnerabilitate AI (cum ar fi OWASP Top 10): injecție, autentificare, dezvăluire de date sensibile, control acces.
- Să fie justificată fiecare constatare. Pentru fiecare steag: ce linie, ce clasă de vulnerabilitate, cum poate fi exploatată, care sunt dovezile. O constatare nejustificată nu este luată în serios.
- Elimina falsul pozitiv. Intrarea este cu adevărat ștersă, calea este cu adevărat accesibilă - verificați cu contextul.
- Verificați remedierea. Confirmați că patch-ul recomandat de AI închide efectiv vulnerabilitatea, nu introduce noi vulnerabilități/bug-uri și a trecut testarea.
- Aprobare umană. Dezvoltator + expert în securitate analizează constatarea și remedierea; Așa intră în depozitul de coduri.
Termeni: SAST (Static Application Security Testing — testare statică de securitate care analizează codul sursă fără a-l rula). DAST (Dynamic — testare dinamică care testează aplicația care rulează extern). OWASP Top 10 este lista standard a celor mai comune vulnerabilități ale aplicațiilor web. Injectarea este o vulnerabilitate cauzată de interpretarea intrării utilizatorului ca o comandă/interogare (de exemplu, injecție SQL). Interogarea parametrizată este metoda corectă care previne injectarea prin separarea intrării de cod.
Tabelul claselor comune de vulnerabilitate
Clasa de vulnerabilitate
Simptom (în cod)
solutie corecta
Capcana AI
injecție SQL
Unirea intrării în interogare
Interogare parametrizată
Poate ignora igienizarea
secret codificat greu
Parolă/introduceți codul
Seif secret (seif), înv
Fals pozitiv (probă/test)
Autentificare slabă
Control lipsă/incorect
Control puternic, centralizat
ratează contextul
Control de acces defect
Nicio verificare a autorizației
Autorizare partea serverului
Nu înțelege fluxul complex
Dezvăluirea datelor sensibile
Stocare/înregistrare fără parolă
Criptare, mascare
Nu pot cunoaște criticitatea
Serializare nesigură
Deserializați datele nesigure
Analizare sigură
Pierde un model rar
trei mini cutii
Cazul 1 — Captarea injecției efective. Un dezvoltator pune AI să examineze o funcție de acces la date. AI marchează linia în care valoarea userId de la utilizator este concatenată direct în textul SQL și spune „aceasta este injecția SQL clasică, transformați-o într-o interogare parametrizată”; Oferă corectarea eșantionului. Dezvoltatorul confirmă că intrarea nu a fost dezinfectată în altă parte, verifică că este o vulnerabilitate reală, implementează interogarea parametrizată sugerată și scrie un test. AI a evidențiat vulnerabilitatea; testarea de verificare și corecție a venit de la dezvoltator.
Cazul 2 – Secret fix pozitiv fals. AI vede linia parola = „test1234” într-un fișier și spune „critical: parolă hardcoded”. Dezvoltatorul verifică contextul: acesta este un fișier de testare unitară, date de testare fictive, care nu sunt lansate în producție și nu sunt portate într-un sistem real. Constatarea este un fals pozitiv. Dezvoltatorul documentează acest lucru, dar nu ia măsuri pentru că nu este un secret real. Lecție: semnul „secret greu” al AI trebuie eliminat prin context; Nu orice șir este un secret.
Cazul 3 — O nouă remediere a vulnerabilității. AI propune o remediere pentru o vulnerabilitate XSS (cross-site scripting); dar codul pe care îl sugerează șterge intrarea în locul greșit și omite codificarea ieșirii în altă zonă; Drept urmare, decalajul nu se închide complet. Expertul în securitate examinează remedierea, observă codificarea lipsă și o repară la nivelul corect. Lecție: Patch-ul pe care AI îl recomandă nu este automat sigur; Fiecare remediere este revizuită și testată.
Prompt slab / Prompt puternic
Prompt slab:
Există o lacună în acest cod, remediați-o: [code]
Acest prompt nu oferă context (limbaj, cadru, sursă de intrare), nu cere justificare, nu pune la îndoială falsul pozitiv și este deschis să accepte orbește corecția produsă de AI. AI a amestecat semne atât de vulnerabilitate reală, cât și de vulnerabilitate inexistentă.
Solicitare puternică:
Rolul dvs.: asistent care este AL DOILEA OCHI al dezvoltatorului în revizuirea codului securizat. Luarea deciziilor; luați în considerare soluția aplicată direct. Cod: [specificați limba/cadru].Context: această funcție [sursa de intrare: de ex. primește [cerere HTTP externă], scrie în [destinație de ieșire]. Sarcina dvs.: (1) semnalați posibilele vulnerabilități cu clasa OWASP, dați numărul de linie + de ce riscant + cum să exploateze + dovezi pentru fiecare, (2) scrieți cel puțin 1 scenariu fals pozitiv pentru fiecare constatare (de exemplu, dacă intrarea este dezinfectată într-un alt strat), (3) sugerați o remediere, dar cu semnul „[revizuire + scriere test]”; De asemenea, evaluați dacă remedierea introduce noi vulnerabilități/ erori. Adăugarea unei vulnerabilități false.[cod]
Un prompt puternic oferă context, solicită clasa OWASP și dovezi, pune întrebări fals pozitive și riscuri de remediere, forțează revizuirea umană.
Șabloane de prompt copiabile
VULNERABILITY SCAN TEMPLATE Examinați codul [limbă/cadru] pentru OWASP Top 10. Pentru fiecare posibilă constatare: numărul de linie, clasa de vulnerabilitate, de ce este riscant, eșantion de exploatare, puterea dovezilor (cert/probabil/slab). Context: intrare [sursă], ieșire [țintă]. Adăugarea de descoperiri fabricate; Dacă nu sunteți sigur, introduceți „[trebuie verificat]”. Cod: [paste]
MODEL DE ELIMINARE FAL POZITIV Pentru următoarea constatare a codului, enumerați scenariile în care NU există o vulnerabilitate reală: ar putea fi ștearsă intrarea la un alt strat, este această cale accesibilă, este această valoare un test/eșantion, este framework-ul protejat automat. Scrieți cum să confirmați pentru fiecare. Găsire: [paste]
ȘABLAN DE EVALUARE RECOMANDAȚI o remediere pentru următoarea vulnerabilitate; apoi critică-ți propria remediere: (1) închide cu adevărat vulnerabilitatea, (2) introduce o nouă vulnerabilitate/bug, (3) ce test ar trebui să scriu (caz pozitiv și negativ), (4) impact asupra performanței/funcționalității. Voi revizui și voi testa remedierea. Vulnerabilitate + cod: [paste]
ȘABLON DE PREDARE PATRON SECURITATE pentru clasa de vulnerabilitate [de ex. SQL injection] arată comparativ un model de tastare sigur și modele eronate comune în acest limbaj/cadru. Regula generală + da un exemplu de cod; dar vreau să întrebați contextul înainte de a-l implementa în codul meu. Limba/cadru: [scrie]
Greșeli comune
- Recenzie fără context. Fără limbaj, cadru și context de intrare/ieșire, AI confundă atât constatările reale, cât și cele false; Asigurați-vă că oferiți context.
- Confundând fiecare semn cu o slăbiciune reală. AI produce fals pozitive (date de testare, intrare curățată la alt strat); Cerne fiecare constatare cu contextul.
- Aplicând orbește corecția AI. Patch-ul recomandat poate introduce noi vulnerabilități/bug-uri; revizuiți și scrieți teste.
- Încredere în falsul negativ. Chiar dacă AI spune „fără vulnerabilități”, examinați singur căile critice; Scanarea statică nu detectează toate vulnerabilitățile.
- Oferirea codului/secretului instrumentului extern. Codul privat și secretele reale (cheie, parolă) sunt proprietate intelectuală și vulnerabilitate; anonimizați sau utilizați instrumente corporative izolate.
Sfat: Când aveți codul de revizuire AI, cel mai eficient filtru este să cereți „puterea dovezilor” (cert/probabil/slab) pentru fiecare constatare. Cele mai multe constatări marcate „slab” sunt fals pozitive; îți aloci energia celor „siguri”.
Atenție: soluția de securitate propusă de AI nu ar trebui să intre în depozit fără a fi testată. O „remediere” incorectă poate lăsa vulnerabilitatea deschisă și poate duce la o eroare funcțională în producție; Fiecare patch trece prin poarta de revizuire și testare.
În concluzie
Revizuirea securizată a codului este cea mai ieftină modalitate de a surprinde vulnerabilități înainte de a intra în producție și, deoarece codul este un limbaj, AI devine un al doilea ochi puternic aici: semnalează modele periculoase, explică riscul și sugerează remedieri. Dar AI nu vede întregul context de operare, produce false pozitive și false negative, iar patch-ul pe care îl recomandă poate introduce noi vulnerabilități. Deci, revizuirea are șase pași (context, screening, justificare, eliminare fals pozitiv, verificare corectă, aprobare umană) iar decizia aparține dezvoltatorului și expertului în securitate. Trei principii: nicio constatare nu este interpretată fără context, fiecare semn este eliminat cu context, nicio remediere nu intră în stocare netestată. Și codul/secretul nu este niciodată dat unui instrument extern fără anonimizare.
Sarcina de aplicare
Luați un fragment de cod eșantion (fie eliminând părți sensibile din propriul cod, fie un exemplu de cod cu vulnerabilități). Cereți AI să-l examineze cu șablonul „Scanare vulnerabilități”; Aplicați șablonul „Eliminare fals pozitivă” pentru fiecare constatare și eliminați-le pe cele reale. Luați corectarea celei mai serioase constatări cu șablonul „Evaluare de remediere”, revizuiți-l singur și scrieți un caz de testare pozitiv + unul negativ. Observați câte constatări au fost fals pozitive.
lista de verificare
- [ ] Am dat limbajul, cadrul și contextul de intrare/ieșire înainte de a revizui codul.
- [ ] Am cerut numărul de linie, clasa de vulnerabilitate, calea de exploatare și dovezi pentru fiecare descoperire.
- [ ] Am verificat fiecare constatare pentru false pozitive cu context.
- [ ] Nu am aplicat orbește corecția AI; Am revizuit și am scris un test.
- [ ] În ciuda rezultatului „Fără vulnerabilități”, am examinat personal căile critice.
- [ ] Am anonimizat codul/secretele sau am folosit instrumente izolate corporative.
- [ ] Am trecut de descoperire și am remediat prin aprobarea dezvoltator + securitate.