Vienetas 11 / 12

Kodo patikrinimas, pažeidžiamumas ir AI išvesties rizika

Pelnas:

  • Galimybė patikrinti AI išvestį trimis lygmenimis: tikslumu, saugumu ir šaltiniu / licencija
  • Gebėjimas padengti tokias rizikas kaip injekcija, haliucinacijų paketai ir palaidotos paslaptys saugiomis formomis ir įrankiais
  • Gebėjimas pateikti saugumui svarbų kodą kompetentingam inžinieriui patvirtinti ir suprasti atsakomybės neperleidžiamumą

Sukurti AI kodą paprasta; Pasitikėti juo yra brangu. Vienintelis šio skyriaus tikslas – „patikrinti“ principą, kurį kartojome visuose ankstesniuose skyriuose, paversti sistemine inžinerine disciplina. Kadangi dirbtinio intelekto sukurtas kodas, net jei iš pirmo žvilgsnio atrodo teisingas, kelia tris skirtingus pavojus: neveikiantis / neteisingas (haliucinacijos), nesaugus (pažeidžiamumas) ir teisinė / licencijavimo rizika. Žinodami šias tris ir kiekvienam iš jų nustatydami duris, jūs tampate profesionalu.

„Patvirtinimas“ nagrinėjamas trimis lygmenimis: teisingumas (ar kodas iš tikrųjų atlieka savo darbą?), saugumas (ar jis atlaiko kenksmingą įvestį?) ir kilmė / licencija (ar turiu teisę naudoti šį kodą?). Kiekvienas sluoksnis turi savo valdymo priemones ir nė vieno iš jų negalima apeiti „taip pasakė AI“.

Trys rizikos sluoksniai

1. Tikslumo rizika (haliucinacijos). Modelis gali iškviesti neegzistuojančią funkciją, netinkamai naudoti API, tyliai apeiti kraštinį atvejį. Kodas atrodo „pagrįstas“, bet neteisingas. Priešnuodis: kompiliavimas, testavimas, statinė analizė ir vizualinis patikrinimas.

2. Saugumo rizika. AI gali pakartoti nesaugius mokymo duomenų modelius: užklausą, pažeidžiamą SQL injekcijos, neautentifikuotą vartotojo įvestį, silpną šifravimą, nesaugų deserializavimą, atvirą peradresavimą. Kodas veikia, bet yra pažeidžiamas atakų. Priešnuodis: į saugumą orientuota peržiūra, automatizuoti skaitytuvai (SAST) ir žinomų saugių modelių primetimas.

3. Šaltinio / licencijos rizika. AI gali sukurti išvestį, labai panašią į autorių teisių saugomą arba ribojantį licencijuotą kodą, arba gali pasiūlyti netinkamai licencijuotą priklausomybę. Priešnuodis: priklausomybės ir licencijų tikrinimas, originalumo tikrinimas, įmonės politika.

Atsargiai: klastingiausia iš šių trijų rizikų yra saugumas; nes kodas gali išlaikyti testavimą, sklandžiai veikti gamyboje, o pažeidžiamumas atskleidžiamas tik tada, kai jį randa užpuolikas. „Dirbti“ nėra tas pats, kas „saugus“.

Žingsnis po žingsnio: sluoksniuoti autentifikavimo vartai

  1. Skaitykite supratingai. Tikrai supraskite kodą prieš jį priimdami; Nejunkite kodo, kurio nesuprantate. Jei negalite paaiškinti „kodėl tai veikia“, tai dar nepatvirtinta.
  2. Patikrinkite, ar jis egzistuoja. Patvirtinkite, kad kiekviena naudojama funkcija, API ir paketas iš tikrųjų egzistuoja ir yra tinkamai naudojami (haliucinacijų vartai).
  3. Paleiskite automatinius įrankius. Kompiliatorius, linteris (stiliaus / klaidų skaitytuvas), tipo tikrintuvas, vienetų testai ir, jei įmanoma, SAST (Static Application Security Testing – įrankis, nuskaitantis šaltinio kodą, ar nėra pažeidžiamumų).
  4. Pažvelkite į tai iš saugumo perspektyvos. Ar įvestis patvirtinta? Ar užklausa yra parametrizuota? Ar paslaptis palaidota? Ar yra autorizavimo kontrolė?
  5. Patikrinkite šaltinį ir licenciją. Ar licencijuotos naujos priklausomybės? Ar išvestis atrodo pernelyg panaši į žinomą kodų bazę?
  6. Jei tai labai svarbu saugumui, paprašykite eksperto patvirtinimo. Privaloma atlikti nepriklausomą inžinieriaus, kompetentingo tokiose srityse kaip autentifikavimas, mokėjimas, kriptografija, prieigos kontrolė, peržiūra.

Trys mini dėklai

1 atvejis – SQL įpurškimas sugautas prie patikrinimo vartų. AI sukurtas kodas, kuris sujungia vartotojo įvestį tiesiai į SQL užklausą, skirtą paieškos galutiniam taškui ("... WHERE name = '" + q + "'"). Kodas veikė ir išlaikė testą. Į saugumą orientuota patikra ir SAST nuskaitymas tai užfiksavo; Jis buvo konvertuotas į parametrizuotą užklausą (parengtą pareiškimą). Jei jis nebūtų užfiksuotas, tai būtų buvęs klasikinis duomenų nutekėjimo pažeidžiamumas.

2 atvejis – Haliucinacijų paketas. AI pasiūlė neegzistuojantį npm paketą (fast-safe-parse) užduočiai atlikti. Kai kūrėjas bandė jį įdiegti, paketas nerastas. Dar blogiau: kai kuriais atvejais užpuolikai gali užpildyti tokius „vaiduoklius“ paketų pavadinimus tikrais, kenkėjiškais paketais (priklausomybės painiava). Pamoka: patikrinkite kiekvieną rekomenduojamą paketą pagal oficialų registrą ir atsisiuntimo / priežiūros istoriją.

3 atvejis – licencijos nesuderinamumas. AI pasiūlyta daili papildoma biblioteka turėjo stiprią copyleft licenciją, kuri buvo nesuderinama su įstaigos produkto licencija. Apie tai pranešė priklausomybės licencijos nuskaitymas; Komanda pakeitė licenciją tinkama alternatyva. Nepatikrinus produktų platinimo atsirastų teisinė našta.

Keturi kopijuojami šablonai

Savikontrolė prieš priėmimą:

Prieš priimdami šį AI sugeneruotą kodą, patikrinkite: 1) Ar kiekviena jo naudojama funkcija / API / paketas iš tikrųjų egzistuoja? Pažymėkite įtariamuosius.2) Ar yra nepatvirtintos įvesties, SQL / komandų sujungimo, paslėptos paslapties, silpnos šifravimo?3) Kokios yra neadresuotos klaidos / krašto atvejai? Pažymėkite kiekvieną radinį kaip „tikėtinas / tikėtinas“ ir pasiūlykite pataisymus.{{kodas}}

Apžvalga, orientuota į saugumą:

Apsaugos akimis patikrinkite šį kodą. Ieškokite įprastų OWASP stiliaus spragų: įpurškimo, neveikiančio autentifikavimo / autorizavimo, neskelbtinų duomenų atskleidimo, nesaugaus deserializavimo, neautentifikuoto peradresavimo. Kiekvienam atradimui: rizika, eksploatavimo scenarijus, ištaisymas. Tai preliminarus patikrinimas; kritines išvadas nukreipkite į žmogaus saugumo peržiūrą.{{code}}

Priklausomybės ir licencijos tikrinimas:

Išvardykite priklausomybes, kurias pridėjo / siūlo šis kodas. Kiekvienam: ar paketas iš tikrųjų egzistuoja, ar jis prižiūrimas, kokia būtų jo tipinė licencija (TURI BŪTI PATIKRINTA) ir ar jis iš tikrųjų reikalingas projektui, ar galima tai padaryti naudojant esamą įrankį?{{kodas arba priklausomybių sąrašas}}

Saugus klojinių klojimas (gamyboje):

Parašykite kodą {{užduočiai}}. PRIVALOMOS saugumo taisyklės: - Patvirtinkite / išvalykite visą išorinę įvestį. - Prieigoje prie duomenų bazės naudokite tik parametrizuotas užklausas. - Neįterpkite paslapčių į kodą; prisiima aplinkos kintamąjį/slaptą tvarkyklę – Nepraryk klaidų; Apsvarstykite tai prasmingai. Paaiškinkite, kaip kodas atitinka šias taisykles, 3 punktuose.

Silpnas raginimas / Stiprus raginimas

Silpna: „Parašykite užklausą, kuri ieško pagal vartotojo vardą“. (Gali atsirasti įpurškimui pažeidžiamas kodas.)
Stiprus: "Parašykite funkciją, kuri ieško pagal vartotojo vardą. Niekada nesujunkite vartotojo įvesties į užklausą kaip eilutės; naudokite parametrizuotą užklausą (paruoštą teiginį). Patvirtinkite įvestį ilgį ir simbolį. Paaiškinkite 2 sakiniais, kodėl kodas uždarytas įterpimui."

Stipri versija nuo pat pradžių nustato saugų modelį; Taigi jis užtikrina, kad pažeidžiamumas iš viso nepasireikš, o ne vėliau. Tačiau sugeneruotą kodą būtina perduoti per patvirtinimo vartus.

Autentifikavimo sluoksnis

Priemonė/metodas

Ar užtenka „pasakyti AI“?

tikslumu

Surinkimas, testavimas, vizualinė apžiūra

ne

API / paketo tikrovė

Oficiali dokumentų/įrašų kontrolė

ne

Saugumas

SAST, saugumo peržiūra

ne

Licencija / šaltinis

Priklausomybės ir licencijos tikrinimas

ne

Saugumui svarbi logika

Inžinieriaus eksperto patvirtinimas

Visiškai ne

Atsakomybė negali būti perkelta

Atsakomybė už klaidas, pažeidžiamumą ar pažeidimus, atsirandančius dėl AI įrankio sukurto kodo, priklauso komandai, kuri surenka ir platina tą kodą, o ne įrankio tiekėjui. Tai yra profesinis ir teisinis faktas: jūs pasirašote. Taigi „AI jį pagamino“ nėra pasiteisinimas, o papildomo atsargumo pateisinimas. Ypač svarbiose saugai sistemose AI išvestis jokiomis aplinkybėmis nepakeičia kvalifikuoto inžinieriaus peržiūros ir patvirtinimo; DI daugiausiai pateikia planą, kuris pagreitina tą inžinierių.

Patarimas: savo komandoje sukurkite trumpą kontrolinį sąrašą, kurį vadinate „AI sugeneruoto kodo patvirtinimo vartais“ (kūrimas + bandymas + saugos nuskaitymas + vizualinis patikrinimas). Kai šie vartai tampa įpročiu, greičio praradimas yra minimalus, o rizika sumažinama maksimaliai.

Dažnos klaidos

  • „darbų“ painiojimas su „seifu“. Kodas, kuris išlaiko testą, gali būti pažeidžiamas atakų.
  • Paketo / API naudojimas jo nepatvirtinus. Haliucinaciniai paketai sugadinami ir kelia pavojų saugumui.
  • Aplenkiant automatinius įrankius. Linter, tipo tikrintuvas ir SAST pigiai pagauna tai, ko žmonės pasigenda.
  • Licencijos nepaisymas. Netinkama licencijuota priklausomybė sukuria teisinę naštą platinimui.
  • Atsakomybės perkėlimas ant transporto priemonės. Komanda yra atsakinga už kodą gamyboje; „AI padarė tai“ nėra pasiteisinimas.

Apibendrinant

Norint priimti dirbtinio intelekto išvestį, reikia trijų lygių tikrinimo: teisingumo (kompiliavimas, bandymas, vizualinis patikrinimas), saugos (SAST ir į saugumą orientuota peržiūra) ir šaltinio / licencijos (priklausomybės tikrinimas). Patvirtinkite, kad kiekvienas naudojamas paketas ir API iš tikrųjų egzistuoja, nuo pat pradžių vykdykite saugius modelius ir pateikite saugumui svarbų kodą, kad jį patvirtintų kvalifikuotas inžinierius. „Darbas“ nereiškia, kad saugu, o „pagamintas dirbtinis intelektas“ nepanaikina atsakomybės. Patikrinimo vartai yra profesionalumo, o ne greičio kaina.

Taikymo užduotis

Sąmoningai suteikite AI saugai jautrią užduotį (pvz., „funkcija, kuri ieško duomenų bazėje su naudotojo įvestimi“), šį kartą nenustatant saugaus modelio. Perduokite gaunamą kodą naudodami „savarankinio patikrinimo prieš priėmimą“ ir „į saugumą orientuotos peržiūros“ šablonus: ar yra kokių nors injekcijų, paslėptų paslapčių, haliucinuotų paketų ar neautentifikuotos įvesties? Tada dar kartą užduokite tą pačią užduotį naudodami „saugaus modelio įvedimo“ šabloną ir palyginkite du išvestis. Jei įmanoma, paleiskite linter / SAST įrankį ir palyginkite rezultatus su AI savireguliacija.

kontrolinis sąrašas

  • [ ] Aš tikrinu AI išvestį trimis lygmenimis: tikslumą, saugumą ir licenciją.
  • [ ] Patvirtinu, kad kiekviena naudojama funkcija, API ir paketas iš tikrųjų egzistuoja.
  • [ ] Aš paleidžiu kompiliavimo, testavimo, linijavimo ir, jei įmanoma, SAST įrankius.
  • [ ] Nuo pat pradžių primetu saugius šablonus (parametrų užklausa, įvesties patvirtinimas, slaptas valdymas).
  • [ ] Aš tikrinu licencijavimą ir naujų priklausomybių reikalavimą.
  • [ ] Pateikiu saugos požiūriu kritinį kodą, kad jį patvirtintų kompetentingas inžinierius ir suprantu, kad esu atsakingas.