ການໂຈມຕີ Supply Chain ໃນການພັດທະນາ AI ປີ 2026 — ຄູ່ມືປ້ອງກັນການປົນເປື້ອນຂອງ Model, Dependency Package ແລະ ການລະເມີດ SaaS

Supply chain ຂອງການພັດທະນາ AI ແມ່ນລະບົບຕ່ອງໂສ້ການສະໜອງທັງໝົດ ເຊິ່ງລວມເຖິງໂມເດວເປີດເຜີຍ (Open Models), ແພັກເກດທີ່ຕ້ອງເພິ່ງພາອາໄສ, ແພລດຟອມ SaaS DevOps, ແລະ AI Agent ທີ່ຖືກລວມເຂົ້າໃນການພັດທະນາ ເຊິ່ງຜະລິດຕະພັນ AI ຕ້ອງອີງໃສ່. ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອ CTO, ຫົວໜ້າຝ່າຍຄວາມປອດໄພ ແລະ SRE ຂອງບໍລິສັດທີ່ພັດທະນາ ແລະ ດຳເນີນງານຜະລິດຕະພັນ AI, ໂດຍຈະສະຫຼຸບເຫດການສຳຄັນທີ່ເກີດຂຶ້ນໃນປີ 2024–2026, ອະທິບາຍເຖິງພື້ນທີ່ການໂຈມຕີສະເພາະຂອງ AI ທີ່ SBOM ຢ່າງດຽວບໍ່ສາມາດປ້ອງກັນໄດ້, ລວມເຖິງຍຸດທະສາດການປ້ອງກັນທີ່ປະສົມປະສານລະຫວ່າງ AI BOM / ການກວດສອບ Model Card / ການກຳນົດສິດ OAuth ຂັ້ນຕໍ່າສຸດ / ການບໍລິຫານຈັດການ Sensitive Secret / ແລະ ການແຍກ CI/CD ອອກຈາກກັນ. ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດສ້າງລາຍການກວດສອບ (Checklist) ສຳລັບມາດຕະການປ້ອງກັນທີ່ຍັງຂາດຫາຍໄປໃນຂະບວນການ ຫຼື Pipeline ການພັດທະນາ AI ຂອງບໍລິສັດທ່ານໄດ້.

ຕ່ອງໂສ້ການສະໜອງຜະລິດຕະພັນ AI ມີຄວາມກວ້າງກວ່າຕ່ອງໂສ້ການສະໜອງຊອບແວແບບດັ້ງເດີມ. ມີການກວດພົບການບຸກລຸກຢ່າງຕໍ່ເນື່ອງໃນ 4 ເສັ້ນທາງ ຄື: ຕົວແບບ (Model), ແພັກເກດທີ່ເພິ່ງພາອາໄສ (Dependency packages), SaaS DevOps ແລະ AI Agent. ໃນບົດນີ້, ພວກເຮົາຈະສະຫຼຸບເຫດການສຳຄັນທີ່ເປີດຕົວ ຫຼື Launch ໃນຮອບ 10 ປີ (2024-2026) ແລະ ຄວາມກວ້າງຂອງພື້ນທີ່ຄວາມສ່ຽງທີ່ເປັນເອກະລັກສະເພາະໃນການພັດທະນາ AI.

ເຫດການທີ່ສັ່ນສະເທືອນວົງການພັດທະນາ AI ໃນຊ່ວງປີ 2024-2026 ໄດ້ເກີດຂຶ້ນຜ່ານ 4 ເສັ້ນທາງທີ່ມີລັກສະນະແຕກຕ່າງກັນ:

1. xz utils backdoor (CVE-2024-3094, ປະກາດໃນເດືອນມີນາ 2024): ຜູ້ໂຈມຕີທີ່ໃຊ້ເວລາປະມານ 2 ປີໃນການຍຶດສິດທິ Maintainer ໄດ້ຝັງ Backdoor ໄວ້ໃນ liblzma ເພື່ອຫຼີກລ່ຽງ ການຢືນຢັນຕົວຕົນ ຜ່ານ SSH. ຖ້າ Andres Freund ຈາກ Microsoft ບໍ່ໄດ້ຄົ້ນພົບໂດຍບັງເອີນ, ມັນກໍຄົງຈະປົນເປື້ອນເຂົ້າໄປໃນຫຼາຍ Distribution (ທີ່ມາ: NVD CVE-2024-3094).
2. ການລະເມີດ tj-actions/changed-files (ປະກາດໃນເດືອນມີນາ 2025): GitHub Action ທີ່ຖືກນຳໃຊ້ໃນຫຼາຍ Repository ໄດ້ຖືກດັດແກ້ໃຫ້ມີພຶດຕິກຳຂຽນ Secret ຂອງ CI ລົງໃນ Log ການເຮັດວຽກ. Repository ທີ່ຍັງຄົງໃຊ້ການອ້າງອີງແບບ Tag (ໂດຍບໍ່ມີ SHA pin) ໄດ້ຮັບຜົນກະທົບ (ທີ່ມາ: GitHub Security Advisory, ບົດລາຍງານການວິເຄາະຈາກ StepSecurity).
3. ການກວດພົບ Backdoor ໃນໂມເດວ Hugging Face: ReversingLabs ແລະ JFrog Security Research ໄດ້ກວດພົບໄຟລ໌ Pickle ທີ່ເປັນອັນຕະລາຍຢ່າງຕໍ່ເນື່ອງຈາກໂມເດວທີ່ເປີດໃຫ້ໃຊ້ງານສາທາລະນະ (ທີ່ມາ: ReversingLabs Blog, JFrog Security Research).
4. ເຫດການ Vercel ໃນເດືອນເມສາ 2026: ຈາກການຖືກລະເມີດບັນຊີພະນັກງານ ເຮັດໃຫ້ Environment variable ທີ່ "encrypted" ຂອງລູກຄ້າບາງສ່ວນຖືກ ເປີດຕົວ ຫຼື Launch ອອກສູ່ພາຍນອກ. Vercel ໄດ້ປະກາດວ່າ Environment variable ທີ່ມີຄວາມລະອຽດອ່ອນ (Sensitive) ຍັງຢູ່ພາຍໃຕ້ການປົກປ້ອງດ້ວຍການເຂົ້າລະຫັດ ແລະ ຍັງບໍ່ພົບຫຼັກຖານການເຂົ້າເຖິງ (ທີ່ມາ: Vercel KB Bulletin "April 2026 security incident").

ເຫດການເຫຼົ່ານີ້ເບິ່ງຄືວ່າເປັນເຫດການແຍກຕ່າງຫາກ ແຕ່ທັງໝົດລ້ວນແຕ່ມີໂຄງສ້າງດຽວກັນຄື: "ເມື່ອພາກສ່ວນໃດໜຶ່ງທີ່ AI / SaaS ຕ້ອງເພິ່ງພາອາໄສຖືກລະເມີດ → ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ກຸນແຈ ຫຼື ລະຫັດຕ່າງໆຮົ່ວໄຫຼອອກໄປເປັນທອດໆ".

ມີ 4 ເຫດຜົນທີ່ເຮັດໃຫ້ພື້ນທີ່ຄວາມສ່ຽງໃນການພັດທະນາ AI ກວ້າງກວ່າແຕ່ກ່ອນ:

ອັນທີໜຶ່ງ, ໄຟລ໌ນ້ຳໜັກ (Weight files) ສາມາດກາຍເປັນ Payload ທີ່ສາມາດປະຕິບັດງານໄດ້. ໂມເດວໃນຮູບແບບ Pickle ສາມາດປະຕິບັດໂຄ້ດ Python ໄດ້ຢ່າງອິດສະຫຼະ ແລະ ຖ້າຫາກອ່ານໄຟລ໌ໂດຍບໍ່ມີການສະແກນ ກໍຈະເກີດການລະເມີດຄວາມປອດໄພຂຶ້ນ. ອັນທີສອງ, ມີທຳນຽມການດຶງເອົານ້ຳໜັກພື້ນຖານ (Base weights) ຫຼື ຊຸດຂໍ້ມູນມາຈາກ Hub ທີ່ເປີດຕົວ ຫຼື Launch ຕໍ່ສາທາລະນະ, ເຊິ່ງການຖືກລະເມີດບັນຊີໃນຝັ່ງ Hub ຈະສົ່ງຜົນໃຫ້ເກີດການແຊກແຊງທັນທີ. ອັນທີສາມ, ການພັດທະນາ AI ປະກອບຂຶ້ນຈາກຕ່ອງໂສ້ຂອງ SaaS — ບໍ່ວ່າຈະເປັນ Model Registry, Vector Database, ແພລດຟອມການ Deploy, ລະບົບ Log ແລະອື່ນໆ, ເຊິ່ງ API Key / OAuth Scope ແຕ່ລະອັນຈະກາຍເປັນສ່ວນໜຶ່ງຂອງຕ່ອງໂສ້ການສະໜອງ (Supply chain). ອັນທີສີ່, ການທີ່ຫຼາຍບໍລິສັດນຳເອົາ AI Coding Agent ເຂົ້າມາລວມໃນການພັດທະນາ ເຮັດໃຫ້ການເພີ່ມ Dependency ທີ່ Agent ເປັນຜູ້ຂຽນນັ້ນ ສາມາດກາຍເປັນຊ່ອງທາງການໂຈມຕີໄດ້. ສິ່ງເຫຼົ່ານີ້ແມ່ນຂົງເຂດທີ່ບໍ່ສາມາດເບິ່ງເຫັນໄດ້ດ້ວຍພຽງແຕ່ SBOM ແລະ CVE Scan ແບບດັ້ງເດີມ, ຈຶ່ງຈຳເປັນຕ້ອງມີມາດຕະການປ້ອງກັນສະເພາະສຳລັບ AI.

ການໂຫຼດໂມເດວທີ່ໄດ້ມາຈາກ Public Hub ເຊັ່ນ Hugging Face ໂດຍຍັງຢູ່ໃນຮູບແບບ Pickle ອາດນຳໄປສູ່ການປະຕິບັດຄຳສັ່ງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດໂດຍກົງ. ການຍ້າຍໄປໃຊ້ safetensors ແລະການກວດສອບລາຍເຊັນຂອງ Model Card ແມ່ນແນວປ້ອງກັນດ່ານທຳອິດ. ໃນບົດນີ້, ພວກເຮົາຈະສະຫຼຸບຕົວຢ່າງຈິງຂອງ Backdoor ໃນໂມເດວສາທາລະນະ ແລະຄວາມສ່ຽງທີ່ເກີດຈາກການໂຫຼດໂດຍບໍ່ມີການກວດສອບ.

ໃນ Registry ຂອງໂມເດວທີ່ເປີດຕົວ ຫຼື Launch ລວມເຖິງ Hugging Face, ໄດ້ມີການລາຍງານຢ່າງຕໍ່ເນື່ອງກ່ຽວກັບກໍລະນີທີ່ມີການຝັງ Backdoor ໄວ້ໃນໂມເດວຮູບແບບ Pickle (.bin / .pkl / .pt). ReversingLabs ໄດ້ເປີດຕົວ ຫຼື Launch PoC ທີ່ສາມາດຫຼົບຫຼີກ Pickle scanner ແລະສັ່ງງານການເຊື່ອມຕໍ່ພາຍນອກ ຫຼື Reverse shell ໃນຂະນະທີ່ໂຫຼດໂມເດວ, ພ້ອມທັງໄດ້ກວດພົບຕົວຢ່າງທີ່ເປັນອັນຕະລາຍຫຼາຍກໍລະນີ (ທີ່ມາ: ບົດວິເຄາະ "nullifAI" ຂອງ ReversingLabs). ນອກຈາກນີ້, JFrog Security Research ຍັງໄດ້ກວດພົບໂມເດວທີ່ມີ Backdoor ໂດຍອີງໃສ່ Pickle ເປັນຈຳນວນຫຼາຍ ແລະ ໄດ້ແຈ້ງໃຫ້ທາງ Hugging Face ຮັບຊາບແລ້ວ (ທີ່ມາ: JFrog Security Research).

ການໂຈມຕີເຫຼົ່ານີ້ມີການນຳໃຊ້ປັດໄຈດ້ານວິສະວະກຳສັງຄົມ (Social Engineering) ມາປະສົມປະສານ ເຊັ່ນ: "ການເປີດຕົວ ຫຼື Launch ໂດຍໃຊ້ຊື່ Repository ທີ່ຄ້າຍຄືກັບຊື່ໂມເດວທີ່ເປັນທາງການ" ຫຼື "ການແຈກຢາຍໂດຍອ້າງວ່າເປັນເວີຊັນທີ່ຜ່ານການ Fine-tuned ຂອງໂມເດວທີ່ເປັນທາງການ". ຕາບໃດທີ່ອົງກອນພັດທະນາ AI ຍັງປ່ອຍໃຫ້ວິສະວະກອນແຕ່ລະຄົນຕັດສິນໃຈເອີ້ນໃຊ້ from_pretrained() ດ້ວຍຕົນເອງ, ຄວາມສ່ຽງຈາກການປະມວນຜົນ Pickle ກໍຈະຍັງຄົງມີຢູ່ຕະຫຼອດເວລາ. ບັນຫາສຳຄັນກໍຄື Backdoor ບໍ່ແມ່ນ "ກໍລະນີພິເສດ" ແຕ່ເປັນໄພຂົ່ມຂູ່ທີ່ເກີດຂຶ້ນຢ່າງຕໍ່ເນື່ອງ ເຊິ່ງມີຕົ້ນຕໍມາຈາກໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ Public Hub ນັ້ນເອງ.

ການທີ່ Pickle ສາມາດປະຕິບັດລະຫັດ (Arbitrary Code Execution) ໄດ້ນັ້ນ ແມ່ນເປັນໄປຕາມມາດຕະຖານ ຫຼື Specification ບໍ່ແມ່ນຂໍ້ຜິດພາດ. pickle.load() ຂອງ Python ຖືກອອກແບບມາໃຫ້ອະນຸຍາດການເອີ້ນໃຊ້ຟັງຊັນໃດກໍໄດ້ຜ່ານ __reduce__ ເຮັດໃຫ້ການໂຫຼດໂດຍບໍ່ມີ scanner ສາມາດເກີດການລະເມີດຄວາມປອດໄພໄດ້ທັນທີ (ທີ່ມາ: ເອກະສານທາງການຂອງ Python ຫົວຂໍ້ "Warning" ໃນໂມດູນ pickle).

ມາດຕະການປ້ອງກັນມີ 3 ຂັ້ນຕອນດັ່ງນີ້:

1. ປ່ຽນໄປໃຊ້ຮູບແບບ safetensors: ເປັນຮູບແບບທີ່ Hugging Face ແນະນຳ ເຊິ່ງບໍ່ສາມາດປະຕິບັດລະຫັດອື່ນນອກເໜືອຈາກ Tensor ໄດ້. ຕ້ອງບັງຄັບໃຫ້ໃຊ້ສະບັບ safetensors ສຳລັບການນຳເຂົ້າໂມເດວໃໝ່.
2. ການນຳໃຊ້ Pickle scanner: ຕ້ອງນຳເອົາເຄື່ອງມືເຊັ່ນ: pickle scan ຂອງ Hugging Face, ModelScan ຂອງ ProtectAI, ຫຼື ເຄື່ອງມືກວດຈັບຂອງ JFrog ມາລວມ ຫຼື Merge ເຂົ້າໃນ CI ແລະ ຕ້ອງຜ່ານການສະແກນໂມເດວຮູບແບບ Pickle ທຸກຄັ້ງ.
3. ການກວດສອບລາຍເຊັນຂອງ Model Card: ກວດສອບວ່າແຫຼ່ງທີ່ມາແມ່ນບັນຊີທາງການຂອງ provider ໂດຍໃຊ້ Sigstore / cosign ແລະ ອື່ນໆ. ໂມເດວທາງການຂອງ Hugging Face ສາມາດກວດສອບຄວາມຖືກຕ້ອງໄດ້ຜ່ານລາຍເຊັນ GPG ຫຼື Verified Publisher badge.

ການລວມການເອີ້ນໃຊ້ from_pretrained() ພາຍໃນອົງກອນໃຫ້ເປັນ wrapper ດຽວ ແລະ ບັງຄັບໃຫ້ wrapper ນັ້ນກວດສອບ Registry, ຮູບແບບ, ແລະ ລາຍເຊັນ ແມ່ນຮູບແບບທີ່ງ່າຍຕໍ່ການບໍລິຫານຈັດການ. ການກຳຈັດສະພາວະທີ່ວິສະວະກອນໂຫຼດ Pickle ແຍກຕ່າງຫາກນັ້ນເອງ ຖືເປັນການປ້ອງກັນໃນລະດັບອົງກອນ.

npm / PyPI ຂອງພາກສ່ວນທີສາມ (Third-party packages) ແລະ GitHub Actions ແມ່ນຊັ້ນຂອງການເພິ່ງພາອາໄສ (Dependency layers) ທີ່ຖືກນຳໃຊ້ເປັນມາດຕະຖານໃນການພັດທະນາ AI ເຊັ່ນກັນ. ບໍ່ວ່າຈະເປັນ typosquatting, ການຍຶດບັນຊີຜູ້ເບິ່ງແຍງລະບົບ, ຫຼືການປ່ຽນແທນໃນລະຫວ່າງການ build ລ້ວນແຕ່ມີຕົວຢ່າງທີ່ເກີດຂຶ້ນຈິງ. ໃນບົດນີ້, ພວກເຮົາຈະຈັດລະບຽບກ່ຽວກັບກໍລະນີຕົວຢ່າງທີ່ເປັນຮູບປະທຳ ແລະ ໂຄງສ້າງຂອງການໂຈມຕີແບບຫຼາຍຂັ້ນຕອນ.

ການລະເມີດຊັ້ນຂອງແພັກເກັດທີ່ເພິ່ງພາອາໄສ (Dependency) ແມ່ນພົບເຫັນໄດ້ເລື້ອຍໆໃນການພັດທະນາ AI. ເຊິ່ງມີຮູບແບບຫຼັກໆ 3 ຢ່າງດັ່ງນີ້:

• Typosquatting: ການເປີດຕົວ ຫຼື Launch ແພັກເກັດທີ່ມີຊື່ຄ້າຍຄືກັບຊື່ແພັກເກັດປົກກະຕິໂດຍຜິດພຽງຕົວອັກສອນດຽວ ເພື່ອຫຼອກໃຫ້ຜູ້ໃຊ້ຕິດຕັ້ງຜິດ. Sonatype ແລະ Phylum ໄດ້ກວດພົບແພັກເກັດທີ່ເປັນອັນຕະລາຍຫຼາຍຮ້ອຍລາຍການຕໍ່ປີໃນ PyPI / npm ຢ່າງຕໍ່ເນື່ອງ (ທີ່ມາ: Sonatype "State of the Software Supply Chain").
• ການຍຶດບັນຊີຜູ້ເບິ່ງແຍງລະບົບ (Maintainer account hijacking): ບັນຊີ npm / PyPI ຂອງນັກພັດທະນາສ່ວນບຸກຄົນຖືກລະເມີດ ແລະ ມີການເປີດຕົວ ຫຼື Launch ເວີຊັນທີ່ມີມັນແວ (Malware) ລົງໃນແພັກເກັດທີ່ມີຢູ່ແລ້ວ. ເຖິງຈະເປັນວິທີແບບດັ້ງເດີມ ແຕ່ກໍຍັງເກີດຂຶ້ນຢູ່ໃນປັດຈຸບັນ.
• ການປອມແປງ GitHub Actions: ກໍລະນີຕົວຢ່າງທີ່ເດັ່ນຊັດຄືການລະເມີດ tj-actions/changed-files ໃນເດືອນມີນາ 2025. ຜູ້ໂຈມຕີໄດ້ຂຽນທັບ Release tag ຂອງ Action ແລະເຮັດໃຫ້ຕົວແປສະພາບແວດລ້ອມ (Secrets) ຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ໃນບັນທຶກ (Log) ເມື່ອມີການປະມວນຜົນ CI. ຫໍໄຕ (Repository) ທີ່ອ້າງອີງໂດຍບໍ່ມີການກຳນົດ SHA pin ອາດຈະຖືກດຶງຂໍ້ມູນອອກຈາກບັນທຶກຂອງ GitHub Actions (ທີ່ມາ: GitHub Security Advisory, ການວິເຄາະຂອງ StepSecurity).

ໃນການພັດທະນາ AI, ນອກເໜືອຈາກແພັກເກັດລະດັບສູງເຊັ່ນ transformers / torch / accelerate ແລ້ວ, ຍັງມີການເພິ່ງພາອາໄສໃນລະດັບທີສອງ ແລະ ທີສາມທີ່ເລິກເຊິ່ງ ເຊັ່ນ: Vector DB client, Agent framework, ແລະ Library ສຳລັບການປະເມີນຜົນ. ທີມງານທີ່ຄຸ້ມຄອງພຽງແຕ່ແພັກເກັດຜິວເຜີນ ຈຶ່ງມີຄວາມສ່ຽງທາງໂຄງສ້າງທີ່ເຮັດໃຫ້ຍາກຕໍ່ການກວດພົບການລະເມີດໃນລະດັບທີ່ເລິກເຊິ່ງ.

xz utils back door (CVE-2024-3094) ແມ່ນຕົວຢ່າງທີ່ສະແດງໃຫ້ເຫັນວ່າການລະເມີດຊັ້ນຂອງການເພິ່ງພາອາໄສ (dependency) ບໍ່ໄດ້ຈົບລົງພຽງແຕ່ໃນແພັກເກດດຽວ. ຜູ້ໂຈມຕີທີ່ໃຊ້ຊື່ວ່າ "Jia Tan" ໄດ້ໃຊ້ເວລາຫຼາຍກວ່າ 2 ປີ ເພື່ອໃຫ້ໄດ້ສິດທິໃນການເປັນ maintainer ຂອງໂຄງການ xz ແລະໄດ້ຝັງ back door ທີ່ຖືກເຮັດໃຫ້ອ່ານຍາກ (obfuscated) ລົງໃນ liblzma ຢ່າງເປັນຂັ້ນຕອນ. payload ສຸດທ້າຍແມ່ນການຂຽນທັບ logic ການຢືນຢັນຕົວຕົນ ຂອງ sshd ຜ່ານ liblzma ເພື່ອສ້າງສະພາວະທີ່ອະນຸຍາດໃຫ້ຜູ້ໂຈມຕີສະເພາະກຸ່ມສາມາດຫຼີກລ່ຽງການຢືນຢັນຕົວຕົນຜ່ານ SSH ໄດ້ (ທີ່ມາ: NVD CVE-2024-3094, ລາຍງານຈາກ Andres Freund ໃນລາຍຊື່ທາງອີເມວ oss-security).

ເມື່ອເບິ່ງຈາກມຸມມອງການພັດທະນາ AI, ມີບົດຮຽນ 2 ຢ່າງຄື:

ຢ່າງທີໜຶ່ງ, ການຍຶດຄອງທາງສັງຄົມຂອງ maintainer ບໍ່ສາມາດປ້ອງກັນໄດ້ດ້ວຍການກວດສອບທາງເຕັກນິກ. ນອກເໜືອໄປຈາກການເຊັນຊື່ໃນ commit ແລະການສະແກນ CI ແລ້ວ, ຍັງຈຳເປັນຕ້ອງມີການບໍລິຈາກເພື່ອສະໜັບສະໜູນຜູ້ດູແລໃນ OSS ທີ່ສຳຄັນ, ການຕິດຕາມລະດັບ SLSA, ແລະການນຳໃຊ້ Reproducible Build. ຢ່າງທີສອງ, ໄລບຣາຣີທີ່ບໍ່ໄດ້ເພິ່ງພາອາໄສໂດຍກົງ (ເຊັ່ນ: ໄລບຣາຣີການບີບອັດອ້ອມຂ້າງ libc) ອາດສົ່ງຜົນກະທົບຕໍ່ເສັ້ນທາງ SSH ຂອງເຊີບເວີ AI inference. ຂອບເຂດຂອງ AI BOM ບໍ່ຄວນມີພຽງແຕ່ ML stack ເທົ່ານັ້ນ, ແຕ່ຄວນລວມໄປເຖິງຊັ້ນ OS ຂອງ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ໃຊ້ໃນການບໍລິການຕົວແບບ (model serving) ອີກດ້ວຍ. ຖ້າຫາກກຳນົດຂອບເຂດໂດຍຕັ້ງສົມມຸດຕິຖານວ່າເປັນ "OSS ທີ່ບໍ່ກ່ຽວຂ້ອງກັບການພັດທະນາ AI", ກໍອາດຈະເຮັດໃຫ້ພາດການໂຈມຕີໃນຮູບແບບດຽວກັນກັບ xz utils ໄດ້.

ການລະເມີດຄວາມປອດໄພຂອງແພລດຟອມ SaaS DevOps ບໍ່ຄືກັບການຮົ່ວໄຫຼຂອງຂໍ້ມູນນັກພັດທະນາລາຍບຸກຄົນ, ເນື່ອງຈາກສິດທິໃນການເຂົ້າເຖິງລະຫັດລັບ (Secret Code) ແລະ ການ Deploy ຂອງລູກຄ້າຫຼາຍລາຍຈະໄດ້ຮັບຜົນກະທົບພ້ອມກັນ. ເຫດການທີ່ເກີດຂຶ້ນກັບ Vercel ໃນເດືອນເມສາ 2026 ໄດ້ສະແດງໃຫ້ເຫັນເຖິງຄວາມແຕກຕ່າງໃນການດຳເນີນງານລະຫວ່າງຂໍ້ມູນທີ່ຖືກ encrypted ແລະ ຂໍ້ມູນທີ່ເປັນ Sensitive. ໃນບົດນີ້, ພວກເຮົາຈະມາສະຫຼຸບໂຄງສ້າງຂອງເຫດການດັ່ງກ່າວ ແລະ ບົດຮຽນທີ່ໄດ້ຮັບຈາກການດຳເນີນງານ.

ເຫດການທີ່ Vercel ໄດ້ ເປີດຕົວ ຫຼື Launch ໃນເດືອນເມສາ 2026 ແມ່ນກໍລະນີທີ່ບັນຊີຂອງພະນັກງານຖືກບຸກລຸກຜ່ານເຄື່ອງມື AI ຂອງພາກສ່ວນທີສາມ, ເຮັດໃຫ້ຕົວແປສະພາບແວດລ້ອມ (environment variables) ທີ່ຖືກເຂົ້າລະຫັດ (encrypted) ຂອງລູກຄ້າບາງສ່ວນຖືກເປີດເຜີຍອອກສູ່ພາຍນອກ. Vercel ໄດ້ ເປີດຕົວ ຫຼື Launch ຂໍ້ມູນວ່າ ຕົວແປສະພາບແວດລ້ອມທີ່ມີຄວາມອ່ອນໄຫວ (Sensitive) ຍັງຢູ່ພາຍໃຕ້ການປົກປ້ອງດ້ວຍການເຂົ້າລະຫັດ ແລະ ບໍ່ພົບຫຼັກຖານການເຂົ້າເຖິງ, ການບໍລິການຍັງຄົງດຳເນີນງານຕໍ່ໄປໄດ້ ແລະ ລະບົບຕ່ອງໂສ້ການສະໜອງ (supply chain) ຂອງ npm package ຍັງມີຄວາມປອດໄພ (ທີ່ມາ: Vercel KB Bulletin "April 2026 security incident").

ສິ່ງທີ່ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນທີ່ນີ້ຄື Vercel ມີໂໝດການຈັດເກັບຕົວແປສະພາບແວດລ້ອມຫຼາຍຮູບແບບ:

• encrypted: ເປັນໂໝດມາດຕະຖານທີ່ Vercel ຈະເຂົ້າລະຫັດໄວ້ໃນຂະນະຈັດເກັບ, ເຊິ່ງສາມາດສະແດງຜົນ ແລະ ດຶງຄ່າຜ່ານ Dashboard ຫຼື CLI ໄດ້ງ່າຍ ແຕ່ຕ້ອງເພິ່ງພາການຈັດການກຸນແຈ (key management) ຂອງຝ່າຍ Vercel. ເຊິ່ງຂໍ້ມູນໃນໂໝດນີ້ແມ່ນສ່ວນທີ່ຖືກເປີດເຜີຍໃນເຫດການຄັ້ງນີ້.
• Sensitive: ເປັນໂໝດປົກປ້ອງຂັ້ນສູງທີ່ຈຳກັດແມ້ກະທັ້ງ API ທີ່ໃຊ້ດຶງຄ່າ, ໃຊ້ສຳລັບຂໍ້ມູນລັບທີ່ແທ້ຈິງ (true secret) ເຊັ່ນ: API token ຫຼື OAuth client secret. ເຊິ່ງຂໍ້ມູນໃນໂໝດນີ້ບໍ່ໄດ້ຮັບຜົນກະທົບຈາກເຫດການດັ່ງກ່າວ.

ບົດຮຽນທີ່ໄດ້ຮັບນັ້ນຈະແຈ້ງ: API key, token, ຂໍ້ມູນຢືນຢັນຕົວຕົນຂອງຖານຂໍ້ມູນ ແລະ ກຸນແຈການລົງລາຍເຊັນ (signing key) ຕ້ອງເປັນ Sensitive ເທົ່ານັ້ນ. ຫ້າມນຳໃຊ້ໂໝດ encrypted ແບບເດີມພຽງເພາະ "ມັນປ່ຽນແປງໜ້ອຍກວ່າ" ໂດຍເດັດຂາດ. ການສ້າງກຸນແຈໃໝ່ຄວນຕັ້ງຄ່າເປັນ Sensitive ຕັ້ງແຕ່ຕົ້ນ ແລະ ຄວນປັບປ່ຽນໃຫ້ເປັນ Sensitive ທຸກຄັ້ງທີ່ມີການໝູນວຽນກຸນແຈ (rotation) ເພື່ອໃຫ້ເປັນມາດຕະຖານ. ຫຼັງຈາກເກີດເຫດການນີ້, Vercel ເອງກໍໄດ້ປ່ຽນຄ່າເລີ່ມຕົ້ນຂອງຕົວແປສະພາບແວດລ້ອມໃຫ້ເປັນ Sensitive ໂດຍອັດຕະໂນມັດແລ້ວ.

ຄວາມໜ້າຢ້ານຂອງ SaaS chain ແມ່ນການທີ່ການລະເມີດຄວາມປອດໄພຂອງແພລດຟອມໜຶ່ງ ສາມາດສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ເກີນກວ່າຂອບເຂດຂອງ OAuth scope ທີ່ເຊື່ອມຕໍ່ໄວ້. ຕົວຢ່າງເຊັ່ນ: OAuth ຈາກ Vercel ໄປຫາ GitHub, ການແຈ້ງເຕືອນຈາກ Vercel ໄປຫາ Slack, ຫຼື Telemetry ຈາກ Vercel ໄປຫາ PostHog / Sentry ເປັນຕົ້ນ, ເຊິ່ງ SaaS ມັກຈະມີການຖື API key ຫຼື OAuth token ຂອງກັນແລະກັນໄວ້. ຖ້າຫາກ API key ຂອງ SaaS ອື່ນຖືກບັນຈຸຢູ່ໃນ encrypted env ທີ່ຖືກເປີດຕົວ ຫຼື Launch ອອກມາ, ຄວາມເສຍຫາຍກໍຈະແຜ່ຂະຫຍາຍໄປເຖິງ SaaS ນັ້ນໆດ້ວຍ.

ໃນດ້ານການດຳເນີນງານ ໃຫ້ປະຕິບັດຕາມ 4 ຫຼັກການດັ່ງນີ້:

1. ການຈັດເກັບກຸນແຈແບບ Sensitive ເທົ່ານັ້ນ: ໃຫ້ລົງທະບຽນ secret ເປັນປະເພດ Sensitive ຕັ້ງແຕ່ຕົ້ນ ແລະ ຕັ້ງຄ່າເລີ່ມຕົ້ນຂອງໂຄງການໃໝ່ໃຫ້ເປັນ Sensitive.
2. OAuth ທີ່ມີສິດທິຂັ້ນຕໍ່າສຸດ: ໃຫ້ມອບສິດທິພຽງແຕ່ຂອບເຂດທີ່ຈຳເປັນເທົ່ານັ້ນໃຫ້ແກ່ GitHub Apps ຫຼື OAuth client. ໃຊ້ປະໂຫຍດຈາກການຈຳກັດສິດທິໃນແຕ່ລະ Repository ແລະ ການຄວບຄຸມການອະນຸມັດ App ໃນລະດັບອົງກອນ.
3. ການໝູນວຽນກຸນແຈເປັນໄລຍະ: ກຳນົດຮອບວຽນການໝູນວຽນຕາມລະດັບຄວາມລັບ (ສູງ: 30-90 ວັນ / ກາງ: ເຄິ່ງປີ / ຕ່ຳ: ປະຈຳປີ) ແລະ ເຮັດໃຫ້ເປັນອັດຕະໂນມັດ.
4. ແຜນການໝູນວຽນເມື່ອພົບການລະເມີດ: ຈັດກຽມໄວ້ລ່ວງໜ້າວ່າຈະໝູນວຽນຫຍັງແດ່ໃນທັນທີທີ່ໄດ້ຮັບແຈ້ງການລະເມີດຈາກ SaaS ທີ່ນຳໃຊ້ ແລະ ຈັດເກັບໄວ້ເປັນຄູ່ມື (Rollbook).

ແພລດຟອມຂະໜາດໃຫຍ່ເຊັ່ນ Vercel ຍິ່ງຕ້ອງການການແຍກກຸນແຈ ແລະ ການອອກແບບສິດທິຂັ້ນຕໍ່າສຸດຈາກຝ່າຍຜູ້ໃຊ້. ການສ້າງໂຄງສ້າງທີ່ສາມາດຫຼຸດຜ່ອນຂອບເຂດຄວາມເສຍຫາຍໄດ້ຢ່າງຕັ້ງໜ້າເມື່ອເກີດການລະເມີດຈາກຜູ້ໃຫ້ບໍລິການ (Vendor) ຄືການປ້ອງກັນທີ່ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ.

AI Coding Agent ຊ່ວຍເພີ່ມປະສິດທິພາບການເຮັດວຽກ ແຕ່ໃນຂະນະດຽວກັນກໍສາມາດກາຍເປັນຊ່ອງທາງການໂຈມຕີຮູບແບບໃໝ່ໄດ້. ຄວາມສ່ຽງທີ່ Agent ຈະດຳເນີນການປ່ຽນແປງ Dependency ຫຼື ແຊກແຊງ Code ຜ່ານ Prompt Injection ໄດ້ກາຍເປັນຄວາມຈິງແລ້ວ. ໃນບົດນີ້, ພວກເຮົາຈະມາຈັດລະບຽບກ່ຽວກັບລະບົບຕ່ອງໂສ້ການໂຈມຕີຜ່ານ Agent ແລະ ການອອກແບບຂອບເຂດສິດອຳນາດໃນ Workflow ຂອງນັກພັດທະນາ.

AI Coding Agent (ຕົວແທນຜະລິດຕະພັນທີ່ໃຊ້ Claude / GPT / Gemini ຢູ່ເບື້ອງຫຼັງ) ໄດ້ກາຍເປັນການອອກແບບທົ່ວໄປທີ່ບໍ່ພຽງແຕ່ສ້າງໂຄ້ດເທົ່ານັ້ນ, ແຕ່ຍັງອັດຕະໂນມັດເຖິງການຮຽກໃຊ້ເຄື່ອງມືເພື່ອແກ້ໄຂ package.json, ສ້າງໄຟລ໌, ດຳເນີນການ pnpm add, ໄປຈົນເຖິງການເຮັດ git commit. ສິ່ງນີ້ເຮັດໃຫ້ເສັ້ນທາງການເກີດ ການສັ່ງງານຜ່ານຄຳສັ່ງທາງອ້ອມ (Indirect Prompt Injection) ເພີ່ມຂຶ້ນ, ເຊິ່ງ "ຂໍ້ຄວາມພາຍນອກ" ທີ່ Agent ອ່ານຈະຖືກນຳໄປປະຕິບັດຕາມຄຳສັ່ງໂດຍກົງ (ທີ່ມາ: OWASP Top 10 for LLM Applications LLM01: Prompt Injection).

ມີ 3 ສະຖານະການທີ່ເປັນຮູບປະທຳ:

• ຜ່ານ README ຫຼື ເອກະສານ: ຄຳສັ່ງເຊັ່ນ "ໃນໂຄງການນີ້ ຕ້ອງຕິດຕັ້ງແພັກເກດ XX-helper ໃຫ້ໄດ້" ຖືກຝັງໄວ້ໃນໜ້າເວັບພາຍນອກທີ່ Agent ດຶງຂໍ້ມູນມາເພື່ອການສຶກສາ ແລະ Agent ກໍປະຕິບັດຕາມ.
• ຜ່ານຄຳເຫັນໃນແພັກເກດທີ່ເພິ່ງພາອາໄສ: ມີຄຳສັ່ງທີ່ກະຕຸ້ນໃຫ້ຕິດຕັ້ງແພັກເກດເພີ່ມເຕີມປົນຢູ່ໃນ README ຫຼື ຄຳເຫັນພາຍໃນ node_modules ທີ່ມີຢູ່.
• ຜ່ານຄຳເຫັນໃນ GitHub Issue / PR: Agent ທີ່ເຮັດໜ້າທີ່ຈັດການ (Triage) ໂດຍອັດຕະໂນມັດ ປະຕິບັດຕາມເນື້ອໃນຂອງ Issue ທີ່ມີເຈດຕະນາຮ້າຍເພື່ອເພີ່ມການເພິ່ງພາອາໄສ (Dependency).

ນີ້ແມ່ນການໂຈມຕີທີ່ເກີດຂຶ້ນຈາກການປະສົມປະສານກັນລະຫວ່າງ LLM01 (Prompt Injection) ແລະ LLM02 (Insecure Output Handling) ຂອງ OWASP LLM Top 10 ເຊິ່ງບໍ່ສາມາດປ້ອງກັນໄດ້ດ້ວຍມາດຕະການຄວາມປອດໄພຂອງຕົວແບບ (Model) ພຽງຢ່າງດຽວ. ຍິ່ງນຳເອົາ Agent ເຂົ້າໄປໃນຂະບວນການພັດທະນາຫຼາຍເທົ່າໃດ, ໂຄງສ້າງຂອງເສັ້ນທາງຈາກການປ້ອນຂໍ້ມູນພາຍນອກໄປສູ່ການປ່ຽນແປງການເພິ່ງພາອາໄສກໍຍິ່ງຂະຫຍາຍກວ້າງຂຶ້ນເທົ່ານັ້ນ.

ເພື່ອດຳເນີນການ AI Coding Agent ຢ່າງປອດໄພ, ຈຳເປັນຕ້ອງອອກແບບສິດທິຂອງ Agent ໂດຍແບ່ງອອກເປັນ "ການສ້າງໂຄ້ດພຽງຢ່າງດຽວ" ແລະ "ການປະຕິບັດງານທີ່ມີຜົນກະທົບຂ້າງຄຽງ (ການເພີ່ມແພັກເກດ, ການຄອມມິດ, ການເດັບພອຍ)". ຮູບແບບການຈັດຕັ້ງປະຕິບັດມີ 4 ຢ່າງທີ່ຄວນນຳມາປະສົມປະສານກັນດັ່ງນີ້:

1. ການກຳນົດຂອບເຂດການຂຽນໃຫ້ຊັດເຈນ: ຈຳກັດການເຮັດວຽກຂອງ Agent ໄວ້ພຽງແຕ່ໃນ git feature branch + temporary directory ເທົ່ານັ້ນ. ດຳເນີນການໃນສະພາບແວດລ້ອມທີ່ບໍ່ສາມາດເຂົ້າເຖິງ branch ຫຼັກ ຫຼື ຕົວແປສະພາບແວດລ້ອມ (Environment Variables) ຂອງລະບົບຫຼັກໄດ້.
2. ການອະນຸມັດໂດຍມະນຸດສຳລັບຜົນກະທົບຂ້າງຄຽງ (HITL): ກຳນົດຂັ້ນຕອນການເພີ່ມ Dependency ເຊັ່ນ pnpm add / npm install / pip install ໃຫ້ເປັນແບບ 2 ຂັ້ນຕອນ ຄື Agent ເປັນຜູ້ສະເໜີ ແລະ ນັກພັດທະນາເປັນຜູ້ອະນຸມັດ. ໃນ CI ກໍຕ້ອງບັງຄັບໃຊ້ --frozen-lockfile ແລະ ບັງຄັບໃຫ້ມີການກວດສອບ (Review) ທຸກຄັ້ງທີ່ມີການເພີ່ມ Dependency ໃໝ່.
3. Allowlist / Denylist ສຳລັບການເພີ່ມ Dependency: ສ້າງກົນໄກທີ່ອະນຸຍາດໃຫ້ Agent ເພີ່ມໄດ້ສະເພາະແພັກເກດທີ່ຢູ່ໃນ White list ຂອງບໍລິສັດເທົ່ານັ້ນ. ການເພີ່ມແພັກເກດໃໝ່ຕ້ອງຜ່ານການກວດສອບດ້ານ Security ຢ່າງຈຳເປັນ.
4. ການແຍກສິດທິຂອງ MCP Server: ແຍກ MCP Server ທີ່ສົ່ງໃຫ້ Agent ອອກເປັນ "ແບບອ່ານຢ່າງດຽວ (Read-only)" ແລະ "ແບບຂຽນໄດ້ (Writable)" ໂດຍໃຫ້ຄ່າເລີ່ມຕົ້ນເປັນແບບອ່ານຢ່າງດຽວ. ສຳລັບ MCP ທີ່ຂຽນໄດ້ ຕ້ອງມີການກຳນົດ OAuth scope ໃຫ້ໜ້ອຍທີ່ສຸດ.

ສິ່ງເຫຼົ່ານີ້ອາດຈະຕ້ອງມີ ການແລກປ່ຽນ ຫຼື Trade-off ກັບປະສິດທິພາບການເຮັດວຽກບາງສ່ວນ ແຕ່ເປັນການອອກແບບທີ່ມີຄວາມຈຳເປັນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ເມື່ອ AI Coding Agent ຖືກນຳມາໃຊ້ໃນອົງກອນຂະໜາດໃຫຍ່. ການເປີດໃຊ້ງານ Agent ຢ່າງເຕັມຮູບແບບໂດຍບໍ່ມີການຄວບຄຸມໃນລະບົບ Supply Chain ຈະເຮັດໃຫ້ເກີດຄວາມສ່ຽງໃນໂຄງສ້າງດຽວກັນກັບການອ້າງອີງ Third-party Action ເຊັ່ນ tj-actions ໂດຍບໍ່ມີການລະບຸ SHA pin.

ການປ້ອງກັນລະບົບຕ່ອງໂສ້ການສະໜອງ (Supply Chain) ຂອງການພັດທະນາ AI ບໍ່ສາມາດເຮັດໃຫ້ສຳເລັດໄດ້ດ້ວຍເຄື່ອງມືພຽງຢ່າງດຽວ. ການປ້ອງກັນແບບຫຼາຍຊັ້ນໂດຍການປະສົມປະສານລະຫວ່າງ AI BOM, ການກວດສອບ Model Card, OAuth ສິດທິຂັ້ນຕໍ່າສຸດ, ການຈັດການ Sensitive Secret, ການແຍກ CI/CD ແລະ ບັນທຶກການກວດສອບ (Audit Trail) ແມ່ນວິທີທີ່ເປັນຈິງທີ່ສຸດ. ໃນບົດນີ້, ພວກເຮົາຈະຈັດກຸ່ມຮູບແບບການນຳໄປໃຊ້ງານອອກເປັນ 2 ກຸ່ມ.

AI BOM (AI Bill of Materials) ແມ່ນການຂະຫຍາຍ SBOM ແບບດັ້ງເດີມໃຫ້ກວມເອົາອົງປະກອບຂອງ AI (ນ້ຳໜັກຂອງຕົວແບບ / ຊຸດຂໍ້ມູນ / ຕົວປະມວນຜົນການອ້າງອີງ / ຂໍ້ມູນການປະເມີນຜົນ). ມາດຕະຖານ ຫຼື Specification ຂອງ CycloneDX AI/ML BOM, OWASP AI Exchange, ແລະ SPDX 3.0 ML profile ກຳລັງຖືກພັດທະນາໃຫ້ເປັນມາດຕະຖານອຸດສາຫະກຳ (ທີ່ມາ: CycloneDX Specification 1.5 ຂຶ້ນໄປ, OWASP AI Exchange, SPDX 3.0).

ຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດມີ 4 ຂັ້ນຕອນດັ່ງນີ້:

1. ການສຳຫຼວດອົງປະກອບ: ເຮັດລາຍການຕົວແບບທີ່ເປີດໃຫ້ໃຊ້ງານ, ຕົວແບບຕົ້ນສະບັບທີ່ນຳມາ fine-tune, ຊຸດຂໍ້ມູນ, ເຊີບເວີປະມວນຜົນ, Vector DB, ແລະ ເຄື່ອງມື AI ທີ່ຝັງໄວ້.
2. ການເກັບກຳຂໍ້ມູນ Metadata: ບັນທຶກຜູ້ໃຫ້ບໍລິການ (provider), ໃບອະນຸຍາດ (license), ເວີຊັນ (commit hash), ຮູບແບບ (Pickle / safetensors), ແລະ ສະຖານະການກວດສອບຂອງແຕ່ລະຕົວແບບ.
3. ການສົ່ງອອກໃນຮູບແບບ CycloneDX-AI: ຝັງການສ້າງອັດຕະໂນມັດເຂົ້າໃນຂະບວນການ ຫຼື Pipeline ການສ້າງຊອບແວ ແລະ ແນບ AI BOM ໄປກັບຜົນງານທີ່ປ່ອຍອອກມາ (release artifacts).
4. ຂັ້ນຕອນການກວດສອບ Model Card: ໃນເວລາທີ່ນຳຕົວແບບເຂົ້າມາ, ໃຫ້ບັງຄັບໃຊ້ 4 ລາຍການຜ່ານ CI ຄື: ການດຶງຂໍ້ມູນຈາກບັນຊີທາງການຂອງຜູ້ໃຫ້ບໍລິການ, ຄວາມເຂົ້າກັນໄດ້ຂອງໃບອະນຸຍາດ, ການຜ່ານການກວດສອບດ້ວຍ Pickle scanner, ແລະ ການແນະນຳໃຫ້ໃຊ້ safetensors.

ການຈັດຕັ້ງປະຕິບັດ AI BOM ຈະຊ່ວຍໃຫ້ສາມາດກວດສອບຍ້ອນຫຼັງຈາກ BOM ໄດ້ວ່າ "ບໍລິສັດໄດ້ຮັບຜົນກະທົບຫຼືບໍ່" ໃນເວລາທີ່ມີການເປີດເຜີຍກ່ຽວກັບການປົນເປື້ອນຂອງຕົວແບບ ຫຼື ການປ່ຽນແປງການເພິ່ງພາອາໄສໃໝ່ໆ. ເຊິ່ງຈະຊ່ວຍຫຼຸດຜ່ອນເວລາໃນການຕອບໂຕ້ເຫດການສຸກເສີນໃນເບື້ອງຕົ້ນໄດ້ຢ່າງຫຼວງຫຼາຍ.

ເພື່ອເປັນການປ້ອງກັນອີກຊັ້ນໜຶ່ງ, ໃຫ້ຄວບຄຸມ SaaS chain ແລະ ຂະບວນການ ຫຼື Pipeline ການດຳເນີນງານດ້ວຍ 4 ຈຸດດັ່ງນີ້:

1. OAuth ທີ່ມີສິດທິຂັ້ນຕໍ່າສຸດ: ຈຳກັດຂອບເຂດຂອງ GitHub App / Slack App / Vercel API keys ແລະ ອື່ນໆ ໃຫ້ເຫຼືອພຽງແຕ່ສິ່ງທີ່ຈຳເປັນເທົ່ານັ້ນ. ເປີດໃຊ້ການຄວບຄຸມການອະນຸມັດ App ໃນລະດັບອົງກອນ ເພື່ອບໍ່ໃຫ້ຜູ້ພັດທະນາແຕ່ລະຄົນສາມາດອະນຸມັດ OAuth ໃນວົງກວ້າງໄດ້.
2. ການຈັດການ Sensitive Secret: ລົງທະບຽນ API keys ໃນ SaaS ຫຼັກໆ ເຊັ່ນ Vercel / Cloudflare / Supabase ໂດຍໃຊ້ປະເພດ Sensitive. ຖ້າສະພາບແວດລ້ອມ development ຈຳເປັນຕ້ອງມີການປົກປິດຂໍ້ມູນ ກໍໃຫ້ແຍກອອກເປັນລາຍການຕ່າງຫາກ. ໃນເວລາໝູນວຽນ (Rotation), ໃຫ້ສ້າງໃໝ່ໂດຍຍັງຄົງເປັນ Sensitive ແລະ ຍົກເລີກການໃຊ້ງານກະແຈເກົ່າ.
3. ການແຍກ CI/CD: ຈຳກັດ Secret ທີ່ສາມາດໃຊ້ໄດ້ໃນແຕ່ລະ Build job (ຕົວຢ່າງ: ມີພຽງແຕ່ Production deploy job ເທົ່ານັ້ນທີ່ສາມາດອ້າງອີງ Prod key ໄດ້, PR job ໃຫ້ອ້າງອີງໄດ້ສະເພາະ Public mirror ເທົ່ານັ້ນ). ໃນ GitHub Actions, ໃຫ້ໃຊ້ປະໂຫຍດຈາກ Secret ຕາມ Environment + Required reviewer. ສຳລັບ Third-party Action ຕ້ອງມີການກຳນົດ SHA pin ສະເໝີ.
4. ບັນທຶກການກວດສອບ (Audit Trail): ລວມ Audit Log ຈາກຝັ່ງ SaaS ເຂົ້າສູ່ SIEM / ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ການເກັບບັນທຶກ ເພື່ອເຮັດໃຫ້ການສ້າງ API key, ການໃຫ້ສິດ OAuth, ແລະ ການປ່ຽນແປງ Environment variable ສາມາດເບິ່ງເຫັນໄດ້. ຮັກສາສະຖານະໃຫ້ສາມາດສ້າງຄືນໃໝ່ໄດ້ທັນທີວ່າ "ໃຜ, ເວລາໃດ, ໄດ້ແຕະຕ້ອງຫຍັງ" ເມື່ອເກີດເຫດການບໍ່ຄາດຝັນ.

4 ຈຸດນີ້ຈະເປັນຕົວຕັດໄຟສຸດທ້າຍທີ່ປ້ອງກັນບໍ່ໃຫ້ຄວາມເສຍຫາຍລາມໄປທົ່ວອົງກອນ ເຖິງແມ່ນວ່າ SaaS ຕົວໃດຕົວໜຶ່ງຈະຖືກບຸກລຸກກໍຕາມ. ສິ່ງສຳຄັນແມ່ນການເຮັດໃຫ້ສິ່ງເຫຼົ່ານີ້ກາຍເປັນກົດລະບຽບການດຳເນີນງານຮ່ວມກັນຂອງອົງກອນ ບໍ່ແມ່ນມາດຕະການສະເພາະຂອງ Vendor.

ຕ່ອງໂສ້ການສະໜອງ (Supply chain) ໃນການພັດທະນາ AI ໄດ້ຂະຫຍາຍຕົວຈາກ 2 ຊັ້ນແບບດັ້ງເດີມ ຄື "Code + 依存パッケージ" ມາເປັນ 4 ຊັ້ນ ຄື "ເປີດຕົວ ຫຼື Launch ໂມເດວ + 依存パッケージ + SaaS DevOps + AI ເອເຈນ". ເຫດການ Pickle arbitrary code execution ຂອງ Hugging Face, ການປອມແປງຂອງ tj-actions, ປະຕູຫຼັງ (Backdoor) ຫຼາຍຊັ້ນຂອງ xz utils, ແລະ ເຫດການຂອງ Vercel ໃນເດືອນເມສາ 2026 ລ້ວນແລ້ວແຕ່ເປັນຜົນມາຈາກການທີ່ຈຸດໃດໜຶ່ງໃນຕ່ອງໂສ້ການສະໜອງທີ່ຂະຫຍາຍຕົວນີ້ຖືກບຸກລຸກ.

ການປ້ອງກັນບໍ່ສາມາດສຳເລັດໄດ້ດ້ວຍການແກ້ໄຂພຽງຢ່າງດຽວ. ຖ້າຈັດລະບຽບມາດຕະການຕາມແຕ່ລະເສັ້ນທາງຈະໄດ້ດັ່ງນີ້:

• ເສັ້ນທາງໂມເດວ (Model path): ການຍ້າຍໄປໃຊ້ safetensors, Pickle scanner, ການກວດສອບ Model card
• ເສັ້ນທາງການເພິ່ງພາອາໄສ (Dependency path): SHA pin, SBOM, Reproducible Build, ການຕິດຕາມຊັ້ນການເພິ່ງພາອາໄສທີ່ເລິກເຊິ່ງ
• ເສັ້ນທາງ SaaS DevOps: ການຈັດເກັບຂໍ້ມູນ Sensitive ແບບຈຳກັດ, OAuth ທີ່ມີສິດທິຂັ້ນຕໍ່າສຸດ, ການລວມ Audit Log
• ເສັ້ນທາງ AI ເອເຈນ (AI agent path): ຂອບເຂດການຂຽນຂໍ້ມູນ, HITL (Human-in-the-loop), Allowlist, ການແຍກສິດທິ MCP

ການຈັດປະເພດຕາມກອບ 4 ເສັ້ນທາງໃນບົດຄວາມນີ້, ການລະບຸຊັ້ນທີ່ຍັງຂາດຫາຍໄປໃນບໍລິສັດຂອງທ່ານ ແລະ ການຕື່ມເຕັມສ່ວນນັ້ນ ແມ່ນທາງລັດໃນການອັບເດດການພັດທະນາ AI ຂອງອົງກອນໃຫ້ເປັນໄປຕາມມາດຕະຖານ ຫຼື Specification ປີ 2026. ບໍລິສັດຂອງພວກເຮົາໄດ້ນຳເອົາຈຸດກວດສອບໃນບົດຄວາມນີ້ໄປພັດທະນາເປັນແມ່ແບບການກວດສອບພາຍໃນສຳລັບອົງກອນພັດທະນາ AI, ພ້ອມທັງນຳໄປປະຕິບັດຄວບຄູ່ກັບປຶ້ມຄູ່ມືການຕອບໂຕ້ທັນທີເມື່ອໄດ້ຮັບແຈ້ງການບຸກລຸກຈາກຜູ້ໃຫ້ບໍລິການ (Vendor).