Ieguvumi:
- Iespēja pārbaudīt AI izvadi trīs slāņos: precizitāte, drošība un avots/licence
- Spēja segt tādus riskus kā injekcijas, halucināciju paketes un aprakti noslēpumi ar drošām veidnēm un instrumentiem
- Spēja iesniegt drošības ziņā kritisko kodu kompetenta inženiera apstiprināšanai un saprast atbildības nenodošanu
AI koda ģenerēšana ir vienkārša; Uzticēties viņam ir dārgi. Šīs vienības vienīgais mērķis ir pārveidot "pārbaudīt" principu, ko esam atkārtojuši visās iepriekšējās nodaļās, par sistemātisku inženierijas disciplīnu. Jo mākslīgā intelekta radītais kods, pat ja tas pirmajā mirklī šķiet pareizs, rada trīs atsevišķas briesmas: nedarbošanos/nepareizu (halucinācijas), nedrošu (neaizsargātību) un juridisku/licencēšanas risku. Zinot šos trīs un izveidojot durvis katrai no tām, jūs kļūstat par profesionāli.
Šeit mēs aplūkojam “validāciju” trīs līmeņos: pareizība (vai kods patiešām veic savu darbu?), drošība (vai tas iztur ļaunprātīgu ievadi?) un izcelsme/licence (vai man ir tiesības izmantot šo kodu?). Katram slānim ir savi kontroles līdzekļi, un nevienu no tiem nevar apiet ar "tā teica AI".
Trīs riska slāņi
1. Precizitātes risks (halucinācijas). Modelis var izsaukt neesošu funkciju, ļaunprātīgi izmantot API, klusi apiet malas gadījumu. Kods izskatās "saprātīgs", bet ir nepareizs. Pretlīdzeklis: apkopošana, testēšana, statiskā analīze un vizuāla pārbaude.
2. Drošības risks. AI var atkārtot nedrošus modeļus apmācības datos: vaicājums ir neaizsargāts pret SQL injekciju, neautentificēta lietotāja ievade, vāja šifrēšana, nedroša deserializācija, atvērta novirzīšana. Kods darbojas, bet ir neaizsargāts pret uzbrukumiem. Pretlīdzeklis: uz drošību vērsta pārskatīšana, automatizēti skeneri (SAST) un zināmu drošu modeļu uzlikšana.
3. Avota/licences risks. AI var radīt izvadi, kas ļoti atgādina ar autortiesībām aizsargātu vai ierobežojošu licencētu kodu, vai arī var norādīt uz neatbilstoši licencētu atkarību. Pretlīdzeklis: atkarības un licences pārbaude, oriģinalitātes pārbaude, korporatīvā politika.
Uzmanību: mānīgākais no šiem trim riskiem ir drošība; jo kods var izturēt testēšanu, darboties nevainojami ražošanā, un ievainojamība tiek atklāta tikai tad, kad uzbrucējs to atrod. “Darbs” nav tas pats, kas “drošs”.
Soli pa solim: slāņu autentifikācijas vārti
- Lasiet ar izpratni. Tiešām saprotiet kodu pirms tā pieņemšanas; Neapvienojiet kodu, kuru nesaprotat. Ja nevarat izskaidrot "kāpēc tas darbojas", tas vēl nav apstiprināts.
- Pārbaudiet, vai tā pastāv. Apstipriniet, ka katra izmantotā funkcija, API un pakotne patiešām pastāv un tiek pareizi izmantota (halucinācijas vārti).
- Palaidiet automatizētus rīkus. Kompilators, linter (stila/kļūdu skeneris), tipa pārbaudītājs, vienību testi un, ja iespējams, SAST (Static Application Security Testing — rīks, kas skenē avota kodu, lai noteiktu ievainojamības).
- Paskatieties uz to no drošības viedokļa. Vai ievade ir apstiprināta? Vai vaicājums ir parametrizēts? Vai noslēpums ir aprakts? Vai pastāv autorizācijas kontrole?
- Pārbaudiet avotu un licenci. Vai jaunas atkarības ir licencētas? Vai izvade izskatās pārāk līdzīga zināmai kodu bāzei?
- Ja tas ir svarīgi drošībai, lūdziet eksperta apstiprinājumu. Ir obligāta neatkarīga pārbaude, ko veic inženieris, kurš ir kompetents tādās jomās kā autentifikācija, maksājumi, kriptogrāfija, piekļuves kontrole.
Trīs mini futrāļi
1. gadījums — SQL injekcija tika noķerta pie pārbaudes vārtiem. AI ģenerēts kods, kas savieno lietotāja ievadi tieši SQL vaicājumā meklēšanas galapunktam ("... WHERE name = '" + q + "'"). Kods darbojās un izturēja pārbaudi. Uz drošību vērsta pārbaude un SAST skenēšana to atklāja; Tas tika pārveidots par parametrizētu vaicājumu (sagatavots paziņojums). Ja tas nebūtu noķerts, tā būtu klasiska datu noplūdes ievainojamība.
2. gadījums — halucināciju pakete. AI uzdevumam ieteica neeksistējošu npm pakotni (fast-safe-parse). Kad izstrādātājs mēģināja to instalēt, pakotne netika atrasta. Sliktāk: dažos gadījumos uzbrucēji var aizpildīt šādus "spoku" pakotņu nosaukumus ar īstām, ļaunprātīgām pakotnēm (atkarības apjukums). Nodarbība: pārbaudiet katru ieteikto pakotni saskaņā ar oficiālo reģistru un lejupielādes/apkopes vēsturi.
3. gadījums — licenču nesaderība. Izsmalcinātai AI ieteiktajai bibliotēkai bija spēcīga copyleft licence, kas nebija saderīga ar iestādes produkta licenci. Par to ziņoja atkarības licences skenēšana; Komanda aizstāja licenci ar piemērotu alternatīvu. Bez pārbaudes produktu izplatīšanā rastos juridisks slogs.
Četras kopējamas veidnes
Pašpārbaude pirms uzņemšanas:
Pirms akceptējat tālāk norādīto AI ģenerēto kodu, pārbaudiet: 1) Vai katra tā izmantotā funkcija/API/pakotne patiešām pastāv? Atzīmējiet aizdomās turamos. 2) Vai ir kāda nevalidēta ievade, SQL/komandu savienošana, apglabāts noslēpums, vāja šifrēšana?3) Kādi ir neadresēti kļūdu/malu gadījumi? Katram atradumam atzīmējiet kā “noteikts/iespējams” un iesakiet labojumus.{{code}}
Uz drošību vērsts pārskats:
Pārbaudiet šo kodu ar drošības aci. Meklējiet izplatītas OWASP stila ievainojamības: injekcija, bojāta autentifikācija/autorizācija, sensitīvu datu izpaušana, nedroša deserializācija, neautentificēta novirzīšana. Katram konstatējumam: risks, izmantošanas scenārijs, sanācija. Šī ir sākotnējā pārbaude; nododiet kritiskos konstatējumus cilvēku drošības pārskatīšanai.{{code}}
Atkarības un licences pārbaude:
Uzskaitiet šī koda pievienotās/ieteiktās atkarības. Katram: vai pakotne patiešām pastāv, vai tā tiek uzturēta, kāda būtu tās tipiskā licence (JĀPĀRVER) un vai tā patiešām ir nepieciešama projektam, vai arī to var izdarīt ar esošu rīku?{{code or dependency list}}
Droša veidņu uzlikšana (ražošanā):
Uzrakstiet kodu {{uzdevumam}}. OBLIGĀTI drošības noteikumi: - Validēt/sanitizēt visu ārējo ievadi.- Izmantojiet tikai parametrizētu vaicājumu datu bāzes piekļuvei.- Neiegult noslēpumus kodā; pieņemt vides mainīgo/slepeno pārvaldnieku - Nenorīt kļūdas; Apsveriet to jēgpilni. Paskaidrojiet, kā kods atbilst šiem noteikumiem, 3 punktos.
Vāja uzvedne / spēcīga uzvedne
Vāji: "Uzrakstiet vaicājumu, kas meklē pēc lietotājvārda." (Var rasties kods, kas ir neaizsargāts pret injekciju.)
Strong: "Rakstiet funkciju, kas meklē pēc lietotājvārda. Nekad nepievienojiet lietotāja ievadi vaicājumam kā virkni; izmantojiet parametrizētu vaicājumu (sagatavots paziņojums). Apstipriniet ievadīto garumu un rakstzīmi. Paskaidrojiet 2 teikumos, kāpēc kods ir slēgts injekcijai."
Spēcīgā versija jau no paša sākuma uzliek drošu modeli; Tādējādi tiek nodrošināts, ka ievainojamība nerodas vispār, nevis tiek uztverta vēlāk. Tomēr ir svarīgi ģenerēto kodu nodot caur verifikācijas vārtiem.
Autentifikācijas slānis
Instruments/metode
Vai pietiek ar "AI teikto"?
precizitāte
Sastādīšana, testēšana, vizuālā pārbaude
nē
API/pakotnes realitāte
Oficiālā dokumentu/ierakstu kontrole
nē
Drošība
SAST, drošības pārbaude
nē
Licence/avots
Atkarības un licences pārbaude
nē
Drošībai kritiska loģika
Eksperta inženiera apstiprinājums
Absolūti nē
Atbildību nevar nodot
Atbildība par kļūdām, ievainojamībām vai pārkāpumiem, kas izriet no AI rīka radītā koda, ir komandai, kas apkopo un izplata šo kodu, nevis rīka nodrošinātājam. Tas ir gan profesionāls, gan juridisks fakts: jūs parakstāties. Tātad "AI to ražoja" nav attaisnojums, bet gan attaisnojums papildu piesardzībai. Īpaši drošības ziņā kritiskās sistēmās mākslīgā intelekta izvade nekādā gadījumā neaizstāj kvalificēta inženiera veiktu pārskatīšanu un apstiprinājumu; Maksimālais AI nodrošina projektu, kas paātrina šo inženieri.
Padoms. Savā komandā izveidojiet īsu kontrolsarakstu, ko saucat par “AI ģenerēta koda validācijas vārtiem” (būvējums + pārbaude + drošības skenēšana + vizuālā pārbaude). Kad šie vārti kļūst par ieradumu, ātruma zudums ir minimāls un riska samazināšana ir maksimāla.
Biežas kļūdas
- Jaukt "darbus" ar "drošs". Kods, kas iztur pārbaudi, var būt neaizsargāts pret uzbrukumu.
- Pakotnes/API izmantošana, to nepārbaudot. Halucinācijas paketes gan sabojājas, gan rada drošības risku.
- Apejot automatizētos rīkus. Linter, tipa pārbaudītājs un SAST lēti noķer to, kas cilvēkiem pietrūkst.
- Licences ignorēšana. Nepareiza licencēta atkarība rada juridisku slogu izplatīšanai.
- Atbildības uzlikšana transportlīdzeklim. Komanda ir atbildīga par kodu ražošanā; “AI to izdarīja” nav attaisnojums.
Rezumējot
Lai pieņemtu AI izvadi, ir nepieciešamas trīs verifikācijas pakāpes: pareizība (kompilēšana, pārbaude, vizuāla pārbaude), drošība (SAST un uz drošību vērsta pārskatīšana) un avota/licence (atkarības pārbaude). Apstipriniet, ka katra izmantotā pakotne un API patiešām eksistē, jau no paša sākuma ieviesiet drošus modeļus un iesniedziet drošībai būtisko kodu apstiprināšanai kvalificētam inženierim. “Darbs” nenozīmē drošu, un “AI ražots” neatceļ atbildību. Pārbaudes vārti ir profesionalitātes, nevis ātruma cena.
Lietojumprogrammas uzdevums
Apzināti piešķiriet AI drošības ziņā jutīgu uzdevumu (piemēram, “funkcija, kas meklē datu bāzē ar lietotāja ievadi”), šoreiz neuzliekot drošu modeli. Nododiet ienākošo kodu, izmantojot “pirmspieņemšanas pašpārbaudes” un “uz drošību vērstas pārskatīšanas” veidnes: vai ir kāda injekcija, aprakts noslēpums, halucinēta pakete vai neautentificēta ievade? Pēc tam vēlreiz uzdodiet to pašu uzdevumu, izmantojot veidni “droša modeļa uzlikšana” un salīdziniet abus izvadus. Ja iespējams, palaidiet linter/SAST rīku un salīdziniet rezultātus ar AI pašregulāciju.
kontrolsaraksts
- [ ] Es pārbaudu AI izvadi trīs slāņos: precizitāte, drošība un licence.
- [ ] Es apstiprinu, ka katra izmantotā funkcija, API un pakotne patiešām pastāv.
- [ ] Palaižu kompilēšanas, testēšanas, linterēšanas un, ja iespējams, SAST rīkus.
- [ ] Es no paša sākuma uzlieku drošus modeļus (parametrizēts vaicājums, ievades validācija, slepenā pārvaldība).
- [ ] Es pārbaudu jaunu atkarību licencēšanu un prasības.
- [ ] Es iesniedzu drošībai būtisko kodu, lai to apstiprinātu kompetents inženieris, un es saprotu, ka esmu atbildīgs.