ในช่วงไม่กี่ปีที่ผ่านมา การรักษาความปลอดภัยของแอปพลิเคชันมีขอบเขตที่ชัดเจน คือ ระหว่างที่เก็บข้อมูลและตัวแอปพลิเคชันเอง pipelineนั่นคือที่ตั้งของระบบควบคุม ที่ซึ่งการสแกนทำงาน ที่ซึ่งทีมตัดสินใจว่าจะส่งอะไรไปใช้งานจริงหรือไม่ ทุกอย่างขึ้นอยู่กับสมมติฐานเดียวคือ นักพัฒนาเป็นผู้เลือกอย่างชัดเจนว่าโค้ดและส่วนประกอบใดที่จะเข้าสู่ระบบ
ข้อสันนิษฐานนั้นใช้ไม่ได้อีกต่อไปแล้ว ปัจจุบันโค้ดส่วนใหญ่ถูกเขียน แนะนำ หรือติดตั้งโดยเอเจนต์ AI โดยที่ไม่มีใครตรวจสอบชื่อของสิ่งที่ถูกดึงเข้ามาด้วยซ้ำ เมื่อ decisยิ่งตำแหน่งของสิ่งที่ป้อนเข้าสู่โค้ดเปลี่ยนแปลงไป การโจมตีก็จะเปลี่ยนแปลงตามไปด้วย มันจะย้ายไปอยู่ที่จุดเริ่มต้นของกระบวนการ นั่นคือช่วงเวลาที่โค้ดถูกสร้างขึ้น ภายในตัวช่วยเองและในไฟล์ที่ใช้ในการกำหนดค่า
นี่คือพื้นที่เสี่ยงต่อการโจมตีของ AI ของคุณ: ทุกโมเดล เอเจนต์ เซิร์ฟเวอร์ MCP ทักษะ และการพึ่งพาที่ AI แนะนำ ซึ่งอาจก่อให้เกิดความเสี่ยงก่อนที่มนุษย์จะตรวจสอบเสียด้วยซ้ำ AI ตัวเดียวกันกับที่นักพัฒนาของคุณไว้วางใจ ตอนนี้ก็เป็นส่วนหนึ่งของความเสี่ยงนี้แล้ว นี่ไม่ใช่ความเสี่ยงในอนาคต แต่เป็นการเปลี่ยนแปลงที่เกิดขึ้นแล้ว และนี่คือสิ่งที่เกิดขึ้นจริง
เป็นการโจมตีหลายระลอก ไม่ใช่เหตุการณ์โดดเดี่ยว
ไม่มีข้อใดต่อไปนี้เป็นแบบฝึกหัดในห้องปฏิบัติการcisหรือสถานการณ์สมมติ เหตุการณ์เหล่านี้เป็นเหตุการณ์สาธารณะที่มีการบันทึกไว้เกือบทั้งหมดเกิดขึ้นในปีที่ผ่านมา และแต่ละเหตุการณ์ก็เข้าใกล้ตัวแทน AI มากขึ้นเรื่อยๆ:
- สิงหาคม 2025, s1ngularity: ผู้โจมตีขโมยโทเค็นการเผยแพร่จาก Nx ซึ่งเป็นหนึ่งในระบบสร้างซอฟต์แวร์ที่ใช้กันอย่างแพร่หลายที่สุด และผลักดันเวอร์ชันที่เป็นอันตรายไปยัง npm โดยใช้เครื่องมือ AI ในการค้นหาความลับในเครื่องของนักพัฒนา
- กันยายน 2025, chalk/debug: หนึ่งในเหตุการณ์การละเมิดข้อมูลครั้งใหญ่ที่สุดของ npm ในแง่ของขอบเขตการเข้าถึง คือแพ็กเกจ 18 รายการที่มีการดาวน์โหลดมากกว่าสองพันล้านครั้งต่อสัปดาห์ ถูกแฮ็กผ่านการแฮ็กบัญชีของผู้ดูแลเพียงคนเดียว
- กันยายน 2025, ชัยฮูลุด: เป็นหนึ่งในเวิร์มตัวแรกๆ ที่มีการบันทึกไว้ว่าสามารถแพร่กระจายตัวเองได้ผ่านทาง npm การระบาดระลอกที่สองในเดือนพฤศจิกายนนั้นรุนแรงกว่าและเชื่อมโยงกับข้อมูลลับที่ถูกเปิดเผยในคลังเก็บโค้ดมากกว่า 25,000 แห่ง
- ตุลาคม 2025, สินค้านำเข้าที่ไม่ได้ใช้: ส่วนหนึ่งของแคมเปญ PhantomRaven ซึ่งการใช้ AI สร้างภาพลวงตาเพื่อนำมัลแวร์จริงเข้าสู่ npm ผ่านเทคนิคการจดทะเบียนโดเมนโดยไม่ได้รับอนุญาต
- ในปีนี้ ClawHub: ระบบลงทะเบียนทักษะ AI ที่ปนเปื้อน ซึ่งทักษะที่มีการดาวน์โหลดมากที่สุด 7 อันดับแรกนั้น 5 ใน 7 ทักษะเป็นมัลแวร์
อุตสาหกรรมกำลังทำให้ข้อสรุปเดียวกันนี้เป็นทางการมากขึ้น OWASP Top 10 สำหรับแอปพลิเคชัน LLM จัดให้การแทรกข้อความแจ้งเตือน (prompt injection) อยู่ในอันดับหนึ่ง OWASP MCP Top 10 (ปัจจุบันอยู่ในช่วงเบต้า) มุ่งเป้าไปที่โปรโตคอลที่เอเจนต์ใช้ในการสื่อสารกับเครื่องมือต่างๆ OWASP Agentic Skills Top 10 ซึ่งเป็นโครงการใหม่ในระยะบ่มเพาะ ระบุว่าทักษะที่เป็นอันตรายเป็นความเสี่ยงสูงสุด OWASP มักจะดำเนินการอย่างระมัดระวัง การเปิดประเด็นสามด้านพร้อมกัน โดยหนึ่งในนั้นมีความเร่งด่วน บ่งบอกถึงความเร็วในการเปลี่ยนแปลงนี้
ทั้งสามประเด็นนี้ชี้ไปในทิศทางเดียวกัน นั่นคือ คำสั่ง เครื่องมือ และการตั้งค่าต่างๆ ที่เกี่ยวข้องกับโมเดลนั้น ล้วนเป็นส่วนหนึ่งของพื้นที่เสี่ยงต่อการโจมตีของ AI และโดยปกติแล้วสิ่งเหล่านี้จะอยู่ในคลังเก็บข้อมูลของคุณเอง ซึ่งนำไปสู่คำถามแรกที่ควรสอบถามทีมของคุณก็คือ ใครเป็นผู้ตรวจสอบไฟล์กฎ ทักษะ และการตั้งค่า MCP ที่อยู่ในคลังเก็บข้อมูลของคุณ?
เวกเตอร์ 1: ทักษะพิษ
ทักษะคือไฟล์คำสั่งและความสามารถที่สอนให้เอเจนต์ AI ทำงานบางอย่าง ไม่ใช่ว่าทักษะจะเป็นวิธีเดียวในการกำหนดพฤติกรรมของเอเจนต์ (ไฟล์กฎ) hooks(และไฟล์กำหนดค่า MCP ก็ทำเช่นเดียวกัน) แต่พวกมันมีคุณสมบัติร่วมกันอย่างหนึ่งคือ พวกมันจะเดินทางไปพร้อมกับโค้ดภายในที่เก็บข้อมูล
งานวิจัยในปีนี้ได้ทบทวนทักษะเหล่านี้จำนวน 4,000 รายการ:
- 36% มีช่องโหว่ด้านความปลอดภัยอย่างน้อยหนึ่งจุด
- 13.4% อยู่ในภาวะวิกฤต
- เกือบ 100 เครื่องมีมัลแวร์แฝงอยู่โดยตรง
การเปลี่ยนแปลงที่สำคัญคือ ผู้โจมตีไม่ได้มุ่งเป้าไปที่โค้ดของคุณอีกต่อไปแล้ว พวกเขาจะมุ่งเป้าไปที่เอเจนต์ที่เขียนโค้ดของคุณ โดยฝังคำสั่งที่ซ่อนไว้ (บางครั้งใช้ตัวอักษรที่มองไม่เห็น) ซึ่งโมเดลจะอ่านและประมวลผลราวกับว่าเป็นคำสั่งที่ใช้งานได้ จากนั้นผู้ตรวจสอบที่เป็นมนุษย์จะอนุมัติ pull request ด้วยความสุจริตใจ เพราะในสายตาของพวกเขา ไฟล์นั้นดูสะอาดเรียบร้อยดี โมเดลนั้นตีความคำสั่งที่ผู้ตรวจสอบไม่เคยเห็นมาก่อน
นี่ไม่ใช่เรื่องสมมติ ช่องโหว่ CVE-2025-59536 (CVSS 8.7) อนุญาตให้เรียกใช้ Claude Code จากแหล่งเก็บข้อมูลที่ไม่น่าเชื่อถือ ซึ่งการตั้งค่าที่เป็นอันตรายสามารถเรียกใช้คำสั่งต่างๆ ได้ก่อนที่ผู้ใช้จะยอมรับกล่องโต้ตอบความน่าเชื่อถือ ช่องโหว่ที่สอง CVE-2026-21852 อนุญาตให้ขโมยคีย์ API ผ่านการตั้งค่าที่ควบคุมโดยโปรเจกต์ โดยที่ผู้ใช้ไม่ได้อนุมัติอะไรเลย
H2: เวกเตอร์ 2: การนั่งยองๆ
ชื่อนี้เป็นการผสมผสานระหว่าง “slop” (ข้อมูลขยะที่ AI สร้างขึ้นในบางครั้ง) กับการโจมตีแบบ typosquatting แบบคลาสสิก การโจมตีแบบ typosquatting อาศัยความผิดพลาดของมนุษย์: ผู้โจมตีจะลงทะเบียนชื่อแพ็กเกจที่ใกล้เคียงกับชื่อที่นิยมใช้ และรอจังหวะที่ผู้ใช้พิมพ์ผิด ซึ่งเป็นการสุ่ม
การนั่งยองๆ ไม่รอให้เกิดความผิดพลาด ในการศึกษาที่อ้างถึงในระหว่างการบรรยายนี้ 19.7% ของการอ้างอิงแพ็กเกจที่สร้างโดยโมเดล AI ชี้ไปยังแพ็กเกจที่ไม่มีอยู่จริง โดยทั่วไปแล้ว โมเดล AI มักจะสร้างชื่อเดิมซ้ำๆ กัน ดังนั้นผู้โจมตีจึงคอยสังเกตว่า AI สร้างชื่ออะไรขึ้นมาบ้าง บันทึกชื่อเหล่านั้นด้วยโค้ดที่เป็นอันตราย และรอจังหวะที่ AI แนะนำการติดตั้งครั้งต่อไปเพื่อดึงซอฟต์แวร์นั้นเข้ามาในแอปพลิเคชันของคุณ
เรื่องนี้ไม่ใช่เรื่องเล็กเลย: มีการค้นพบแพ็กเกจมัลแวร์ใหม่มากกว่า 450,000 รายการในปี 2025 ตัวอย่างสองข้อนี้จะช่วยให้เข้าใจได้ชัดเจนยิ่งขึ้น:
- นักวิจัยได้วางกล่องทดสอบที่ไม่เป็นอันตรายชื่อว่า... กอดใบหน้า-cli เพื่อพิสูจน์ประเด็นนั้น มันบันทึกไว้ มียอดดาวน์โหลดมากกว่า 30,000 ครั้งภายในสามเดือน
- การนำเข้าที่ไม่ได้ใช้จากลำดับเหตุการณ์ข้างต้น พบว่ามีมัลแวร์ที่ได้รับการยืนยันแล้ว อยู่ในฐานข้อมูลสาธารณะ โดยใช้เทคนิคนี้อย่างแน่นอน นั่นไม่ใช่การทดสอบ
คำถามไม่ได้อยู่ที่ว่าเหตุการณ์แบบนี้จะเกิดขึ้นกับทีมของคุณได้หรือไม่ แต่เป็นว่ามีแพ็กเกจที่ AI แนะนำเข้ามาอยู่ในโค้ดของคุณมากแค่ไหนในวันนี้โดยที่ไม่มีใครตรวจสอบเลย
การตอบสนอง: standardกำลังตามทัน
สองพลังดำเนินไปพร้อมกัน ในขณะที่การโจมตีทวีความรุนแรงขึ้น standardร่างกายกำลังตอบสนอง:
- NIST SP 800-218A ขยายกรอบการพัฒนาซอฟต์แวร์ที่ปลอดภัยด้วยแนวปฏิบัติเฉพาะสำหรับโมเดล AI รวมถึงหลักฐานความถูกต้องและที่มาของข้อมูล
- In อาจ 2026, CISA และพันธมิตรระหว่างประเทศกลุ่ม G7 มีการเผยแพร่คำแนะนำเกี่ยวกับรายการส่วนประกอบซอฟต์แวร์สำหรับ AI โดยกำหนดสิ่งที่ควรอยู่ในรายการดังกล่าว ได้แก่ โมเดล ชุดข้อมูล ส่วนประกอบ ผู้ให้บริการ และการพึ่งพา
ทิศทางนั้นชัดเจน: SBOM กำลังขยายไปสู่ AI-BOM (Intelligent Business Module) คุณไม่สามารถรับรองหรือยืนยันในสิ่งที่คุณไม่สามารถตรวจสอบสินค้าคงคลังได้ และในปัจจุบัน องค์กรส่วนใหญ่ก็ไม่สามารถทำได้เช่นกัน:
- 43% ไม่สามารถตรวจสอบหรือจัดทำบัญชีรายการเครื่องมือ AI ที่พวกเขากำลังใช้งานอยู่ได้
- 79% ไม่มีข้อมูลใดๆ เกี่ยวกับเอเจนต์ AI และระบบ MCP ที่ทำงานอยู่ในสภาพแวดล้อมของตนเอง
ในสภาพแวดล้อมที่มีการควบคุม การตรวจสอบสินค้าคงคลังนี้กำลังเปลี่ยนจากแนวปฏิบัติที่ดีไปสู่ความคาดหวังตามสัญญาหรือภาระผูกพันตามข้อกำหนด แต่การตรวจสอบสินค้าคงคลังบอกได้เพียงว่าคุณมีอะไรอยู่บ้างเท่านั้น มันไม่สามารถป้องกันการโจมตีได้ด้วยตัวเอง
ช่องว่าง: EDR สำหรับ AppSec
SAST และ SCA เครื่องมือเหล่านี้ได้รับการออกแบบมาเพื่อวิเคราะห์โค้ดและความสัมพันธ์ของโค้ด ไม่ใช่พฤติกรรมของเอเจนต์หรือการกำหนดค่าของมัน EDR เครื่องมือเหล่านี้มองเห็นกระบวนการและการเชื่อมต่อเครือข่าย แต่โดยทั่วไปแล้วจะขาดบริบทด้านความปลอดภัยของแอปพลิเคชันในการตีความความสัมพันธ์หรือการกำหนดค่าเอเจนต์ ระหว่างเครื่องมือสองประเภทนี้จึงมีช่องว่างอยู่ ซึ่งเป็นจุดที่โค้ดถูกสร้างขึ้น และเป็นจุดที่พื้นผิวการโจมตีของ AI อยู่
ช่องว่างนั้นมีจุดบอดอยู่สามจุด:
- สินทรัพย์ AI โมเดล เอเจนต์ และเซิร์ฟเวอร์ MCP จะไม่ปรากฏบนหน้าจอของคุณ SASTของหรือ SCAมันเหมือนเรดาร์ คุณไม่สามารถสำรวจสิ่งที่คุณมองไม่เห็นได้
- ไฟล์การกำหนดค่า ทักษะ กฎ และการตั้งค่า MCP มีส่วนกำหนดพฤติกรรมของเอเจนต์ แต่โดยทั่วไปแล้วจะถูกตรวจสอบราวกับว่าเป็นข้อความธรรมดาที่ไม่เป็นอันตราย
- การติดตั้งแพ็กเกจ A การพึ่งพาที่เป็นอันตรายสามารถทำงานได้ก่อนที่จะทราบว่าเป็นอันตรายจากนั้นจึงลักลอบนำข้อมูลลับและโทเค็นออกไปโดยที่ไม่มีใครอนุมัติ
Xygeni ปิดมันอย่างไร
EDR ทำอะไรให้กับอุปกรณ์ปลายทางบ้าง ไซเกนี Shield ทำหน้าที่ปกป้องวงจรการพัฒนาที่ใช้ AI ช่วยเหลือ โดยคำนึงถึงตำแหน่งที่สร้างโค้ด พร้อมทั้งเข้าใจบริบทด้านความปลอดภัยของแอปพลิเคชัน
- การมองเห็นในที่ใด SAST และ SCA อย่าเอื้อมมือไป Xygeni จะตรวจจับทักษะและไฟล์กฎที่เป็นอันตราย วิเคราะห์การตั้งค่า MCP และสร้างไฟล์ที่พร้อมสำหรับการตรวจสอบ AI-BOMโดยเชื่อมโยงกับ 10 อันดับแรกของทักษะสำคัญในหลักสูตร OWASP LLM, MCP และ Agentic Skills
- ข้อมูลข่าวกรองสำคัญกว่าลายเซ็นเพียงอย่างเดียว MEW (Malware Early Warning) วิเคราะห์พฤติกรรมและความเสี่ยงของโปรแกรมมัลแวร์เพื่อบล็อกก่อนที่จะมีการประกาศ CVE, คำแนะนำ หรือลายเซ็นสาธารณะ ระบบข่าวกรองเครือข่ายที่ทันสมัยจะตัดการเชื่อมต่อกับโครงสร้างพื้นฐานที่เป็นอันตรายที่รู้จักกันดี
- จุดควบคุมเดียว ตั้งแต่โค้ดจนถึงปลายทาง เอเจนต์เพียงตัวเดียว สามารถใช้งานได้โดยไม่ต้องปรับโครงสร้างสภาพแวดล้อมใหม่ พร้อมด้วยหลักฐานการรักษาอธิปไตยทางข้อมูลและการปฏิบัติตามกฎระเบียบของยุโรปที่ติดตั้งมาในตัว
ในการสาธิตสด การบังคับใช้นโยบายนี้ได้บล็อกความพยายามของเอเจนต์ AI ในการติดตั้งแพ็กเกจที่เป็นอันตรายผ่านเส้นทางการติดตั้งที่แตกต่างกันสามเส้นทาง (สภาพแวดล้อมเสมือนจริง ตัวจัดการแพ็กเกจ และการดาวน์โหลดโดยตรง) ก่อนที่การติดตั้งจะเสร็จสมบูรณ์ โดยทั้งหมดจะถูกบันทึกแบบเรียลไทม์และสามารถส่งออกไปยัง SOC ได้ การเริ่มต้นโครงการแรกโดยทั่วไปใช้เวลาประมาณหนึ่งชั่วโมง การขยายการครอบคลุมไปทั่วทั้งองค์กรโดยปกติจะใช้เวลาหนึ่งถึงสองสัปดาห์ ขึ้นอยู่กับโครงสร้าง
คำถามที่พบบ่อย
ในย่อหน้าเดียว พื้นที่เสี่ยงต่อการโจมตีของ AI คืออะไร?
พื้นผิวการโจมตีของ AI คือชุดของโมเดล เอเจนต์ เซิร์ฟเวอร์ MCP ทักษะ ไฟล์กฎ และการพึ่งพาที่ AI แนะนำ ซึ่งความเสี่ยงสามารถแทรกซึมเข้าสู่แอปพลิเคชันได้ บ่อยครั้งก่อนที่มนุษย์จะตรวจสอบ นอกจากนี้ยังครอบคลุมมากกว่าโค้ดและการพึ่งพาแบบดั้งเดิม โดยรวมถึงไฟล์การกำหนดค่าและคำสั่งที่กำหนดพฤติกรรมของเอเจนต์ AI ด้วย
ฉันจะรู้ได้อย่างไรว่าชื่อแพ็กเกจที่ผู้ช่วย AI แนะนำนั้นเป็นภาพลวงตาหรือเป็นชื่อที่ถูกต้องแต่ฉันไม่คุ้นเคย?
ตรวจสอบความถูกต้องก่อนติดตั้ง: ตรวจสอบรีจิสทรีและวิเคราะห์เนื้อหาและจุดประสงค์ที่แท้จริงของแพ็กเกจ แทนที่จะเชื่อแค่ชื่อแพ็กเกจเพียงอย่างเดียว Xygeni จะทำการตรวจสอบความถูกต้องนี้โดยอัตโนมัติแบบเรียลไทม์ในระหว่างการสร้างโค้ด ดังนั้นการติดตั้งจะได้รับการอนุมัติหรือถูกบล็อกก่อนที่จะเริ่มทำงาน ไม่ว่าแพ็กเกจนั้นจะเป็นแพ็กเกจที่คุณรู้จักหรือไม่ก็ตาม
การนั่งยองๆ ส่งผลกระทบต่อโมเดล AI ทุกตัวเท่ากันหรือไม่?
งานวิจัยที่อยู่เบื้องหลังตัวเลข 19.7% นี้ครอบคลุมโมเดลหลายแบบและพบว่าปัญหานี้กระจายตัวอย่างกว้างขวาง โดยมีความแตกต่างกันเพียงเล็กน้อยระหว่างโมเดลต่างๆ นี่เป็นรูปแบบที่พบได้ทั่วไปในการพัฒนาโดยใช้ AI ไม่ใช่ข้อบกพร่องเฉพาะของ AI ผู้ช่วยตัวใดตัวหนึ่ง
เราสามารถตรวจสอบย้อนหลังได้หรือไม่ว่าเราได้ติดตั้งแพ็กเกจที่ทำให้เกิดภาพลวงตาหรือเป็นอันตรายไปแล้วหรือไม่?
ใช่แล้ว แพลตฟอร์มของ Xygeni ช่วยให้ลูกค้าเข้าถึงฐานข้อมูลที่ได้รับการดูแลรักษาอย่างดีของแพ็กเกจมัลแวร์ที่ตรวจพบ ซึ่งสามารถค้นหาได้ในรายการส่วนประกอบที่มีอยู่ของคุณ ดังนั้นคุณจึงสามารถตรวจสอบได้ในไม่กี่คลิกว่าสิ่งใดที่ติดตั้งอยู่แล้วเป็นภัยคุกคามที่รู้จักหรือไม่
การดำเนินการติดตั้งระบบสำหรับองค์กรขนาดกลางที่มีหลายทีมใช้เวลานานแค่ไหน?
โดยทั่วไป การเริ่มต้นใช้งานโปรเจกต์แรกจะใช้เวลาประมาณหนึ่งชั่วโมง การขยายผลไปทั่วทั้งองค์กรมักใช้เวลาหนึ่งถึงสองสัปดาห์ ขึ้นอยู่กับโครงสร้างทีมและวิธีการทำงาน
สร้างแผนที่แสดงจุดอ่อนของการโจมตี AI ของคุณได้ฟรี
ตรวจสอบร่องรอยการใช้งาน AI ของแอปพลิเคชันของคุณได้ฟรี: สร้างบัญชีผู้ใช้และ ทำการสแกนครั้งแรกภายในไม่กี่นาทีเริ่มต้นด้วยแอปพลิเคชันเดียว ตรวจสอบดูว่ามี AI อะไรอยู่ภายใน และดูว่าส่วนใดของช่องโหว่การโจมตี AI ของคุณที่อันตราย
*ความสามารถบางอย่างที่กล่าวถึงข้างต้นนั้นถูกบังคับใช้ผ่านทาง Xygeni Shield และ ASPMโมดูลรักษาความปลอดภัย AI; ความพร้อมใช้งานอาจแตกต่างกันไปตามแพ็กเกจ โปรดดูรายละเอียดเพิ่มเติม xygeni.io สำหรับรายละเอียดสินค้าปัจจุบัน
