Fitimet:
- Aftësia për të verifikuar daljen e AI në tre shtresa: saktësia, siguria dhe burimi/licenca
- Aftësia për të mbuluar rreziqe të tilla si injeksione, paketa halucinacionesh dhe sekrete të varrosura me kallëpe dhe mjete të sigurta
- Aftësia për të paraqitur kodin kritik të sigurisë për miratimin e një inxhinieri kompetent dhe për të kuptuar mostransferimin e përgjegjësisë
Gjenerimi i kodit të AI është i lehtë; Të besosh tek ai është e shtrenjtë. Qëllimi i vetëm i kësaj njësie është shndërrimi i parimit "verifikoj", të cilin e kemi përsëritur në të gjitha njësitë e mëparshme, në një disiplinë sistematike inxhinierike. Sepse kodi i prodhuar nga AI, edhe nëse duket i saktë në shikim të parë, mbart tre rreziqe të veçanta: të qenit jofunksionues/i pasaktë (halucinacion), të qenit i pasigurt (vulnerabiliteti) dhe mbart rreziqe ligjore/licensuese. Njohja e këtyre treve dhe krijimi i një dere për secilën prej tyre ju bën një profesionist.
Këtu marrim parasysh "vlefshmërinë" në tre shtresa: korrektësia (a e bën kodi në të vërtetë punën?), siguria (a i reziston hyrjes me qëllim të keq?) dhe prejardhja/licenca (a kam të drejtë ta përdor këtë kod?). Çdo shtresë ka mjetet e veta të kontrollit dhe asnjëra prej tyre nuk mund të anashkalohet me "kështu tha AI".
Tre shtresa rreziku
1. Rreziku i saktësisë (halucinacione). Modeli mund të thërrasë një funksion jo-ekzistent, të keqpërdor një API, të anashkalojë në heshtje një rast të skajit. Kodi duket "i arsyeshëm", por është i gabuar. Antidoti: përpilimi, testimi, analiza statike dhe inspektimi vizual.
2. Rreziku i sigurisë. Inteligjenca artificiale mund të përsërisë modele të pasigurta në të dhënat e trajnimit: pyetës i cenueshëm ndaj injektimit SQL, hyrje e paautentikuar e përdoruesit, kriptim i dobët, deserializimi i pasigurt, ridrejtim i hapur. Kodi funksionon por është i prekshëm ndaj sulmit. Kundërhelmi: rishikim i fokusuar te siguria, skanerë të automatizuar (SAST) dhe imponim i modeleve të njohura të sigurta.
3. Rreziku i burimit/licencës. AI mund të prodhojë rezultate që i ngjan shumë kodit të licencuar me të drejtë autori ose kufizues, ose mund të sugjerojë një varësi të licencuar në mënyrë të papërshtatshme. Antidoti: kontrolli i varësisë dhe licencës, kontrolli i origjinalitetit, politika e korporatës.
Kujdes: Më e fshehta nga këto tre rreziqe është siguria; sepse kodi mund të kalojë testimin, të funksionojë pa probleme në prodhim dhe dobësia zbulohet vetëm kur e gjen një sulmues. "Të punosh" nuk është e njëjtë me "të sigurt".
Hap pas hapi: Porta e vërtetimit me shtresa
- Lexoni me mirëkuptim. Kuptoni vërtet kodin përpara se ta pranoni atë; Mos e bashkoni kodin që nuk e kuptoni. Nëse nuk mund të shpjegoni "pse funksionon", nuk është vërtetuar ende.
- Verifiko se ekziston. Konfirmoni që çdo funksion, API dhe paketë e përdorur ekziston në të vërtetë dhe përdoret si duhet (porta halucinacioni).
- Ekzekutoni mjete të automatizuara. Përpiluesi, linter (skaneri i stilit/gabimeve), kontrolluesi i tipit, testet e njësisë dhe nëse është e mundur një SAST (Static Application Security Testing — mjet që skanon kodin burimor për dobësi).
- Shikojeni atë nga një këndvështrim sigurie. A është e vërtetuar hyrja? A është pyetja e parametrizuar? A është varrosur sekreti? A ka kontroll autorizimi?
- Kontrolloni burimin dhe licencën. A janë të licencuara varësitë e reja? A duket dalja tepër e ngjashme me një bazë kodi të njohur?
- Nëse është kritike për sigurinë, kërkoni miratimin e ekspertit. Rishikimi i pavarur nga një inxhinier kompetent në fusha të tilla si vërtetimi, pagesa, kriptografia, kontrolli i aksesit është i detyrueshëm.
Tre Mini Rastet
Rasti 1 - Injeksion SQL i kapur në portën e inspektimit. Kodi i gjeneruar nga AI që bashkon hyrjen e përdoruesit drejtpërdrejt në pyetjen SQL për një pikë fundore kërkimi ("... WHERE emri = '" + q + "'"). Kodi po funksiononte dhe e kaloi testin. Inspektimi i fokusuar në siguri dhe skanimi SAST e kapi këtë; Ai u shndërrua në një pyetje të parametrizuar (deklaratë e përgatitur). Nëse nuk do të ishte kapur, do të kishte qenë një cenueshmëri klasike e rrjedhjes së të dhënave.
Rasti 2 — Paketa e halucinacioneve. AI sugjeroi një paketë npm inekzistente (parse e shpejtë e sigurt) për një detyrë. Kur zhvilluesi u përpoq ta instalonte, paketa nuk u gjet. Më keq: në disa raste, sulmuesit mund të mbushin emra të tillë të paketave "fantazmë" me paketa reale, me qëllim të keq (konfuzion i varësisë). Mësimi: verifikoni çdo paketë të rekomanduar kundrejt regjistrit zyrtar dhe historisë së shkarkimit/mirëmbajtjes.
Rasti 3 - Papajtueshmëria e licencës. Një bibliotekë e shkëlqyer shoqëruese e sugjeruar nga AI kishte një licencë të fortë të autorit që ishte e papajtueshme me licencën e produktit të institucionit. Skanimi i licencës së varësisë e raportoi këtë; Ekipi zëvendësoi licencën me një alternativë të përshtatshme. Pa verifikim, do të lindte një barrë ligjore në shpërndarjen e produktit.
Katër modele të kopjueshme
Vetëkontrolli para pranimit:
Përpara se të pranoni kodin e mëposhtëm të gjeneruar nga AI, kontrolloni: 1) A ekziston në të vërtetë çdo funksion/API/paketë që përdor? Tregoni të dyshuarit. 2) A ka ndonjë hyrje të pavlefshme, lidhje SQL/komandë, sekret të fshirë, kripto të dobët?3) Cilat janë gabimet e paadresuara/rastet e skajshme? Etiketoni çdo gjetje si "të sigurt / e mundshme" dhe sugjeroni rregullime.{{kodi}}
Rishikim i fokusuar në siguri:
Shqyrtoni këtë kod me një sy sigurie. Kërkoni dobësi të zakonshme të stilit OWASP: injeksion, vërtetim/autorizim i prishur, zbulim i ndjeshëm i të dhënave, deserializimi i pasigurt, ridrejtim i paautentikuar. Për çdo gjetje: rreziku, skenari i shfrytëzimit, riparimi. Ky është një kontroll paraprak; referojuni gjetjeve kritike te rishikimi i sigurisë njerëzore.{{code}}
Kontrolli i varësisë dhe licencës:
Listoni varësitë e shtuara/sugjeruara nga ky kod. Për secilën: a ekziston në të vërtetë paketa, a mirëmbahet ajo, cila do të ishte licenca e saj tipike (DUHET VERIFIKUAR) dhe a është realisht e nevojshme për projektin apo mund të bëhet me një mjet ekzistues?{{kodi ose lista e varësisë}}
Vendosja e sigurt e kallëpeve (në prodhim):
Shkruani kodin për {{detyrë}}. Rregullat e detyrueshme të sigurisë: - Vërtetoni/sanitizoni të gjitha hyrjet e jashtme.- Përdorni vetëm pyetjen e parametrizuar në aksesin në bazën e të dhënave.- Mos i futni sekretet në kod; supozoni variablin e mjedisit/menaxherin sekret - Mos i gëlltisni gabimet; Konsideroni atë me kuptim. Shpjegoni se si kodi përputhet me këto rregulla në 3 artikuj.
Prompt i dobët / Prompt i fortë
E dobët: "Shkruani një pyetje që kërkon sipas emrit të përdoruesit." (Mund të ndodhë një kod i cenueshëm ndaj injektimit.)
Strong: "Shkruani një funksion që kërkon sipas emrit të përdoruesit. Asnjëherë mos e bashkoni hyrjen e përdoruesit në një pyetje si varg; përdorni një pyetje të parametrizuar (deklaratë e përgatitur). Vërtetoni hyrjen për gjatësinë dhe karakterin. Shpjegoni me 2 fjali pse kodi është i mbyllur për injeksion."
Versioni i fortë imponon modelin e sigurt që në fillim; Kështu, siguron që cenueshmëria të mos ndodhë fare, në vend që ta kapni më vonë. Sidoqoftë, është thelbësore që kodi i gjeneruar të kalohet përmes portave të verifikimit.
Shtresa e vërtetimit
Mjet/metodë
A mjafton "u tha AI"?
saktësi
Kompilim, testim, inspektim vizual
nr
API/realiteti i paketës
Kontrolli i dokumenteve/rekordeve zyrtare
nr
Siguria
SAST, rishikim i sigurisë
nr
Licenca/burimi
Kontrolli i varësisë dhe licencës
nr
Logjika kritike e sigurisë
Miratimi i inxhinierit ekspert
Absolutisht jo
Përgjegjësia nuk mund të bartet
Përgjegjësia për gabimet, dobësitë ose shkeljet që dalin nga kodi i prodhuar nga një mjet AI i takon ekipit që mbledh dhe shpërndan atë kod, jo ofruesit të mjetit. Ky është një fakt profesional po aq edhe ligjor: ju firmosni. Pra, "AI e prodhoi atë" nuk është një justifikim, por një justifikim për kujdes shtesë. Veçanërisht në sistemet kritike për sigurinë, prodhimi i AI nuk është një zëvendësim për rishikimin dhe miratimin nga një inxhinier i kualifikuar në asnjë rrethanë; Më së shumti, AI ofron një plan që e përshpejton atë inxhinier.
Këshillë: Krijoni një listë të shkurtër kontrolli në ekipin tuaj që ju e quani "porta e verifikimit për kodin e gjeneruar nga AI" (ndërtim + test + skanim sigurie + inspektim vizual). Pasi kjo portë bëhet zakon, humbja e shpejtësisë është minimale dhe ulja e rrezikut është maksimal.
Gabimet e zakonshme
- Ngatërrimi i "punës" me "të sigurt". Kodi që kalon testimin mund të jetë i prekshëm ndaj sulmit.
- Përdorimi i paketës/API pa e verifikuar atë. Paketat halucinative korruptojnë dhe paraqesin rrezik sigurie.
- Duke anashkaluar mjetet e automatizuara. Linter, tip checker dhe SAST kapin me çmim të lirë atë që njerëzve u mungon.
- Injorimi i licencës. Varësia e papërshtatshme e licencuar krijon barrë ligjore në shpërndarje.
- Vendosja e përgjegjësisë mbi automjetin. Ekipi është përgjegjës për kodin në prodhim; "AI e bëri atë" nuk është justifikim.
Në përmbledhje
Pranimi i prodhimit të AI kërkon tre shtresa verifikimi: korrektësia (përpilimi, testimi, inspektimi vizual), siguria (SAST dhe rishikimi i fokusuar në siguri) dhe burimi/licenca (kontrolli i varësisë). Konfirmoni që çdo paketë dhe API e përdorur ekziston në të vërtetë, zbatoni modele të sigurta që në fillim dhe dorëzoni kodin kritik të sigurisë për miratim nga një inxhinier i kualifikuar. "Punon" nuk do të thotë të sigurt, dhe "AI i prodhuar" nuk heq përgjegjësinë. Porta e verifikimit është çmimi i profesionalizmit, jo i shpejtësisë.
Detyra e aplikimit
Jepini qëllimisht një AI një detyrë të ndjeshme ndaj sigurisë (p.sh. "një funksion që kërkon bazën e të dhënave me hyrjen e përdoruesit"), këtë herë pa imponuar një model të sigurt. Kaloni kodin hyrës përmes shablloneve të "vetë-kontrollit para-pranimit" dhe "rishikimit të fokusuar në siguri": a ka ndonjë injeksion, sekret të groposur, paketë halucinative ose hyrje të paautentikuar? Më pas kërkoni sërish të njëjtën detyrë me shabllonin "imponimi i modelit të sigurt" dhe krahasoni të dy rezultatet. Nëse është e mundur, përdorni një mjet linter/SAST dhe krahasoni gjetjet me vetë-rregullimin e AI.
listë kontrolli
- [ ] Unë verifikoj daljen e AI në tre shtresa: saktësinë, sigurinë dhe licencën.
- [ ] Konfirmoj që çdo funksion, API dhe paketë e përdorur ekziston në të vërtetë.
- [ ] Unë ekzekutoj përpilimin, testimin, linter dhe, nëse është e mundur, mjetet SAST.
- [ ] Unë imponoj modele të sigurta (kërkim i parametrizuar, vërtetim i hyrjes, menaxhim sekret) që në fillim.
- [ ] Unë kontrolloj licencimin dhe kërkesat e varësive të reja.
- [ ] Po paraqes kodin kritik për sigurinë për miratim nga një inxhinier kompetent dhe e kuptoj që jam përgjegjës.