ทำไมการตรวจสอบมนุษย์ยังจำเป็น แม้โค้ดจาก AI ดูถูกต้อง

โค้ดจาก AI ไม่ใช่โค้ดปลอดภัยโดยอัตโนมัติ

การตรวจสอบโค้ด AI คือกระบวนการที่องค์กรบังคับให้มนุษย์ตรวจดูโค้ดหรือแพคเกจที่ผู้ช่วยเขียนโค้ดด้วย AI เสนอให้ ก่อนนำไปใช้จริง โดยไม่เชื่อผลลัพธ์จากเครื่องมือหรือเทสต์อัตโนมัติแบบลอย ๆ แต่ต้องตรวจแหล่งที่มา เนื้อโค้ด และความสอดคล้องกับข้อกำกับดูแลอย่างละเอียด เพื่อป้องกันโค้ดเปราะบางหรือแพคเกจ malware ที่ถูกแฝงมาในชื่อที่ดูน่าเชื่อถือ

ปัญหาที่หลายทีมมองข้ามคือ โค้ดที่ AI สร้างอาจผ่านเทสต์และดูสะอาด แต่กลับมีช่องโหว่ด้านความปลอดภัยอย่างน่าเป็นห่วง งานศึกษาหนึ่งพบว่าโปรแกรมที่สร้างด้วย Copilot 1,689 ชิ้นมีช่องโหว่ถึง 40% ของทั้งหมด ซึ่งหมายความว่าเกือบครึ่งของสิ่งที่ถูก merge เข้าไปในฐานโค้ดมีความเสี่ยง แม้จะมีชื่อมนุษย์กดอนุมัติอยู่บน pull request ก็ตาม การเห็นสถานะ “approved” เลยกลายเป็นภาพลวงตา ทำให้ทีมคิดว่าระบบปลอดภัย ทั้งที่การตรวจสอบมนุษย์แทบไม่ได้เกิดขึ้นจริง

เมื่อ AI เสนอแพคเกจ malware ที่ดูเหมือนปลอดภัย

กรณีของวิศวกรที่ถาม AI ให้แนะนำแพคเกจสำหรับงานทั่วไปแล้วได้รับชื่อไลบรารีที่ฟังดูถูกต้อง เป็นภาพสะท้อนชัดว่าความปลอดภัยโค้ดไม่ควรถูกฝากไว้กับ AI โดยลำพัง ชื่อแพคเกจถูกจัดรูปแบบเหมือนไลบรารียอดนิยม ทำให้ดูน่าเชื่อถือสำหรับคนที่รีบส่งงานหรือเชื่อเครื่องมือมากเกินไป ถ้าองค์กรนั้นไม่มีนโยบายตรวจสอบแหล่งที่มาและโค้ดก่อนติดตั้ง ก็มีโอกาสสูงที่จะลงแพคเกจ malware เข้าไปในระบบโดยไม่รู้ตัว

ผู้โจมตีเริ่มฉวยโอกาสจากพฤติกรรม “หลงเชื่อชื่อแพคเกจ” ของ AI โดยใช้เทคนิคที่นักวิจัยเรียกว่า slopsquatting คือรอให้โมเดล AI แต่งชื่อแพคเกจที่ดูสมเหตุสมผลแต่ไม่มีอยู่จริง แล้วไปลงทะเบียนแพคเกจจริงภายใต้ชื่อนั้น จากนั้นก็วาง payload เพื่อเปิดช่องทาง backdoor หรือขโมยข้อมูล เมื่อวิศวกรเผลอติดตั้ง แพคเกจ malware เหล่านี้อาจให้คนร้ายเข้าถึงระบบจากระยะไกลหรือทำลายซัพพลายเชนซอฟต์แวร์ได้ กรณีที่องค์กรหนึ่งรอดมาได้ก็เพราะมีนิสัยตรวจจำนวนดาวน์โหลดและอ่านซอร์สโค้ดบน GitHub ทุกครั้งก่อนติดตั้ง

• ตรวจเช็กจำนวนดาวน์โหลดและประวัติรีลีสของแพคเกจจาก registry หรือ GitHub ก่อนติดตั้ง
• อ่านซอร์สโค้ดอย่างน้อยส่วนหลัก เพื่อมองหโค้ดที่พยายาม exfiltrate ข้อมูลหรือเปิดพอร์ตแปลก ๆ
• ตั้งนโยบายองค์กรว่าห้ามติดตั้งแพคเกจที่ AI แนะนำ หากไม่มีการตรวจสอบมนุษย์ยืนยัน

การตรวจสอบมนุษย์คือด่านสุดท้าย ไม่ใช่ขั้นตอนอัตโนมัติ

ปัญหาใหญ่ของการพึ่งพา AI คือ automation bias เมื่อทีมเริ่มเชื่อผลลัพธ์จากเครื่องมือมากขึ้น ก็หยุดตั้งคำถามและละเลยการตรวจสอบมนุษย์ การรีวิวโค้ดที่ AI สร้างต้องใช้พลังสมองเพิ่มขึ้นอย่างชัดเจน ซึ่ง 38% ของนักพัฒนาบอกว่ารู้สึกได้ นี่คือเงื่อนไขที่ทำให้หลายคนจบการรีวิวด้วยการมองว่าเทสต์ผ่านก็พอแล้ว ไม่ได้ตรวจดูว่ามีโค้ดอันตรายหรือแพคเกจแปลกปลอมแฝงมาหรือไม่

การมีชื่อรีวิวเวอร์บน PR ไม่ได้แปลว่าการตัดสินใจเกิดขึ้น แต่แปลว่ามีคนกดปุ่ม approve เท่านั้น เป็นการสร้าง “ความรับผิดชอบแบบยืมชื่อ” ที่อันตรายอย่างยิ่งในสภาพแวดล้อมที่ถูกกำกับดูแล เพราะโค้ดที่ AI เขียนอาจสอดคล้องกับเทสต์แต่ขัดกับเจตนาของข้อกำกับ หรือเปลี่ยนรูปแบบการล็อกข้อมูลจนทำให้ระบบไม่สามารถตรวจสอบย้อนหลังในอนาคตได้ สิ่งเหล่านี้ไม่มีทางให้โมเดลตัดสินแทนมนุษย์ได้ การตรวจสอบมนุษย์จึงต้องถูกออกแบบให้มีขอบเขตงานชัดเจน เช่น จำกัดขนาด diff ให้ไม่เกินระดับที่คนอ่านไหว และกำหนดให้โค้ดที่แตะเรื่อง compliance ต้องมีเจ้าของมนุษย์ชัดเจนทุกครั้ง

1. กำหนดขนาดโค้ดต่อหนึ่งรีวิวให้สั้นลง ใกล้เคียงระดับที่มนุษย์อ่านแล้วเข้าใจภาพรวมได้
2. แยกรีวิวที่เกี่ยวกับข้อกำกับและโครงสร้างระบบให้คนที่มีความรู้เฉพาะรับผิดชอบ
3. บังคับให้รีวิวเวอร์อธิบายให้ได้ว่า “ถ้าโค้ดนี้ผิด มันจะผิดแบบไหน” ก่อนอนุมัติ

นโยบายองค์กร: ตรวจสอบโค้ด AI ก่อน deploy เสมอ

บทเรียนจากกรณีแพคเกจ malware ชี้ชัดว่า นโยบายองค์กรที่เน้นความปลอดภัยโค้ดไม่ได้เป็นเรื่องสวยหรูบนกระดาษ แต่เป็นสัญญาณว่าองค์กรยอมเสียเวลาเพิ่มเล็กน้อย เพื่อไม่ต้องเสียหายทั้งซัพพลายเชนในภายหลัง บริษัทหนึ่งรอดจากการติดตั้งแพคเกจ malware เพราะมีนโยบายชัดเจนให้วิศวกร “double-check” ซอฟต์แวร์ทุกตัวที่ AI แนะนำว่าถูกต้องและปลอดภัยก่อน และสร้างนิสัยตรวจจำนวนดาวน์โหลดกับอ่านซอร์สโค้ดบน GitHub ก่อนติดตั้งเสมอ

องค์กรที่ใช้ AI เป็นผู้ช่วยเขียนโค้ดควรเขียนนโยบายตรวจสอบโค้ด AI ให้ชัดเจน เช่น ห้ามใช้แพคเกจที่ไม่มีประวัติการใช้งานชัดเจน หรือไม่มีคนรับผิดชอบรีวิว พร้อมกำหนดให้โค้ดจาก AI ทุกชิ้นต้องผ่านการตรวจสอบมนุษย์ก่อน merge และสำหรับซอฟต์แวร์ที่ถูกกำกับดูแล ต้องระบุเจ้าของโค้ดที่เป็นมนุษย์อย่างชัดเจน ไม่ใช่ใช้คณะกรรมการหมุนเวียนที่ไม่มีใครรับผิดชอบจริง การมีมนุษย์ตรวจซัพพลายเชนและโค้ดภายนอกทุกครั้งที่นำเข้าจึงไม่ใช่ทางเลือก แต่เป็นมาตรฐานใหม่ที่องค์กรควรยึด ถ้าไม่อยากให้ AI กลายเป็นช่องโหว่ใหญ่ในระบบของตัวเอง

บทสรุป: อย่าให้ชื่อแพคเกจและปุ่ม approve หลอกคุณ

เมื่อโค้ดถูกสร้างด้วย AI และรีวิวด้วยเครื่องมืออัตโนมัติ ความเร็วและความสะดวกอาจทำให้ทีมเข้าใจผิดว่าระบบปลอดภัยแล้ว ทั้งที่ตัวเลขชี้ว่าช่องโหว่ยังสูงและผู้โจมตีก็ปรับตัวให้เข้ากับพฤติกรรมของโมเดลมากขึ้นเรื่อย ๆ โค้ดที่ผ่านเทสต์ไม่ใช่โค้ดที่ปลอดภัยเสมอไป และชื่อแพคเกจที่ดูคุ้นเคยไม่ใช่สิ่งรับประกันว่าไม่มี malware แฝงอยู่ สิ่งที่ป้องกันเหตุการณ์เลวร้ายได้ในโลกจริงไม่ใช่ AI รุ่นใหม่ แต่คือมนุษย์ที่หยุดดูซอร์สโค้ด ตรวจซัพพลายเชน และกล้าปฏิเสธข้อเสนอที่ดู “ง่าย” เกินไป

ทางเลือกมีสองแบบ: ปล่อยให้ AI และปุ่ม approve ตัดสินชะตาซัพพลายเชนซอฟต์แวร์ของคุณ หรือสร้างวัฒนธรรมการตรวจสอบโค้ด AI ที่เข้มงวด มีนโยบายชัดเจน และให้มนุษย์รับผิดชอบด่านสุดท้ายอย่างจริงจัง บทเรียนจากองค์กรที่เกือบติดตั้งแพคเกจ malware บอกเราชัดว่า การตรวจสอบมนุษย์ไม่ใช่ข้อแนะนำ แต่มันคือเกราะป้องกันหลักที่คุณถอดออกไม่ได้ หากยังให้ AI เขียนโค้ดในระบบของคุณอยู่

ทำไมต้องตรวจสอบโค้ด AI ทุกครั้งแม้เทสต์ผ่านหมด?

เพราะเทสต์มักตรวจเฉพาะพฤติกรรมเชิงฟังก์ชัน ไม่ตรวจหาช่องโหว่หรือโค้ดอันตรายที่ใช้ขโมยข้อมูลหรือเปิด backdoor ซึ่งซ่อนอยู่ได้ในโค้ดที่ดูปกติและผ่านเทสต์ทั้งหมด