
Claude Mythos Preview ແລະ Project Glasswing ໄດ້ສະແດງໃຫ້ເຫັນເຖິງການມາເຖິງຂອງຍຸກທີ່ AI ສາມາດຄົ້ນພົບ "ຊ່ອງໂຫວ່ຂອງຊອບແວທີ່ຝັງຕົວມາຢ່າງຍາວນານ" ແລະສ້າງລະຫັດໂຈມຕີ (exploit) ຂຶ້ນມາໄດ້ດ້ວຍຕົນເອງ. ບໍ່ວ່າຈະເປັນບັກທີ່ນອນນິ້ງຢູ່ໃນ Network Stack ຂອງ OpenBSD ມາຕະຫຼອດ 27 ປີ, ບັກອາຍຸ 16 ປີທີ່ລອດພົ້ນຈາກການເຮັດ Fuzzing ອັດຕະໂນມັດຫຼາຍກວ່າ 5 ລ້ານຄັ້ງຂອງ FFmpeg, ຫຼືການປະຕິບັດລະຫັດທາງໄກ (Remote Code Execution) ໃນ NFS ຂອງ FreeBSD (CVE-2026-4747), ພື້ນທີ່ທີ່ສ່ຽງຕໍ່ການຖືກໂຈມຕີທີ່ມະນຸດບໍ່ສາມາດຄົ້ນພົບໄດ້ນັ້ນ ໄດ້ຖືກເປີດຕົວ ຫຼື Launch ອອກມາເທື່ອລະຈຸດ.
ໃນບົດຄວາມນີ້, ອີງຕາມການປະກາດຢ່າງເປັນທາງການຂອງ Anthropic (red.anthropic.com, anthropic.com/glasswing) ແລະ ການປະເມີນຈາກຜູ້ຊ່ຽວຊານຢ່າງ Bruce Schneier, ພວກເຮົາຈະມາສະຫຼຸບວ່າ Mythos ແລະ Glasswing ຈະປ່ຽນແປງສິ່ງໃດແດ່. ພ້ອມກັນນັ້ນ, ພວກເຮົາຈະສະຫຼຸບ 5 ການປະຕິບັດທີ່ບໍລິສັດຂອງພວກເຮົາແນະນຳໃຫ້ກັບທີມ DevSecOps ຂອງວິສາຫະກິດຂະໜາດກາງ ໃນຮູບແບບລາຍການກວດສອບ (Checklist). ເຖິງແມ່ນວ່າ Mythos ຈະຍັງຢູ່ໃນການເປີດຕົວແບບຈຳກັດ, ແຕ່ສິ່ງທີ່ອົງກອນສາມາດເຮັດໄດ້ດ້ວຍໂມເດວໃນປັດຈຸບັນນັ້ນມີຫຼາຍຢ່າງແລ້ວ. ພວກເຮົາໄດ້ກ້າວເຂົ້າສູ່ຍຸກທີ່ການ "ລໍຖ້າໃຫ້ເປີດຕົວແລ້ວຄ່ອຍຄິດ" ຈະເຮັດໃຫ້ທ່ານຫຼ້າຫຼັງຢ່າງແນ່ນອນ.
Claude Mythos Preview ແມ່ນໂມເດວແບບຈຳກັດທີ່ Anthropic ວາງຕຳແໜ່ງໃຫ້ເປັນຟຣອນເທຍໂມເດວ (Frontier Model) ທີ່ເນັ້ນດ້ານຄວາມປອດໄພທາງໄຊເບີໂດຍສະເພາະ. ມັນບໍ່ແມ່ນໂມເດວສ້າງໂຄ້ດແບບທົ່ວໄປ ແຕ່ສາມາດຈັດການວົງຈອນການບຸກໂຈມຕີ ແລະ ປ້ອງກັນໄດ້ຢ່າງອັດຕະໂນມັດ ຕັ້ງແຕ່ການຄົ້ນຫາຊ່ອງໂຫວ່ຂອງຊອບແວ, ການສ້າງລະຫັດໂຈມຕີ (Exploit), ໄປຈົນເຖິງການສ້າງແພັດແກ້ໄຂ.
ບລັອກການຄົ້ນຄວ້າຂອງທີມ Red Team ຈາກ Anthropic ທີ່ red.anthropic.com ໄດ້ລະບຸວ່າ Mythos Preview ມີລະດັບຄວາມສາມາດ "ເໜືອກວ່າຜູ້ຊ່ຽວຊານທີ່ເປັນມະນຸດສ່ວນໃຫຍ່". ເຖິງວ່າຈະບໍ່ມີແຜນເປີດຕົວ ຫຼື Launch ຕໍ່ສາທາລະນະ ແຕ່ມີລາຍງານວ່າຈະໃຫ້ບໍລິການແກ່ຄູ່ຮ່ວມງານທີ່ຖືກຄັດເລືອກໃນລາຄາ 25 ໂດລາ ຕໍ່ 1 ລ້ານ Input Token ແລະ 125 ໂດລາ ສຳລັບ Output.
ໂມເດວນີ້ຖືກນຳໃຊ້ເປັນເຄື່ອງມື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງ Project Glasswing ເພື່ອກວດສອບຊອບແວທີ່ສຳຄັນທົ່ວໂລກໃນລັກສະນະ "ກັນໄວ້ດີກວ່າແກ້". ສຳລັບຝ່າຍປ້ອງກັນເຊັ່ນບໍລິສັດຂອງພວກເຮົາ, ນີ້ຖືເປັນເງື່ອນໄຂເບື້ອງຕົ້ນທີ່ຄວນຮັບຮູ້ໄວ້ເມື່ອພິຈາລະນາເຖິງຄວາມຕໍ່ເນື່ອງທາງທຸລະກິດ.
ແບບຈຳລອງທົ່ວໄປທີ່ຜ່ານມາແມ່ນມີຄວາມໂດດເດັ່ນໃນການສ້າງໂຄ້ດ ແລະ ການກວດຫາຮູບແບບຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກກັນດີ, ແຕ່ຍັງບໍ່ສາມາດທຽບເທົ່າກັບນັກຄົ້ນຄວ້າມະນຸດໄດ້ໃນດ້ານການສ້າງລະບົບໂຈມຕີ (Exploit chain) ທີ່ຊັບຊ້ອນແບບອັດຕະໂນມັດ ຫຼື ການຄົ້ນຫາບັກດ້ານຄວາມປອດໄພຂອງໜ່ວຍຄວາມຈຳລະດັບຕ່ຳໂດຍອັດຕະໂນມັດ.
ຄວາມພິເສດຂອງ Mythos Preview ແມ່ນສາມາດດຳເນີນການແບບອັດຕະໂນມັດໄດ້ຫຼັງຈາກ "ການປ້ອນຄຳສັ່ງ (Prompt) ເບື້ອງຕົ້ນພຽງຄັ້ງດຽວ" ເຊິ່ງກວມເອົາຕັ້ງແຕ່: (1) ການຄົ້ນຫາບັກຈາກ Source code, (2) ການສ້າງລະບົບໂຈມຕີທີ່ເຮັດວຽກໄດ້ຢ່າງສົມບູນ, (3) ການວິເຄາະວິສະວະກຳປີ້ນກັບ (Reverse engineering) ຂອງຊອບແວປິດ (Closed source), ຈົນເຖິງ (4) ການສ້າງແພັດແກ້ໄຂ. Anthropic ໄດ້ລະບຸຢ່າງເປັນທາງການວ່າເປັນການເຮັດວຽກ "fully autonomously" ແລະ ລາຍງານວ່າສາມາດຄົ້ນຫາ ແລະ ໃຊ້ປະໂຫຍດຈາກຊ່ອງໂຫວ່ Remote code execution ທີ່ມີມາເຖິງ 17 ປີໄດ້ໂດຍບໍ່ຕ້ອງມີມະນຸດເຂົ້າມາແຊກແຊງ.
ນີ້ຄືການປ່ຽນແປງທາງດ້ານຄຸນນະພາບໃນໂລກຂອງການຄົ້ນຫາຊ່ອງໂຫວ່. SAST (Static Analysis) ແລະ DAST (Dynamic Analysis) ແບບດັ້ງເດີມນັ້ນອາໄສການຈັບຄູ່ຮູບແບບ ແລະ ການເຮັດ Input fuzzing, ເຮັດໃຫ້ສິ່ງທີ່ສາມາດຄົ້ນຫາໄດ້ຖືກຈຳກັດຢູ່ພຽງແຕ່ "ພື້ນທີ່ການໂຈມຕີທີ່ຜູ້ອອກແບບຄາດຄິດໄວ້ເທົ່ານັ້ນ". Mythos ເຂົ້າໃຈຄວາມໝາຍຂອງ Source code ທັງໝົດ ແລະ ສາມາດສ້າງເສັ້ນທາງການໂຈມຕີທີ່ແມ້ແຕ່ນັກພັດທະນາເອງກໍຍັງບໍ່ທັນຮູ້ຕົວ. ນີ້ຄືເຫດຜົນທີ່ພວກເຮົາອະທິບາຍໃຫ້ລູກຄ້າຟັງວ່າ "AI Code Review ບໍ່ແມ່ນການທົດແທນເຄື່ອງມືທີ່ມີຢູ່ແລ້ວ, ແຕ່ເປັນຊັ້ນການກວດຫາໃນອີກມິຕິໜຶ່ງ".
ອີງຕາມການເປີດຕົວ ຫຼື Launch ຂອງ Anthropic, ໃນການທົດສອບ CyberGym ເຊິ່ງເປັນມາດຕະຖານ ຫຼື Specification ທີ່ວັດແທກທັງການຄົ້ນຫາຊ່ອງໂຫວ່ ແລະ ການສ້າງລະຫັດໂຈມຕີ (Exploit) ຈາກມຸມມອງຂອງຜູ້ໂຈມຕີ ເຊິ່ງມີລັກສະນະແຕກຕ່າງຈາກ SWE-bench ທີ່ວັດແທກຄວາມສາມາດດ້ານການຂຽນໂຄ້ດ, ຕົວແບບ Claude ທົ່ວໄປສາມາດບັນທຶກຄະແນນໄດ້ 66.6% ໃນຂະນະທີ່ Mythos Preview ສາມາດບັນລຸໄດ້ເຖິງ 83.1%.
ໃນການປະເມີນຜົນໂດຍໃຊ້ OSS-Fuzz, ຕົວແບບທົ່ວໄປສາມາດຄົ້ນຫາຂໍ້ຜິດພາດ (Crash) ໄດ້ 150-175 ລາຍການໃນ Tier 1-2, ໃນຂະນະທີ່ Mythos Preview ສາມາດບັນທຶກການຄົ້ນຫາຂໍ້ຜິດພາດໄດ້ເຖິງ 595 ລາຍການໃນ Tier ດຽວກັນ. ຍິ່ງໄປກວ່ານັ້ນ, ມັນຍັງປະສົບຜົນສຳເລັດໃນ Tier 5 ເຊິ່ງເປັນລະດັບຄວາມຍາກສູງສຸດ (ການຄວບຄຸມ Control Flow ຢ່າງສົມບູນ) ໄດ້ເຖິງ 10 ເປົ້າໝາຍ, ເຊິ່ງໝາຍເຖິງການກ້າວກະໂດດຈາກລະດັບ "ເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດ" ໄປສູ່ລະດັບ "ການປະຕິບັດລະຫັດຕາມໃຈມັກ (Arbitrary Code Execution)".
ໃນການທົດສອບການໃຊ້ປະໂຫຍດຈາກຊ່ອງໂຫວ່ຂອງ Firefox, ຕົວແບບທົ່ວໄປປະສົບຜົນສຳເລັດພຽງ 2 ຄັ້ງຈາກການທົດລອງຫຼາຍຮ້ອຍຄັ້ງ, ໃນຂະນະທີ່ Mythos Preview ປະສົບຜົນສຳເລັດເຖິງ 181 ຄັ້ງ ແລະ ຍັງສາມາດຄວບຄຸມ Register ໄດ້ເພີ່ມອີກ 29 ຄັ້ງ. ຄວາມສາມາດໃນການເຮັດຊ້ຳນັ້ນແຕກຕ່າງກັນຢ່າງມະຫາສານ. ນີ້ບໍ່ແມ່ນຄວາມສຳເລັດແບບບັງເອີນທີ່ຂຶ້ນກັບຄວາມສຸ່ມ, ແຕ່ເປັນການສະແດງໃຫ້ເຫັນເຖິງຄວາມສາມາດໃນການວາງແຜນຂັ້ນຕອນການໂຈມຕີຢ່າງເປັນລະບົບທີ່ໝັ້ນຄົງ.
ຫາກຄວາມສາມາດນີ້ຕົກໄປຢູ່ໃນມືຂອງຜູ້ໂຈມຕີ, ເວລາໃນການກຽມຕົວຂອງຝ່າຍປ້ອງກັນຈະສັ້ນລົງຢ່າງຫຼວງຫຼາຍ. ສະຖານະການທີ່ "Anthropic ກຸມຄວາມໄດ້ປຽບໄວ້ກ່ອນ" ນັ້ນມີຄວາມໝາຍທາງຍຸດທະສາດຢ່າງຍິ່ງ.
ກໍລະນີການຄົ້ນພົບທີ່ Mythos Preview ໄດ້ເປີດຕົວ ຫຼື Launch ແມ່ນມີຄວາມສຳຄັນໃນການສະແດງໃຫ້ເຫັນເຖິງຂອບເຂດຄວາມສາມາດຂອງມັນ. ທຸກກໍລະນີໄດ້ຜ່ານຂະບວນການເປີດເຜີຍຊ່ອງໂຫວ່ຢ່າງມີຄວາມຮັບຜິດຊອບ (Coordinated Vulnerability Disclosure) ແລະ ໄດ້ຮັບການແກ້ໄຂແລ້ວ, ເຊິ່ງຖືເປັນກໍລະນີຕົວຢ່າງແຫ່ງຄວາມສຳເລັດສຳລັບຝ່າຍປ້ອງກັນ.
4 ກໍລະນີທີ່ນຳສະເໜີຢູ່ນີ້ ລ້ວນແລ້ວແຕ່ມີລັກສະນະທີ່ "ການເຮັດ Fuzzing ຫຼື ການກວດສອບໂດຍມະນຸດທີ່ມີຢູ່ເດີມໄດ້ພາດໄປ". ເຫດຜົນທີ່ບັກ (Bug) ເຊິ່ງຝັງຕົວມາເປັນເວລາຫຼາຍປີຖືກຄົ້ນພົບຢ່າງໜາແໜ້ນນັ້ນ ກໍຍ້ອນວ່າຄວາມສາມາດຂອງແບບຈຳລອງທີ່ສາມາດເຂົ້າໃຈຄວາມໝາຍຂອງ Source Code ແລະ ສ້າງເສັ້ນທາງການໂຈມຕີໄປພ້ອມໆກັນນັ້ນ ແມ່ນສິ່ງທີ່ເຄື່ອງມືອັດຕະໂນມັດໃນສະໄໝກ່ອນຍັງຂາດແຄນ.
ໃນເວລາທີ່ບໍລິສັດຂອງພວກເຮົາໃຫ້ການຊ່ວຍເຫຼືອດ້ານ DevSecOps ແກ່ລູກຄ້າ, ພວກເຮົາໄດ້ຍົກຕົວຢ່າງເຫຼົ່ານີ້ມາອ້າງອີງເລື້ອຍໆ ເພື່ອອະທິບາຍເຖິງຄວາມຄຸ້ມຄ່າຂອງການນຳໃຊ້ AI Code Review. ຖ້າຫາກພາຍໃນອົງກອນຖືກຖາມວ່າ "ມີເຫດຜົນຫຍັງທີ່ຕ້ອງລົງທຶນໃນ AI Review?", ການນຳສະເໜີກໍລະນີເຫຼົ່ານີ້ຈະຊ່ວຍເພີ່ມນ້ຳໜັກໃນການໂນ້ມນ້າວໃຈໄດ້ຢ່າງວ່ອງໄວ.
OpenBSD ແມ່ນ OS ທີ່ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງໃນ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ສຳຄັນ ໃນຖານະເປັນ Firewall ແລະ VPN Gateway. Mythos Preview ໄດ້ຄົ້ນພົບຊ່ອງໂຫວ່ທີ່ເຮັດໃຫ້ເກີດການ Remote Crash ເຊິ່ງແຝງຕົວຢູ່ໃນການປະມວນຜົນ TCP SACK (Selective Acknowledgment) ຂອງ OS ນີ້ມາເປັນເວລາ 27 ປີ.
ກົນໄກການໂຈມຕີແມ່ນຮູບແບບທີ່ໃຊ້ປະໂຫຍດຈາກ Integer Overflow ຂອງໝາຍເລກ TCP Sequence. SACK ເປັນຟັງຊັນການເພີ່ມຄວາມໄວທີ່ຝ່າຍຮັບໃຊ້ເພື່ອລາຍງານຊຸດຂອງ Packet ທີ່ຂາດຫາຍໄປ, ແຕ່ການຄຳນວນຂອບເຂດດັ່ງກ່າວບໍ່ໄດ້ພິຈາລະນາເຖິງສະຖານະການທີ່ໝາຍເລກ Sequence ໝູນວຽນຄົບຮອບໃນຂອບເຂດ 32 ບິດ. ຜູ້ໂຈມຕີສາມາດສົ່ງ Sequence ທີ່ຂ້າມຂອບເຂດດັ່ງກ່າວໂດຍເຈດຕະນາ ເພື່ອທຳລາຍສະຖານະພາຍໃນ ແລະ ກະຕຸ້ນໃຫ້ເກີດ Kernel Panic.
ຄວາມຈິງທີ່ວ່າຊ່ອງໂຫວ່ນີ້ຖືກມອງຂ້າມໂດຍນັກຄົ້ນຄວ້າ ແລະ ເຄື່ອງມືອັດຕະໂນມັດຈຳນວນຫຼາຍມາເປັນເວລາຫຼາຍປີ ສະແດງໃຫ້ເຫັນວ່າ ແບບຈຳລອງທີ່ເຂົ້າໃຈຄວາມໝາຍຂອງບໍລິບົດໃນ Source Code ສາມາດເສີມການເຮັດວຽກຂອງເຄື່ອງມືກວດສອບທາງ Syntax ທີ່ມີຢູ່ໄດ້. ບັກໃນເງື່ອນໄຂຂອບເຂດ (Boundary conditions) ເປັນປະເພດທີ່ເປັນແບບຢ່າງຂອງ "ຖ້າບໍ່ສາມາດຈິນຕະນາການເຖິງ Test case ກໍຈະບໍ່ພົບ", ເຊິ່ງເປັນຂົງເຂດທີ່ AI ທີ່ສາມາດອະນຸມານພື້ນທີ່ການປ້ອນຂໍ້ມູນ (Input space) ຢ່າງມີຄວາມໝາຍຈະສະແດງຈຸດແຂງອອກມາໄດ້.
ເນື່ອງຈາກ OpenBSD ຖືກນຳໃຊ້ເປັນພື້ນຖານຂອງຜະລິດຕະພັນປ້ອງກັນ, ຖ້າຫາກການຄົ້ນພົບນີ້ເກີດຂຶ້ນກ່ອນໂດຍຝ່າຍໂຈມຕີ, ມັນອາດຈະກາຍເປັນສະຖານະການທີ່ຮ້າຍແຮງທີ່ເຮັດໃຫ້ຂອບເຂດຂອງເຄືອຂ່າຍວິສາຫະກິດຖືກບຸກລຸກໄດ້.
ໃນການປະຕິບັດງານຂອງ Video Codec ໃນ FFmpeg, Mythos Preview ໄດ້ກວດພົບຂໍ້ຜິດພາດ (Bug) ທີ່ມີອາຍຸຮອບ 10 ປີ ເຊິ່ງມີສາເຫດມາຈາກຂໍ້ຈຳກັດການປະຕິບັດງານແບບເກົ່າທີ່ໃຊ້ຮູບແບບ 16-bit ພາຍໃນຕົວຖອດລະຫັດ H.264. ເມື່ອປະມວນຜົນໄຟລ໌ວິດີໂອພິເສດທີ່ມີຂໍ້ມູນເກີນຂອບເຂດທີ່ກຳນົດໄວ້, ຈະເຮັດໃຫ້ Buffer ພາຍໃນເກີດການລົ້ນ ແລະ ນຳໄປສູ່ການປະຕິບັດຄຳສັ່ງຕາມໃຈມັກ (Arbitrary Code Execution). ນີ້ແມ່ນຂໍ້ຜິດພາດລະດັບທີ່ OSS-Fuzz ບໍ່ສາມາດຄົ້ນພົບໄດ້ເຖິງແມ່ນວ່າຈະໄດ້ດຳເນີນການທົດສອບ Fuzzing ແບບອັດຕະໂນມັດຫຼາຍກວ່າ 5 ລ້ານຄັ້ງ, ແລະ ເປັນຕົວຢ່າງທີ່ດີທີ່ AI ສາມາດຄົ້ນພົບເສັ້ນທາງຂອງ Code ທີ່ການປ້ອນຂໍ້ມູນແບບສຸ່ມບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຢ່າງມີເຫດຜົນ.
ໃນ FreeBSD, Mythos Preview ໄດ້ຄົ້ນພົບ ແລະ ນຳໃຊ້ຂໍ້ຜິດພາດທີ່ມີອາຍຸຮອບ 10 ປີ (CVE-2026-4747) ທີ່ອະນຸຍາດໃຫ້ສາມາດປະຕິບັດຄຳສັ່ງຈາກໄລຍະໄກ (Remote Code Execution) ໃນ NFS (Network File System) ໄດ້ຢ່າງອິດສະຫຼະ. ໂດຍການປະສົມປະສານລະຫວ່າງການສັບສົນຂອງປະເພດຂໍ້ມູນ (Type Confusion) ແລະ ການທຳລາຍໜ່ວຍຄວາມຈຳ (Memory Corruption) ທີ່ແຝງຢູ່ໃນຂະບວນການຖອດລະຫັດ RPC ຂອງ NFS, ມັນສາມາດເຮັດໃຫ້ການສ້າງ ROP (Return-Oriented Programming) chain ເປັນອັດຕະໂນມັດຢ່າງສົມບູນ. Anthropic ໄດ້ຢືນຢັນຢ່າງຈະແຈ້ງວ່າ "ເປັນການເຮັດວຽກແບບອັດຕະໂນມັດຢ່າງສົມບູນຫຼັງຈາກການປ້ອນ Prompt ເບື້ອງຕົ້ນ", ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າ AI ສາມາດຄົ້ນຫາ ROP gadget ທີ່ຜູ້ໂຈມຕີມັກໃຊ້ໄດ້ດ້ວຍຕົນເອງ.
ໃນ Linux kernel, ຕົວແບບໄດ້ເຊື່ອມໂຍງຊ່ອງໂຫວ່ຫຼາຍຢ່າງເຂົ້າດ້ວຍກັນ ເພື່ອຍົກລະດັບສິດທິຈາກຜູ້ໃຊ້ທົ່ວໄປໄປສູ່ root. ເຖິງແມ່ນວ່າບັກແຕ່ລະຕົວຈະມີຂະໜາດນ້ອຍ, ແຕ່ການນຳມາປະກອບເຂົ້າກັນຕາມລຳດັບ ເຊັ່ນ: ການຈັດການ memory layout, ການນຳ kernel object ກັບມາໃຊ້ໃໝ່ ແລະ ການ dereference ຢູ່ຂອບເຂດຂອງສິດທິພິເສດ ກໍເປັນເສັ້ນທາງການຍົກລະດັບສິດທິທີ່ພົບເຫັນໄດ້ບໍ່ຍາກ. ນີ້ຄືຮູບແບບທີ່ຕົວແບບສາມາດສ້າງເສັ້ນທາງການໂຈມຕີໄດ້ໂດຍອັດຕະໂນມັດ ເຊິ່ງປົກກະຕິແລ້ວຜູ້ທົດສອບການເຈາະລະບົບ (Penetration Tester) ທີ່ເປັນມະນຸດຕ້ອງໃຊ້ເວລາຫຼາຍມື້.
ສຳລັບ browser, ມັນໄດ້ສ້າງ exploit ແບບປະສົມສຳລັບ JIT (Just-In-Time) compiler ຂອງ Firefox. ໂດຍການປະສົມປະສານລະຫວ່າງ JIT spray ແລະ ການຄາດຄະເນ heap layout, ມັນສາມາດສ້າງເສັ້ນທາງໄປສູ່ການປະຕິບັດລະຫັດຕາມໃຈມັກ (arbitrary code execution) ຈາກໜ້າເວັບໄດ້ສຳເລັດເຖິງ 181 ຄັ້ງ ແລະ ຍັງສາມາດຄວບຄຸມ register ໄດ້ເພີ່ມອີກ 29 ຄັ້ງ. ຄວາມສາມາດໃນການເຮັດຊ້ຳໄດ້ໃນລະດັບນີ້ ສະແດງໃຫ້ເຫັນວ່າ ມັນບໍ່ແມ່ນ "ຄວາມບັງເອີນ" ອີກຕໍ່ໄປ ແຕ່ເປັນຄວາມສາມາດທີ່ໝັ້ນຄົງທີ່ກຳລັງຖືກສ້າງຂຶ້ນ.
Project Glasswing ແມ່ນກຸ່ມພັນທະມິດໃນອຸດສາຫະກຳທີ່ຖືກສ້າງຕັ້ງຂຶ້ນເພື່ອໃຫ້ຝ່າຍປ້ອງກັນສາມາດນຳໃຊ້ Mythos Preview ໄດ້ "ກ່ອນຜູ້ໂຈມຕີ". ນີ້ແມ່ນຄວາມພະຍາຍາມໃນການກວດສອບຊອບແວທີ່ສຳຄັນຢ່າງຄົບຖ້ວນດ້ວຍ AI ເພື່ອສ້າງຍຸກທີ່ຝ່າຍປ້ອງກັນມີຄວາມໄດ້ປຽບຢ່າງຕັ້ງໃຈ.
ອີງຕາມໜ້າເວັບໄຊທາງການຂອງ Anthropic ທີ່ anthropic.com/glasswing, ບັນດາຄູ່ຮ່ວມກໍ່ຕັ້ງມີ 11 ອົງການຈັດຕັ້ງດັ່ງນີ້: Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, ແລະ Palo Alto Networks. ນອກຈາກນີ້, ຍັງມີອີກຫຼາຍກວ່າ 40 ອົງການຈັດຕັ້ງທີ່ເຂົ້າຮ່ວມໃນຖານະຜູ້ຮັກສາ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ສຳຄັນ.
ເວລາທີ່ຝ່າຍປ້ອງກັນຈະສາມາດຄອບຄອງຄວາມສາມາດດ້ານ AI ໄດ້ຢ່າງຜູກຂາດນັ້ນມີຈຳກັດ. Anthropic ເອງກໍໄດ້ກ່າວວ່າ "ຖ້າລົງມືເຮັດໃນຕອນນີ້ ກໍຈະສາມາດສ້າງຍຸກ AI ທີ່ຝ່າຍປ້ອງກັນມີຄວາມໄດ້ປຽບໄດ້" ແຕ່ໃນທາງກັບກັນ ນັ້ນກໍເປັນການເຕືອນໄພວ່າ ຖ້າບໍ່ລົງມືເຮັດ ຝ່າຍໂຈມຕີກໍຈະເປັນຝ່າຍທີ່ມີຄວາມໄດ້ປຽບແທນ.
Anthropic ໄດ້ໃຫ້ຄຳໝັ້ນສັນຍາວ່າຈະສະໜັບສະໜູນສິນເຊື່ອການນຳໃຊ້ Mythos Preview ສູງສຸດເຖິງ 100 ລ້ານໂດລາ ແລະ ບໍລິຈາກໂດຍກົງໃຫ້ແກ່ອົງການຮັກສາຄວາມປອດໄພແບບເປີດເຜີຍ (Open Source) ເປັນຈຳນວນ 4 ລ້ານໂດລາ. ລາຍລະອຽດການບໍລິຈາກປະກອບມີ 2.5 ລ້ານໂດລາໃຫ້ແກ່ Alpha-Omega ແລະ OpenSSF ຜ່ານທາງ Linux Foundation ແລະ 1.5 ລ້ານໂດລາໃຫ້ແກ່ Apache Software Foundation.
Glasswing ມີແຜນທີ່ຈະເປີດຕົວ ຫຼື Launch ລາຍງານຜົນການດຳເນີນງານພາຍໃນ 90 ວັນ. ຂະບວນການເປີດເຜີຍຂໍ້ມູນຢ່າງມີຄວາມຮັບຜິດຊອບທັງໝົດ ແມ່ນປະຕິບັດຕາມນະໂຍບາຍ Coordinated Vulnerability Disclosure ຂອງ Anthropic, ໂດຍມີຫຼັກການເປີດເຜີຍຂໍ້ມູນພາຍໃນ 90 ວັນ ຫຼື ເມື່ອມີການປ່ອຍ Patch ອອກມາ, ເຊິ່ງອັນໃດເກີດຂຶ້ນກ່ອນ. ນອກຈາກນີ້, ຫຼັງຈາກການປ່ອຍ Patch ແລ້ວ ໂດຍປົກກະຕິຈະມີການພັກໄວ້ 45 ວັນ ກ່ອນທີ່ຈະເປີດເຜີຍລາຍລະອຽດທາງເຕັກນິກ ເພື່ອສ້າງຄວາມສົມດຸນລະຫວ່າງການໃຫ້ເວລາແກ່ນັກພັດທະນາໃນການແກ້ໄຂບັນຫາ ແລະ ການແບ່ງປັນຂໍ້ມູນໃຫ້ແກ່ຜູ້ປ້ອງກັນລະບົບ.
ວິທີການທີ່ວິສາຫະກິດຂະໜາດກາງ ແລະ ຜູ້ເບິ່ງແຍງ OSS ຈະມີສ່ວນຮ່ວມກັບ Glasswing ນັ້ນມີຢູ່ 2 ຊ່ອງທາງຫຼັກ:
ຊ່ອງທາງທຳອິດແມ່ນໂຄງການ "Claude for Open Source" ເຊິ່ງເປັນກອບການເຮັດວຽກທີ່ສະໜອງ Claude ໃຫ້ແກ່ຜູ້ເບິ່ງແຍງ OSS ໂດຍບໍ່ເສຍຄ່າ ຫຼື ໃນລາຄາພິເສດ. ສຳລັບໂຄງການ OSS ທີ່ມີຜົນງານການເຄື່ອນໄຫວຢ່າງຕໍ່ເນື່ອງໃນ GitHub, ຜູ້ເບິ່ງແຍງສ່ວນບຸກຄົນກໍສາມາດສະໝັກເຂົ້າຮ່ວມໄດ້. ຫາກຜູ້ເບິ່ງແຍງ OSS ທີ່ຜະລິດຕະພັນຂອງບໍລິສັດຕົນເອງມີຄວາມເພິ່ງພາອາໄສນັ້ນສະໝັກເຂົ້າຮ່ວມ, ການປັບປຸງຄວາມປອດໄພໃນລະດັບຕົ້ນນ້ຳກໍຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ການປົກປ້ອງລະບົບ Supply Chain ຂອງບໍລິສັດຕົນເອງໃນທີ່ສຸດ.
ອີກຊ່ອງທາງໜຶ່ງແມ່ນ "Cyber Verification Program" ເຊິ່ງນັກຄົ້ນຄວ້າ ຫຼື ບໍລິສັດທີ່ມີຜົນງານການເຮັດວຽກດ້ານຄວາມປອດໄພທາງໄຊເບີຢ່າງຖືກຕ້ອງ ສາມາດຍື່ນຄຳຮ້ອງຂໍເຂົ້າເຖິງໂມເດວທີ່ມີປະສິດທິພາບສູງຂຶ້ນໄດ້. ກຸ່ມເປົ້າໝາຍຫຼັກຄືບໍລິສັດທີ່ມີທີມ SOC ພາຍໃນ, ທີມ Pentest, ຫຼື ຜູ້ໃຫ້ບໍລິການດ້ານຄວາມປອດໄພ.
ເຖິງແມ່ນວ່າອົງກອນທີ່ຈະສາມາດເຂົ້າເຖິງ Mythos Preview ຕົວຈິງໄດ້ນັ້ນຈະມີຈຳນວນຈຳກັດ, ແຕ່ການຕິດຕາມຄວາມເຄື່ອນໄຫວເຫຼົ່ານັ້ນເພື່ອມາປັບໃຊ້ກັບທ່າທີດ້ານຄວາມປອດໄພຂອງບໍລິສັດຕົນເອງນັ້ນ ຖືວ່າມີຄວາມໝາຍສຳຄັນສຳລັບທຸກບໍລິສັດ. ກ່ອນທີ່ຈະຕັດສິນໃຈວ່າ "ຕົນເອງບໍ່ກ່ຽວຂ້ອງເພາະບໍ່ຢູ່ໃນກຸ່ມເປົ້າໝາຍ", ຄວນພິຈາລະນາເຖິງຄວາມເປັນໄປໄດ້ໃນການຍື່ນຄຳຮ້ອງພາຍໃນບໍລິສັດກ່ອນຈະດີກວ່າ.
ສຳລັບການເປີດຕົວ ຫຼື Launch ຂອງ Mythos ແລະ Glasswing, ໄດ້ມີການຍົກປະເດັນສຳຄັນຫຼາຍຢ່າງຈາກຊຸມຊົນຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພທາງໄຊເບີ. ແທນທີ່ຈະມີຄວາມຄິດໃນແງ່ບວກແບບບໍ່ມີເງື່ອນໄຂ, ພວກເຮົາຈຳເປັນຕ້ອງຈັດລະບຽບຄວາມຄິດຢ່າງມີສະຕິວ່າສິ່ງໃດທີ່ປ່ຽນແປງ ແລະ ສິ່ງໃດທີ່ບໍ່ປ່ຽນແປງ.
ໃນທີ່ນີ້, ພວກເຮົາຈະຍົກສອງປະເດັນທີ່ມີອິດທິພົນໂດຍສະເພາະ ຄື: ຄຳເຕືອນຂອງ Bruce Schneier ທີ່ວ່າ "ຄວາມໄດ້ປຽບໃນການປ້ອງກັນຈະຫຼຸດລົງ" ແລະ ການຊີ້ແຈງຂອງບໍລິສັດຄວາມປອດໄພ Aisle ທີ່ວ່າ "ຄວາມສາມາດບາງສ່ວນສາມາດສ້າງຂຶ້ນໃໝ່ໄດ້ດ້ວຍໂມເດວທີ່ມີຢູ່ແລ້ວ". ທັງສອງປະເດັນນີ້ໄດ້ຊີ້ໃຫ້ເຫັນເຖິງລຳດັບຄວາມສຳຄັນຂອງການກະທຳທີ່ອົງກອນຄວນດຳເນີນການໃນທັນທີ.
ນັກຄົ້ນຄວ້າດ້ານຄວາມປອດໄພ Bruce Schneier ໄດ້ເຕືອນຜ່ານບລັອກສ່ວນຕົວຂອງລາວທີ່ schneier.com ວ່າ ຄວາມໄດ້ປຽບໃນການປ້ອງກັນຂອງ Mythos ແມ່ນເລື່ອງຈິງ ແຕ່ "ເມື່ອມີໂມເດວທີ່ມີພະລັງຫຼາຍຂຶ້ນປະກົດຕົວອອກມາ ຄວາມໄດ້ປຽບນັ້ນກໍມີແນວໂນ້ມທີ່ຈະຫຼຸດໜ້ອຍຖອຍລົງ".
ໃນຂະນະທີ່ຍອມຮັບວ່າຄວາມບໍ່ສົມດຸນທີ່ວ່າ "ການຊອກຫາບັກເພື່ອແກ້ໄຂນັ້ນ AI ສາມາດເຮັດໄດ້ງ່າຍກວ່າການຊອກຫາເພື່ອໃຊ້ປະໂຫຍດ" ເປັນຂໍ້ໄດ້ປຽບຊົ່ວຄາວ, ລາວກໍໄດ້ຊີ້ໃຫ້ເຫັນວ່າເປັນພຽງເລື່ອງຂອງເວລາເທົ່ານັ້ນທີ່ຝ່າຍໂຈມຕີຈະສາມາດບັນລຸຄວາມສາມາດທີ່ທຽບເທົ່າກັນໄດ້ດ້ວຍໂມເດວ Open Source.
Schneier ຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງໄປສູ່ຄວາມສາມາດໃນການຟື້ນຕົວ (Resilience) ໃນລະດັບລະບົບ ໂດຍຕັ້ງສົມມຸດຕິຖານວ່າຈະຢູ່ໃນ "ໂລກທີ່ການໂຈມຕີແບບ Zero-day ກາຍເປັນເລື່ອງທົ່ວໄປ (dime-a-dozen)". ໂດຍສະເພາະ, ການດຳເນີນງານບໍ່ແມ່ນພຽງແຕ່ການແກ້ໄຂ Patch ແບບດ່ຽວ ແຕ່ຕ້ອງຍຶດຖືການອອກແບບແບບແບ່ງສ່ວນ, ການບັນທຶກ Log, ການໃຫ້ສິດທິພິເສດຂັ້ນຕໍ່າສຸດ ແລະ ລະບົບການຕອບໂຕ້ຢ່າງວ່ອງໄວ ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ. ນີ້ຄືການປ່ຽນແປງຈາກໂມເດວທີ່ "ຕັ້ງເປົ້າໝາຍວ່າຈະບໍ່ໃຫ້ຖືກບຸກລຸກ" ໄປສູ່ໂມເດວທີ່ "ຫຼຸດຜ່ອນຄວາມເສຍຫາຍໃຫ້ໜ້ອຍທີ່ສຸດເຖິງແມ່ນວ່າຈະຖືກບຸກລຸກແລ້ວ" ເຊິ່ງກໍຄືການອອກແບບແບບ Zero Trust ຢ່າງເຕັມຮູບແບບ.
ບໍລິສັດຮັກສາຄວາມປອດໄພ Aisle ຊີ້ໃຫ້ເຫັນວ່າ ສາມາດນຳໃຊ້ໂມເດວທົ່ວໄປທີ່ມີລາຄາຖືກເຊິ່ງໄດ້ ເປີດຕົວ ຫຼື Launch ໄປແລ້ວນັ້ນ ມາຈຳລອງຄວາມສາມາດບາງຢ່າງທີ່ Mythos ເຮັດໄດ້. ເຖິງວ່າຈະຍັງມີຊ່ອງຫວ່າງລະຫວ່າງ "ການຊອກຫາຈຸດອ່ອນ" ກັບ "ການປ່ຽນໃຫ້ເປັນການໂຈມຕີທີ່ໃຊ້ງານໄດ້ຈິງ", ແຕ່ສຳລັບຈຸດປະສົງດ້ານການປ້ອງກັນຂອງບໍລິສັດນັ້ນ ເປົ້າໝາຍຄື "ການຊອກຫາ ແລະ ແກ້ໄຂບັກທີ່ສາມາດໂຈມຕີໄດ້ໂດຍໄວ" ຈຶ່ງບໍ່ຈຳເປັນຕ້ອງເຮັດໃຫ້ຂະບວນການສ້າງ Exploit ເປັນອັດຕະໂນມັດ. ພຽງແຕ່ການຊອກຫາບັກໂດຍໄວ ແລະ ການສະເໜີແກ້ໄຂ Patch ໂດຍອັດຕະໂນມັດ ກໍພຽງພໍທີ່ຈະສ້າງຄວາມຄຸ້ມຄ່າໃນການລົງທຶນໄດ້ແລ້ວ.
ກ່າວຄື, ເຖິງແມ່ນວ່າບໍລິສັດຂະໜາດກາງຈະບໍ່ສາມາດເຂົ້າເຖິງ Mythos Preview ໄດ້, ແຕ່ກໍຍັງມີຊ່ອງວ່າງຫຼາຍໃນການນຳ "ການຊອກຫາຈຸດອ່ອນດ້ວຍ AI" ມາລວມເຂົ້າໃນການເຮັດວຽກ ໂດຍໃຊ້ພຽງແຕ່ໂມເດວທີ່ມີຢູ່ໃນປັດຈຸບັນ. ນີ້ຄື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ບໍລິສັດຂອງພວກເຮົາເນັ້ນຢ້ຳກັບລູກຄ້າຫຼາຍທີ່ສຸດ. ຄວນເລີ່ມຕົ້ນຈາກ "ການເຂົ້າໃຈຢ່າງຖືກຕ້ອງວ່າໂມເດວໃນປັດຈຸບັນສາມາດເຮັດຫຍັງໄດ້บ้าง" ແທນທີ່ຈະຄິດວ່າ "ເຮັດຫຍັງບໍ່ໄດ້ເລີຍເພາະບໍ່ມີ Frontier Model".
ເພື່ອບໍ່ໃຫ້ຂ່າວຂອງ Mythos Preview ເປັນພຽງ "ເລື່ອງຂອງຄົນອື່ນ" ແຕ່ສາມາດນຳມາປັບໃຊ້ກັບທ່າທີດ້ານຄວາມປອດໄພຂອງບໍລິສັດຕົນເອງໄດ້ນັ້ນ, ຈຳເປັນຕ້ອງປ່ຽນຈາກທິດສະດີທີ່ເປັນນາມມະທຳໃຫ້ກາຍເປັນການກະທຳທີ່ເປັນຮູບປະທຳ. ພວກຂ້າພະເຈົ້າຂໍແນະນຳ 5 ການປະຕິບັດງານເພື່ອການຈັດຕັ້ງປະຕິບັດສຳລັບວິສາຫະກິດຂະໜາດກາງ.
ທັງໝົດນີ້ບໍ່ໄດ້ອີງໃສ່ການເຂົ້າເຖິງ Mythos ໂດຍກົງ. ພວກຂ້າພະເຈົ້າໄດ້ຄັດເລືອກເອົາສິ່ງທີ່ສາມາດຈັດຕັ້ງປະຕິບັດໄດ້ດ້ວຍການປະສົມປະສານລະຫວ່າງໂມເດວປັດຈຸບັນ ແລະ ເຄື່ອງມືທີ່ມີຢູ່ແລ້ວ, ເຊິ່ງສາມາດເຫັນຮູບຮ່າງໄດ້ພາຍໃນເວລາສັ້ນທີ່ສຸດຄື 1-2 ອາທິດ ແລະ ປະມານ 3 ເດືອນສຳລັບການນຳໃຊ້ງານຢ່າງເຕັມຮູບແບບ. ຖ້າຫາກດຳເນີນການໄປພ້ອມກັບການປັບປຸງດ້ານ AI Governance, ການຈັດເຮັດເອກະສານດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ແລະ ການຈັດຕັ້ງປະຕິບັດຈະດຳເນີນໄປພ້ອມກັນ, ເຮັດໃຫ້ສາມາດຫຼີກລ່ຽງສະຖານະການທີ່ຕ້ອງມາແລ່ນແກ້ໄຂບັນຫາໃນພາຍຫຼັງເມື່ອມີການກວດສອບໄດ້ງ່າຍຂຶ້ນ.
Mythos ຕົວມັນເອງຍັງເປັນການເປີດຕົວ ຫຼື Launch ແບບຈຳກັດ, ແຕ່ການວິເຄາະໂຄດແບບສະຖິດ ແລະ ການກວດສອບອັດຕະໂນມັດໂດຍໃຊ້ Claude ຫຼື GPT ແບບທົ່ວໄປໃນປັດຈຸບັນແມ່ນສາມາດນຳໄປໃຊ້ງານໄດ້ແລ້ວ. ຖ້ານຳໄປລວມເຂົ້າໃນ CI/CD ຂະບວນການ ຫຼື Pipeline ໂດຍກຳນົດໃຫ້ມີ 3 ຂັ້ນຕອນໃນທຸກໆ PR ຄື: "LLM Review → Linter ທີ່ມີຢູ່ → Fuzzing", ຈະສາມາດຫຼຸດຜ່ອນຂໍ້ຜິດພາດທາງເຫດຜົນທີ່ຜູ້ກວດສອບທີ່ເປັນມະນຸດອາດຈະເບິ່ງຂ້າມໄປໄດ້ຢ່າງຫຼວງຫຼາຍ.
ຢ່າຟ້າວຮີບຮ້ອນເຮັດໃຫ້ເປັນອັດຕະໂນມັດທັງໝົດ, ຄວນເລີ່ມຈາກການວັດແທກຜົນໃນ Repository ຂະໜາດນ້ອຍກ່ອນ ເພື່ອສະສົມອັດຕາການກວດພົບ ແລະ ອັດຕາການກວດພາດໃຫ້ເປັນຂໍ້ມູນພາຍໃນບໍລິສັດ ເຊິ່ງເປັນທາງອອກທີ່ເປັນຈິງທີ່ສຸດ. ຖ້າວັດແທກຜົນໃນຮອບ 3 ເດືອນ ໂດຍເບິ່ງຈາກ "ອັດຕາສ່ວນຂອງຂໍ້ຜິດພາດທີ່ LLM ຊີ້ໃຫ້ເຫັນແລ້ວເປັນຂໍ້ຜິດພາດແທ້" ແລະ "ຈຳນວນຂໍ້ຜິດພາດທີ່ LLM ກວດພົບທັງທີ່ຜ່ານການກວດສອບຈາກມະນຸດມາແລ້ວ", ທ່ານກໍຈະມີຂໍ້ມູນພຽງພໍສຳລັບການຕັດສິນໃຈໃນການລົງທຶນ.
ສຳລັບບໍລິສັດທີ່ເຮັດທຸລະກິດດ້ານຄວາມປອດໄພ ຫຼື ອົງກອນທີ່ມີນັກຄົ້ນຄວ້າຊ່ຽວຊານພາຍໃນ, ການພິຈາລະນາສະໝັກເຂົ້າຮ່ວມ Cyber Verification Program ແມ່ນມີຄວາມຄຸ້ມຄ່າ. ຖ້າໄດ້ຮັບການຍອມຮັບ, ທ່ານຈະສາມາດເຂົ້າເຖິງຟັງຊັນຂອງໂມເດວລະດັບ Mythos ໄດ້ບາງສ່ວນ ເຊິ່ງຈະຊ່ວຍໃຫ້ສາມາດກວດສອບຜະລິດຕະພັນຂອງບໍລິສັດຕົນເອງໄດ້ຢ່າງລະອຽດກ່ອນການນຳໃຊ້ຈິງ.
ເນື່ອງຈາກການສະໝັກຈຳເປັນຕ້ອງມີການສະແດງຜົນງານທາງທຸລະກິດທີ່ຖືກຕ້ອງ, ດັ່ງນັ້ນການເກັບບັນທຶກຜົນງານການປະກອບສ່ວນໃນການເປີດເຜີຍຊ່ອງໂຫວ່ ຫຼື ການເຂົ້າຮ່ວມໂຄງການ Bug Bounty ໄວ້ຕັ້ງແຕ່ປົກກະຕິແມ່ນມີຄວາມສຳຄັນຫຼາຍ. ຜົນງານທີ່ນຳມາປະເມີນລວມມີ: ປະຫວັດການເຂົ້າຮ່ວມແພລັດຟອມເຊັ່ນ HackerOne / Bugcrowd ຂອງພະນັກງານ, ການລາຍງານຊ່ອງໂຫວ່ທີ່ມີການອອກ CVE, ແລະ ຈຳນວນຄັ້ງທີ່ໄດ້ຮັບການຂອບໃຈຈາກການເປີດເຜີຍຂໍ້ມູນຢ່າງມີຄວາມຮັບຜິດຊອບ.
ສຳລັບອົງກອນທີ່ມີການເປີດຕົວ ຫຼື Launch ໂຄງການ OSS, Claude for Open Source ຈະເປັນທາງເຂົ້າທີ່ເໝາະສົມກວ່າ. ຖ້າເປັນໂຄງການ OSS ທີ່ມີປະຫວັດການເຄື່ອນໄຫວໃນ GitHub, ທາງເຮົາກໍເປີດຮັບສະໝັກໃນລະດັບຜູ້ດູແລລະບົບ (Maintainer) ເຊັ່ນກັນ.
ປຶ້ມຄູ່ມືການຮັບມືກັບອຸບັດຕິເຫດ (Incident Response Playbook) ແບບດັ້ງເດີມ ມັກຈະຖືກສ້າງຂຶ້ນໂດຍມີເງື່ອນໄຂເບື້ອງຕົ້ນວ່າ "ຈະຮັບມືຫຼັງຈາກທີ່ມີການລາຍງານ CVE ທີ່ຮູ້ຈັກແລ້ວ". ແຕ່ສິ່ງທີ່ Mythos ໄດ້ສະແດງໃຫ້ເຫັນຄືຄວາມເປັນຈິງທີ່ວ່າ ມີ Zero-day ທີ່ຍັງບໍ່ທັນໄດ້ ເປີດຕົວ ຫຼື Launch ຫຼາຍພັນລາຍການທີ່ຍັງຕົກຄ້າງຢູ່ໃນ OS, Browser ແລະ Library ຫຼັກໆຂອງໂລກ. ໃນທັນທີທີ່ຜູ້ໂຈມຕີສາມາດບັນລຸຄວາມສາມາດໃນການຄົ້ນພົບທີ່ທຽບເທົ່າກັນດ້ວຍ AI, ສິ່ງເຫຼົ່ານີ້ຈະຖືກນຳມາໃຊ້ເປັນອາວຸດ.
ໂດຍມີເງື່ອນໄຂເບື້ອງຕົ້ນວ່າ "Zero-day ມີຢູ່ຕະຫຼອດເວລາ", IR Playbook ຄວນຈະລວມເອົາ 4 ຈຸດດັ່ງຕໍ່ໄປນີ້:
ການເຊື່ອມໂຍງຫຼັກການພື້ນຖານຂອງ DevSecOps ຢ່າງ Shift Left ເຂົ້າກັບການກວດສອບ Code ດ້ວຍ AI. ການສ້າງກົນໄກເພື່ອສະທ້ອນລາຍການກວດສອບຂອງ OWASP Top 10 ຫຼື OWASP LLM Top 10 ໃຫ້ເປັນການສະແດງຄວາມຄິດເຫັນແບບອັດຕະໂນມັດໃນ PR ຈະຊ່ວຍໃຫ້ຜູ້ພັດທະນາສາມາດປ່ຽນຜ່ານໄປສູ່ຮູບແບບ "ໄດ້ຮັບຄຳຕິຊົມທັນທີທີ່ຂຽນ Code" ແທນທີ່ຈະເປັນ "ແກ້ໄຂຫຼັງຈາກຖືກຊີ້ແຈງ".
ນອກຈາກນີ້ ຍັງມີຜົນປະໂຫຍດທາງອ້ອມຄື ການຊ່ວຍໃຫ້ Senior Reviewer ສາມາດສຸມເວລາໄປກັບການກວດສອບການອອກແບບທີ່ຍາກ ແລະ ຈຳເປັນຕ້ອງໃຊ້ການຕັດສິນໃຈສູງໄດ້. ໃນໂຄງການທີ່ພວກເຮົາໃຫ້ການສະໜັບສະໜູນ ມີກໍລະນີສຶກສາທີ່ເວລາໃນການກວດສອບໂດຍມະນຸດຫຼຸດລົງ 30-40% ພາຍໃນ 2 ເດືອນຫຼັງຈາກນຳໃຊ້ AI Code Review.
ຂໍ້ຄວນລະວັງຄື ຕ້ອງມີການສ້າງກົດລະບຽບເພື່ອບໍ່ໃຫ້ AI Review ກາຍເປັນພຽງ "ການອະນຸມັດຜ່ານໆໄປ". ຖ້າຫາກເຊື່ອໝັ້ນຫຼາຍເກີນໄປວ່າ "LLM ໃຫ້ຜ່ານແລ້ວ ສະແດງວ່າປອດໄພ" ຈະເຮັດໃຫ້ເກີດບັນຫາໃນທາງກົງກັນຂ້າມກັບການກວດພົບຜິດພາດ ນັ້ນກໍຄືການກວດບໍ່ພົບ (False Negative). ຕ້ອງມີການຂຽນກົດລະບຽບການນຳໃຊ້ໃຫ້ຊັດເຈນວ່າ AI ເປັນພຽງຊັ້ນຊ່ວຍເຫຼືອເທົ່ານັ້ນ ແລະ ບໍ່ແມ່ນສິ່ງທີ່ຈະມາທົດແທນການຕັດສິນໃຈຂັ້ນສຸດທ້າຍຂອງມະນຸດ.
ໃນ EU AI Act ທີ່ໄດ້ມີການບັງຄັບໃຊ້ຢ່າງເຕັມຮູບແບບແລ້ວ, ລະບົບ AI ທີ່ມີຄວາມສ່ຽງສູງຈະຕ້ອງມີມາດຕະການດ້ານຄວາມປອດໄພທາງໄຊເບີ ແລະ ການບໍລິຫານຈັດການຄວາມສ່ຽງຢ່າງຕໍ່ເນື່ອງ. ໃນກໍລະນີທີ່ມີການນຳໃຊ້ຂະບວນການຄົ້ນຫາຊ່ອງໂຫວ່ໂດຍໃຊ້ AI ຢ່າງເປັນທາງການ, ຄວາມຮັບຜິດຊອບຂອງ AI ຕົວມັນເອງ ແລະ ການຮັກສາບັນທຶກຂໍ້ມູນ (Log) ຈະກາຍເປັນປະເດັນສຳຄັນທາງດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance). ການເກັບຮັກສາຂໍ້ມູນໃນຮູບແບບທີ່ສາມາດຕິດຕາມກວດສອບຍ້ອນຫຼັງໄດ້ວ່າ "ແບບຈຳລອງໃດ, ລະຫັດໃດ, ເວລາໃດ ແລະ ໄດ້ມີການຊີ້ແຈງແນວໃດ" ແມ່ນເງື່ອນໄຂເບື້ອງຕົ້ນສຳລັບການກວດສອບ.
ການກວດສອບຄວາມສອດຄ່ອງລະຫວ່າງແຕ່ລະໝວດໝູ່ຂອງ OWASP LLM Top 10 (ເຊັ່ນ: Prompt Injection, ການຮົ່ວໄຫຼຂອງຂໍ້ມູນລັບ, Supply Chain ແລະ ອື່ນໆ) ກັບການບໍລິຫານຈັດການພາຍໃນ, ລວມເຖິງການລະບຸຂອບເຂດຄວາມຮັບຜິດຊອບໃຫ້ຊັດເຈນໃນກໍລະນີທີ່ຜົນການກວດສອບລະຫັດໂດຍ AI ພັດທະນາກາຍເປັນເຫດການບໍ່ຄາດຝັນ (Incident), ຈະເປັນປະໂຫຍດຢ່າງຍິ່ງຕໍ່ການກວດສອບໃນອະນາຄົດ.
ໃນບັນດາປະເທດ ASEAN ກໍໄດ້ມີການປັບປຸງກົດໝາຍວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນ (ເຊັ່ນ: PDPA ຂອງໄທ, PDPL ຂອງຫວຽດນາມ, ກົດໝາຍ PDP ຂອງອິນໂດເນເຊຍ ແລະ ກົດໝາຍວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນຂອງລາວ) ເຊິ່ງຮຽກຮ້ອງໃຫ້ມີຄວາມສອດຄ່ອງຂອງໂຄງຮ່າງການບໍລິຫານຈັດການ (Governance Framework) ທີ່ກວມເອົາໄປເຖິງບໍລິສັດຍ່ອຍໃນທ້ອງຖິ່ນນຳອີກ.
Mythos Preview ຕົວມັນເອງອາດຈະຍັງບໍ່ທັນເຖິງມືຂອງວິສາຫະກິດຂະໜາດກາງ. ແຕ່ເຖິງຢ່າງນັ້ນ, "ຍຸກທີ່ AI ສາມາດຊອກຫາຊ່ອງໂຫວ່ ແລະ ນຳໄປໃຊ້ໃນທາງທີ່ຜິດ" ກໍບໍ່ແມ່ນເລື່ອງໄກຕົວ. ສິ່ງທີ່ພວກເຮົາຕ້ອງການສື່ສານຄື: ດ້ວຍໂມເດວໃນປັດຈຸບັນ ກໍສາມາດເສີມສ້າງການປ້ອງກັນໃຫ້ພຽງພໍໄດ້ແລ້ວ ແລະ ໃນທາງກັບກັນ, ເວລານີ້ທີ່ເປັນຊ່ວງເວລາແຫ່ງການກຽມພ້ອມ ຄືເວລາທີ່ຄວນລົງມືເຮັດ.
ຈາກມຸມມອງໃນການສະໜັບສະໜູນວິສາຫະກິດຂະໜາດກາງໃນໄທ, ຍີ່ປຸ່ນ ແລະ ບັນດາປະເທດ ASEAN, ລຳດັບຄວາມສຳຄັນນັ້ນມີຄວາມຊັດເຈນ. ຢ່າງທີໜຶ່ງ, ຕ້ອງນຳເອົາການກວດສອບພາຍໃນ ແລະ Fuzzing ໂດຍໃຊ້ Claude ຫຼື GPT ແບບທົ່ວໄປທີ່ມີຢູ່ໃນປັດຈຸບັນ ມາລວມເຂົ້າໃນການເຮັດວຽກ. ຢ່າງທີສອງ, ຕ້ອງຂຽນ IR Playbook ຄືນໃໝ່ໂດຍຕັ້ງສົມມຸດຕິຖານວ່າ "Zero-day ແມ່ນເລື່ອງປົກກະຕິ" ພ້ອມທັງຈັດຕັ້ງລະບົບການເກັບຮັກສາ Log ແລະ ການຝຶກຊ້ອມເທິງໂຕະ (Tabletop Exercise). ຢ່າງທີສາມ, ຕ້ອງປັບກອບການເຮັດວຽກຂອງ AI Governance (EU AI Act / OWASP LLM Top 10) ໃຫ້ສອດຄ່ອງກັບການດຳເນີນງານຂອງບໍລິສັດ.
ຖ້າຄິດວ່າ "ຈະຄິດກໍຕໍ່ເມື່ອ Mythos ເປີດຕົວ ຫຼື Launch ຢ່າງເປັນທາງການ" ກໍອາດຈະສາຍເກີນໄປ. ສິ່ງທີ່ Glasswing ໄດ້ສະແດງໃຫ້ເຫັນຄືຄວາມເປັນຈິງທີ່ວ່າ ໄລຍະເວລາຜ່ອນຜັນທີ່ຝ່າຍປ້ອງກັນໄດ້ຮັບນັ້ນບໍ່ໄດ້ຍາວນານປານໃດ. ດັ່ງທີ່ Schneier ໄດ້ເຕືອນໄວ້, ມັນເປັນພຽງບັນຫາຂອງເວລາເທົ່ານັ້ນທີ່ຝ່າຍໂຈມຕີຈະມີຄວາມສາມາດທຽບເທົ່າກັນ, ແລະ ເມື່ອຮອດເວລານັ້ນ ບໍລິສັດທີ່ "ບໍ່ໄດ້ເຮັດຫຍັງເລີຍ" ຈະຕົກເປັນເຫຍື່ອລາຍທຳອິດ.
ບໍລິສັດຂອງພວກເຮົາໃຫ້ບໍລິການສະໜັບສະໜູນການສ້າງລະບົບ Secure Coding ໂດຍໃຊ້ Claude, ການຈັດຕັ້ງ LLM Governance ແລະ ການນຳເອົາລະບົບ AI Code Review ມາໃຊ້ພາຍໃນອົງກອນ. ບໍລິສັດໃດທີ່ຕ້ອງການທົບທວນທັດສະນະຄະຕິດ້ານຄວາມປອດໄພທາງໄຊເບີໃນຍຸກ AI, ຂໍເຊີນປຶກສາຫາລືກັບພວກເຮົາໄດ້.

Yusuke Ishihara
ເລີ່ມຂຽນໂປຣແກຣມຕັ້ງແຕ່ອາຍຸ 13 ປີ ດ້ວຍ MSX. ຫຼັງຈົບການສຶກສາຈາກມະຫາວິທະຍາໄລ Musashi, ໄດ້ເຮັດວຽກໃນການພັດທະນາລະບົບຂະໜາດໃຫຍ່ ລວມທັງລະບົບຫຼັກຂອງສາຍການບິນ ແລະ ໂຄງສ້າງ Windows Server Hosting/VPS ທຳອິດຂອງຍີ່ປຸ່ນ. ຮ່ວມກໍ່ຕັ້ງ Site Engine Inc. ໃນປີ 2008. ກໍ່ຕັ້ງ Unimon Inc. ໃນປີ 2010 ແລະ Enison Inc. ໃນປີ 2025, ນຳພາການພັດທະນາລະບົບທຸລະກິດ, NLP ແລະ ແພລດຟອມ. ປັດຈຸບັນສຸມໃສ່ການພັດທະນາຜະลິດຕະພັນ ແລະ ການສົ່ງເສີມ AI/DX ໂດຍນຳໃຊ້ generative AI ແລະ LLM.