อ่านสไลด์ Vibe Coding with Security แล้วคิดอะไรบ้าง: 7 เรื่องที่ผมสะดุด

หมายเหตุก่อนอ่าน: ผม ไม่ได้อยู่ในห้อง ผมอ่านจากไฟล์สไลด์ของเซสชัน "Vibe Coding with Security" ที่ Pichaya Morimoto (Lead Penetration Tester, Siam Thanat Hack หรือ STH) พูดในงาน Cybersecurity x Cybersecurity 2026 วันที่ 2026-11-12 ที่ Sofitel Bangkok Sukhumvit และเป็นสไลด์ที่ผู้พูดแชร์ผ่านลิงก์สาธารณะ (ดูท้ายบทความ) ความคิดเห็นในบทความนี้เป็นของผม ส่วนข้อเท็จจริงผมพยายามไล่ไปหาแหล่งต้นทางมาแปะไว้ท้ายบทความ อันไหนตามไม่เจอผมเขียนบอกไว้ว่า ยังไม่ยืนยัน สไลด์และภาพในสไลด์เป็นของผู้พูดและ STH ผมไม่ได้นำภาพมาใส่

เซสชันนี้มีสไลด์ 53 หน้า ชื่อเรื่องคือ "ใช้ AI เขียนโค้ดให้เร็ว โดยไม่เปิดช่องโหว่" ผมอ่านจบรวดเดียว แล้วอ่านซ้ำอีกรอบเพื่อไล่ตรวจตัวเลข ข้างล่างคือ 7 เรื่องที่ทำให้ผมหยุดคิด

เครดิตภาพ: ภาพทุกภาพในบทความคือหน้าสไลด์จากเซสชัน "Vibe Coding with Security" โดย Pichaya Morimoto (STH) นำมาใช้เพื่ออธิบายประกอบการสรุป สไลด์เป็นลิขสิทธิ์ของผู้พูดและ STH หากเจ้าของต้องการให้ถอดภาพ ผมพร้อมถอดทันที ไฟล์สไลด์ต้นทางดูที่ลิงก์ท้ายบทความ

1. "ไม่พบช่องโหว่" ไม่ใช่หลักฐานว่าปลอดภัย

สไลด์เปิดด้วยฉากจำลองที่ผมชอบมาก: พิมพ์ /goal Find all security bugs. 100% coverage. แล้ว AI รายงานว่า "Coverage: 100%, ไม่พบช่องโหว่" ทั้งที่ log ด้านบนเขียนว่าอ่านไป 214 จาก 1,284 ไฟล์

สไลด์หน้า 7/54: ภาพจำลองของผู้พูด ไม่ใช่ log จริงของเครื่องมือใด

สไลด์หน้า 8/54: Context window เหมือนไฟฉาย (อ้าง README ของ Cloudflare security-audit-skill)

ต้องบอกก่อนว่า ฉากนี้เป็นภาพจำลองของผู้พูด ไม่ใช่ log จริงของเครื่องมือใด แต่ประเด็นไม่ใช่เรื่องสมมติ README ของ Cloudflare security-audit-skill เขียนไว้ว่า (แปลโดยผม) ในการรันทดสอบของพวกเขา การรันครั้งเดียวเจอช่องโหว่ราวครึ่งหนึ่งของที่เจอรวมจากการรันซ้ำหลายรอบ ผมว่านี่คือสิ่งที่คนทำงานสาย AI ควรจำให้ขึ้นใจ: ผลที่ได้จากการรันครั้งเดียวคือ ตัวอย่าง ไม่ใช่ การพิสูจน์

ท่าที่ทีมไหนก็ทำได้คือ ให้เอเจนต์ "หา" แล้วให้อีกตัว "ค้าน" แล้วให้คนตัดสิน และทุก finding ต้องมี PoC หรือ test ติดมาด้วย สไลด์เรียกว่า pipeline 4 gate (scanner → AI review → validator → human) ผมเห็นด้วยกับหลักการนี้ทั้งหมด

2. ตัวเลข Veracode: ดีขึ้นจริง แต่อย่าอ่านเกินจริง

สไลด์อ้างว่าโค้ดที่ AI สร้างผ่านเกณฑ์ความปลอดภัยเฉลี่ย 62% และโมเดลที่ดีที่สุดได้ 73% ผมไปเช็กกับ press release ของ Veracode (29 ต.ค. 2026) ตัวเลขตรงกัน: ค่าเฉลี่ยขึ้นจาก 56% เป็น 62% และ Claude Opus 5.5 กับ GPT-6-Sol ได้ 73% เท่ากัน

สไลด์หน้า 10/54: ตัวเลข Veracode ตามที่สไลด์สรุป (ผมตรวจกับ press release แล้ว ดูหัวข้อ 2)

แต่มีรายละเอียดที่สไลด์ไม่มีที่ว่างให้บอก และผมคิดว่าสำคัญ:

• การทดสอบครอบคลุม 4 หมวด CWE เท่านั้น (SQL injection, crypto, XSS, log injection) บน 18 โมเดล ไม่ใช่ "ความปลอดภัยทั้งหมด"
• SQL injection ผ่านที่ 84% และ crypto ที่ 87% (Veracode ว่าสองหมวดนี้ทรงตัวใกล้เพดานอยู่แล้ว) XSS คือตัวที่ขยับ (ไปอยู่ที่ 18%) ส่วน log injection ยังนิ่งที่ 13%
• Veracode อธิบายว่า XSS เป็นช่องโหว่ที่แก้ได้ง่ายที่สุดด้วยการจำแพตเทิร์น ซึ่งตรงกับจุดที่ LLM เก่งอยู่แล้ว (ความเห็นของ Veracode ไม่ใช่ข้อสรุปของผม)

ข้อสังเกตของผมคือ ข่าวดีที่แท้จริงคือ "ดีขึ้นในจุดที่มีตัวอย่างสอนเยอะ" ไม่ใช่ "ความปลอดภัยดีขึ้นทุกด้าน" และข้อสรุปของ Veracode ที่ผมชอบคือ โมเดลระดับกลางบวกการสแกน อาจคุ้มกว่าโมเดลแพงสุดที่ไม่มีการตรวจ (แน่นอนว่านี่เป็นบริษัทที่ขายเครื่องมือสแกน ให้นับเป็นความเห็นของผู้ขาย)

3. เคส Binance: สไลด์ชี้ไปที่เครื่องของวิศวกร

ส่วนที่ทำให้ผมรู้สึกหนักที่สุดคือเคส Binance (ประกาศ Initial Findings 3 พ.ย. 2026) ตามประกาศของ Binance เอง สินทรัพย์ประมาณ USD 6.34 พันล้าน ได้รับผลกระทบ และ freeze/intercept ได้ประมาณ USD 2.85 พันล้าน (สไลด์ปัดเป็น ~3B) ผู้โจมตีเข้าถึง internal wallet signing service แล้วใช้กลไก EIP-7702 (ที่ให้บัญชีมอบสิทธิ์ execution บางส่วนแก่ smart contract) กับ hot wallet ตามคำอธิบายของ Binance ส่วนวิธีเข้า สื่ออย่าง CNBC และ BBC รายงานตามที่ co-CEO ให้สัมภาษณ์ว่า ใช้การสัมภาษณ์งานปลอม (ตามที่ co-CEO ให้สัมภาษณ์ ตรงกับพาดหัวของ BBC) และ "ใช้เวลาหลายเดือนสร้างทางเข้า"

สไลด์หน้า 17/54: ไทม์ไลน์ตามสไลด์ *ผมยืนยันได้เฉพาะ USD 6.34B, ~2.85B ที่ freeze, สัมภาษณ์งานปลอม, signing service และ EIP-7702** ส่วน Homebrew/pyenv/TraderTraitor ยังไม่ยืนยัน*

สไลด์หน้า 18/54: ไฟล์ใน repo ที่ทำให้โค้ดรันได้โดยผู้ใช้ไม่ได้สั่งตรง ๆ

สไลด์ลงรายละเอียดมากกว่านั้นอีก (เริ่มจาก Homebrew ที่ถูกดัดแปลง, pyenv, ขยายไปยึด AI tool ภายใน, ผู้โจมตีคือ TraderTraitor) ส่วนนี้ผมตามหาในประกาศต้นทางไม่เจอ จึงขอไม่ยืนยัน Binance เองก็ระบุว่าจะเก็บรายละเอียดทางเทคนิคบางส่วนเป็นความลับ

สิ่งที่ผมเอากลับมาคิด: เราคุ้นกับการป้องกันเซิร์ฟเวอร์ แต่เครื่อง developer ที่มี ~/.aws, ~/.ssh, token ใน .env และตอนนี้มี AI agent ที่มีสิทธิ์รันคำสั่ง คือเป้าที่มีค่ามากกว่าหลายเซิร์ฟเวอร์ สไลด์ยกตัวอย่างไฟล์ใน repo ที่ทำให้โค้ดรันได้โดยผู้ใช้ไม่ได้สั่งตรง ๆ (ตอนเปิดโฟลเดอร์ ตอนติดตั้ง หรือตอนเปิด agent) ได้แก่ .vscode/tasks.json ที่ตั้ง runOn: folderOpen, postinstall ใน package.json, hooks ใน .claude/settings.json และ command ใน .mcp.json (บางตัวมีขั้นตอน trust/อนุมัติคั่นอยู่ แต่เราไม่ควรพึ่งการกดยอมรับอย่างเดียว) ข้อแนะนำที่ผมจะเอาไปใช้ทันที: repo แปลกหน้าเปิดใน VM หรือ dev container ที่ไม่มี credential จริงเท่านั้น

4. axios 3 ชั่วโมง: จุดที่ผมเพิ่งสังเกตคือ "ข้าม CI"

เรื่องนี้ตรวจกับ Datadog Security Labs และ CISA ได้เลย เมื่อ 2026-03-31 ผู้โจมตีแฮ็กบัญชี npm ของ maintainer แล้วเผยแพร่ [email protected] และ [email protected] ที่เพิ่มดีเพนเดนซีปลอม plain-crypto-js (typosquat ของ crypto-js) ที่ดาวน์โหลดและรัน RAT ตอนติดตั้ง ช่วงที่อันตรายอยู่ประมาณ 3 ชั่วโมง (00:21 ถึง 03:25 UTC) ก่อน npm ถอดออก

สไลด์หน้า 26/54: เคส axios 2026-03-31 (ตรวจกับ Datadog และ CISA แล้ว)

รายละเอียดที่ผมชอบจาก Datadog: เวอร์ชันถูกต้อง 1.14.0 เผยแพร่ผ่าน GitHub Actions OIDC trusted publishing ส่วนเวอร์ชันมัลแวร์ถูก เผยแพร่ตรงจากบัญชีที่ถูกยึด ข้าม CI/CD กล่าวคือ ถ้าเรามองเฉพาะ "ผ่าน pipeline หรือเปล่า" เราจะพลาด

และตัวเลขที่ทำให้แนวคิด dependency cooldown ดูมีเหตุผลขึ้นมาก: Datadog รายงานว่า 50% ขององค์กรใช้ไลบรารีภายใน 1 วันหลังปล่อย ทำให้ชุมชนมีเวลาตรวจพบน้อยมาก แค่ตั้งให้ไม่รับ release ที่ใหม่เกินไป (เช่น minimumReleaseAge ใน pnpm) ก็ตัดความเสี่ยงช่วงต้นของเคสแบบนี้ได้โดยแทบไม่ต้องลงแรง

5. LiteLLM: เครื่องมือสแกนก็คือ supply chain

ตามประกาศของ LiteLLM เอง เวอร์ชัน 1.82.7 และ 1.82.8 บน PyPI เผยแพร่เมื่อ 2026-03-24 อยู่ราว 40 นาที ก่อนถูก PyPI กักกัน เวอร์ชันหลังมีไฟล์ litellm_init.pth ที่ทำงานเมื่อ Python เริ่ม ทีม LiteLLM เชื่อว่าต้นเหตุมาจาก Trivy ซึ่งเป็นเครื่องมือสแกนความปลอดภัยใน CI ของพวกเขา ถูก compromise และผู้โจมตีอัปโหลดขึ้น PyPI ตรง ข้าม workflow ปกติ (เป็น "ข้อสันนิษฐานจากหลักฐานเบื้องต้น" ตามถ้อยคำของประกาศ)

สไลด์หน้า 27/54: ห่วงโซ่ Trivy → LiteLLM ตามสไลด์ (ไฟล์ sysmon.py ในภาพ ผมยังไม่ยืนยัน)

ผมคิดว่านี่คือประโยคที่สรุปเรื่อง supply chain ได้ดีที่สุดในเซสชัน: scanner ที่รันใน CI ก็เป็น supply chain ต้อง pin version และจำกัดสิทธิ์เหมือนดีเพนเดนซีตัวอื่น เรื่องนี้เตือนว่าเครื่องมือฝั่ง security ก็ต้องถูกตั้งคำถามเหมือนกัน

(สไลด์ยังบอกถึงไฟล์ persistence ที่ ~/.config/sysmon/sysmon.py ส่วนนี้ผมยังไม่เจอในประกาศของ LiteLLM จึงไม่ขอยืนยัน)

6. Slopsquatting: ปัญหาคือ "ชื่อที่ AI แต่ง" ซ้ำได้

คำว่า package hallucination ไม่ใช่เรื่องใหม่ แต่สไลด์เล่าเคส huggingface-cli ได้เห็นภาพ: นักวิจัยของ Lasso จดแพ็กเกจเปล่าชื่อนี้บน PyPI ที่ AI เคยแนะนำให้ pip install และใน 3 เดือนมีดาวน์โหลดจริงเกิน 30,000 ครั้ง (คำสั่งที่ถูกต้องคือ pip install -U "huggingface_hub[cli]")

สไลด์หน้า 28/54: ตัวเลข 576,000 / 19.7% ตรงกับเปเปอร์ USENIX ส่วน 205,474 และ 43% ผมยังไม่ยืนยัน

ส่วนตัวเลขระดับงานวิจัย ผมยืนยันได้จากเปเปอร์ USENIX Security 2025 (Spracklen et al.): ทดสอบ 16 โมเดล สร้างโค้ด 576,000 ตัวอย่าง และ 19.7% ของแพ็กเกจที่แนะนำไม่มีอยู่จริง สไลด์ยังอ้างว่า 43% ของชื่อปลอมโผล่ซ้ำทั้ง 10 รอบ ซึ่งถ้าจริงจะสำคัญมาก เพราะแปลว่าผู้โจมตีคาดเดาชื่อที่ควรจดไว้ได้ แต่ ผมยังไม่ได้ยืนยันตัวเลข 43% และ 205,474 ชื่อกับตัวเปเปอร์เอง

ข้อสรุปเชิงปฏิบัติที่ผมชอบเพราะทำได้เลย: อย่าปล่อยให้ "คนจำได้" เป็นด่านป้องกัน ให้ lockfile, npm ci --ignore-scripts และ SCA/สแกนใน PR เป็นด่านบังคับ

7. LLM แอป: ถ้าสิทธิ์อยู่ที่เหยื่อ ไม่ต้องเจาะอะไรเลย

สไลด์หน้า 42/54: Lethal Trifecta (แนวคิดของ Simon Willison)

สไลด์หน้า 45/54: เคส RovoBlast (Varonis, DEF CON 34)

สไลด์หน้า 46/54: เคส CoSnitch (CVE-2026-24301)

สไลด์หน้า 49/54: Reference architecture ของผู้พูด

ส่วนสุดท้ายของเซสชันว่าด้วยแอปที่เรียก LLM ผมประทับใจแนวคิด Lethal Trifecta ของ Simon Willison: ถ้า agent เดียวมีทั้ง (1) ข้อมูลส่วนตัว (2) เนื้อหาจากคนนอกที่ไม่น่าเชื่อถือ (3) ช่องทางส่งข้อมูลออก ข้อมูลรั่วได้ด้วยข้อความเดียว วิธีแก้คือตัดอย่างน้อยหนึ่งขา

สองเคสจริงที่สไลด์ยกมาแสดงให้เห็นชัด:

• RovoBlast (Varonis): ลิงก์เดียวมี prompt ใน URL parameter ที่ถูกเติมในแชทของ Rovo ผู้ใช้ที่ login อยู่แค่คลิก Varonis เน้นว่า "ไม่ต้อง jailbreak ไม่ต้อง bypass สิทธิ์" เพราะ AI ใช้สิทธิ์ที่เหยื่อมีอยู่แล้ว มีโพสต์ในชุมชน Atlassian (เขียนโดยสมาชิกชุมชน ไม่ใช่ประกาศทางการ) ที่ระบุว่า RovoBlast ถูกแก้แล้ว แต่ prompt injection แบบ indirect ผ่านเนื้อหาที่ Rovo ประมวลผล (เช่น Jira issue, Confluence, PDF) แล้วรั่วผ่านรูป Markdown ยังเป็นช่องทางที่ผู้เขียนระบุว่าเปิดอยู่
• CoSnitch (CVE-2026-24301): ผมอยากชี้แจงให้ชัดว่ามันเกี่ยวกับ Copilot Personal (เวอร์ชันผู้ใช้ทั่วไป) และตามรายงานของ The Hacker News งานวิจัยไม่ได้ระบุว่าพฤติกรรมเดียวกันกระทบ Microsoft 365 Copilot Varonis แบ่งเป็น 3 ช่องโหว่: 2 ข้อเป็นเส้นทางส่งข้อมูลออกผ่านลิงก์เดียว และอีก 1 ข้อเป็นการเขียนคำสั่งลง memory ผ่านหน้าเว็บที่ให้ Copilot สรุป ซึ่งตามรายงานคำสั่งนั้นอยู่ต่อแม้เปลี่ยนรหัสผ่านหรือ revoke session จนกว่าผู้ใช้จะลบเอง

บทเรียนทางสถาปัตยกรรมที่ผมจดไว้จากสไลด์: Model ไม่ใช่ security boundary ให้ LLM "เสนอ" tool call แล้วให้ backend ตรวจ schema → identity → authorization → budget → human approval → audit ทุกครั้ง

ความรู้สึกหลังอ่านจบ

สิ่งที่ผมได้จากเซสชันนี้ ไม่ใช่ "AI อันตราย อย่าใช้" ตรงกันข้าม สไลด์ตั้งต้นจากการที่ทุกคนใช้ AI ไปแล้ว และถามต่อว่า รัศมีความเสียหายใหญ่แค่ไหนเมื่อมันพลาด คำตอบเชิงปฏิบัติสั้นมาก: least privilege, sandbox, pin version, พิสูจน์ด้วยหลักฐาน, ให้คนเป็นคนกดอนุมัติเรื่องที่ย้อนไม่ได้

มีอยู่สามประโยคที่ผมอยากแปะไว้ข้างจอ:

1. "กฎที่ไม่มี test บังคับ เป็นแค่คำขอร้อง" (จากหัวข้อ AGENTS.md ในสไลด์) — ผมว่าเป็นคำสอนที่ใช้ได้กับทุกอย่าง ไม่ใช่แค่ AI
2. AI review คือ signal ไม่ใช่ใบรับรอง — ผมเห็นด้วย และจะไม่เขียนว่า "AI ตรวจแล้วปลอดภัย" ในรายงานใด ๆ
3. ความเร็วเป็นของฟรีที่ AI ให้มา แต่รัศมีความเสียหายไม่ใช่ของฟรี — ลดรัศมีก่อนเพิ่มความเร็ว

สิ่งที่ผมจะลงมือทำสัปดาห์นี้: (1) ย้ายการเปิด repo แปลกหน้าไปทำใน VM ที่ไม่มี credential (2) เปิด cooldown ใน package manager ที่ใช้ (3) ตรวจว่า agent ที่รันอยู่มี deny read กับ .env / ~/.aws / ~/.ssh หรือยัง (4) ตั้ง hard limit และ budget alert ให้ทุก API key

ข้อจำกัดของบทความนี้

• ผมอ่านจากสไลด์ ไม่ได้ฟังคำบรรยายสด อาจพลาดบริบทที่ผู้พูดเล่าเพิ่ม
• หลายเหตุการณ์ในสไลด์เกิดล่าสุดมาก และบางรายละเอียดยังอยู่ระหว่างสอบสวน (เช่น Binance) ข้อมูลอาจเปลี่ยน
• สไลด์ยกเคส Cowork ลบไฟล์ ~275 GB (GitHub issue #106205) ซึ่งเป็นรายงานของผู้ใช้ สาเหตุที่ผู้แจ้งสันนิษฐานยังไม่ถูกตรวจสอบอิสระ ผมจึงไม่ได้เอามาเป็นข้อสรุปในบทความ
• ข้อมูลของ Veracode และ Codex Security (สแกนมากกว่า 1.2 ล้าน commit ใน 30 วันช่วง beta พบ 792 critical และ 10,561 high ตามที่ OpenAI เผยแพร่ และ The Hacker News รายงานต่อ) เป็นตัวเลขจากผู้ให้บริการเอง

แหล่งอ้างอิง

• Binance, "Security Incident: Initial Findings and Response Update" (3 พ.ย. 2026): https://www.binance.com/en/square/post/384312159834579
• BBC, "Binance says fake job interviews used as part of $6.3bn crypto hack": https://www.bbc.co.uk/news/articles/ck5ynwz9gy67o
• CNBC, "Binance co-CEO Teng says hackers used fake job interviews…" (3 พ.ย. 2026): https://www.cnbc.com/2026/11/03/binance-co-ceo-teng-says-hackers-used-fake-job-interviews-to-steal-6point3-billion-in-crypto.html
• Datadog Security Labs, "Compromised axios npm package delivers cross-platform RAT": https://securitylabs.datadoghq.com/articles/axios-npm-supply-chain-compromise
• CISA, "Supply Chain Compromise Impacts Axios Node Package Manager" (20 เม.ย. 2026): http://cisa.gov/news-events/alerts/2026/04/20/supply-chain-compromise-impacts-axios-node-package-manager
• LiteLLM, "Security Update: Suspected Supply Chain Incident": https://docs.litellm.ai/blog/security-update-march-2026
• Microsoft Security Blog, "Guidance for … the Trivy supply chain compromise" (24 มี.ค. 2026): https://www.microsoft.com/en-us/security/blog/2026/03/24/detecting-investigating-defending-against-trivy-supply-chain-compromise
• Veracode, "Veracode Finds First Meaningful Gain in AI Code Security Since 2025…" (29 ต.ค. 2026): https://www.veracode.com/press-release/veracode-finds-first-meaningful-gain-in-ai-code-security-since-2025-as-average-pass-rate-hits-62/
• Cloudflare, security-audit-skill (README): https://github.com/cloudflare/security-audit-skill
• OpenAI, "Codex Security: now in research preview": https://openai.com/index/codex-security-now-in-research-preview/
• Spracklen et al., "We Have a Package for You!…", USENIX Security 2025: https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen
• Lasso Security, "AI Package Hallucinations": https://www.lasso.security/blog/ai-package-hallucinations
• Varonis, "RovoBlast": https://www.varonis.com/blog/rovoblast
• Atlassian Community (โพสต์สมาชิกชุมชน), "Two prompt injection paths into Rovo: one fixed (RovoBlast), one open": https://community.atlassian.com/forums/discussion/3282296/two-prompt-injection-paths-into-rovo-one-fixed-rovoblast-one-open
• GitHub issue anthropics/claude-code #106205 (รายงานของผู้ใช้): https://github.com/anthropics/claude-code/issues/106205
• The Hacker News, "Microsoft Copilot Personal Flaws Could Let One Click Exfiltrate Data…" (ส.ค. 2026): https://thehackernews.com/2026/08/microsoft-copilot-personal-flaws-could.html
• Google Cloud / GTIG, "The Rise of LLMJacking": https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models
• Simon Willison, "The lethal trifecta for AI agents" (มิ.ย. 2025): https://simonwillison.net/2025/Jun/16/the-lethal-trifecta
• GitHub Advisory GHSA-4fgq-fpq9-mr3g / CVE-2025-59536, "Command execution prior to Claude Code startup trust dialog": https://github.com/anthropics/claude-code/security/advisories/GHSA-4fgq-fpq9-mr3g
• สไลด์ต้นทาง: STH, "Vibe Coding with Security" (Pichaya Morimoto) แชร์ผ่าน Dropbox https://www.dropbox.com/scl/fi/kfc7gbo42j5b4hwstjxx8/STH_Slide_Vibe_Coding_with_Security.pdf?rlkey=cobozd5q1s8lvcc1c6cfyyoo8&st=bhrs2a27&dl=0