Dobici:
- Sposobnost provjere AI izlaza na tri razine: točnost, sigurnost i izvor/licenca
- Sposobnost pokrivanja rizika kao što su injekcije, paketi halucinacije i zakopane tajne sa sigurnim kalupima i alatima
- Sposobnost prezentiranja sigurnosno kritičnog koda na odobrenje nadležnog inženjera i razumijevanje neprenosivosti odgovornosti
Generiranje AI koda je jednostavno; Vjerovati mu je skupo. Jedina svrha ove cjeline je transformirati princip "provjeri", koji smo ponavljali u svim prethodnim cjelinama, u sustavnu inženjersku disciplinu. Jer kod koji proizvodi umjetna inteligencija, čak i ako se na prvi pogled čini točnim, nosi tri odvojene opasnosti: da ne radi/neispravan je (halucinacija), da je nesiguran (ranjivost) i nosi pravne/licencne rizike. Poznavanje ovo troje i postavljanje vrata za svako od njih čini vas profesionalcem.
Ovdje razmatramo "provjeru valjanosti" na tri razine: ispravnost (odrađuje li kod zaista posao?), sigurnost (podnosi li zlonamjerni unos?) i porijeklo/licenca (imam li pravo koristiti ovaj kod?). Svaki sloj ima vlastita sredstva kontrole i nijedan se ne može zaobići s "to je ono što je AI rekao."
Tri razine rizika
1. Rizik od točnosti (halucinacije). Model može pozvati nepostojeću funkciju, zloupotrijebiti API, tiho zaobići rubni slučaj. Kodeks izgleda "razumno", ali je pogrešan. Protuotrov: kompilacija, testiranje, statička analiza i vizualni pregled.
2. Sigurnosni rizik. AI može ponoviti nesigurne obrasce u podacima za obuku: upit ranjiv na SQL injekciju, neautentificirani korisnički unos, slaba enkripcija, nesigurna deserijalizacija, otvoreno preusmjeravanje. Kod radi, ali je ranjiv na napad. Protuotrov: pregled usmjeren na sigurnost, automatizirani skeneri (SAST) i nametanje poznatih sigurnih obrazaca.
3. Rizik izvora/licence. AI može proizvesti izlaz koji je vrlo sličan kodu zaštićenom autorskim pravima ili restriktivnom licenciranom kodu ili može sugerirati neprikladno licenciranu ovisnost. Protuotrov: ovisnost i provjera licenci, provjera izvornosti, korporativna politika.
Oprez: Najpodmukliji od ova tri rizika je sigurnost; jer kod može proći testiranje, radi glatko u proizvodnji, a ranjivost se otkriva tek kada je napadač pronađe. "Raditi" nije isto što i "sigurno".
Korak po korak: Vrata za slojevitu autentifikaciju
- Čitajte s razumijevanjem. Stvarno razumjeti kod prije nego što ga prihvatite; Ne spajajte kod koji ne razumijete. Ako ne možete objasniti "zašto radi", još nije potvrđeno.
- Provjerite postoji li. Potvrdite da svaka korištena funkcija, API i paket stvarno postoji i da se koristi ispravno (halucinacijska vrata).
- Pokreni automatizirane alate. Kompajler, linter (provjera stila/pogrešaka), provjera tipa, jedinični testovi i, ako je moguće, SAST (Static Application Security Testing — alat koji skenira izvorni kod radi ranjivosti).
- Gledajte na to iz sigurnosne perspektive. Je li unos potvrđen? Je li upit parametriran? Je li tajna zakopana? Postoji li kontrola autorizacije?
- Provjerite izvor i licencu. Jesu li nove ovisnosti licencirane? Izgleda li izlaz previše sličan poznatoj bazi koda?
- Ako je sigurnosno kritično, zatražite odobrenje stručnjaka. Obavezan je neovisni pregled od strane inženjera kompetentnog za područja kao što su autentifikacija, plaćanje, kriptografija, kontrola pristupa.
Tri mini kućišta
Slučaj 1 — SQL injekcija uhvaćena na vratima za inspekciju. AI je generirao kod koji spaja korisnički unos izravno u SQL upit za krajnju točku pretraživanja ("... WHERE name = '" + q + "'"). Kod je radio i prošao je test. Inspekcija usmjerena na sigurnost i SAST skeniranje su ovo uhvatili; Pretvoren je u parametrizirani upit (pripremljeni iskaz). Da nije uhvaćen, radilo bi se o klasičnoj ranjivosti curenja podataka.
Slučaj 2 — Halucinacijski paket. AI je predložio nepostojeći npm paket (fast-safe-parse) za zadatak. Kad ga je programer pokušao instalirati, paket nije pronađen. Još gore: u nekim slučajevima, napadači mogu ispuniti takva imena "sablasnih" paketa pravim, zlonamjernim paketima (zabuna ovisnosti). Lekcija: provjerite svaki preporučeni paket prema službenom registru i povijesti preuzimanja/održavanja.
Slučaj 3 — Neusklađenost licence. Zgodna popratna biblioteka koju je predložio AI imala je snažnu licencu za kopiranje koja je bila nekompatibilna s licencom proizvoda institucije. Skeniranje licence ovisnosti prijavilo je ovo; Tim je licencu zamijenio odgovarajućom alternativom. Bez provjere nastao bi pravni teret u distribuciji proizvoda.
Četiri predloška za kopiranje
Samokontrola prije prijema:
Prije prihvaćanja sljedećeg koda generiranog umjetnom inteligencijom, provjerite: 1) Postoji li svaka funkcija/API/paket koji koristi? Označite osumnjičene. 2) Ima li nepotvrđenih unosa, spajanja SQL/naredbi, skrivene tajne, slabe šifre? 3) Koji su neriješeni bugovi/ružni slučajevi? Označite svaki nalaz kao "siguran/vjerojatan" i predložite popravke.{{code}}
Pregled usmjeren na sigurnost:
Pregledajte ovaj kod sigurnosnim okom. Potražite uobičajene ranjivosti OWASP stila: ubacivanje, neispravna autentifikacija/autorizacija, otkrivanje osjetljivih podataka, nesigurna deserijalizacija, neautentificirano preusmjeravanje. Za svaki nalaz: rizik, scenarij eksploatacije, sanacija. Ovo je preliminarni pregled; uputi kritične nalaze na reviziju ljudske sigurnosti.{{code}}
Provjera ovisnosti i licence:
Navedite ovisnosti dodane/predložene ovim kodom. Za svaki: postoji li paket stvarno, održava li se, koja bi bila njegova tipična licenca (MORA BITI PROVJEREN), i je li stvarno potreban za projekt ili se to može učiniti pomoću postojećeg alata?{{code or dependency list}}
Sigurno postavljanje oplate (u proizvodnji):
Napišite kod za {{zadatak}}. OBAVEZNA sigurnosna pravila:- Provjeri valjanost/očistite sav vanjski unos.- Koristite samo parametrizirane upite u pristupu bazi podataka.- Nemojte ugrađivati tajne u kod; pretpostaviti varijablu okruženja/tajnog upravitelja - Ne gutajte pogreške; Razmotrite to suvislo. Objasnite kako je kodeks u skladu s ovim pravilima u 3 stavke.
Slab upit / Jak upit
Slabo: "Napišite upit koji pretražuje prema korisničkom imenu." (Može se pojaviti kôd osjetljiv na ubacivanje.)
Jako: "Napišite funkciju koja pretražuje prema korisničkom imenu. Nikada ne spajajte korisnički unos u upit kao niz; koristite parametrizirani upit (pripremljenu izjavu). Provjerite valjanost unosa za duljinu i znak. Objasnite u 2 rečenice zašto je kod zatvoren za ubacivanje."
Snažna verzija nameće siguran obrazac od početka; Stoga osigurava da se ranjivost uopće ne pojavi, umjesto da se kasnije otkrije. Međutim, bitno je proslijediti generirani kod kroz vrata za provjeru.
Sloj provjere autentičnosti
Alat/metoda
Je li "AI rekao" dovoljno?
točnost
Sastavljanje, testiranje, vizualni pregled
br
API/stvarnost paketa
Kontrola službenog dokumenta/zapisa
br
Sigurnost
SAST, sigurnosni pregled
br
Licenca/izvor
Provjera ovisnosti i licence
br
Sigurnosno kritična logika
Odobrenje stručnog inženjera
Apsolutno ne
Odgovornost se ne može prenijeti
Odgovornost za pogreške, ranjivosti ili kršenja koja proizlaze iz koda koji proizvodi AI alat pripada timu koji sastavlja i distribuira taj kod, a ne dobavljaču alata. Ovo je profesionalna činjenica kao i pravna: potpisujete. Dakle, "AI ga je proizvela" nije isprika, već opravdanje za dodatni oprez. Osobito u sigurnosnim kritičnim sustavima, AI izlaz ni pod kojim okolnostima nije zamjena za pregled i odobrenje od strane kvalificiranog inženjera; U najboljem slučaju, AI daje nacrt koji ubrzava tog inženjera.
Savjet: Napravite kratak popis za provjeru u svom timu koji nazivate "vrata za provjeru valjanosti koda generiranog umjetnom inteligencijom" (izrada + testiranje + sigurnosno skeniranje + vizualni pregled). Jednom kada ova vrata pređu u naviku, gubitak brzine je minimalan, a smanjenje rizika maksimalno.
Uobičajene greške
- Brkanje "radi" sa "sigurno". Kod koji prođe testiranje može biti ranjiv na napad.
- Korištenje paketa/API-ja bez provjere. Halucinantni paketi kvare i predstavljaju sigurnosni rizik.
- Zaobilaženje automatiziranih alata. Linter, provjera tipa i SAST jeftino hvataju ono što ljudima nedostaje.
- Ignoriranje licence. Neodgovarajuća licencirana ovisnost stvara pravni teret distribuciji.
- Prebacivanje odgovornosti na vozilo. Tim je odgovoran za kod u proizvodnji; "AI je to učinio" nije isprika.
Ukratko
Prihvaćanje AI izlaza zahtijeva tri razine provjere: ispravnost (kompilacija, testiranje, vizualni pregled), sigurnost (SAST i pregled usmjeren na sigurnost) i izvor/licenca (provjera ovisnosti). Potvrdite da svaki korišteni paket i API stvarno postoje, nametnite sigurne uzorke od samog početka i pošaljite sigurnosni kritični kod na odobrenje kvalificiranom inženjeru. "Radi" ne znači sigurno, a "proizvedeno umjetnom inteligencijom" ne uklanja odgovornost. Vrata za provjeru cijena su profesionalizma, a ne brzine.
Zadatak aplikacije
Namjerno dajte umjetnoj inteligenciji zadatak koji je osjetljiv na sigurnost (npr. "funkcija koja pretražuje bazu podataka pomoću korisničkog unosa"), ovaj put bez nametanja sigurnog uzorka. Provedite dolazni kod kroz predloške "samoprovjera prije pristupa" i "provjera usmjerena na sigurnost": postoji li ubrizgavanje, skrivena tajna, halucinirani paket ili neautentificirani unos? Zatim ponovno postavite isti zadatak s predloškom "sigurno nametanje uzorka" i usporedite dva izlaza. Ako je moguće, pokrenite alat linter/SAST i usporedite nalaze sa samoregulacijom umjetne inteligencije.
popis za provjeru
- [ ] Provjeravam izlaz umjetne inteligencije na tri razine: točnost, sigurnost i licenca.
- [ ] Potvrđujem da svaka korištena funkcija, API i paket stvarno postoje.
- [ ] Pokrećem alate za prevođenje, testiranje, linter i, ako je moguće, SAST.
- [ ] Od početka namećem sigurne obrasce (parametrizirani upit, provjera valjanosti unosa, upravljanje tajnom).
- [ ] Provjeravam licenciranje i zahtjeve novih ovisnosti.
- [ ] Šaljem sigurnosni kod kritičan na odobrenje nadležnom inženjeru i razumijem da sam odgovoran.