สกิล security-audit ของ Cloudflare ขึ้นเทรนด์ GitHub หลังถูกรื้อใหม่ทั้งชุด — บังคับ sandbox ก่อนรันโค้ดเป้าหมาย และให้เอเจนต์คนละตัวมาพยายามล้มผลของกันเอง

cloudflare/security-audit-skill เป็นสกิลสำหรับ coding agent ที่ Cloudflare เปิดซอร์สไว้ใต้ MIT ตั้งแต่ 18 มิ.ย. 2026 และวันนี้มันกลับมาอยู่บน GitHub Trending อีกครั้งที่ราว 5.4 พันดาว หลังถูกรื้อครั้งใหญ่ที่สุดนับตั้งแต่เปิดตัว — PR #12 merge เมื่อ 10 ก.ย. ด้วยขนาด +4,792 / −701 บรรทัดใน 21 ไฟล์ ตามด้วยคอมมิต 14 ก.ย. ที่ชื่อ “Clarify guidance and full audit modes” ซึ่งแก้ SKILL.md, HUNTING.md และ README อีกรอบ

ตัวสกิลไม่ใช่ linter และไม่ใช่ wrapper ของ scanner เดิม แต่เป็น ชุดคำสั่งที่เปลี่ยนเอเจนต์เขียนโค้ดของคุณให้เป็นทีมตรวจความปลอดภัย README ระบุว่านี่คือ “สกิลที่เป็นเมล็ดพันธุ์ของ vulnerability discovery harness ของ Cloudflare เอง” ซึ่งภายหลังโตเป็นระบบหลายสเตจระดับทั้งกองโค้ด ส่วนตัวสกิลคือจุดตั้งต้นแบบ repo เดียวที่ระบบนั้นวิวัฒน์ออกมา

หกเฟส และการให้เอเจนต์คนละตัวล้มผลของกันเอง

เวิร์กโฟลว์เต็มมีหกเฟสตามที่ README ระบุ:

1. Reconnaissance — วาดสถาปัตยกรรม, trust boundary, พื้นผิวรับอินพุต และสร้าง architecture.md กับ coverage-ledger.json
2. Coverage-led hunting — แจกงานให้ hunter ที่แยกกันจาก unit ใน ledger บันทึกสิ่งที่แต่ละตัวตรวจไปแล้ว แล้วใช้ “coverage critic” ไล่หาช่องที่ยังไม่มีใครดู
3. Candidate validation — ส่งผู้ต้องสงสัยทุกตัวให้ verifier ตัวใหม่ที่พยายามพิสูจน์ว่ามันไม่จริง
4. Structured output — เขียนระเบียน confirmed / needs_validation / rejected ลง findings.json แล้วตรวจกับ report-schema.json
5. Independent record verification — เอเจนต์ชุดใหม่ตรวจข้ออ้างที่อ้างอิงซอร์สอีกรอบ ของที่ถูกแทนที่แบบมีนัยสำคัญต้องผ่าน verifier อิสระอีกตัว
6. Target-neutral reporting — สรุปเป็น REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md

หัวใจของการรื้อรอบนี้อยู่ที่ สัญญาของผลลัพธ์ (findings contract) สามกิ่งที่นิยามไว้คนละแบบชัดเจน: confirmed ต้องมีร่องรอยจากซอร์สครบและผลที่สังเกตได้จริงแบบมีขอบเขต, needs_validation ต้องระบุ ข้อเท็จจริงที่ยังค้างอยู่แบบเจาะจง และ ไม่มีระดับความรุนแรง, ส่วน rejected คือบันทึกของผู้ต้องสงสัยที่ถูกพิสูจน์ว่าไม่ใช่ นอกจากนี้ความรุนแรงถูก “capped at demonstrated impact” คือห้ามให้คะแนนเกินผลกระทบที่สาธิตได้จริง และสถานะ “รันไม่จบ” ถูกทำให้เป็นสถานะที่ต้องประกาศออกมา แทนที่จะเงียบแล้วปล่อยให้เข้าใจว่าตรวจครบ

ฝั่งตรวจทานผลมี validator ไร้ dependency สองตัว คือ validate-findings.cjs (ถูกทำให้แข็งขึ้น: แยก prose ออกจาก payload ที่ต้องตรงตัว, ปฏิเสธ path ที่ไม่ปลอดภัย, จำกัดโครงสร้างก่อน parse, ไม่ตาม symlink, UTF-8 ผิดถือว่า fatal) และ validate-coverage-ledger.cjs ตัวใหม่ รวมเทสต์ 65 ข้อ รวมถึงเทสต์ความสอดคล้องข้าม validator ทั้งสองตัว ทั้งหมดเขียนเป็น .cjs ที่รันได้ด้วย Node เปล่า ๆ ไม่ต้องติดตั้งอะไรเพิ่ม

ข้อที่ควรลอกไปใช้แม้ไม่ได้ใช้สกิลนี้: กฎการรันโค้ดของเป้าหมาย

ส่วนที่ผมคิดว่ามีค่าที่สุดสำหรับคนทำ agent workflow ทั่วไปคือหมวด Universal execution safety ซึ่งบังคับใช้ทั้งสองโหมด: การอ่านซอร์สเป็น read-only ส่วนการรัน build, test, process, browser, emulator, fuzzer หรือประมวลผล fixture ของเป้าหมาย ทำได้ เฉพาะใน sandbox ที่ OS บังคับ และต้องมีครบทุกข้อต่อไปนี้

• ไม่มีเน็ตภายนอก ใช้ได้แค่ loopback namespace ที่แยกออกมา เมื่อการตรวจนั้นต้องมี traffic client/server ในเครื่อง
• environment ว่างเปล่าที่เติมจาก allowlist เท่านั้น พร้อม HOME, temp dir และ cache ที่อยู่ใน scratch
• target กับ toolchain เป็น read-only กระบวนการที่เป้าหมายคุมได้เขียนได้เฉพาะใน scratch/ ของตัวเอง
• จำกัด CPU, หน่วยความจำ, จำนวน process, ขนาดไฟล์, ดิสก์ และ wall-clock อย่างชัดเจน

และประโยคที่สำคัญที่สุด: ถ้าบังคับครบทุกข้อไม่ได้ ห้ามรันโค้ดของเป้าหมาย ให้รายงานว่าขาดความสามารถ sandbox ข้อไหนเป็น blocker ระดับ needs_validation พร้อมเสนอแผนตรวจที่ปลอดภัยแทน — แปลว่าสกิลเลือกที่จะ “ไม่รู้” มากกว่าจะ “รู้แบบเสี่ยง” ซึ่งตรงข้ามกับพฤติกรรมปริยายของเอเจนต์ส่วนใหญ่

ยังมีข้อห้ามชัด ๆ อีกชุด: ห้ามยิง endpoint ที่ deploy จริง, บริการภายนอก, โครงสร้างพื้นฐานที่ใช้ร่วมกัน, ตัวตนใน production, ข้อมูลของผู้ใช้คนอื่น หรือ control plane ที่ยังมีชีวิต; ห้ามทดสอบ availability กับ process จริง; ห้ามใช้โควตา API ที่เสียเงิน; ห้ามติดตั้ง dependency หรือปล่อยให้ build ไปดึงของจากเน็ต — ใช้เฉพาะเครื่องมือที่มีอยู่แล้วในเครื่อง

เรื่อง write isolation ก็ละเอียดผิดคาด: parent เป็นผู้เขียนไฟล์ส่วนกลางเพียงผู้เดียว, hunter/verifier แต่ละตัวได้ root ของตัวเองใต้ agents/<agent-id>/ โดย agent ID ต้องตรง ^[a-z0-9][a-z0-9_-]{0,63}$ และ ห้ามเป็นชื่ออุปกรณ์ของ Windows อย่าง con, prn, aux, nul, com1–com9, lpt1–lpt9 ส่วนการย้ายไฟล์หลักฐานจาก scratch/ ไป artifacts/ มีขั้นตอน 11 ข้อที่ต้องเดิน path ด้วย descriptor แบบ no-follow, ตรวจ fstat ว่าเป็น regular file ที่ link count เท่ากับหนึ่ง, ตรวจขนาดซ้ำหลังคัดลอก และห้ามคัดลอกแบบ recursive หรือแตก archive เข้า artifacts เด็ดขาด นี่คือเช็กลิสต์กัน TOCTOU และ symlink attack ที่เขียนไว้ให้เอเจนต์อ่าน ซึ่งหาอ่านยากในสกิลสาธารณะตัวอื่น

สองโหมด และสิ่งที่คอมมิต 14 ก.ย. ไปแก้

คอมมิตล่าสุดทำให้ขอบเขตชัดขึ้นว่า โหลดสกิลไม่เท่ากับอนุญาตให้รันเวิร์กโฟลว์เต็ม

• Guidance mode (ค่าปริยาย) — สำหรับคำถามด้านความปลอดภัย, รีวิวเฉพาะจุด, วิธีการ, triage ให้ใช้เฉพาะส่วนที่เกี่ยวข้อง ห้ามรันครบหกเฟสเอง ห้ามสร้างไดเรกทอรีผลลัพธ์ ห้ามเขียนไฟล์รายงาน
• Full audit mode — ใช้เมื่อผู้ใช้สั่งตรวจ/pen-test ทั้ง codebase, ขอรีวิวแบบครบวงจร หรือขอไฟล์รายงาน จึงรันหกเฟสและเขียนไฟล์
• ถ้าคำสั่งกำกวม สกิลสั่งให้ ถามหนึ่งคำถาม ก่อนจะสร้างไฟล์หรือเริ่มเวิร์กโฟลว์

ผลลัพธ์ปริยายถูกบังคับให้ออกไป นอก repo ของเป้าหมาย ที่ ~/security-audit-skill/<repo-name>/run-<N> และจะเขียนในไดเรกทอรีของเป้าหมายได้ต่อเมื่อผู้ใช้เลือกเองและ parent ตรวจแล้วว่า version control ไม่สนใจไดเรกทอรีนั้นทั้งก้อน — แก้ปัญหาคลาสสิกของเอเจนต์ที่ทิ้งรายงานช่องโหว่ไว้กลาง repo แล้วมีคน commit ตามขึ้นไปโดยไม่ตั้งใจ

ตัวสกิลเขียนแบบ agent-neutral (นิยามบทบาทเป็น parent, Task tool, research agent, general agent แล้วบอกให้ map กับความสามารถของแพลตฟอร์มที่ใช้) ติดตั้งผ่าน Skills CLI:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

แล้วสั่งเป็นภาษาคนอย่าง security audit this codebase หรือ find security vulnerabilities in ./src ไฟล์ companion แยกตามโดเมนมีสิบกว่าไฟล์ ตั้งแต่ AI-AND-LLM.md (prompt injection, agent/tool, output handling), SUPPLY-CHAIN-AND-RELEASE.md, CLOUD-AND-DEPLOYMENT.md, DATA-ISOLATION-AND-LIFECYCLE.md ไปจนถึง MEMORY-SAFETY-AND-BINARY.md สำหรับเป้าหมาย native

สิ่งที่ยังไม่มี: repo นี้ยังไม่มี release หรือ tag แม้แต่อันเดียว ทุกคนดึงจาก main ที่ขยับได้ตลอด และ “หลักฐาน” ว่ามันได้ผลคือคำอธิบายใน PR ของ Cloudflare เอง — validator ผ่าน 65/65, ตรวจ end-to-end สองรอบบน repo ภายในด้วยโมเดล gpt-5.6-sol โดยไม่มี provider error และรันหนึ่งรายงานตัวเองว่าครอบคลุมไม่ครบเพราะชน budget — ไม่ใช่เบนช์มาร์กสาธารณะที่ใครไปทำซ้ำได้

มุมมอง AI Curator

เมื่อวานเราเพิ่งเขียนถึงรายงาน Trail of Bits ที่รื้อเบนช์มาร์กแพตช์ช่องโหว่ของ 1Password ซึ่งประเด็นหลักคือ “ตัวเลขพาดหัวเชื่อไม่ได้ถ้าไม่ดูว่าเขานับอะไรเข้าไปบ้าง” สกิลตัวนี้น่าสนใจเพราะมันตอบโจทย์เดียวกันจากอีกด้าน — แทนที่จะพยายามทำให้เอเจนต์เก่งขึ้น มันพยายามทำให้ ผลลัพธ์ของเอเจนต์ตรวจสอบได้ ด้วยกลไกสามอย่าง: แยกคำตัดสินเป็นสามกิ่งโดยมีกิ่ง “ยังไม่รู้” ที่ไม่ยอมให้ใส่ความรุนแรง, ให้เอเจนต์ตัวใหม่ที่ไม่มีบริบทเดิมมาพยายามล้มผล และบังคับให้รายงานความครอบคลุมที่ไม่ครบออกมาเป็นสถานะ ไม่ใช่ความเงียบ

สำหรับทีมไทย ผมคิดว่าคุณค่าที่หยิบไปใช้ได้ทันทีไม่ใช่การรัน security audit แล้วเชื่อรายงาน แต่คือ การอ่าน SKILL.md เป็นแบบฝึกหัดการเขียน prompt สำหรับงานที่ผิดพลาดไม่ได้ สังเกตว่ามันไม่ได้บอกเอเจนต์ว่า “จงระวัง” แต่เขียนเงื่อนไขหยุด, สถานะปลายทาง, ขอบเขตความลึกของการสำรวจ และขั้นตอนย้ายไฟล์ 11 ข้อแบบที่โปรแกรมเมอร์เขียน spec ให้โปรแกรม นี่คือทิศทางที่งานเขียนสกิลกำลังมุ่งไป — จากย่อหน้าแนะนำสไตล์ กลายเป็นสัญญาที่ตรวจด้วยเครื่องได้

ข้อควรระวังที่อยากฝากไว้: สกิลที่เก่งเรื่องหาช่องโหว่คือสกิลที่รู้วิธีโจมตีด้วย และนี่คือไฟล์ markdown ใต้ MIT ที่ใครก็แก้ได้ การติดตั้งด้วย npx skills add จาก URL ตรง ๆ โดยไม่มี release ให้ตรึงเวอร์ชัน แปลว่าคุณกำลังเชื่อ main ณ วินาทีที่ดึง — ในบริบทที่สเปก MCP เพิ่งออกกฎว่าสกิลจากภายนอกต้องถือเป็นข้อมูลที่ไม่น่าเชื่อถือและต้องผูกการอนุมัติกับ digest (SEP-2640) การ fork มาไว้ใน repo ของตัวเองแล้ว pin commit คือขั้นตอนที่ไม่ควรข้าม ยิ่งถ้าจะให้มันรันบนโค้ดของลูกค้า

แหล่งข่าว

• cloudflare/security-audit-skill บน GitHub
• PR #12 — Rework the audit workflow, findings contract, and validators end to end
• SKILL.md ฉบับปัจจุบัน
• Build your own vulnerability harness — Cloudflare Blog (18 มิ.ย. 2026)