Mga nadagdag:
- Kakayahang i-verify ang output ng AI sa tatlong layer: katumpakan, seguridad at pinagmulan/lisensya
- Kakayahang masakop ang mga panganib tulad ng pag-iniksyon, mga pakete ng guni-guni at mga nakabaon na lihim na may ligtas na mga hulma at kasangkapan
- Kakayahang ipakita ang code na kritikal sa seguridad sa pag-apruba ng isang karampatang inhinyero at maunawaan ang hindi paglilipat ng responsibilidad
Ang pagbuo ng AI code ay madali; Ang pagtitiwala sa kanya ay mahal. Ang tanging layunin ng yunit na ito ay gawing isang sistematikong disiplina sa inhinyero ang prinsipyong "i-verify", na inulit namin sa lahat ng nakaraang yunit. Dahil ang code na ginawa ng AI, kahit na mukhang tama ito sa unang tingin, ay nagdadala ng tatlong magkakahiwalay na panganib: pagiging hindi gumagana/hindi tama (hallucination), pagiging insecure (vulnerability) at nagdadala ng mga panganib sa legal/licensing. Ang pag-alam sa tatlong ito at pagtatatag ng pinto para sa bawat isa sa kanila ay ginagawa kang isang propesyonal.
Dito, isinasaalang-alang namin ang "pagpapatunay" sa tatlong layer: kawastuhan (talaga bang ginagawa ng code ang trabaho?), seguridad (nakatiis ba ito ng malisyosong input?), at provenance/lisensya (may karapatan ba akong gamitin ang code na ito?). Ang bawat layer ay may sariling paraan ng kontrol, at wala sa mga ito ang maaaring lampasan ng "iyan ang sinabi ng AI."
Tatlong Layer ng Panganib
1. Panganib ng katumpakan (hallucination). Maaaring tumawag ang modelo ng isang hindi umiiral na function, maling paggamit ng API, tahimik na mag-bypass ng isang edge case. Ang code ay mukhang "makatwiran" ngunit mali. Antidote: compilation, testing, static analysis at visual inspection.
2. Panganib sa seguridad. Maaaring ulitin ng AI ang mga hindi secure na pattern sa data ng pagsasanay: ang query na mahina sa SQL injection, hindi napatotohanang input ng user, mahinang pag-encrypt, hindi secure na deserialization, bukas na pag-redirect. Gumagana ang code ngunit mahina sa pag-atake. Antidote: pagsusuri na nakatuon sa seguridad, mga automated scanner (SAST), at nagpapataw ng mga kilalang secure na pattern.
3. Panganib sa pinagmulan/lisensya. Maaaring gumawa ang AI ng output na halos kamukha ng naka-copyright o mahigpit na lisensyadong code, o maaari itong magmungkahi ng hindi naaangkop na lisensyadong dependency. Antidote: dependency at pagsuri ng lisensya, pagsuri sa pagka-orihinal, patakaran ng korporasyon.
Pag-iingat: Ang pinaka mapanlinlang sa tatlong panganib na ito ay seguridad; dahil ang code ay maaaring pumasa sa pagsubok, tumakbo nang maayos sa produksyon, at ang kahinaan ay makikita lamang kapag nahanap ito ng isang umaatake. Ang "pagtatrabaho" ay hindi katulad ng "secure."
Hakbang sa Hakbang: Layered Authentication Gate
- Magbasa nang may pang-unawa. Talagang maunawaan ang code bago tanggapin ito; Huwag pagsamahin ang code na hindi mo maintindihan. Kung hindi mo maipaliwanag ang "bakit ito gumagana", hindi pa ito napapatunayan.
- I-verify na mayroon ito. Kumpirmahin na ang bawat function, API at package na ginamit ay aktwal na umiiral at ginagamit nang tama (hallucination gate).
- Patakbuhin ang mga awtomatikong tool. Compiler, linter (style/error scanner), type checker, unit test, at kung maaari ay isang SAST (Static Application Security Testing — tool na nag-scan ng source code para sa mga kahinaan).
- Tingnan ito mula sa isang pananaw sa seguridad. Na-validate ba ang input? Nakaparameter ba ang query? Nakabaon ba ang sikreto? Mayroon bang kontrol sa awtorisasyon?
- Suriin ang pinagmulan at lisensya. May lisensya ba ang mga bagong dependency? Ang output ba ay mukhang sobrang katulad sa isang kilalang codebase?
- Kung ito ay kritikal sa seguridad, humingi ng pag-apruba ng eksperto. Ang independiyenteng pagsusuri ng isang inhinyero na may kakayahan sa mga lugar tulad ng pagpapatunay, pagbabayad, cryptography, kontrol sa pag-access ay sapilitan.
Tatlong Mini Case
Case 1 — Nahuli ang SQL injection sa inspeksyon gate. Ang code na binuo ng AI na direktang pinagsasama-sama ang input ng user sa SQL query para sa isang search endpoint ("... WHERE name = '" + q + "'"). Gumagana ang code at pumasa sa pagsubok. Nahuli ito ng inspeksyon na nakatuon sa seguridad at SAST scan; Na-convert ito sa isang parameterized na query (inihanda na pahayag). Kung hindi ito nahuli, ito ay magiging isang klasikong kahinaan sa pagtagas ng data.
Case 2 — Hallucination package. Iminungkahi ng AI ang isang hindi umiiral na npm package (fast-safe-parse) para sa isang gawain. Nang sinubukan ng developer na i-install ito, hindi nakita ang package. Mas masahol pa: sa ilang mga kaso, maaaring punan ng mga umaatake ang naturang "ghost" na mga pangalan ng package ng tunay, malisyosong mga pakete (dependency confusion). Aralin: i-verify ang bawat inirerekomendang pakete laban sa opisyal na pagpapatala at kasaysayan ng pag-download/pagpapanatili.
Kaso 3 — Hindi pagkakatugma ng lisensya. Ang isang magandang kasamang library na iminungkahi ng AI ay may isang malakas na lisensya ng copyleft na hindi tugma sa lisensya ng produkto ng institusyon. Iniulat ito ng pag-scan ng lisensya ng dependency; Pinalitan ng team ang lisensya ng angkop na alternatibo. Kung walang pag-verify, magkakaroon ng legal na pasanin sa pamamahagi ng produkto.
Apat na Nakokopyang Template
Pre-admission self-check:
Bago tanggapin ang sumusunod na code na nabuo ng AI, suriin:1) Talaga bang umiiral ang bawat function/API/package na ginagamit nito? I-flag ang mga suspek.2) Mayroon bang anumang hindi wastong input, SQL/command concatenation, buried secret, weak crypto?3) Ano ang hindi natugunan na mga bug/edge case? Lagyan ng label ang bawat paghahanap bilang "tiyak / malamang" at magmungkahi ng mga pag-aayos.{{code}}
Pagsusuri na nakatuon sa seguridad:
Suriin ang code na ito gamit ang isang security eye. Maghanap ng mga karaniwang kahinaan sa istilo ng OWASP: iniksyon, sirang pagpapatotoo/awtorisasyon, sensitibong pagbubunyag ng data, hindi secure na deserialization, hindi napatotohanang pag-redirect. Para sa bawat paghahanap: panganib, senaryo ng pagsasamantala, remediation. Ito ay isang preliminary screening; sumangguni sa mga kritikal na natuklasan sa pagsusuri sa seguridad ng tao.{{code}}
Dependency at pagsuri ng lisensya:
Ilista ang mga dependency na idinagdag/iminumungkahi ng code na ito. Para sa bawat: umiiral ba talaga ang package, pinapanatili ba ito, ano ang magiging tipikal na lisensya nito (DAPAT NA PATUNAYAN), at talagang kailangan ba ito para sa proyekto o maaari ba itong gawin gamit ang isang umiiral na tool?{{code o dependency list}}
Ligtas na pagpapataw ng formwork (sa paggawa):
Sumulat ng code para sa {{task}}. MANDATORY na mga panuntunan sa seguridad:- I-validate/i-sanitize ang lahat ng external na input.- Gumamit lamang ng parameterized na query sa database access.- Huwag mag-embed ng mga lihim sa code; ipagpalagay ang variable ng kapaligiran/lihim na tagapamahala - Huwag lunukin ang mga error; Isaalang-alang ito nang may kabuluhan. Ipaliwanag kung paano sumusunod ang code sa mga panuntunang ito sa 3 item.
Mahinang prompt / Malakas na prompt
Mahina: "Sumulat ng query na naghahanap sa pamamagitan ng username." (Maaaring mangyari ang isang code na mahina sa iniksyon.)
Strong: "Sumulat ng function na naghahanap sa pamamagitan ng username. Huwag kailanman isama ang input ng user sa isang query bilang isang string; gumamit ng parameterized na query (inihanda na pahayag). I-validate ang input para sa haba at character. Ipaliwanag sa 2 pangungusap kung bakit sarado ang code sa injection."
Ang malakas na bersyon ay nagpapataw ng secure na pattern mula sa simula; Kaya, tinitiyak nito na ang kahinaan ay hindi mangyayari, sa halip na mahuli ito sa ibang pagkakataon. Gayunpaman, mahalagang ipasa ang nabuong code sa pamamagitan ng verification gate.
Layer ng pagpapatunay
Tool/paraan
Sapat na ba ang "sabi ng AI"?
katumpakan
Compilation, pagsubok, visual inspeksyon
hindi
API/package reality
Opisyal na kontrol ng dokumento/record
hindi
Seguridad
SAST, pagsusuri sa seguridad
hindi
Lisensya/pinagmulan
Dependency at pagsuri ng lisensya
hindi
Logic na kritikal sa seguridad
Pag-apruba ng ekspertong inhinyero
Hinding-hindi
Hindi Maililipat ang Responsibilidad
Ang responsibilidad para sa mga error, kahinaan, o paglabag na nagmumula sa code na ginawa ng isang AI tool ay kabilang sa team na nag-assemble at namamahagi ng code na iyon, hindi sa tool provider. Ito ay isang propesyonal na katotohanan pati na rin ang isang legal na katotohanan: lumagda ka. Kaya ang "AI ginawa ito" ay hindi isang dahilan, ngunit isang katwiran para sa karagdagang pag-iingat. Partikular sa mga sistemang kritikal sa kaligtasan, ang output ng AI ay hindi kapalit ng pagsusuri at pag-apruba ng isang kwalipikadong engineer sa anumang sitwasyon; Sa karamihan, ang AI ay nagbibigay ng blueprint na nagpapabilis sa engineer na iyon.
Tip: Gumawa ng maikling checklist sa iyong team na tinatawag mong “validation gate para sa AI-generated code” (build + test + security scan + visual inspection). Kapag ang gate na ito ay naging isang ugali, ang pagkawala ng bilis ay minimal at ang pagbabawas ng panganib ay pinakamataas.
Mga karaniwang pagkakamali
- Nakakalito ang "gumagana" sa "ligtas". Ang code na pumasa sa pagsubok ay maaaring mahina sa pag-atake.
- Gamit ang package/API nang hindi ito bini-verify. Ang mga hallucinatory packet ay parehong corrupt at nagdudulot ng panganib sa seguridad.
- Pag-bypass sa mga awtomatikong tool. Ang linter, type checker at SAST ay murang nakakakuha ng kung ano ang nakakaligtaan ng mga tao.
- Hindi pinapansin ang lisensya. Ang hindi wastong lisensyadong dependency ay lumilikha ng legal na pasanin sa pamamahagi.
- Paglalagay ng responsibilidad sa sasakyan. Ang koponan ay responsable para sa code sa produksyon; "Ginawa ito ng AI" ay walang dahilan.
Sa buod
Ang pagtanggap sa output ng AI ay nangangailangan ng tatlong layer ng pag-verify: kawastuhan (compile, pagsubok, visual na inspeksyon), seguridad (SAST at pagsusuri na nakatuon sa seguridad), at pinagmulan/lisensya (pagsusuri ng dependency). Kumpirmahin na ang bawat package at API na ginamit ay aktwal na umiiral, ipatupad ang mga secure na pattern mula sa simula, at magsumite ng code na kritikal sa seguridad para sa pag-apruba ng isang kwalipikadong engineer. Ang "Works" ay hindi nangangahulugang ligtas, at ang "AI na ginawa" ay hindi nag-aalis ng pananagutan. Ang verification gate ay ang presyo ng propesyonalismo, hindi bilis.
Gawain ng aplikasyon
Sadyang bigyan ang AI ng isang gawaing sensitibo sa seguridad (hal. "isang function na naghahanap sa database gamit ang input ng user"), sa pagkakataong ito nang hindi nagpapataw ng ligtas na pattern. Ipasa ang papasok na code sa pamamagitan ng "pre-admission self-audit" at "security-focused review" na mga template: mayroon bang anumang iniksiyon, nakabaon na lihim, hallucinated na packet, o hindi napatotohanang input? Pagkatapos ay tanungin muli ang parehong gawain gamit ang template na "secure pattern imposition" at ihambing ang dalawang output. Kung maaari, magpatakbo ng linter/SAST tool at ihambing ang mga natuklasan sa self-regulation ng AI.
checklist
- [ ] Bine-verify ko ang output ng AI sa tatlong layer: katumpakan, seguridad at lisensya.
- [ ] Kinukumpirma ko na ang bawat function, API at package na ginamit ay talagang umiiral.
- [ ] Nagpapatakbo ako ng compile, pagsubok, linter at, kung maaari, mga tool ng SAST.
- [ ] Nagpapataw ako ng mga secure na pattern (parameterized na query, input validation, secret management) mula sa simula.
- [ ] Sinusuri ko ang paglilisensya at kinakailangan ng mga bagong dependency.
- [ ] Nagsusumite ako ng code na kritikal sa seguridad para sa pag-apruba ng isang karampatang inhinyero at naiintindihan ko na ako ang may pananagutan.