ການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ (Supply Chain Attack)

ການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ (Supply Chain Attack) ແມ່ນຫຍັງ

ການພັດທະນາຊອບແວໃນປັດຈຸບັນບໍ່ໄດ້ເຮັດໂດຍບໍລິສັດດຽວອີກຕໍ່ໄປ. ບໍ່ວ່າຈະເປັນ OSS library, CI/CD pipeline, package registry, ຫຼື ໃບຢັ້ງຢືນການເຊັນລະຫັດ (code signing certificate) — ເສັ້ນທາງທັງໝົດນັບແຕ່ຜະລິດຕະພັນຖືກສ້າງຂຶ້ນຈົນເຖິງມືຜູ້ໃຊ້ ຄື "ລະບົບຕ່ອງໂສ້ການສະໜອງ" (Supply Chain) ແລະ ຜູ້ໂຈມຕີຈະແນເປົ້າໝາຍໄປຍັງຈຸດທີ່ມີການປ້ອງກັນອ່ອນແອທີ່ສຸດໃນລະບົບນັ້ນ. ຈຸດທີ່ແຕກຕ່າງຈາກການໂຈມຕີແບບດັ້ງເດີມຢ່າງສິ້ນເຊີງຄື ອົງກອນທີ່ຕົກເປັນເຫຍື່ອບໍ່ໄດ້ຖືກບຸກລຸກໂດຍກົງ ແຕ່ຖືກໃຊ້ເປັນທາງຜ່ານຜ່ານຜູ້ໃຫ້ບໍລິການຕົ້ນນ້ຳທີ່ພວກເຂົາໄວ້ວາງໃຈ.

ເປັນຫຍັງມັນຈຶ່ງຮ້າຍແຮງ

ເນື່ອງຈາກມັນຜ່ານຊ່ອງທາງການແຈກຢາຍທີ່ຖືກຕ້ອງຕາມກົດໝາຍ, ຄວາມຍາກໃນການກວດພົບຈຶ່ງແຕກຕ່າງຈາກຊ່ອງໂຫວ່ຂອງ Web Application ທົ່ວໄປທີ່ OWASP ໄດ້ລະບຸໄວ້ຢ່າງຫຼວງຫຼາຍ. Backdoor ທີ່ແຝງມາໃນການອັບເດດທີ່ມີການເຊັນຮັບຮອງ (signed update) ສາມາດຫຼົບຫຼີກການປ້ອງກັນຂອງ Endpoint ໄດ້ ແລະ ບໍ່ແມ່ນເລື່ອງແປກທີ່ອາດຕ້ອງໃຊ້ເວລາຫຼາຍເດືອນກວ່າຈະກວດພົບ. ໃນ Public registry ເຊັ່ນ npm ຫຼື PyPI, ການເຮັດ Typosquatting (ການເຜີຍແຜ່ Package ທີ່ເປັນອັນຕະລາຍໂດຍໃຊ້ຊື່ຄ້າຍຄືກັບ Package ທີ່ຖືກຕ້ອງ) ໄດ້ຖືກລາຍງານຊ້ຳແລ້ວຊ້ຳອີກ. Library ທີ່ປົນເປື້ອນພຽງໜຶ່ງອັນສາມາດສົ່ງຜົນກະທົບຕໍ່ໂຄງການຫຼາຍພັນໂຄງການ — ຜົນກະທົບແບບທະວີຄູນນີ້ເອງຄືໄພຂົ່ມຂູ່ທີ່ໃຫຍ່ທີ່ສຸດຂອງການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ.

ແນວທາງການປ້ອງກັນ

ໃນບໍລິບົດຂອງ DevSecOps, ຍຸດທະສາດພື້ນຖານຄືການນຳເອົາການກວດສອບຄວາມສຳພັນ (dependency) ເຂົ້າໄປໃນຂັ້ນຕອນການພັດທະນາຕັ້ງແຕ່ຕົ້ນ ຕາມຫຼັກການ Shift Left. ໂດຍສະເພາະ, ແນວທາງຕໍ່ໄປນີ້ກຳລັງກາຍເປັນມາດຕະຖານໃນການປະຕິບັດງານ:

• ການສ້າງ ແລະ ຈັດການ SBOM (Software Bill of Materials): ລວບລວມລາຍການຄວາມສຳພັນທັງໝົດທີ່ຢູ່ໃນຜະລິດຕະພັນ ແລະ ກວດສອບກັບຖານຂໍ້ມູນຊ່ອງໂຫວ່ຢ່າງຕໍ່ເນື່ອງ
• ການກຳນົດເວີຊັນ (Pinning) ແລະ ການກວດສອບ Hash: ກຳນົດເວີຊັນຂອງ Dependency ດ້ວຍ Lock file ແລະ ກວດສອບ Checksum ໃນຂະນະດາວໂຫຼດ
• ການອອກແບບ CI/CD ດ້ວຍສິດທິຕໍ່າສຸດ (Least Privilege): ບໍ່ໃຫ້ສິດທິເກີນຄວາມຈຳເປັນແກ່ Build pipeline. ແນວຄິດ Zero Trust Network Access ບໍ່ໄດ້ໃຊ້ກັບເຄືອຂ່າຍເທົ່ານັ້ນ ແຕ່ຍັງໃຊ້ກັບສະພາບແວດລ້ອມໃນການ Build ອີກດ້ວຍ
• ການອັດຕະໂນມັດການກວດສອບລາຍເຊັນ (Signature Verification): ກວດສອບລາຍເຊັນຂອງ Commit ຫຼື Artifact ໂດຍອັດຕະໂນມັດໃນ CI ເພື່ອສະກັດກັ້ນໂຄດທີ່ຖືກດັດແກ້ກ່ອນທີ່ຈະມີການ Merge

ຈາກປະສົບການຂອງຜູ້ຂຽນ, ການນຳໃຊ້ SBOM ຊ່ວຍແກ້ໄຂບັນຫາ "ບໍ່ຮູ້ວ່າໃນນັ້ນມີຫຍັງແດ່" ເຊິ່ງເຮັດໃຫ້ການລະບຸຂອບເຂດຜົນກະທົບເມື່ອເກີດເຫດການ (Incident) ໄວຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ຄວາມສ່ຽງໃນການພັດທະນາ AI

ໃນລະບົບທີ່ນຳໃຊ້ LLM, ໄຟລ໌ນ້ຳໜັກຂອງ Model (weight file) ແລະ ຂໍ້ມູນທີ່ໃຊ້ໃນການຝຶກສອນ (training data) ກໍຖືເປັນສ່ວນໜຶ່ງຂອງລະບົບຕ່ອງໂສ້ການສະໜອງເຊັ່ນກັນ. Model ທີ່ຜ່ານການ Fine-tuning ດ້ວຍຊຸດຂໍ້ມູນທີ່ປົນເປື້ອນ ອາດສ້າງຜົນລັດທີ່ບໍ່ຕັ້ງໃຈຜ່ານເສັ້ນທາງທີ່ແຕກຕ່າງຈາກ Prompt Injection. ການກວດສອບຄວາມໜ້າເຊື່ອຖືຂອງ AI Supply Chain ນັ້ນຍາກກວ່າຊອບແວແບບດັ້ງເດີມຫຼາຍ ແລະ ຍັງຢູ່ໃນຂັ້ນຕອນທີ່ທັງອຸດສາຫະກຳກຳລັງຊອກຫາວິທີຮັບມື.