เวลาสั่ง coding agent ว่า "ช่วยหาช่องโหว่ในโปรเจกต์นี้หน่อย" คำถามสำคัญไม่ได้มีแค่ว่ามันจะหาเจอกี่ข้อ แต่รวมถึง สิ่งที่มันบอกว่าเจอ เป็นช่องโหว่จริง หรือเป็นเพียงเรื่องที่ฟังดูน่ากังวล
Cloudflare เปิดซอร์สเครื่องมือชื่อ Security Audit Skill เพื่อจัดระเบียบงานนี้ให้จริงจังขึ้น แทนที่จะให้ AI อ่านโค้ดแล้วสรุปตามความเข้าใจของตัวเอง เครื่องมือนี้กำหนดขั้นตอนตั้งแต่สำรวจระบบ แบ่งงานค้นหา ท้าทายข้อค้นพบ ไปจนถึงตรวจหลักฐานก่อนออกรายงาน โดยใช้ agent หลายตัวที่แยกหน้าที่กันชัดเจน
สิ่งที่น่าสนใจคือแนวคิดเบื้องหลัง: AI ไม่ควรได้รับความเชื่อถือเพียงเพราะอธิบายได้ดูมีเหตุผล แต่ต้องผ่านกระบวนการตรวจสอบที่เปิดโอกาสให้ข้อสรุปของมันถูกหักล้างได้
ไม่ใช่โมเดลใหม่ แต่เป็นคู่มือทำงานที่มีด่านตรวจ
Security Audit Skill ไม่ใช่โมเดล AI ตัวใหม่ และไม่ใช่ระบบตรวจความปลอดภัยระดับองค์กรทั้งหมดที่ Cloudflare ใช้ภายใน แต่เป็นจุดเริ่มต้นสำหรับตรวจทีละ repository ซึ่งต่อมาถูกพัฒนาเป็นระบบประสานงานขนาดใหญ่ หรือ harness ของบริษัท
ภายใน repository จึงไม่ได้มีแค่ prompt ยาว ๆ ไฟล์เดียว แต่มีคู่มือสำรวจสถาปัตยกรรม วิธีค้นหาช่องโหว่ กฎการตรวจสอบหลักฐาน โครงสร้างรายงาน JSON และสคริปต์ตรวจความถูกต้องของข้อมูล นอกจากนี้ยังมีคู่มือเฉพาะด้าน เช่น เว็บและการยืนยันตัวตน ระบบ AI/LLM, cloud, supply chain และการแยกข้อมูลระหว่างลูกค้าแต่ละราย
ภาพที่ใกล้เคียงจึงไม่ใช่ "เพิ่มความรู้ให้ AI อีกนิด" แต่เป็น การให้คู่มือปฏิบัติงาน แบ่งหน้าที่ และกำหนดเกณฑ์รับงาน ว่าต้องมีหลักฐานระดับไหนจึงจะเรียกสิ่งหนึ่งว่าช่องโหว่ได้
หกเฟสที่เริ่มจากเข้าใจระบบ ไม่ใช่รีบหาข้อผิดพลาด
README แบ่งกระบวนการตรวจแบบเต็มออกเป็นหกเฟส โดยแต่ละช่วงมีหน้าที่ต่างกัน
เฟสแรก สำรวจสถาปัตยกรรมและวางแผนความครอบคลุม - Agent ต้องเข้าใจก่อนว่าระบบทำอะไร ใครมีสิทธิ์ทำอะไร ข้อมูลจากภายนอกเข้าทางไหน และผ่านจุดควบคุมใดบ้าง ผลลัพธ์คือ architecture.md และบัญชีติดตามพื้นที่ตรวจสอบ coverage-ledger.json ซึ่งช่วยแยกพื้นที่ที่ตรวจแล้วออกจากพื้นที่ที่ยังไม่ได้ตรวจ ไม่ใช่มองว่าอ่านบางไฟล์แล้วเท่ากับเข้าใจทั้งระบบ
เฟสที่สอง แบ่งงานค้นหาตามพื้นที่ที่ต้องตรวจ - Agent ผู้ประสานงานแจกงานให้ผู้ค้นหาแต่ละตัวตามขอบเขตที่กำหนด ผู้ค้นหาต้องติดตามเส้นทางข้อมูลและกฎความปลอดภัยจริง รวมถึงเส้นทางผิดพลาด การย้อนกลับ หรือกรณีที่องค์ประกอบสองส่วนตีความข้อมูลไม่ตรงกัน พื้นที่ที่งบประมาณไม่พอตรวจต้องถูกบันทึกว่าเลื่อนออกไป ไม่ใช่หายจากรายงานเงียบ ๆ และมีผู้ตรวจความครอบคลุมช่วยหาจุดที่ตกหล่นด้วย
เฟสที่สาม ส่งข้อค้นพบให้ agent ใหม่พยายามหักล้าง - ผู้ตรวจสอบต้องไม่ใช่ตัวที่ค้นพบประเด็นนั้น มันต้องกลับไปอ่านโค้ดที่อ้างถึง ตรวจมาตรการป้องกันบนเส้นทางเดียวกัน และทดสอบผลขั้นต่ำอย่างปลอดภัยเมื่อทำได้ เป้าหมายไม่ใช่ช่วยเขียนรายงานให้น่าเชื่อ แต่คือพิสูจน์ว่าข้อกล่าวหานั้นผิดตรงไหนได้บ้าง
เฟสที่สี่ บันทึกผลเป็นข้อมูลที่เครื่องอ่านได้ - ผลที่ผ่านการตัดสินถูกเขียนลง findings.json โดยแยกสถานะอย่างชัดเจน แล้วตรวจตาม schema ที่กำหนด ทำให้รายงานไม่ได้เป็นเพียงข้อความอิสระที่แต่ละรอบเขียนคนละรูปแบบ
เฟสที่ห้า ตรวจความถูกต้องของรายการสุดท้ายอีกชั้น - มีการตรวจข้อกล่าวอ้างในรายการผลลัพธ์กับซอร์สโค้ดอีกครั้ง หากแก้สาระสำคัญของรายการ ก็ต้องมีผู้ตรวจอิสระตรวจสิ่งที่แก้ด้วย เพื่อไม่ให้ข้อความในรายงานสุดท้ายกล่าวเกินกว่าหลักฐานที่มี
เฟสที่หก สร้างรายงานสำหรับคนอ่าน - ระบบสร้าง REPORT.md, FINDINGS-DETAIL.md และ NEEDS-VALIDATION.md จากข้อมูลที่ตรวจสอบแล้วและบัญชีความครอบคลุม แยกภาพรวม รายละเอียดข้อค้นพบ และประเด็นที่ยังต้องตรวจเพิ่มเติมออกจากกัน
จุดสำคัญคือ JSON ถูกต้องตาม schema ไม่ได้แปลว่าข้อค้นพบถูกต้อง การตรวจโครงสร้างข้อมูลกับการตรวจความจริงของช่องโหว่เป็นคนละงาน กระบวนการนี้จึงมีทั้งสคริปต์ตรวจรูปแบบและ agent ตรวจหลักฐาน ไม่ใช่เลือกอย่างใดอย่างหนึ่ง
หัวใจคือ "คนหา" ต้องไม่เป็น "คนตัดสิน" เสียเอง
ลองนึกภาพว่า agent ตัวหนึ่งพบ endpoint ที่ดูเหมือนไม่ตรวจสิทธิ์ แล้วเขียนคำอธิบายอย่างมั่นใจว่าเป็นช่องโหว่ หากให้ตัวเดิมตรวจซ้ำโดยไม่เปลี่ยนบริบท คำถามคือมันกำลังตรวจหลักฐานใหม่ หรือเพียงขยายเหตุผลเดิมให้ละเอียดขึ้น
Cloudflare จึงกำหนดให้ผู้ตรวจได้รับข้อค้นพบ หลักฐาน และบริบทที่จำเป็น แต่ต้องอ่านซอร์สปัจจุบันเอง และต้องไม่ได้รับข้อสรุปของผู้ตรวจคนอื่นมาชี้นำ ความเป็นอิสระในที่นี้คือการแยกบทบาทและการตรวจสอบ ไม่ใช่ข้อรับประกันว่า AI จะไม่มีวันผิด
ผลลัพธ์แบ่งเป็นสามสถานะที่ไม่ควรปะปนกัน:
confirmed คือมีเส้นทางจากซอร์สโค้ดและผลที่สังเกตได้รองรับครบตามเกณฑ์ จึงประเมินความรุนแรงได้
needs_validation คือมีหลักฐานจากโค้ดรองรับประเด็น แต่ยังติดข้อเท็จจริงจำเป็นบางอย่าง ต้องระบุให้ชัดว่าขาดอะไรและจะตรวจอย่างไร โดย ยังไม่ให้ระดับความรุนแรง
rejected คือข้อกล่าวหาถูกหักล้าง เช่น มีมาตรการป้องกันอยู่จริง หรือเงื่อนไขที่อ้างว่าใช้โจมตีไม่เกิดขึ้นตามที่เข้าใจ ทั้งนี้ needs_validation ไม่ใช่ที่เก็บข้อสงสัยลอย ๆ ทุกชนิด ประเด็นต้องมีหลักฐานตั้งต้นก่อน
การแยกเช่นนี้ทำให้ "ยังไม่รู้" เป็นผลลัพธ์ที่ยอมรับได้ โดยไม่จำเป็นต้องแต่งให้กลายเป็น "พบช่องโหว่แล้ว"
ไม่มีแนวป้องกันชั้นที่สอง ไม่ได้แปลว่าถูกเจาะได้
อีกหลักการที่ควรนำไปใช้แม้ไม่ได้ติดตั้ง skill นี้ คือ ต้องแยกช่องโหว่ออกจากข้อเสนอเพิ่มความแข็งแรงของระบบ
สมมติว่า endpoint ไม่มีการตรวจสิทธิ์ซ้ำภายในฟังก์ชัน แต่พิสูจน์ได้ว่าทุกเส้นทางที่เข้าถึงมันต้องผ่าน middleware ซึ่งบังคับสิทธิ์ถูกต้องอยู่แล้ว การไม่มีการตรวจซ้ำอาจเป็นเรื่องที่ควรปรับปรุง แต่ยังไม่ใช่หลักฐานว่าผู้ใช้สามารถข้ามสิทธิ์ได้ หลักของโครงการจึงกำหนดว่า หากแนวป้องกันชั้นแรกหยุดการโจมตีได้จริง การไม่มีชั้นถัดไปเป็นข้อเสนอด้าน hardening ไม่ใช่ช่องโหว่โดยอัตโนมัติ
อย่างไรก็ตาม กฎนี้ไม่ได้อนุญาตให้ AI เดาว่า "น่าจะมีระบบอื่นป้องกันอยู่" หากการตัดสินขึ้นกับ reverse proxy, นโยบายตัวตน หรือการตั้งค่า deployment ที่มองไม่เห็นจาก repository ก็ต้องระบุข้อเท็จจริงที่ยังขาด แทนการสมมติว่าปลอดภัยหรือไม่ปลอดภัยเอง
ตัวเลข "รอบเดียวพบประมาณครึ่งหนึ่ง" ต้องอ่านให้ถูก
Cloudflare ระบุว่า ในการทดลองของทีม การรันหนึ่งรอบพบประมาณครึ่งหนึ่งของช่องโหว่ที่พบรวมจากการรันหลายรอบ นี่เป็นเหตุผลที่ไม่ควรใช้ผลจากรอบเดียวเป็นใบรับรองว่าระบบปลอดภัย
แต่ตัวเลขดังกล่าว ไม่ใช่อัตราตรวจพบ 50% ของช่องโหว่ทั้งหมดที่มีอยู่จริง เพราะฐานเปรียบเทียบคือสิ่งที่การรันหลายรอบค้นพบ ไม่ใช่จำนวนช่องโหว่ทั้งหมดที่มีผู้พิสูจน์ไว้แล้ว และการรันซ้ำก็ไม่ได้รับประกันว่าจะพบครบทุกจุด
วิธีของ skill จึงไม่ใช่แค่สั่งซ้ำแล้วหวังโชคดี แต่ใช้ผลรอบก่อนเพื่อระบุพื้นที่ตกหล่น ตรวจส่วนที่เปลี่ยน และทบทวนหลักฐานกับซอร์สปัจจุบัน เรื่องที่ยังติดเงื่อนไขหรือยังไม่ได้ตรวจต้องไม่ถูกนับกลายเป็นพื้นที่ที่ตรวจเสร็จแล้ว
เริ่มใช้ได้อย่างไร และอะไรที่ต้องเตรียมมากกว่า Node.js
README ให้ติดตั้งผ่าน Skills CLI ด้วยคำสั่ง:
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-auditจากนั้นเปิด coding agent ใน repository ที่มีสิทธิ์ตรวจสอบ แล้วสั่ง:
security audit this codebaseต้องใช้ coding agent และโมเดลที่รองรับการใช้เครื่องมือและ sub-agent แบบขนาน ส่วน Node.js ใช้รันตัวตรวจข้อมูล findings และ coverage ledger
ข้อกำหนดที่ห้ามมองข้ามคือ sandbox สำหรับการรันโค้ดเป้าหมาย คู่มือกำหนดให้การ build หรือทดสอบอยู่ภายใต้ข้อจำกัดที่ระบบปฏิบัติการบังคับจริง เช่น ห้ามออกเครือข่ายภายนอก ไม่รับ environment และ credentials จากเครื่องมาโดยอัตโนมัติ จำกัดทรัพยากร และเขียนได้เฉพาะพื้นที่ชั่วคราวที่จัดไว้ การเขียนใน prompt ว่า "อย่าแตะข้อมูลสำคัญ" จึงไม่ใช่สิ่งทดแทนข้อจำกัดเหล่านี้ หากบังคับไม่ได้ ต้องไม่รันโค้ดนั้น และบันทึกข้อจำกัดที่ขวางการยืนยันแทน
ตัว skill ใช้สัญญาอนุญาต MIT แต่คำว่าใช้ฟรีหมายถึงตัวซอฟต์แวร์ ไม่ได้หมายความว่าการเรียกโมเดลหรือใช้ทรัพยากรประมวลผลไม่มีต้นทุน คู่มือจึงมีทั้งขอบเขตการตรวจ โปรไฟล์ quick, standard, deep และการกำหนดงบจำนวนการเรียก agent โดยลดความกว้างของงานได้ แต่ห้ามลดมาตรฐานหลักฐานเพื่อให้ดูเหมือนตรวจเสร็จ
บทเรียนที่ใหญ่กว่าการตรวจช่องโหว่
สิ่งที่น่าเรียนรู้จากโครงการนี้ไม่ใช่แนวคิดว่า "ต่อไปไม่ต้องมีคนตรวจความปลอดภัยแล้ว" แต่คือวิธีออกแบบให้ AI ทำงานโดยยอมรับข้อจำกัดของตัวเอง
เริ่มจากเข้าใจบริบท แบ่งงานให้ตรวจสอบย้อนหลังได้ เปิดให้ผู้ตรวจอีกตัวหักล้าง เก็บสิ่งที่ยังไม่รู้ไว้อย่างตรงไปตรงมา และไม่สับสนระหว่าง "ยังไม่ได้ตรวจ" กับ "ตรวจแล้วไม่พบปัญหา"
AI ที่เหมาะกับงานจริงจัง ไม่ควรมีหน้าที่แค่สร้างคำตอบที่น่าเชื่อ แต่ต้องทำให้เราตรวจได้ด้วยว่า เหตุใดคำตอบนั้นจึงควรเชื่อ และส่วนไหนยังไม่ควรเชื่อ
Security Audit Skill ของ Cloudflare เป็นตัวอย่างที่น่าสนใจของการเปลี่ยนหลักคิดนี้ให้กลายเป็นกระบวนการทำงาน ไม่ใช่เพียงคำเตือนท้าย prompt ว่า "กรุณาอย่ามั่ว"
ทีม Devsign ออกแบบ AI Workflow ที่ตรวจสอบได้ สำหรับงานจริงขององค์กร ทั้งการแบ่งบทบาท agent การกำหนดเกณฑ์หลักฐาน และการออกแบบ checkpoint ให้ผลลัพธ์ตรวจย้อนได้