ครั้งต่อไปที่ผู้ช่วย AI แนะนำแพ็กเกจให้ติดตั้ง คุณจะตรวจสอบหรือไม่ว่ามันมีอยู่จริงหรือไม่? นักพัฒนาส่วนใหญ่ไม่ได้ทำเช่นนั้น ช่องว่างระหว่างคำแนะนำและการตรวจสอบนี้เองที่เป็นจุดเริ่มต้นของการโจมตีแบบ slopsquatting และในเวลาไม่ถึงสามปี ภัยคุกคามนี้ได้พัฒนาจากแนวคิดต้นแบบของนักวิจัยไปสู่การเรียกใช้โค้ดจากระยะไกลภายในเอเจนต์การเขียนโค้ดอัตโนมัติ บทความนี้จะติดตามวิวัฒนาการของการโจมตีแบบ slopsquatting และความหมายของแต่ละขั้นตอนสำหรับทีม AppSec และ DevSecOps
เพิ่งมาใหม่ใช่ไหม? เริ่มจากคำแนะนำเบื้องต้นของเราก่อนเลย การนั่งยองๆ ในที่โล่งคืออะไร และจะป้องกันได้อย่างไรจากนั้นค่อยกลับมาดูไทม์ไลน์
การโจมตีด้วยการนั่งยองๆ ในย่อหน้าเดียว
การโจมตีแบบนั่งยองๆ ลงทะเบียนแพ็กเกจที่เป็นอันตรายภายใต้ชื่อที่แบบจำลอง AI คาดเดาได้อย่างแม่นยำ ในกรณีที่ typosquatting ใช้ประโยชน์จากความผิดพลาดในการพิมพ์ของมนุษย์ คำขอ สำหรับ การร้องขอการโจมโจมแบบ slopsquatting นั้นใช้ประโยชน์จากโมเดลดังกล่าว โดยการสร้างชื่อที่ดูน่าเชื่อถือแต่ไม่มีอยู่ในทะเบียนใดๆ จากนั้นผู้โจมตีจะอ้างสิทธิ์ในชื่อนั้นก่อนที่บุคคลที่ถูกต้องตามกฎหมายจะทำได้ คำนี้ถูกบัญญัติโดย Seth Larson นักพัฒนาความปลอดภัยประจำ Python Software Foundation และได้รับความนิยมจาก Andrew Nesbitt สิ่งที่ทำให้รูปแบบนี้ควรค่าแก่การติดตามคือความเร็วในการพัฒนาของมัน
วิวัฒนาการของการนั่งยองๆ
ปี 2023: สัญญาณเตือนแรก
บาร์ ลานยาโด นักวิจัยด้านความปลอดภัย สังเกตเห็นว่า LLM หลายรายแนะนำแพ็กเกจที่ชื่อว่า กอดใบหน้า-cliซึ่งไม่มีอยู่จริง (เครื่องมือจริงจะติดตั้งด้วย pip install -U “huggingface_hub[cli]”เพื่อแสดงให้เห็นถึงความเสี่ยง เขาได้อัปโหลดแพ็กเกจเปล่าภายใต้ชื่อที่สร้างขึ้นมาเองนั้น ภายในสามเดือน แพ็กเกจดังกล่าวถูกดาวน์โหลดไปมากกว่า 30,000 ครั้ง โดยไม่มีการโปรโมทใดๆ และชื่อปลอมนั้นยังปรากฏอยู่ในไฟล์ README ของแหล่งเก็บข้อมูลที่เชื่อมโยงกับการวิจัยจากบริษัทเทคโนโลยีขนาดใหญ่แห่งหนึ่ง แพ็กเกจนั้นไม่มีอันตราย แต่บทเรียนที่ได้นั้นไม่ใช่เช่นนั้น: ชื่อที่สร้างขึ้นมาเองนั้น เพียงแค่มีความสอดคล้องกันมากพอ ก็เพียงพอแล้วที่ใครบางคนจะนำไปใช้เป็นอาวุธได้
ปี 2024: จากบทความในบล็อกสู่การรายงานข่าวในสื่อกระแสหลัก
ในเดือนมีนาคม 2024 เว็บไซต์ The Register รายงานเกี่ยวกับโมเดล AI ที่คิดค้นชื่อแพ็กเกจซอฟต์แวร์ได้อย่างมั่นใจ ซึ่งนักพัฒนาได้ดาวน์โหลดไปใช้งาน โดยบางชื่ออาจแฝงด้วยมัลแวร์ ความสำคัญของรายงานนี้ไม่ได้อยู่ที่รายละเอียดทางเทคนิคมากนัก แต่เป็นสิ่งที่บ่งชี้ถึงปัญหาสำคัญมากกว่า: กอดใบหน้า-cli เรื่องนี้ไม่ได้เป็นเพียงเรื่องแปลกประหลาดที่เกิดขึ้นเพียงครั้งเดียวอีกต่อไป แต่เป็นสัญญาณแรกของรูปแบบที่ร้ายแรงพอที่สื่อเทคโนโลยีหลักจะหยิบยกขึ้นมาพูดถึง ก่อนที่จะมีการศึกษาขนาดใหญ่ที่ยืนยันขอบเขตของมันในอีกหนึ่งปีต่อมา
ปี 2025: การวัดผลอย่างเข้มงวดครั้งแรก
บทความ “We Have a Package for You!” (Spracklen et al.) จากงาน USENIX Security 2025 ได้ทดสอบโมเดลการสร้างโค้ด 16 แบบ ทั้งแบบเชิงพาณิชย์และโอเพนซอร์ส กับตัวอย่างโค้ด Python และ JavaScript จำนวน 576,000 ตัวอย่าง ทำให้ปัญหา slopsquatting กลายเป็นข้อมูลเชิงสถิติ:
- 19.7% ของแพ็กเกจที่แนะนำนั้นไม่มีอยู่จริง
- โมเดลโอเพนซอร์สเกิดอาการประสาทหลอนบ่อยกว่ามาก (เฉลี่ย 21.7%) เมื่อเทียบกับโมเดลเชิงพาณิชย์ (5.2%)
- ผู้กระทำผิดที่ร้ายแรงที่สุด ได้แก่ CodeLlama 7B และ 34B ซึ่งมีอาการประสาทหลอนในผลงานมากกว่าหนึ่งในสามของทั้งหมด
- จากการศึกษาในทุกแบบจำลอง นักวิจัยได้บันทึกชื่อหลอนประสาทที่ไม่ซ้ำกันกว่า 205,000 ชื่อ ซึ่งเป็นปริมาณที่มากพอที่จะใช้เป็นแหล่งข้อมูลในการรณรงค์อย่างต่อเนื่องในระบบนิเวศต่างๆ
การศึกษาครั้งนี้ยังจำแนกประเภทของสินค้าปลอมว่าเกิดขึ้นได้อย่างไร โดย 38% เป็นการผสมผสานชื่อบรรจุภัณฑ์จริงสองชื่อเข้าด้วยกัน (ซึ่งเป็นรูปแบบเดียวกับที่เกิดขึ้นในภายหลัง) รีแอค-โค้ดชิฟต์ จาก jscodeshift และ รีแอค-โค้ดม็อด(โดย 13% เป็นรูปแบบการพิมพ์ผิดของบรรจุภัณฑ์จริง และ 51% เป็นการสร้างขึ้นมาเองทั้งหมด ซึ่งฟังดูสมเหตุสมผลแต่เป็นเรื่องที่แต่งขึ้นทั้งหมด กลุ่มแรกมีความสำคัญที่สุดสำหรับงานด้านการป้องกันประเทศ เพราะชื่อที่นำมาประกอบกันจากเครื่องมือจริงสองชิ้นนั้นยากที่สุดที่จะสังเกตเห็นได้ในทันที)
สิ่งที่สำคัญที่สุดสำหรับผู้โจมตีคือ ภาพหลอนไม่ได้เกิดขึ้นแบบสุ่มและไม่เปลี่ยนแปลงในทุกครั้งที่ลอง เมื่อนักวิจัยทำการทดลองซ้ำโดยใช้คำสั่งเดียวกัน 10 ครั้ง พบว่า 43% ของชื่อที่ปรากฏในภาพหลอนนั้นปรากฏขึ้นในทุกครั้งที่ทำการทดลอง และ 58% ปรากฏซ้ำมากกว่าหนึ่งครั้ง ผู้โจมตีไม่จำเป็นต้องเดา พวกเขาสังเกตพฤติกรรมของแบบจำลอง จดบันทึกชื่อที่ปรากฏซ้ำๆ และลงทะเบียนชื่อเหล่านั้นก่อน ความสามารถในการทำซ้ำนี้เองที่เปลี่ยนภาพหลอนที่เกิดขึ้นเพียงครั้งเดียวให้กลายเป็นการโจมตีที่สามารถขยายขนาดได้
2026: จากแพ็กเกจแบบแยกส่วนสู่เอเจนต์อิสระ
ปีนี้มีหลักฐานที่ชัดเจนที่สุดว่า การยึดครองพื้นที่โดยมิชอบ (slopsquatting) ไม่ได้จำกัดอยู่แค่การที่นักพัฒนาคัดลอกและวางข้อเสนอแนะอีกต่อไปแล้ว ติดตั้ง NPM.
ในเดือนมกราคมปี 2026 นักวิจัยด้านความปลอดภัย Charlie Eriksen ค้นพบแพ็กเกจ npm ที่สร้างขึ้นโดยไม่ได้รับอนุญาต รีแอค-โค้ดชิฟต์คำสั่งของเอเจนต์ที่สร้างโดย AI นั้นได้แพร่กระจายไปยังแหล่งเก็บข้อมูล 237 แห่งแล้วผ่านทาง fork โดยที่เอเจนต์ยังคงพยายามติดตั้งมันทุกวัน ต้นกำเนิดของมันมาจากแหล่งเก็บข้อมูลเพียงแห่งเดียว commit เป็นไฟล์ทักษะของเอージェนต์ที่เขียนโดย AI ซึ่งไม่มีมนุษย์ตรวจสอบมาก่อน เอริคเซนจดทะเบียนชื่อนั้นด้วยตนเองเพื่อป้องกันตัวเอง ก่อนที่ผู้โจมตีจะนำไปใช้เป็นอาวุธ
นอกจากนี้ ยังมีแพ็กเกจที่เป็นอันตรายอย่างแท้จริงชื่อว่า การนำเข้าที่ไม่ได้ใช้ภาพลวงตาที่เกิดขึ้นแทนที่สิ่งที่ถูกต้อง eslint-plugin-unused-importsแม้ว่า npm จะระงับการใช้งานเพื่อความปลอดภัยแล้ว แต่ก็ยังคงทำการติดตั้งต่อไป แสดงให้เห็นว่าการโจมตีแบบ slopsquatting สามารถหาเหยื่อได้นานแค่ไหนหลังจากที่ถูกแจ้งเตือนแล้ว
ต่อมาในเดือนกรกฎาคม ปี 2026 นักวิจัยได้อธิบายถึงเทคนิคที่เกี่ยวข้องซึ่งเรียกว่า “HalluSquatting” ที่เชื่อมโยงภาพลวงตาเข้ากับการแทรกคำสั่ง: ตัวแทนการเขียนโค้ด AI ที่ดึงทรัพยากรภาพลวงตาในนามของผู้ใช้สามารถถูกแฮ็กให้รันโค้ดที่ผู้โจมตีจัดหามาได้ นี่เป็นการขยายวิวัฒนาการของ slopsquatting จากความเสี่ยงในการติดตั้งแบบพาสซีฟไปสู่ช่องทางการเรียกใช้โค้ดจากระยะไกลแบบแอคทีฟภายในเวิร์กโฟลว์การพัฒนาของตัวแทน
เหตุใด “การเขียนโค้ดตามความรู้สึก” จึงขยายช่องโหว่ให้กว้างขึ้น
การโจมตีแบบ Slopsquatting คงไม่สำคัญมากนักหากโค้ดที่สร้างโดย AI เป็นเรื่องเฉพาะกลุ่ม แต่มันไม่ใช่ การเกิดขึ้นของตัวช่วยเขียนโค้ด ตัวแทนอัตโนมัติ และเวิร์กโฟลว์ "vibe coding" ซึ่งนักพัฒนาตรวจสอบโค้ดน้อยลงก่อนที่จะรัน ได้เปลี่ยนพื้นที่การโจมตีไปในสองด้านที่ชัดเจน
ประการแรก จุดเริ่มต้นของการโจมตีไม่ได้จำกัดอยู่แค่ผู้พัฒนาซอฟต์แวร์อีกต่อไป การโจมตีแบบ typosquatting เคยขึ้นอยู่กับการพิมพ์ผิดของคนเพียงคนเดียว แต่ตอนนี้ความผิดพลาดเกิดขึ้นภายในโมเดลและแพร่กระจายไปยังผู้พัฒนาซอฟต์แวร์หลายร้อยคนที่ถามคำถามคล้ายกันและได้รับคำแนะนำที่ผิดพลาดเหมือนกัน
ประการที่สอง พื้นที่การโจมตีได้ขยายขึ้นไปตามห่วงโซ่แล้ว การตรวจสอบโค้ดที่มนุษย์เขียนเพียงอย่างเดียวไม่เพียงพออีกต่อไป ทีมงานต้องตรวจสอบการพึ่งพาที่ผู้ช่วย AI แนะนำ เซิร์ฟเวอร์ MCP ที่เชื่อมต่อ และเอเจนต์ที่ติดตั้งแพ็กเกจโดยไม่มีมนุษย์เข้ามาเกี่ยวข้อง AppSec แบบดั้งเดิมถูกสร้างขึ้นเพื่อตรวจสอบที่เก็บโค้ดและมนุษย์ commits ไม่ได้ถูกออกแบบมาเพื่อสังเกตปฏิสัมพันธ์ระหว่างนักพัฒนา AI และรีจิสทรี ซึ่งเป็นจุดที่การจดทะเบียนโดเมนโดยไม่ได้รับอนุญาตซ่อนตัวอยู่
สิ่งนี้หมายความว่าอย่างไรสำหรับการป้องกัน
ทั้งหมดนี้ไม่ได้ทำให้ AI แบบสร้างข้อมูลเองนั้นไม่ปลอดภัยโดยเนื้อแท้ แต่มันนำมาซึ่งความเสี่ยงในห่วงโซ่อุปทานที่เครื่องมือแบบดั้งเดิมไม่ได้ถูกสร้างมาเพื่อตรวจจับ และมันเรียกร้องให้ใช้หลักการตรวจสอบที่เราใช้กับส่วนประกอบภายนอกใดๆ อยู่แล้ว นั่นคือ อย่าเชื่อใจโดยปริยาย ตรวจสอบแหล่งที่มา และทำการตรวจสอบโดยอัตโนมัติแทนที่จะพึ่งพาความจำของนักพัฒนาทุกคน คู่มือการป้องกันฉบับเต็มอยู่ในคู่มือของเรา ความปลอดภัยของห่วงโซ่อุปทาน AIแต่โดยสรุปแล้ว การตรวจสอบด้วยตนเอง แม้จะยังจำเป็นอยู่ แต่ก็ไม่สามารถใช้งานได้อย่างมีประสิทธิภาพในวงกว้างเมื่อชื่อที่ถูกสร้างขึ้นมาใหม่สามารถเข้าถึงนักพัฒนาหลายพันคนพร้อมกัน หรือเมื่อเอเจนต์สามารถติดตั้งได้โดยไม่ต้องมีการตรวจสอบจากมนุษย์เลย
หยุดการติดตั้งแพ็กเกจที่สร้างขึ้นโดยไม่ได้รับอนุญาต ก่อนที่เอเจนต์จะติดตั้งลงไป
กรณีศึกษาทั้ง 2026 กรณีมีลักษณะร่วมกันอย่างหนึ่งคือ การติดตั้งที่เป็นอันตรายเกิดขึ้นโดยไม่มีมนุษย์เข้ามาเกี่ยวข้อง นั่นคือช่องโหว่ที่แท้จริง ไซเกนี Shield สร้างขึ้นมาเพื่อ... Shield เป็นเอเจนต์ขนาดเล็กบนเครื่องปลายทางของนักพัฒนาซอฟต์แวร์ที่บล็อกแพ็กเกจที่เป็นอันตรายในระหว่างการติดตั้ง โดยใช้ ระบบแจ้งเตือนมัลแวร์ล่วงหน้า (MEW) คำตัดสินที่ใช้งานได้ก่อนที่จะมีลายเซ็นใดๆ เมื่อผู้ช่วย AI หรือตัวแทนอัตโนมัติพยายามติดตั้งแพ็กเกจที่ลงทะเบียนใหม่ซึ่งถูกสร้างขึ้นมาอย่างผิดๆ Shield ระบบจะประเมินไฟล์ขณะที่ถูกดึงมาและบล็อกไฟล์นั้น ทำให้สคริปต์การติดตั้งไม่ทำงาน ไม่ว่าจะมีคนเฝ้าดูอยู่หรือไม่ก็ตาม ทุกบล็อกจะไหลลงสู่ที่เดียวกัน ไซเกนี คอนโซลจะแสดงผลลัพธ์ของโค้ด การสร้าง และการทำงานแบบเรียลไทม์ และ Shield ทำงานควบคู่ไปกับ EDR ที่มีอยู่ของคุณ ไม่ใช่ทำงานขัดแย้งกับมัน
เริ่มใช้งานฟรี แพ็คเกจ Developer ของ Xygeni ราคา 0 ยูโร: รองรับ 10 repository, สแกนได้ 200 ครั้งต่อเดือน, ผู้ร่วมพัฒนาได้สูงสุด 5 คน, ไม่ต้องใช้บัตรเครดิต Sign up with GitHubใช้ GitLab หรือ Google และทำการสแกนครั้งแรกได้ภายในเวลาไม่ถึง 10 นาที Shield ระบบป้องกันปลายทาง (Endpoint Protection) จะถูกเพิ่มเข้ามาในแพ็กเกจ Developer ในเร็วๆ นี้
คำถามที่พบบ่อย
โปรแกรมจัดการแพ็กเกจสามารถป้องกันการละเมิดลิขสิทธิ์โดยการจดทะเบียนชื่อโดเมนโดยไม่ได้รับอนุญาตได้ด้วยตัวเองหรือไม่?
ไม่ทั้งหมด ระบบตรวจจับการชนกันของชื่อใน npm จะบล็อกชื่อที่คล้ายกับชื่อแพ็กเกจที่มีอยู่แล้ว ซึ่งช่วยป้องกันการปลอมแปลงชื่อ (typosquatting) ได้ แต่ชื่อที่สร้างขึ้นมาใหม่ (hallucinated name) เป็นสตริงใหม่เอี่ยมที่ไม่มีการตรวจจับการชนกัน หากผู้โจมตีลงทะเบียนแพ็กเกจที่สร้างขึ้นมาใหม่ก่อนที่นักพัฒนาจะติดตั้ง การติดตั้งจะเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด เพราะแพ็กเกจนั้นมีอยู่จริง การป้องกันจำเป็นต้องตรวจสอบที่มาและพฤติกรรมของแพ็กเกจ ไม่ใช่แค่การตรวจสอบของระบบลงทะเบียนเองเท่านั้น
อะไรทำให้กรณีตัวแทนในปี 2026 แตกต่างจากการบุกรุกที่ดินในอดีต?
เหตุการณ์ก่อนหน้านี้ขึ้นอยู่กับการที่มนุษย์คัดลอกและวางคำสั่งติดตั้งที่แนะนำ แต่ใน 2026 กรณีนั้น เอเจนต์อัตโนมัติได้ติดตั้งหรือพยายามติดตั้งแพ็กเกจที่สร้างขึ้นมาโดยไม่มีมนุษย์ตรวจสอบขั้นตอน และเทคนิค HalluSquatting ได้ก้าวไปอีกขั้นด้วยการเชื่อมโยงการสร้างภาพลวงตาเข้ากับการแทรกข้อความแจ้งเตือนเพื่อให้สามารถเรียกใช้โค้ดจากระยะไกลภายในเวิร์กโฟลว์ของเอเจนต์ได้
