ความปลอดภัยของ AI Coding Assistant และ Vibe Coding

ความปลอดภัยของ AI coding assistant คือการควบคุมความเสี่ยงที่เกิดขึ้นเมื่อเครื่องมือ AI ช่วยนักพัฒนาแนะนำ เขียน หรือแม้แต่รันโค้ด Vibe coding เป็นการใช้งานที่ไปไกลสุดทาง ผู้ใช้บอกว่าต้องการอะไร AI สร้างทั้งโครงสร้างระบบและโค้ดให้ แล้วผู้ใช้ดูแค่ว่าผลลัพธ์ใช้ได้หรือไม่ โดยไม่ได้ตรวจโค้ดอย่างละเอียด ตามที่ NCSC (หน่วยงานด้านความมั่นคงไซเบอร์ของสหราชอาณาจักร) อธิบายไว้ บทความนี้อธิบายว่าความเสี่ยงมาจากไหน OWASP (องค์กรด้านความปลอดภัยของซอฟต์แวร์) กับ NIST (สถาบันมาตรฐานและเทคโนโลยีของสหรัฐฯ) พูดถึงเรื่องนี้อย่างไร และมาตรการแบบไหนใช้ได้จริง

ผู้ช่วยเขียนโค้ดกับ vibe coding อยู่บนสเปกตรัมเดียวกัน

บล็อกของ NCSC เดือนมิถุนายน 2026 เรื่อง "vibe coding spectrum" มองว่าการใช้ AI เขียนโค้ดไม่ใช่เรื่องของใช่หรือไม่ใช่ แต่เป็นช่วงต่อเนื่อง ปลายด้านหนึ่ง คุณเขียนโค้ดเอง และใช้ AI เป็นแค่ตัวให้คำแนะนำที่จะรับหรือไม่รับก็ได้ เช่น autocomplete (การเติมโค้ดให้อัตโนมัติ) ปลายอีกด้าน AI ควบคุมทั้งสถาปัตยกรรม โมดูล และการทดสอบ ส่วนคุณคอยตัดสินผลลัพธ์แล้วสั่งใหม่ ตรงกลางมีได้หลายแบบ เช่น AI เขียนบางฟังก์ชันขณะที่คุณออกแบบเอง หรือคุณเขียนเทสต์ไว้ก่อน แล้วให้ AI เขียนโค้ดให้ผ่านเทสต์นั้น

NCSC แนะนำให้เลือกตำแหน่งบนสเปกตรัมตามสิ่งที่กำลังสร้าง งานที่ใช้ vibe coding เต็มรูปแบบได้คือต้นแบบ เดโม เครื่องมือภายในที่เปิดให้ใช้จำกัด และโปรเจกต์ที่ไม่มีข้อมูลสำคัญหรือฟังก์ชันด้านความปลอดภัย ส่วนงานที่ควรเขียนและควบคุมเองคือตรรกะการยืนยันตัวตนและการกำหนดสิทธิ์ ข้อมูลส่วนบุคคลที่ละเอียดอ่อน ความลับสำหรับเข้าระบบ (secret) เช่น token และข้อมูลรับรองการเข้าใช้ (credential) รวมถึงระบบที่ความผิดพลาดกระทบความปลอดภัยโดยตรง (safety-critical)

ความเสี่ยงมาจากไหน

OWASP Top 10 for LLM Applications 2025 เป็นแผนที่ความเสี่ยงที่ใช้อ้างอิงได้ดี LLM คือโมเดลภาษาขนาดใหญ่ ซึ่งเป็นเทคโนโลยีเบื้องหลัง AI ที่สร้างข้อความและโค้ด จากสิบรายการใน OWASP มีห้ารายการที่เกี่ยวกับ coding assistant มากที่สุด ได้แก่

• โค้ดที่ผิดหรือไม่ปลอดภัย (LLM05, Improper Output Handling): OWASP แนะนำให้ถือผลลัพธ์ของโมเดลเป็น input ที่ไม่น่าเชื่อถือ สถานการณ์ตัวอย่างเรื่องโค้ดที่โมเดลสร้างเตือนถึง SQL injection (การแทรกคำสั่งฐานข้อมูลผ่านข้อมูลที่รับเข้ามา) การจัดการข้อมูลที่ไม่ปลอดภัย และ package (ชุดโค้ดสำเร็จรูปที่โปรแกรมเรียกใช้) ที่โมเดลแต่งชื่อขึ้นเอง NCSC เขียนไว้ในปี 2026 ว่าความเสี่ยงของโค้ดที่ AI เขียนน่าจะเกินระดับที่องค์กรส่วนใหญ่ยอมรับได้ในปัจจุบัน
• Package ที่โมเดลแต่งขึ้น: งานวิจัยจาก USENIX Security 2025 ทดสอบโมเดลสร้างโค้ด 16 ตัว ด้วยตัวอย่างโค้ด 576,000 ชิ้น พบว่าอัตราเฉลี่ยของ package ที่ไม่มีอยู่จริงอย่างน้อย 5.2% ในโมเดลเชิงพาณิชย์ และ 21.7% ในโมเดลโอเพนซอร์ส รวมชื่อที่ไม่ซ้ำกัน 205,474 ชื่อ ผู้โจมตีสามารถลงทะเบียนชื่อเหล่านี้เป็น package จริงที่ซ่อนโค้ดอันตรายไว้ วิธีนี้เรียกว่า slopsquatting เมื่อนักพัฒนาติดตั้งตามที่ AI แนะนำ โค้ดอันตรายก็เข้ามาในระบบ
• Agent ที่มีอำนาจเกินจำเป็น (LLM06, Excessive Agency): agent คือโปรแกรม AI ที่ลงมือทำงานเองได้ เช่น รันคำสั่ง shell แก้ไฟล์ และเรียกใช้เครื่องมือ ถ้า agent ได้รับผลลัพธ์ที่คลุมเครือหรือถูกชักนำ ก็อาจทำสิ่งที่สร้างความเสียหายได้ OWASP ระบุสาเหตุหลักสามข้อ คือมีฟังก์ชันเกินจำเป็น มีสิทธิ์เกินจำเป็น และตัดสินใจเองได้มากเกินจำเป็น
• Prompt injection (LLM01): ข้อความใน issue, README, หน้าเว็บ หรือไฟล์ที่ผู้ช่วยอ่านอาจมีคำสั่งแฝงอยู่ เอกสารของ Claude Code นิยามว่าคือการที่ผู้โจมตีแทรกข้อความเพื่อให้ผู้ช่วยทำตามแทนคำสั่งเดิม ส่วนเอกสารของ GitHub ระบุว่า coding agent ของตนกรองอักขระที่ซ่อนอยู่ ซึ่งอาจใช้ปกปิดคำสั่งอันตราย
• ข้อมูลรั่วไหล (LLM02, Sensitive Information Disclosure): ผู้ใช้อาจวาง secret ข้อมูลลูกค้า หรือโค้ดภายในลงใน prompt หรือข้อมูลอาจหลุดออกไปกับบริบทที่ส่งให้ AI เอกสารของ GitHub เตือนว่าโค้ดและข้อความที่สร้างจากบริบทของ issue หรือคอมเมนต์ อาจเปิดเผยข้อมูลสำคัญได้ ถ้าไม่ตรวจทานก่อน ดู Shadow AI: ความเสี่ยงและวิธีรับมือ

ตัวเครื่องมือเองก็เป็นส่วนหนึ่งของห่วงโซ่อุปทานซอฟต์แวร์ (supply chain) ขององค์กร LLM03, Supply Chain ครอบคลุมโมเดล ข้อมูล และแพลตฟอร์มที่ถูกแก้ไขโดยไม่ชอบ แนวคิดเดียวกันใช้กับ plugin และ MCP server (ตัวเชื่อมที่ให้ AI เรียกใช้เครื่องมือหรือข้อมูลภายนอก) ได้เช่นกัน ดู คู่มือความปลอดภัยของ MCP

OWASP และ NIST พูดไว้ว่าอย่างไร

รายการของ OWASP เขียนไว้สำหรับแอปพลิเคชัน LLM โดยรวม ไม่ได้เจาะจงเรื่องการเขียนโค้ด แต่มาตรการป้องกันที่แนะนำนำมาใช้กับ coding assistant ได้ทันที สำหรับความเสี่ยงเรื่อง agent มีอำนาจเกินจำเป็น LLM06 แนะนำให้ใช้เครื่องมือให้น้อยที่สุดและเลี่ยงเครื่องมือแบบปลายเปิด เช่น การรันคำสั่ง shell อะไรก็ได้ ให้สิทธิ์น้อยที่สุด ให้คนอนุมัติการกระทำที่มีผลกระทบสูง และให้ระบบปลายทางเป็นผู้บังคับการกำหนดสิทธิ์ แทนการเชื่อโมเดล ส่วน LLM05 แนะนำให้ตรวจสอบผลลัพธ์ และใช้ parameterized query (การเขียน query ที่แยกคำสั่งออกจากข้อมูลที่ส่งเข้ามา) โดยปฏิบัติต่อโมเดลเหมือนผู้ใช้ทั่วไปคนหนึ่ง

NIST SP 800-218A เผยแพร่เมื่อเดือนกรกฎาคม 2024 เป็น SSDF Community Profile สำหรับ generative AI และ dual-use foundation model (โมเดลพื้นฐานขนาดใหญ่ที่ใช้ได้หลายงาน) SSDF คือกรอบแนวปฏิบัติการพัฒนาซอฟต์แวร์อย่างปลอดภัย (Secure Software Development Framework) ควรอ่านขอบเขตของเอกสารนี้ให้ชัด เอกสารต่อยอดจาก SSDF เวอร์ชัน 1.1 (SP 800-218) โดยเพิ่มแนวปฏิบัติด้านการพัฒนาโมเดล AI สำหรับผู้ผลิตโมเดล AI ผู้ผลิตระบบ AI ที่ใช้โมเดลเหล่านั้น และผู้จัดหา (acquirer) ระบบดังกล่าว เอกสารนี้ไม่ใช่คู่มือสำหรับนักพัฒนาที่ใช้ coding assistant แต่ช่วยได้สองทางอ้อม ทางแรก ในฐานะผู้จัดหา องค์กรถามผู้ให้บริการผู้ช่วยได้ว่านำแนวปฏิบัติการพัฒนาอย่างปลอดภัยมาใช้กับโมเดลของตนอย่างไร ทางที่สอง องค์กรใช้ SSDF พื้นฐานกับโค้ดที่ AI เขียนได้เหมือนโค้ดจากบุคคลที่สาม คือตรวจทานและทดสอบก่อนปล่อยใช้งาน นอกจากนี้ NIST เผยแพร่ร่างฉบับแรกสำหรับรับความเห็นสาธารณะของ SSDF เวอร์ชัน 1.2 (SP 800-218 Rev. 1) ในเดือนธันวาคม 2025 จึงควรตรวจสถานะล่าสุดที่ NIST

มาตรการที่ใช้ได้จริง

เอกสารของผู้ผลิตแต่ละรายแสดงให้เห็นว่าควรมองหามาตรการแบบไหน ต่อไปนี้เป็นตัวอย่าง ไม่ใช่การแนะนำผลิตภัณฑ์ เอกสารของ GitHub สำหรับ Copilot coding agent ระบุว่า เฉพาะผู้ใช้ที่มีสิทธิ์เขียนเท่านั้นที่สั่งงานได้ agent push โค้ดได้เฉพาะ branch ของตัวเอง (branch คือสายงานแยกของโค้ด) ไม่ใช่ default branch (สายหลัก) workflow ที่ agent กระตุ้นต้องได้รับอนุมัติก่อน agent เข้าถึง secret ระดับองค์กรไม่ได้ และเปิดไฟร์วอลล์ไว้เป็นค่าเริ่มต้น เอกสารของ Claude Code ระบุว่า manual mode เริ่มต้นแบบอ่านอย่างเดียว และถามก่อนแก้ไฟล์หรือรันคำสั่ง มีเครื่องมือ bash ที่ทำงานใน sandbox (สภาพแวดล้อมแยกที่รันคำสั่งได้โดยไม่กระทบระบบจริง) ซึ่งแยกไฟล์ซิสเต็มและเครือข่ายออกจากระบบจริง และระบุว่าผู้ใช้เป็นผู้รับผิดชอบในการตรวจทานโค้ดและคำสั่งที่ AI เสนอ

จุดร่วมของทั้งสองตัวอย่างคือ จำกัดสิ่งที่ agent แตะต้องได้ ให้คนอนุมัติในขั้นที่มีผลกระทบสูง และเก็บบันทึกไว้ ในทางปฏิบัติทำได้ดังนี้

• ใช้เฉพาะเครื่องมือที่อนุมัติ: เลือกผู้ช่วยที่องค์กรรับรอง ตั้งค่าจากส่วนกลาง และไม่ให้นำโค้ดของบริษัทไปใช้กับบัญชีส่วนตัว
• สิทธิ์เท่าที่จำเป็น (least privilege): ใช้ข้อมูลรับรองที่จำกัดขอบเขต ไม่ให้มี secret ของระบบ production และให้ agent ทำงานใน sandbox หรือ dev container (สภาพแวดล้อมสำหรับพัฒนาที่แยกจากเครื่องจริง) ที่จำกัดการเข้าถึงเครือข่าย
• ให้คนอนุมัติการกระทำที่มีผลกระทบสูง: เช่น การลบข้อมูล การ deploy (นำโค้ดขึ้นระบบจริง) การเปลี่ยนสิทธิ์ หรือการรันคำสั่งที่ไม่คุ้นเคย
• Branch protection และ review ที่บังคับ: ให้การเปลี่ยนแปลงที่ AI เขียนต้องผ่าน pull request (คำขอรวมโค้ดที่ต้องมีคนตรวจ) เหมือนของนักพัฒนาคนอื่น
• ตรวจอัตโนมัติใน CI: CI คือระบบที่ตรวจโค้ดอัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลง ควรให้รัน static analysis (ตรวจโค้ดโดยไม่ต้องรันโปรแกรม) secret scanning (ค้นหา secret ที่หลุดอยู่ในโค้ด) และตรวจ dependency (package ที่โค้ดเรียกใช้) ไม่ว่าใครเป็นผู้เขียนโค้ด NCSC สนับสนุนการควบคุมแบบกำหนดแน่นอนที่บังคับด้วยกฎและโค้ด มากกว่าการให้ AI ตัวหนึ่งคอยกำกับอีกตัวหนึ่ง
• ตรวจ package ก่อนใช้: ยืนยันว่า dependency ที่ AI แนะนำมีอยู่จริงและเป็นตัวที่ต้องการ แล้วตรึงเวอร์ชันด้วย lockfile (ไฟล์ที่ล็อกเวอร์ชันของ package ที่ใช้)
• บันทึก log: เก็บบันทึกว่า agent ทำอะไรไปบ้าง

กำหนดนโยบายตามระดับความเสี่ยง

นำสเปกตรัมของ NCSC มาเขียนเป็นนโยบายสั้น ๆ ที่นักพัฒนาทำตามได้ โดยไม่ต้องขออนุญาตทุกครั้ง

• ความเสี่ยงต่ำ (ต้นแบบ เดโม เครื่องมือภายในที่ไม่มีข้อมูลสำคัญ): ให้ AI ทำงานเองได้มาก แต่ยังต้องใช้ sandbox ไม่ใช้ข้อมูลรับรองของ production และสแกนอัตโนมัติ
• ความเสี่ยงปานกลาง (ฟีเจอร์ production งานที่ลูกค้าใช้): ให้ AI เขียนโค้ดได้ แต่ต้องมีคนที่เข้าใจโค้ดตรวจทุกการเปลี่ยนแปลง และการตรวจอัตโนมัติทั้งหมดต้องผ่าน
• ความเสี่ยงสูง (การยืนยันตัวตน การกำหนดสิทธิ์ ข้อมูลส่วนบุคคล การจัดการ secret โค้ดที่เกี่ยวกับความปลอดภัยโดยตรง): ให้คนควบคุมเอง และใช้ AI เป็นแค่ตัวแนะนำหรือผู้ตรวจเสริม

ให้เชื่อมนโยบายนี้เข้ากับนโยบาย AI ขององค์กร ดู คู่มือ AI Security และ AI Governance หากทีมใช้ agent ที่ทำงานได้เอง ให้อ่าน Agentic AI Security ด้วย

ข้อควรระวัง

• ถือว่าผลลัพธ์ของ AI เป็นโค้ดที่ตรวจแล้ว: ผลลัพธ์ของ AI เป็น input ที่ไม่น่าเชื่อถือ จนกว่าจะมีคนเข้าใจและทดสอบแล้ว
• ให้ agent ใช้ข้อมูลรับรองเต็มสิทธิ์ของตัวเอง: ควรให้สิทธิ์ที่จำกัดขอบเขตและแยกต่างหาก
• ให้ AI เป็นผู้ตรวจเพียงอย่างเดียว: การตรวจด้วย AI ช่วยได้ แต่โค้ดที่ละเอียดอ่อนยังต้องมีการควบคุมแบบกำหนดแน่นอนและการตรวจโดยคนด้วย
• ติดตั้ง package ที่ AI แนะนำโดยไม่ตรวจ: ควรตรวจก่อนทุกครั้งและใช้ lockfile
• ใช้ vibe coding กับโค้ดที่ความผิดพลาดมีราคาแพง: โค้ดยืนยันตัวตนและการจัดการ secret ควรอยู่ปลายด้านที่คนควบคุมเองของสเปกตรัม
• ไม่มีบัญชีรายการ: องค์กรกำกับดูแลผู้ช่วยที่ไม่รู้ว่ามีอยู่ไม่ได้

ขั้นแรกที่ทำได้ทันที

• ทำรายการผู้ช่วยและ agent ที่ใช้อยู่ รวมถึงบัญชีส่วนตัว เครื่องมือบนเบราว์เซอร์ และ plugin
• เขียนระดับความเสี่ยงสามระดับ และระบุว่าใครเป็นผู้อนุมัติข้อยกเว้น
• เปิดการตรวจใน CI: secret scanning, ตรวจ dependency, static analysis และบังคับ review บน protected branch (branch ที่ห้ามแก้ตรง)
• ย้าย agent ไปสภาพแวดล้อมสิทธิ์เท่าที่จำเป็น: ใช้ sandbox หรือ dev container, token ที่จำกัดขอบเขต และเครือข่ายที่จำกัด
• ทดลองกับหนึ่งทีมก่อน และวัดเวลา review กับจำนวนข้อค้นพบ ก่อนขยายไปทีมอื่น

หากต้องการดูว่าการควบคุมด้าน AI และการพัฒนาซอฟต์แวร์ขององค์กรอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง

โค้ดที่ AI ช่วยเขียนควรผ่านการตรวจอัตโนมัติชุดเดียวกับโค้ดที่คนเขียน ดู DevSecOps: SAST, DAST และ SCA ใช้อย่างไร

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• OWASP Top 10 for LLM Applications 2025: ความเสี่ยงสิบหมวดและรหัสของแต่ละหมวด
• OWASP LLM06:2025 Excessive Agency: สาเหตุหลักและการป้องกันสำหรับ agent
• OWASP LLM05:2025 Improper Output Handling: ถือผลลัพธ์ของโมเดลเป็นข้อมูลที่ไม่น่าเชื่อถือ รวมถึงโค้ดที่โมเดลสร้าง
• NIST SP 800-218A: SSDF Community Profile สำหรับ generative AI: ขอบเขตคือการพัฒนาโมเดล AI สำหรับผู้ผลิตและผู้จัดหา
• NCSC: the vibe coding spectrum approach: ควรอยู่ตรงไหนของสเปกตรัมตามระดับความเสี่ยง
• NCSC: Vibe check, AI may replace SaaS (but not for a while): มุมมองของ NCSC ต่อความเสี่ยงและมาตรการสำหรับโค้ดที่ AI เขียน
• We Have a Package for You! Package hallucinations by code-generating LLMs: งานวิจัย USENIX Security 2025 ที่เป็นที่มาของตัวเลขข้างต้น
• GitHub Docs: Copilot coding agent responsible use: ความเสี่ยงและมาตรการป้องกันที่ผู้ผลิตรายหนึ่งระบุไว้
• เอกสาร Claude Code: Security: โมเดลสิทธิ์และ sandbox ของผู้ผลิตอีกราย