AI Coding ชนะขาดแล้ว แต่สมรภูมิความปลอดภัยเพิ่งเริ่มต้น

การเติบโตในระดับนี้อาจเป็นเรื่องน่ายินดีในแวดวงอื่นๆ ของเทคโนโลยีองค์กร แต่ปัญหาคือจะเกิดอะไรขึ้นเมื่อโค้ดเหล่านั้นมาถึงโดยปราศจากการตอบสนองด้านความปลอดภัยที่เหมาะสม 90% ของผู้นำด้านความปลอดภัย บอกกับ Salt ว่าพวกเขากังวลอย่างจริงจังเกี่ยวกับความเสี่ยงที่มาจากโค้ดที่สร้างโดย AI

และความกังวลนั้นไม่ใช่นามธรรม ข้อมูลการทดสอบล่าสุดของ Veracode ที่ถูกอ้างอิงในรายงานของ Salt ระบุว่า อัตราการผ่านมาตรฐานความปลอดภัยของโค้ดที่สร้างโดย AI อยู่ที่ประมาณ 55% เท่านั้น ซึ่งแทบไม่เปลี่ยนแปลงเลยในรอบสองปี หมายความว่าเกือบครึ่งหนึ่งของโค้ดที่ถูกสร้างนั้นมีช่องโหว่ที่รู้จักกันดี หากไม่มีการให้คำแนะนำด้านความปลอดภัยอย่างชัดเจน

ในกลุ่มผู้ตอบแบบสอบถามของ Salt นั้น 29% ระบุว่ารูปแบบการเขียนโค้ดที่ไม่ปลอดภัย (Insecure Coding Patterns) คือความเสี่ยงสูงสุด ขณะที่ 15% บอกว่าความกังวลหลักคือการที่โค้ดไม่สอดคล้องกับนโยบายความปลอดภัยภายในองค์กร ความกังวลทั้งสองอย่างนี้มีสาเหตุมาจากรากเหง้าเดียวกัน นั่นคือ AI Coding Assistants ถูกฝึกมาจากโค้ดสาธารณะ (Public Code) ไม่ใช่จากนโยบายความปลอดภัยเฉพาะขององค์กร กรอบการทำงานของอุตสาหกรรม หรือข้อกำหนดด้านการปฏิบัติตามกฎระเบียบใดๆ

Security Drift: เมื่อไม่มีใครทันสังเกตเห็นสิ่งที่กำลังถูกส่งขึ้นระบบ

รายงานฉบับนี้แนะนำคำว่า "Security Drift" ในฐานะกลไกที่เปลี่ยนสภาวะกลืนไม่เข้าคายไม่ออกของการนำ AI มาใช้ ให้กลายเป็นความเสี่ยงที่จับต้องได้ แนวคิดนี้ตรงไปตรงมามาก องค์กรเขียนกฎความปลอดภัยของตัวเองลงในคู่มือ Wiki, ไฟล์ PDF และความรู้ที่สืบทอดกันมาในทีม (Tribal Knowledge) ซึ่ง AI Assistant ไม่เคยได้อ่านมาก่อน

ผู้ช่วย AI ก็จะสร้างโค้ดที่ถูกต้องตามหลักภาษา (Syntactically Correct) และใช้งานได้ดี แต่มันละเมิดนโยบายภายในเหล่านั้นอย่างเงียบๆ และไม่มีใครทันจับได้ เพราะกระบวนการตรวจสอบ (Review) ตามไม่ทัน

นี่นำเราไปสู่หนึ่งในข้อค้นพบที่นำไปปฏิบัติได้จริงและน่าตกใจที่สุดของ Salt เกี่ยวกับการกำกับดูแล นั่นคือ 38% ขององค์กรยังคงพึ่งพาการตรวจสอบโค้ดด้วยคน (Manual Code Review) เป็นหลัก ในการรับมือกับผลลัพธ์จาก AI Coding Assistants แต่ปริมาณโค้ดที่สร้างโดย AI ได้แซงหน้าขีดความสามารถที่มนุษย์จะตรวจสอบอย่างมีความหมายไปแล้ว และการคาดการณ์ของ Salt สำหรับปี 2027 ก็ชี้ว่าช่องว่างนี้จะยิ่งกว้างขึ้นเรื่อยๆ

มีองค์กรเพียงส่วนน้อยเท่านั้นที่ได้ผสานระบบป้องกันอัตโนมัติ (Automated Security Guardrails) เข้าไปในกระบวนการทำงาน (Workflow) ของ AI Coding

Roey Eliyahu ซีอีโอของ Salt Security สรุปสถานการณ์อย่างตรงไปตรงมาว่า การกำกับดูแลล้มเหลวในการตามให้ทัน การเปลี่ยนแปลงที่ AI Coding Assistants ได้ก่อให้เกิดขึ้นในการพัฒนาซอฟต์แวร์ เครื่องมือวิเคราะห์แบบ Static และ Dynamic แบบดั้งเดิม (SAST/DAST) นั้นตรวจพบปัญหาช้าเกินไปในสายพานการผลิต (Pipeline) ซึ่งทุกการแก้ไข ณ จุดนั้นหมายถึงการเขียนใหม่ และทุกการเขียนใหม่ก็คือความล่าช้า

METR กับช่องว่างระหว่างการรับรู้: รู้สึกว่าเร็วขึ้น แต่จริงๆ แล้วช้าลง

การกำกับดูแลด้านความปลอดภัยไม่ใช่พื้นที่เดียวที่การรับรู้กับความเป็นจริงนั้นแตกต่างกัน รายงานของ Salt ยังได้เน้นย้ำถึงข้อค้นพบจากการศึกษาภายนอกที่กลายมาเป็นจุดอ้างอิงในการถกเถียงเรื่องเครื่องมือสำหรับนักพัฒนา นั่นคือ การทดลองแบบสุ่มและมีกลุ่มควบคุม (RCT) ของ METR ที่ตีพิมพ์ในเดือนกรกฎาคม 2025

การศึกษานี้ได้ให้นักพัฒนา open-source ที่มีประสบการณ์ 16 คน ทำภารกิจในโลกแห่งความเป็นจริง 246 ภารกิจ บนคลังโค้ด (Repository) ที่พวกเขาดูแลอยู่ ซึ่งมีขนาดเฉลี่ยมากกว่า 1 ล้านบรรทัด และมีดาวบน GitHub หลายหมื่นดวง ผู้เข้าร่วมถูกสุ่มให้ใช้เครื่องมือ AI (ส่วนใหญ่คือ Cursor Pro กับ Claude 3.5/3.7 Sonnet) หรือไม่ใช้เครื่องมือใดๆ เลย

ผลลัพธ์ที่เป็นหัวข้อข่าวถูกอ้างถึงบ่อยครั้งจนเกือบจะเป็นแค่เสียงรบกวนพื้นหลัง แต่ตัวเลขก็ยังคงน่าตกใจ นักพัฒนาที่ใช้ AI ทำงานเสร็จ ช้าลง 19% เมื่อเทียบกับผู้ที่ไม่ได้ใช้ AI ใดๆ เลย ก่อนการทดลอง นักพัฒนาเหล่านี้คาดว่า AI จะทำให้พวกเขาเร็วขึ้น 24% หลังจากทำงานเสร็จ พวกเขาประมาณว่าเครื่องมือเหล่านี้ทำให้พวกเขาเร็วขึ้นประมาณ 20% — แม้ว่าการวัดตามวัตถุวิสัยจะแสดงให้เห็นว่าพวกเขาทำงานช้าลงก็ตาม ช่องว่างระหว่างความรู้สึกถึงผลิตภาพกับผลิตภาพที่แท้จริงนั้นเกินกว่า 39 จุดเปอร์เซ็นต์

ข้อค้นพบของ METR ไม่ได้หมายความว่าเครื่องมือ AI ไร้ประโยชน์ บริบทมีส่วนสำคัญอย่างมาก มีการสังเกตเห็นผลดีในสถานการณ์การเริ่มงานใหม่ (Onboarding), การเขียนโค้ดแม่แบบ (Boilerplate) ซ้ำๆ และงานที่นักพัฒนาไม่คุ้นเคยกับคลังโค้ดมากนัก แต่สำหรับวิศวกรมากประสบการณ์ที่ทำงานที่ซับซ้อนและต้องพึ่งพาคลังโค้ดเฉพาะ หลักฐานบ่งชี้ว่าเครื่องมือเหล่านี้สามารถสร้างแรงเสียดทานที่นักพัฒนาไม่ได้ตระหนักรู้

Salt Code: บังคับใช้กฎตั้งแต่ตอน Prompt ไม่ใช่ตอนปลายสายพาน

Salt ได้กำหนดเวลาเผยแพร่งานวิจัยให้ตรงกับการเปิดตัวผลิตภัณฑ์ที่ออกแบบมาเพื่อแก้ไขช่องว่างด้านการกำกับดูแลที่รายงานระบุไว้ เมื่อวันที่ 1 มิถุนายน 2026 บริษัทได้แนะนำ Salt Code ซึ่งเป็นองค์ประกอบใหม่ของ Agentic Security Platform

แนวทางของ Salt Code คือการหยุด Security Drift ก่อนที่มันจะเริ่มต้น แทนที่จะสแกนโค้ดที่ AI สร้างขึ้นหลังจากเขียนเสร็จแล้ว มันจะบังคับใช้กฎความปลอดภัยและการปฏิบัติตามกฎระเบียบภายในขององค์กร โดยตรงภายใน AI Coding Assistant ณ จังหวะที่โค้ดถูกสร้างขึ้น

ผลิตภัณฑ์นี้ทำงานร่วมกับเครื่องมือหลักๆ ที่องค์กรต่างๆ กำลังเลือกใช้เป็นมาตรฐาน ไม่ว่าจะเป็น Claude Code, Cursor, GitHub Copilot, Windsurf, Codex และ Gemini CLI

เป้าหมายคือการทำให้โค้ดที่สอดคล้องกับนโยบาย กลายเป็นผลลัพธ์มาตรฐาน (Default Output) ไม่ใช่สิ่งที่ต้องถูกสแกนและเขียนใหม่ในภายหลัง สำหรับทีมความปลอดภัย มันมอบนโยบายชั้นเดียวที่ครอบคลุมตั้งแต่การสร้างโค้ด การตรวจสอบใน Pipeline และการเฝ้าติดตามขณะทำงาน (Runtime Monitoring) ซึ่งเป็นการเปลี่ยนจากการตามจับข้อผิดพลาด ไปสู่การป้องกันตั้งแต่แรก

ไม่ว่า Salt Code หรือเครื่องมือที่คล้ายกันจะสามารถปิดช่องว่างด้านการกำกับดูแล ได้ทันกับความเร็วที่การนำ AI มาใช้เรียกร้องหรือไม่ ยังคงเป็นคำถามที่ไม่มีคำตอบ แต่ทิศทางนั้นชัดเจน หากการคาดการณ์ที่ว่า AI จะเป็นผู้เขียนโค้ดมากกว่าครึ่งหนึ่งของโค้ดในองค์กรทั้งหมดภายใน 18 เดือนข้างหน้าเป็นจริง นโยบายความปลอดภัยก็จะต้องย้ายจากขั้นตอนการตรวจสอบ ไปสู่การเป็นค่ามาตรฐานเริ่มต้น ทางเลือกอื่น ดังที่รายงานของ Salt เตือน ก็คือการเกิด Security Drift ในระดับอุตสาหกรรมนั่นเอง