Fitimet:
- Aftësia për të përdorur inteligjencën artificiale si një sy të dytë dhe për të shënuar dobësitë e klasës OWASP (injeksion, sekret i fortë, kontrolli i aksesit) në kod duke dhënë kontekst
- Aftësia për të eliminuar pozitivet e rreme të prodhuara nga inteligjenca artificiale me kontekst dhe për të parandaluar trajtimin e çdo gjetjeje si një cenueshmëri të vërtetë pa e vërtetuar atë
- Aftësia për të njohur se rregullimi i sugjeruar nga inteligjenca artificiale mund të prezantojë dobësi/gabimet e reja dhe të kalojë çdo patch përmes portës së rishikimit dhe testimit
Dobësitë brenda softuerit janë ndër dobësitë më të shtrenjta, sepse ato janë të ngulitura në produkt që nga fillimi dhe shpërndahen në miliona përdorues. Rishikimi i kodit të sigurt është procesi i leximit të kodit burimor rresht pas rreshti dhe kapja e dobësive - injeksioni SQL, dobësia e vërtetimit, fjalëkalimi i koduar, autorizimi i pasaktë - përpara se të hyjnë në prodhim. Kur bëhet me dorë, është e ngadaltë dhe e lodhshme; Është e lehtë të humbasësh një cenueshmëri në një bazë të madhe kodi.
AI është i fuqishëm në rishikimin e kodit për dy arsye: kodi është gjithashtu një gjuhë, dhe AI është i mirë në njohjen e modeleve. Inteligjenca artificiale mund të raportojë shpejt modele të rrezikshme në një pjesë të kodit (duke vendosur hyrjen e përdoruesit direkt në pyetje, ruajtjen e të dhënave të pakriptuara, mungesën e vërtetimit të hyrjes), të shpjegojë pse secili është i rrezikshëm dhe të sugjerojë një rregullim. Por AI nuk e sheh të gjithë kontekstin e funksionimit të kodit (hyrja mund të pastrohet në një shtresë tjetër), mund të shpikë një cenueshmëri që nuk ekziston (false pozitive) ose të humbasë një cenueshmëri të vërtetë (negative false), dhe më e rëndësishmja, "rregullimi" që ai propozon mund të prezantojë një cenueshmëri ose gabim të ri. AI është një sy dhe tregues i dytë në rishikimin e kodit; Zhvilluesi dhe eksperti i sigurisë vendosin nëse një gjetje është një cenueshmëri e vërtetë dhe nëse rregullimi është i saktë dhe i sigurt.
Hapat e rishikimit të kodit
- Jepni hapësirën dhe kontekstin. Cila gjuhë, cila kornizë, ku merr të dhëna ky kod, ku jep dalje, në cilën shtresë funksionon? Rishikimi i kodit pa kontekst prodhon rezultate false.
- Skanoni për modele të rrezikshme. Kërkoni për klasa të njohura të cenueshmërisë së AI (si OWASP Top 10): injeksion, vërtetim, zbulim i të dhënave të ndjeshme, kontroll i aksesit.
- Të arsyetohet çdo gjetje. Për çdo flamur: cila linjë, cila klasë cenueshmërie, si mund të shfrytëzohet, cilat janë provat. Një gjetje e pajustifikuar nuk merret seriozisht.
- Eliminoni pozitivitetin e rremë. A po pastrohet hyrja, a është me të vërtetë e aksesueshme ajo rrugë - kontrolloni me kontekstin.
- Verifikoni rregullimin. Konfirmoni që patch-i i rekomanduar nga AI në të vërtetë mbyll cenueshmërinë, nuk prezanton dobësi/bug të reja dhe ka kaluar testimin.
- Miratimi njerëzor. Zhvilluesi + eksperti i sigurisë shqyrton gjetjen dhe rregullon; Kështu hyn në depon e kodit.
Kushtet: SAST (Static Application Security Testing — testim statik i sigurisë që analizon kodin burimor pa e ekzekutuar atë). DAST (Dynamic — testim dinamik që teston aplikacionin e ekzekutuar nga jashtë). OWASP Top 10 është lista standarde e dobësive më të zakonshme të aplikacioneve në internet. Injeksioni është një cenueshmëri e shkaktuar nga interpretimi i hyrjes së përdoruesit si një komandë/pyetje (p.sh. injeksion SQL). Pyetja e parametrizuar është metoda e saktë që parandalon injektimin duke ndarë hyrjen nga kodi.
Tabela e klasave të zakonshme të cenueshmërisë
Klasa e cenueshmërisë
Simptoma (në kod)
zgjidhje e duhur
kurthi i AI
injeksion SQL
Bashkimi i të dhënave në pyetje
Pyetje e parametrizuar
Mund të injorojë dezinfektimin
sekret i koduar i fortë
Fjalëkalimi/çelësi në kod
Kasafortë sekrete (kasafortë), env
Pozitive e rreme (kampioni/testi)
Vërtetim i dobët
Mungon/kontrolli i pasaktë
Kontroll i fuqishëm, i centralizuar
mungon konteksti
Kontrolli i gabuar i hyrjes
Asnjë kontroll autorizimi
Autorizimi nga ana e serverit
Nuk e kupton rrjedhën komplekse
Zbulimi i të dhënave të ndjeshme
Ruajtja/regjistrimi pa fjalëkalim
Kriptimi, maskimi
Nuk mund ta njoh kritikën
Serializimi i pasigurt
Deserializoni të dhëna jo të besueshme
Parsim i sigurt
Mungon modeli i rrallë
tre mini kuti
Rasti 1 - Kapja e injeksionit aktual. Një zhvillues ka që AI të ekzaminojë një funksion të aksesit të të dhënave. AI shënon linjën ku vlera e userId nga përdoruesi është e lidhur drejtpërdrejt në tekstin SQL dhe thotë "ky është injeksion klasik SQL, kthejeni atë në një pyetje të parametrizuar"; Ofron korrigjim të mostrës. Zhvilluesi konfirmon që hyrja nuk është pastruar diku tjetër, verifikon se është një cenueshmëri e vërtetë, zbaton pyetjen e sugjeruar të parametrizuar dhe shkruan një test. AI theksoi cenueshmërinë; verifikimi dhe testimi i korrigjimit erdhi nga zhvilluesi.
Rasti 2 — Sekret fiks pozitiv fals. Inteligjenca artificiale sheh fjalëkalimin = rreshtin "test1234" në një skedar dhe thotë "kritike: fjalëkalim i koduar". Zhvilluesi kontrollon kontekstin: ky është një skedar testimi i njësisë, një të dhëna testimi të rreme, që nuk lëshohet në prodhim dhe nuk është transferuar në një sistem real. Gjetja është pozitive e rreme. Zhvilluesi e dokumenton këtë, por nuk merr masa sepse nuk është një sekret i vërtetë. Mësimi: Shenja "e fshehtë e vështirë" e AI duhet të eliminohet sipas kontekstit; Jo çdo varg është sekret.
Rasti 3 - Rregullim i ri i cenueshmërisë. AI propozon një rregullim për një dobësi XSS (skriptimi ndër-site); por kodi që ai sugjeron fshin hyrjen në vendin e gabuar dhe anashkalon kodimin e daljes në një zonë tjetër; Si rezultat, hendeku nuk mbyllet plotësisht. Eksperti i sigurisë shqyrton rregullimin, vëren kodimin që mungon dhe e rregullon atë në shtresën e duhur. Mësimi: Patch-i që rekomandon AI nuk është automatikisht i sigurt; Çdo rregullim rishikohet dhe testohet.
Prompt i dobët / Prompt i fortë
Njoftim i dobët:
A ka ndonjë zbrazëti në këtë kod, rregullojeni: [code]
Kjo kërkesë nuk jep asnjë kontekst (gjuhë, kornizë, burim hyrës), nuk kërkon justifikim, nuk vë në dyshim pozitivin e rremë dhe është i hapur për të pranuar verbërisht korrigjimin e prodhuar nga AI. Inteligjenca artificiale ka përzier shenjat e dobësisë reale dhe asaj joekzistente.
Njoftim i fuqishëm:
Roli juaj: asistent që është SYRI I DYTË i zhvilluesit në rishikimin e kodit të sigurt. Vendimmarrja; konsideroni rregullimin e aplikuar drejtpërdrejt. Kodi: [specifiko gjuhën/kornizën]. Konteksti: ky funksion [burimi i hyrjes: p.sh. merr [kërkesë e jashtme HTTP], shkruan në [destinacioni i daljes]. Detyra juaj: (1) shënoni dobësitë e mundshme me klasën OWASP, jepni numrin e linjës + pse e rrezikshme + si të shfrytëzohet + prova për secilën, (2) shkruani të paktën 1 skenar pozitiv fals për çdo gjetje (p.sh. nëse hyrja është e pastruar në një shtresë tjetër), (3) sugjeroni një rregullim, por me shenjën "[rishikoni + shkruani testin]"; Gjithashtu vlerësoni nëse rregullimi prezanton dobësi/bug të reja. Shtimi i një cenueshmërie të rreme.[code]
Njoftimi i fortë jep kontekst, kërkon klasë dhe prova OWASP, vë në pyetje false pozitive dhe rreziqet e korrigjimit, detyron rishikimin njerëzor.
Modele të shpejtë të kopjueshëm
TABLETI I SKANIMIT TË CENUESHMËRISË Ekzaminoni kodin e [gjuhës/kornizës] për OWASP Top 10. Për çdo gjetje të mundshme: numri i linjës, klasa e cenueshmërisë, pse është e rrezikshme, shfrytëzimi i mostrës, fuqia e provave (e sigurt/e mundshme/e dobët). Konteksti: hyrje [burimi], dalja [objektivi]. Shtimi i gjetjeve të fabrikuara; Nëse nuk jeni të sigurt, shkruani "[duhet të verifikohet]". Kodi: [ngjit]
MODEL FALSE POZITIV ELIMINIMI Për gjetjen e kodit të mëposhtëm, rendisni skenarët në të cilët NUK ka një cenueshmëri të vërtetë: a mund të pastrohet hyrja në një shtresë tjetër, a është e aksesueshme kjo shteg, a është kjo vlerë një test/shembull, a është korniza e mbrojtur automatikisht. Shkruani si të konfirmoni për secilën. Gjetja: [ngjit]
RREGULLONI MOBILI I VLERËSIMIT Rekomandoni një rregullim për cenueshmërinë e mëposhtme; më pas kritikoni rregullimin tuaj: (1) a e mbyll vërtet cenueshmërinë, (2) a prezanton një cenueshmëri/bug të ri, (3) çfarë testi duhet të shkruaj (rasti pozitiv dhe negativ), (4) ndikimi i performancës/funksionalitetit. Unë do të shqyrtoj dhe testoj rregullimin. Dobësia + kodi: [ngjit]
TABLETI MËSIMOR I MODELIT SIGURTË për klasën e cenueshmërisë [p.sh. Injeksioni SQL] tregon në mënyrë krahasuese modelin e sigurt të shtypjes dhe modelet e zakonshme të gabuara në këtë gjuhë/kornizë. Rregulli i përgjithshëm + jepni shembullin e kodit; por unë dua që ju të pyesni kontekstin përpara se ta zbatoni atë në kodin tim. Gjuha/korniza: [shkruaj]
Gabimet e zakonshme
- Rishikim pa kontekst. Pa gjuhën, kornizën dhe kontekstin hyrës/dalës, AI ngatërron gjetjet reale dhe të rreme; Sigurohuni që të jepni kontekstin.
- Duke ngatërruar çdo shenjë me dobësi të vërtetë. AI prodhon pozitivë të rremë (të dhënat e testit, inputet pastrohen në një shtresë tjetër); Shosh çdo gjetje me kontekst.
- Zbatimi i verbër i korrigjimit të AI. Patch-i i rekomanduar mund të prezantojë dobësi/bug të reja; rishikoni dhe shkruani teste.
- Duke i besuar negativit të rremë. Edhe nëse AI thotë "pa dobësi", shqyrtoni vetë shtigjet kritike; Skanimi statik nuk zbulon çdo cenueshmëri.
- Dhënia e kodit/sekretit mjetit të jashtëm. Kodi privat dhe sekretet reale (çelës, fjalëkalim) janë pronë intelektuale dhe dobësi; anonimizoni ose përdorni mjete të izoluara të korporatës.
Këshillë: Kur keni kodin e rishikimit të AI, filtri më efikas është të kërkoni "forcën e provave" (të sigurta / e mundshme / e dobët) për çdo gjetje. Shumica e gjetjeve të shënuara "të dobëta" janë pozitive false; ju e shpërndani energjinë tuaj tek të “sigurtve”.
Kujdes: Rregullimi i sigurisë i propozuar nga AI nuk duhet të hyjë në magazinë pa u testuar. Një "rregullim" i pasaktë mund të lërë të hapur cenueshmërinë dhe të çojë në një gabim funksional në prodhim; Çdo patch kalon përmes portës së rishikimit dhe testimit.
Në përmbledhje
Rishikimi i kodit të sigurt është mënyra më e lirë për të kapur dobësitë përpara se ato të hyjnë në prodhim, dhe meqenëse kodi është një gjuhë, AI bëhet një sy i dytë i fuqishëm këtu: shënon modele të rrezikshme, shpjegon rrezikun, sugjeron rregullime. Por AI nuk e sheh të gjithë kontekstin e funksionimit, prodhon pozitivë të rremë dhe negativë të rremë, dhe patch-i që rekomandon mund të prezantojë dobësi të reja. Pra, rishikimi ka gjashtë hapa (konteksti, shqyrtimi, justifikimi, eliminimi fals pozitiv, verifikimi i rregullimit, miratimi njerëzor) dhe vendimi i takon zhvilluesit dhe ekspertit të sigurisë. Tre parime: asnjë gjetje nuk interpretohet pa kontekst, çdo shenjë eliminohet me kontekst, asnjë rregullim nuk shkon në ruajtje të patestuar. Dhe kodi/sekret nuk i jepet kurrë një mjeti të jashtëm pa anonimizim.
Detyra e aplikimit
Merrni një copë kodi mostër (ose duke hequr pjesë të ndjeshme nga kodi juaj ose një kod mostër me dobësi). Lëreni AI ta ekzaminojë atë me shabllonin "Skanimi i Vulnerabilitetit"; Aplikoni shabllonin "Eleminimi i rremë pozitiv" për çdo gjetje dhe eliminoni ato reale. Merrni korrigjimin e gjetjes më serioze me shabllonin "Vlerësimi i riparimit", rishikoni vetë dhe shkruani një rast testimi pozitiv + një negativ. Vini re se sa gjetje ishin pozitive false.
listë kontrolli
- [ ] I dhashë gjuhën, kornizën dhe kontekstin hyrës/dalës përpara se të rishikoja kodin.
- [ ] Unë kërkova numrin e linjës, klasën e cenueshmërisë, rrugën e shfrytëzimit dhe prova për çdo gjetje.
- [ ] Kam ekzaminuar çdo gjetje për pozitive false me kontekst.
- [ ] Nuk e zbatova verbërisht korrigjimin e AI; Shqyrtova dhe shkrova një test.
- [ ] Pavarësisht rezultatit "Pa dobësi", unë i ekzaminova vetë shtigjet kritike.
- [ ] Kam anonimizuar kodin/sekretet ose kam përdorur vegla të izoluara të korporatës.
- [ ] Kam kaluar zbulimin dhe rregullimin përmes miratimit të zhvilluesit + sigurisë.