Jednotka 11 / 12

Overenie kódu, slabé miesta a riziká výstupu AI

zisky:

  • Schopnosť overiť výstup AI v troch vrstvách: presnosť, bezpečnosť a zdroj/licencia
  • Schopnosť pokryť riziká, ako sú injekcie, halucinačné balíčky a skryté tajomstvá pomocou bezpečných foriem a nástrojov
  • Schopnosť predložiť kód kritický z hľadiska bezpečnosti na schválenie kompetentným inžinierom a pochopiť neprenosnosť zodpovednosti

Generovanie kódu AI je jednoduché; Veriť mu je drahé. Jediným cieľom tohto celku je pretransformovať princíp „overiť“, ktorý sme si zopakovali vo všetkých predchádzajúcich blokoch, na systematickú inžiniersku disciplínu. Pretože kód vytvorený AI, aj keď sa na prvý pohľad zdá byť správny, nesie so sebou tri samostatné nebezpečenstvá: nefunkčnosť/nesprávnosť (halucinácie), neistotu (zraniteľnosť) a právne/licenčné riziká. Poznanie týchto troch a vytvorenie dverí pre každého z vás robí profesionála.

Tu uvažujeme o „validácii“ na troch úrovniach: správnosť (skutočne kód robí svoju prácu?), bezpečnosť (odolá škodlivému vstupu?) a pôvod/licencia (mám právo používať tento kód?). Každá vrstva má svoje vlastné prostriedky kontroly a žiadny z nich nemožno obísť slovami „to povedala AI“.

Tri vrstvy rizika

1. Riziko presnosti (halucinácie). Model môže volať neexistujúcu funkciu, zneužiť API, potichu obísť okrajový prípad. Kód vyzerá „rozumne“, ale je nesprávny. Protijed: kompilácia, testovanie, statická analýza a vizuálna kontrola.

2. Bezpečnostné riziko. Umelá inteligencia môže v trénovacích údajoch opakovať nezabezpečené vzory: dotaz zraniteľný voči vstrekovaniu SQL, neoverený používateľský vstup, slabé šifrovanie, nezabezpečená deserializácia, otvorené presmerovanie. Kód funguje, ale je náchylný na útok. Protijed: kontrola zameraná na bezpečnosť, automatické skenery (SAST) a zavedenie známych bezpečných vzorov.

3. Riziko zdroja/licencie. AI môže produkovať výstup, ktorý sa veľmi podobá kódu chránenému autorskými právami alebo reštriktívnym licencovaným kódom, alebo môže naznačovať nevhodne licencovanú závislosť. Protijed: kontrola závislostí a licencií, kontrola originality, firemná politika.

Pozor: Najzákernejšie z týchto troch rizík je bezpečnosť; pretože kód môže prejsť testovaním, bežať bez problémov v produkcii a zraniteľnosť sa odhalí až vtedy, keď ju útočník nájde. „Pracovať“ nie je to isté ako „bezpečné“.

Krok za krokom: Vrstvená autentizačná brána

  1. Čítajte s porozumením. Pred prijatím kódu skutočne pochopte; Nezlučujte kód, ktorému nerozumiete. Ak neviete vysvetliť „prečo to funguje“, ešte to nebolo overené.
  2. Overte, či existuje. Potvrďte, že každá použitá funkcia, API a balík skutočne existujú a sú správne používané (halucinačná brána).
  3. Spustite automatizované nástroje. Kompilátor, linter (skener štýlu/chyby), kontrola typu, testy jednotiek a ak je to možné, aj SAST (Statické testovanie bezpečnosti aplikácií – nástroj, ktorý skenuje zdrojový kód na chyby zabezpečenia).
  4. Pozrite sa na to z hľadiska bezpečnosti. Je vstup overený? Je dopyt parametrizovaný? Je tajomstvo pochované? Existuje kontrola autorizácie?
  5. Skontrolujte zdroj a licenciu. Sú nové závislosti licencované? Zdá sa výstup príliš podobný známej kódovej základni?
  6. Ak je to kritické z hľadiska bezpečnosti, požiadajte o schválenie odborníka. Povinná je nezávislá kontrola inžinierom kompetentným v oblastiach, ako je autentifikácia, platby, kryptografia, kontrola prístupu.

Tri mini puzdrá

Prípad 1 – SQL injekcia zachytená pri inšpekčnej bráne. Kód vygenerovaný AI, ktorý spája vstup používateľa priamo do dotazu SQL pre koncový bod vyhľadávania („... WHERE name = '“ + q + „'“). Kód fungoval a prešiel testom. Kontrola zameraná na bezpečnosť a skenovanie SAST to zachytili; Bol prevedený na parametrizovaný dotaz (pripravený výpis). Ak by sa to nepodarilo zachytiť, išlo by o klasickú zraniteľnosť týkajúcu sa úniku dát.

Prípad 2 – Halucinačný balíček. AI navrhla pre úlohu neexistujúci balík npm (fast-safe-parse). Keď sa ho vývojár pokúsil nainštalovať, balík sa nenašiel. Horšie: v niektorých prípadoch môžu útočníci vyplniť takéto „duchovské“ názvy balíkov skutočnými, škodlivými balíkmi (závislosť zmätku). Lekcia: overte každý odporúčaný balík podľa oficiálneho registra a histórie sťahovania/údržby.

Prípad 3 – Nezlučiteľnosť licencie. Šikovná sprievodná knižnica navrhnutá AI mala silnú copyleftovú licenciu, ktorá nebola kompatibilná s licenciou produktu inštitúcie. Skenovanie licencií závislosti to oznámilo; Tým nahradil licenciu vhodnou alternatívou. Bez overenia by pri distribúcii produktov vznikla právna záťaž.

Štyri kopírovateľné šablóny

Samokontrola pred vstupom:

Pred prijatím nasledujúceho kódu vygenerovaného AI skontrolujte: 1) Existuje skutočne každá funkcia/API/balík, ktorý používa? Označte podozrivých.2) Existujú nejaké neoverené vstupy, zreťazenie SQL/príkazov, skryté tajomstvo, slabé šifrovanie?3) Aké sú neriešené chyby/okrajové prípady? Každý nález označte ako „istý/pravdepodobný“ a navrhnite opravy.{{code}}

Kontrola zameraná na bezpečnosť:

Skontrolujte tento kód bezpečnostným okom. Hľadajte bežné chyby zabezpečenia v štýle OWASP: vstrekovanie, nefunkčná autentifikácia/autorizácia, zverejnenie citlivých údajov, nezabezpečená deserializácia, neoverené presmerovanie. Pre každé zistenie: riziko, scenár využívania, náprava. Toto je predbežný skríning; postúpte kritické zistenia na kontrolu bezpečnosti ľudí.{{code}}

Kontrola závislostí a licencií:

Vypíšte závislosti pridané/navrhnuté týmto kódom. Pre každú z nich: existuje balík skutočne, je udržiavaný, aká by bola jeho typická licencia (MUSÍ BYŤ OVERENÁ) a je skutočne potrebná pre projekt alebo sa to dá urobiť pomocou existujúceho nástroja?{{zoznam kódov alebo závislostí}}

Bezpečné uloženie debnenia (vo výrobe):

Napíšte kód pre {{task}}. POVINNÉ bezpečnostné pravidlá:- Overiť/dezinfikovať všetky externé vstupy.- Pri prístupe k databáze používajte iba parametrizované dopyty.- Nevkladajte tajomstvá do kódu; predpokladať manažéra premennej prostredia/tajného prostredia - Neprehĺtajte chyby; Zvážte to zmysluplne. V 3 položkách vysvetlite, ako kód spĺňa tieto pravidlá.

Slabá výzva / Silná výzva

Slabé: "Napíšte dopyt, ktorý vyhľadáva podľa používateľského mena." (Môže sa vyskytnúť kód zraniteľný voči vstrekovaniu.)
Strong: "Napíšte funkciu, ktorá vyhľadáva podľa používateľského mena. Nikdy nepripájajte vstup používateľa do dotazu ako reťazec; použite parametrizovaný dotaz (pripravený príkaz). Overte dĺžku a znak vstupu. Vysvetlite v 2 vetách, prečo je kód uzavretý pre injekciu."

Silná verzia zavádza bezpečný vzor od začiatku; Zabezpečuje teda, že sa zraniteľnosť vôbec nevyskytne, namiesto toho, aby ju zachytil neskôr. Je však nevyhnutné preniesť vygenerovaný kód cez overovacie brány.

Overovacia vrstva

Nástroj/metóda

Stačí „AI povedal“?

presnosť

Kompilácia, testovanie, vizuálna kontrola

č

Realita API/balíčka

Kontrola úradných dokladov/záznamov

č

Bezpečnosť

SAST, bezpečnostná kontrola

č

Licencia/zdroj

Kontrola závislosti a licencií

č

Logika kritická z hľadiska bezpečnosti

Schválenie odborného inžiniera

Rozhodne nie

Zodpovednosť nemožno preniesť

Zodpovednosť za chyby, zraniteľnosti alebo porušenia vyplývajúce z kódu vytvoreného nástrojom AI patrí tímu, ktorý tento kód zostavuje a distribuuje, nie poskytovateľovi nástroja. Toto je odborná aj právna skutočnosť: podpisujete. Takže „AI to vyrobila“ nie je ospravedlnenie, ale odôvodnenie mimoriadnej opatrnosti. Najmä v systémoch kritických z hľadiska bezpečnosti nie je výstup AI za žiadnych okolností náhradou za kontrolu a schválenie kvalifikovaným technikom; AI poskytuje nanajvýš plán, ktorý tohto inžiniera zrýchľuje.

Tip: Vytvorte vo svojom tíme krátky kontrolný zoznam, ktorý nazývate „overovacia brána pre kód vygenerovaný AI“ (zostavenie + test + bezpečnostná kontrola + vizuálna kontrola). Akonáhle sa táto brána stane zvykom, strata rýchlosti je minimálna a zníženie rizika maximálne.

Časté chyby

  • Zámena „funguje“ s „bezpečným“. Kód, ktorý prejde testovaním, môže byť náchylný na útok.
  • Používanie balíka/API bez jeho overenia. Halucinačné pakety sú poškodené a zároveň predstavujú bezpečnostné riziko.
  • Obchádzanie automatizovaných nástrojov. Linter, type checker a SAST lacno chytia to, čo ľuďom chýba.
  • Ignorovanie licencie. Nesprávna licencovaná závislosť vytvára právnu záťaž na distribúciu.
  • Prenesenie zodpovednosti na vozidlo. Tím je zodpovedný za kód vo výrobe; „Urobila to AI“ nie je ospravedlnenie.

V súhrne

Prijatie výstupu AI vyžaduje tri vrstvy overenia: správnosť (kompilácia, test, vizuálna kontrola), bezpečnosť (SAST a kontrola zameraná na bezpečnosť) a zdroj/licencia (kontrola závislosti). Potvrďte, že každý použitý balík a rozhranie API skutočne existuje, od začiatku vynucujte bezpečné vzory a odošlite kód kritický pre bezpečnosť na schválenie kvalifikovanému technikovi. „Funguje“ neznamená bezpečne a „Vyrábaná AI“ nezbavuje zodpovednosti. Overovacou bránou je cena za profesionalitu, nie rýchlosť.

Aplikačná úloha

Zámerne zadajte AI úlohu citlivú na bezpečnosť (napr. „funkcia, ktorá prehľadáva databázu pomocou vstupu používateľa“), tentoraz bez uloženia bezpečného vzoru. Odovzdajte prichádzajúci kód cez šablóny „predvstupového vlastného auditu“ a „kontroly zameranej na bezpečnosť“: existuje nejaká injekcia, skryté tajomstvo, halucinovaný paket alebo neoverený vstup? Potom znova požiadajte o rovnakú úlohu so šablónou „bezpečného vzoru“ a porovnajte dva výstupy. Ak je to možné, spustite nástroj linter/SAST a porovnajte zistenia so samoreguláciou AI.

kontrolný zoznam

  • [ ] Výstup AI overujem v troch vrstvách: presnosť, bezpečnosť a licencia.
  • [ ] Potvrdzujem, že každá použitá funkcia, API a balík skutočne existujú.
  • [ ] Spúšťam nástroje pre kompiláciu, test, linter a ak je to možné, aj SAST.
  • [ ] Od začiatku zavádzam bezpečné vzory (parametrizovaný dopyt, overenie vstupu, správa tajných údajov).
  • [ ] Kontrolujem licencovanie a požiadavku na nové závislosti.
  • [ ] Predkladám kód kritický z hľadiska bezpečnosti na schválenie kompetentnému technikovi a chápem, že som zodpovedný.