Biztonságos kódellenőrzés és statikus elemzés: Sebezhetőségek keresése mesterséges intelligenciával

Nyereség:

• Lehetőség a mesterséges intelligencia második szemként való használatára, és az OWASP osztályú sebezhetőségek (injektálás, kemény titok, hozzáférés-vezérlés) megjelölése a kódban kontextus megadásával
• Képes a mesterséges intelligencia által előidézett hamis pozitívumok kontextussal való kiküszöbölésére, és megakadályozni, hogy minden egyes leletet valódi sebezhetőségként kezeljenek anélkül, hogy azt validálnák.
• Képes felismerni, hogy a mesterséges intelligencia által javasolt javítás új sebezhetőségeket/hibákat vezethet be, és minden javítást átengedhet a felülvizsgálati és tesztelési kapun

A szoftveren belüli sebezhetőségek a legdrágább sérülékenységek közé tartoznak, mivel a kezdetektől a termékbe vannak beágyazva, és több millió felhasználóhoz terjesztik. A biztonságos kódellenőrzés a forráskód soronkénti beolvasásának folyamata, és a sebezhetőségek – SQL-befecskendezés, hitelesítési sebezhetőség, merev kódolású jelszó, helytelen engedélyezés – elkapása, mielőtt azok élesre kerülnének. Kézzel végezve lassú és fárasztó; Egy nagy kódbázisban könnyű kihagyni egy sebezhetőséget.

Az AI két okból is hatékony a kódellenőrzésben: a kód egyben nyelv is, az AI pedig jó a mintafelismerésben. A mesterséges intelligencia gyorsan meg tudja jelölni a veszélyes mintákat egy kódrészletben (közvetlenül a lekérdezésbe helyezi a felhasználói bevitelt, titkosítatlan adattárolást, hiányzó bemeneti ellenőrzést), elmagyarázza, miért kockázatos mindegyik, és javaslatot tehet a javításra. De az AI nem látja a kód teljes működési kontextusát (lehet, hogy a bemenetet egy másik rétegben törlik), feltalálhat egy nem létező sebezhetőséget (hamis pozitív), vagy kihagy egy valódi sebezhetőséget (hamis negatív), és ami a legfontosabb, az általa javasolt "javítás" új sebezhetőséget vagy hibát vezethet be. Az AI egy második szem és mutató a kód áttekintésében; A fejlesztő és a biztonsági szakértő dönti el, hogy a lelet valódi sebezhetőség-e, és hogy a javítás helyes és biztonságos-e.

A kód felülvizsgálatának lépései

1. Adjon hatókört és kontextust. Melyik nyelven, melyik keretrendszerben, hol vesz ez a kód bemenetet, hol ad kimenetet, melyik rétegen működik? A kód kontextus nélküli áttekintése hamis pozitív eredményt ad.
2. Keressen veszélyes mintákat. Ismert mesterséges intelligencia sebezhetőségi osztályok (például OWASP Top 10) keresése: injekció, hitelesítés, érzékeny adatok közzététele, hozzáférés-vezérlés.
3. Minden megállapítást igazoljon. Minden zászlóhoz: melyik vonal, melyik sebezhetőségi osztály, hogyan lehet kihasználni, mi a bizonyíték. Az indokolatlan megállapítást nem veszik komolyan.
4. Távolítsa el a hamis pozitívumot. Valóban törlődik-e a bemenet, valóban elérhető-e ez az útvonal – ellenőrizze a kontextust.
5. Ellenőrizze a javítást. Győződjön meg arról, hogy az AI által javasolt javítás valóban bezárja a biztonsági rést, nem vezet be új sebezhetőséget/hibákat, és átment a tesztelésen.
6. Emberi jóváhagyás. Fejlesztő + biztonsági szakértő felülvizsgálja a megállapítást és a javítást; Így lép be a kódtárba.

Kifejezések: SAST (Static Application Security Testing – statikus biztonsági tesztelés, amely futtatás nélkül elemzi a forráskódot). DAST (dinamikus – dinamikus tesztelés, amely a futó alkalmazást külsőleg teszteli). Az OWASP Top 10 a webalkalmazások leggyakoribb sebezhetőségeinek standard listája. Az injektálás egy biztonsági rés, amelyet a felhasználói bevitel parancsként/lekérdezésként történő értelmezése okoz (például SQL-befecskendezés). A paraméterezett lekérdezés a helyes módszer, amely megakadályozza a beinjektálást azáltal, hogy elválasztja a bemenetet a kódtól.

A gyakori sebezhetőségi osztályok táblázata

Sebezhetőségi osztály

Tünet (kódban)

helyes megoldás

Az AI csapdája

SQL injekció

Bemenet összekapcsolása lekérdezéssel

Paraméterezett lekérdezés

Figyelmen kívül hagyhatja a fertőtlenítést

keményen kódolt titok

Jelszó/kód beírása

Titkos széf (páncélszekrény), env

Hamis pozitív (minta/teszt)

Gyenge hitelesítés

Hiányzó/hibás vezérlés

Erőteljes, központi vezérlés

hiányzik a kontextus

Hibás hozzáférés-szabályozás

Nincs jogosultság ellenőrzés

Szerver oldali engedélyezés

Nem érti a komplex áramlást

Érzékeny adatok közzététele

Jelszó nélküli tárolás/naplózás

Titkosítás, maszkolás

Nem ismerheti a kritikusságot

Nem biztonságos sorozatosítás

Deszerializálja a megbízhatatlan adatokat

Biztonságos elemzés

Hiányzik a ritka minta

három mini tok

1. eset – A tényleges injekció befogása. A fejlesztőnek az AI megvizsgálja az adathozzáférési funkciót. Az AI megjelöli azt a sort, ahol a felhasználó userId értéke közvetlenül az SQL-szövegbe van kapcsolva, és azt mondja: "ez a klasszikus SQL-injektálás, alakítsd át paraméterezett lekérdezéssé"; Mintakorrekciót biztosít. A fejlesztő megerősíti, hogy a bemenetet máshol nem tisztították, ellenőrzi, hogy valódi sebezhetőségről van szó, végrehajtja a javasolt paraméterezett lekérdezést, és tesztet ír. Az AI kiemelte a sebezhetőséget; ellenőrző és korrekciós tesztelés érkezett a fejlesztőtől.

2. eset – Hamis pozitív rögzített titok. Az AI látja a jelszó = "test1234" sort egy fájlban, és azt mondja, hogy "kritikus: hardcoded password". A fejlesztő ellenőrzi a kontextust: ez egy egységteszt fájl, egy ál-tesztadat, amelyet nem adnak ki termelésbe, és nem portolják át valódi rendszerre. A lelet hamis pozitív. A fejlesztő ezt dokumentálja, de nem tesz semmit, mert ez nem valódi titok. Tanulság: A mesterséges intelligencia „kemény titkos” jelét a kontextusnak megfelelően ki kell küszöbölni; Nem minden húr titok.

3. eset – Új biztonsági rés javítás. Az AI javítást javasol az XSS (cross-site scripting) sebezhetőségére; de az általa javasolt kód törli a rossz helyen lévő bemenetet, és kihagyja a kimeneti kódolást egy másik területen; Ennek eredményeként a rés nem záródik be teljesen. A biztonsági szakértő áttekinti a javítást, észreveszi a hiányzó kódolást, és kijavítja a megfelelő rétegen. Tanulság: Az AI által javasolt javítás nem automatikusan biztonságos; Minden javítást felülvizsgálunk és tesztelünk.

Gyenge felszólítás / Erős felszólítás

Gyenge felszólítás:

Van-e kiskapu ebben a kódban, javítsa ki: [code]

Ez a prompt nem ad kontextust (nyelv, keretrendszer, bemeneti forrás), nem kér indoklást, nem kérdőjelezi meg a hamis pozitívumot, és nyitott az AI által előállított javítás vakon elfogadására. A mesterséges intelligencia a valódi és a nem létező sebezhetőség jeleit keverte.

Erőteljes felszólítás:

Az Ön szerepe: asszisztens, aki a MÁSODIK SZEM a fejlesztő számára a biztonságos kódellenőrzésben.Döntéshozatal; fontolja meg a közvetlenül alkalmazott javítást. Kód: [nyelv/keretrendszer megadása].Kontextus: ez a funkció [bemeneti forrás: pl. fogadja a [külső HTTP kérést], ír a [kimeneti célállomásra]. Az Ön feladata: (1) jelölje meg a lehetséges sebezhetőségeket az OWASP osztállyal, adjon sorszámot + miért kockázatos + hogyan kell kihasználni + bizonyítékot mindegyikre, (2) írjon legalább 1 hamis pozitív forgatókönyvet minden egyes lelethez (pl. ha a bemenetet egy másik rétegben fertőtlenítették), (3) javasoljon egy javítást, de a "[ellenőrzés + teszt írása]" jellel; Azt is értékelje, hogy a javítás nem vezet-e be új sebezhetőséget/hibákat. Hamis sebezhetőség hozzáadása.[code]

Az erős felszólítás kontextust ad, OWASP osztályt és bizonyítékot kér, hamis pozitívumot és a helyreállítás kockázatait kérdőjelezi meg, emberi felülvizsgálatra kényszeríti.

Másolható prompt sablonok

SÉRÜLÉKESSÉG VIZSGÁLATI SABLON Vizsgálja meg az OWASP Top 10 [nyelv/keretrendszer] kódját. Minden lehetséges megállapításhoz: sorszám, sebezhetőségi osztály, miért kockázatos, minta-kihasználás, bizonyítékok erőssége (bizonyos/valószínű/gyenge). Kontextus: bemenet [forrás], kimenet [cél]. koholt leletek hozzáadása; Ha nem biztos benne, írja be, hogy „[ellenőrzött]”. Kód: [beillesztés]

HAMIS POZITÍV ELTÁVOLÍTÁSI MINTA A következő kód megtalálásához sorolja fel azokat a forgatókönyveket, amelyekben NINCS valódi biztonsági rés: törölhető-e a bemenet egy másik rétegen, elérhető-e ez az útvonal, ez az érték teszt/minta, a keretrendszer automatikusan védett-e. Írja le mindegyiknél a megerősítés módját. Találat: [beillesztés]

FIX ÉRTÉKELŐ SABLONJavítása a következő biztonsági réshez; majd bíráld el a saját javításodat: (1) valóban bezárja-e a sebezhetőséget, (2) bevezet-e új sebezhetőséget/hibát, (3) milyen tesztet írjak (pozitív és negatív eset), (4) hatás a teljesítményre/funkcionalitásra. Megnézem és tesztelem a javítást. Sebezhetőség + kód: [beillesztés]

BIZTONSÁGOS MINTATANÍTÁSI SABLON a sebezhetőségi osztályhoz [pl. SQL injekció] viszonylag biztonságos gépelési mintát és gyakori hibás mintákat mutat ezen a nyelven/keretrendszeren. Általános szabály + példa kód megadása; de szeretném, ha megkérdeznéd a környezetet, mielőtt implementálnád a kódomba. Nyelv/keretrendszer: [írás]

Gyakori hibák

• Áttekintés kontextus nélkül. Nyelv, keretrendszer és bemeneti/kimeneti kontextus nélkül a mesterséges intelligencia összekeveri a valós és a hamis megállapításokat; Feltétlenül adja meg a kontextust.
• Minden jelet valódi gyengeségnek téveszt. A mesterséges intelligencia hamis pozitív eredményeket produkál (tesztadatok, a bemenetet egy másik rétegen tisztítják); Szűrje le az egyes megállapításokat a kontextussal.
• Az AI korrekciójának vak alkalmazása. Az ajánlott javítás új sebezhetőségeket/hibákat vezethet be; átnézni és teszteket írni.
• Bízni a hamis negatívban. Még ha az AI azt mondja is, hogy "nincs sebezhetőség", vizsgálja meg saját maga a kritikus utakat; A statikus vizsgálat nem észlel minden sebezhetőséget.
• A kód/titok megadása a külső eszköznek. A privát kód és a valódi titkok (kulcs, jelszó) szellemi tulajdont és sebezhetőséget jelentenek; anonimizálni vagy vállalati, elszigetelt eszközöket használni.

Tipp: A mesterséges intelligencia felülvizsgálati kódja esetén a leghatékonyabb szűrő az, ha minden egyes leletre rákérdez a „bizonyíték erősségére” (bizonyos/valószínű/gyenge). A legtöbb „gyengének” jelölt lelet hamis pozitív; energiádat a „biztosoknak” osztod.

Figyelem: Az AI javasolt biztonsági javítása nem kerülhet be a raktárba anélkül, hogy tesztelné. A helytelen „javítás” egyrészt nyitva hagyhatja a sebezhetőséget, másrészt funkcionális hibához vezethet a termelésben; Minden javítás átmegy a felülvizsgálati és tesztelési kapun.

Összefoglalva

A biztonságos kódellenőrzés a legolcsóbb módja a sérülékenységek gyártás előtti felfedezésének, és mivel a kód egy nyelv, az AI itt erőteljes második szemré válik: megjelöli a veszélyes mintákat, elmagyarázza a kockázatokat, javításokat javasol. Az AI azonban nem látja a teljes működési kontextust, hamis pozitív és hamis negatív értékeket produkál, és az általa javasolt javítás új sebezhetőségeket vezethet be. A felülvizsgálat tehát hat lépésből áll (kontextus, szűrés, indoklás, hamis pozitív eltávolítás, javítás ellenőrzése, emberi jóváhagyás), és a döntés a fejlesztőre és a biztonsági szakértőre esik. Három alapelv: egyetlen lelet sem értelmezhető kontextus nélkül, minden jel kontextussal együtt kiküszöbölve, javítás nem kerül teszteletlenül a tárba. A kódot/titkot pedig soha nem adják át egy külső eszköznek anonimizálás nélkül.

Pályázati feladat

Vegyünk egy minta kódrészletet (vagy távolítson el érzékeny részeket a saját kódjából, vagy egy sebezhetőséget tartalmazó mintakódot). A mesterséges intelligencia vizsgálja meg a „Vulnerability Scanning” sablon segítségével; Alkalmazza a "False Positive Elimination" sablont minden egyes leletnél, és szüntesse meg a valódiakat. Javítsa ki a legsúlyosabb megállapítást a "Kárelhárítási értékelés" sablon segítségével, nézze át saját maga, és írjon egy pozitív + egy negatív tesztesetet. Jegyezze meg, hány lelet volt hamis pozitív.

ellenőrző lista

• [ ] A kód áttekintése előtt megadtam a nyelvet, a keretrendszert és a bemeneti/kimeneti kontextust.
• [ ] Minden egyes megállapításhoz kértem sorszámot, sebezhetőségi osztályt, kihasználási útvonalat és bizonyítékot.
• [ ] Minden egyes leletet átvizsgáltam, hamis pozitívumot keresve a kontextussal.
• [ ] Nem alkalmaztam vakon az AI korrekcióját; Megnéztem és tesztet írtam.
• [ ] A "Nincs sebezhetőség" kimenet ellenére magam vizsgáltam meg a kritikus útvonalakat.
• [ ] A kódot/titkokat anonimizáltam, vagy vállalati izolált eszközöket használtam.
• [ ] A felfedezést és a javítást átadtam a fejlesztői + biztonsági jóváhagyásnak.