LLMSVS v2.0

LLMSVS (Large Language Model Security Verification Standard) เปลี่ยนคำถามจาก “ระบบนี้มีความเสี่ยงอะไร” เป็น “เราจะตรวจ control นี้ด้วยหลักฐานอะไร” ฉบับ v2.0 มี 70 requirements ใน 8 หมวด และกำหนด applicability ตาม assurance level แต่ไม่ได้รับรองว่าระบบปลอดภัยทั้งหมด ไม่แทน risk assessment หรือ Secure Software Development Lifecycle (SSDLC) และไม่ครอบคลุม application security ทั่วไปที่ควรตรวจด้วย OWASP ASVS (LLMSVS v2.0 ฉบับเต็ม)

การเลือก assurance level

Level	ใช้กับ	ข้อควรระวัง
L1 Basic	use case ความเสี่ยงต่ำ เน้น control ขั้นพื้นฐาน	ไม่ได้หมายความว่าเหมาะกับ chatbot ทุกระบบ หากมีข้อมูลอ่อนไหวหรือ side effect ควรพิจารณาระดับสูงขึ้น
L2 Moderate	ระบบที่แตะข้อมูลลูกค้า ข้อมูลภายใน API หรือ workflow ขององค์กร เอกสารระบุว่าเหมาะกับแอปพลิเคชันส่วนใหญ่	L2 ยังไม่มี requirement บังคับ sandbox agent และ human approval ซึ่งอยู่ L3
L3 High assurance	business-critical, high-value transaction, การเงิน สุขภาพ หรือระบบภายใต้ regulation	เป็น baseline ที่เข้มขึ้น แต่ยังต้องเพิ่ม control จาก threat model และข้อกำหนดของอุตสาหกรรม

เลือก level จากผลกระทบ, data classification, capability และ autonomy ไม่ใช่จากขนาดโมเดล โมเดลเล็กที่โอนเงินได้อาจต้องใช้ L3 ขณะที่โมเดลใหญ่สำหรับจัดรูปแบบข้อความสาธารณะอาจมีความเสี่ยงต่ำกว่า

แปดหมวดและสิ่งที่ต้องตรวจ

หมวด	จำนวน	คำถามหลัก	ตัวอย่างหลักฐาน
V1 Secure Configuration & Maintenance	4	secret อยู่ที่ใด, self-hosted model แยก network หรือไม่, มี inventory และ config review หรือไม่	architecture, secret inventory, firewall rule, asset register, review record
V2 Model Lifecycle	18	dataset/model มาจากไหน ถูกแก้โดยใคร ประเมินก่อน deploy และปลดระวางอย่างไร	dataset provenance, training pipeline, risk assessment, ML-BOM, decommission plan
V3 Real-time Learning	5	production ปรับ weights หรือ behavior จาก live input หรือไม่ และหยุดได้หรือไม่	learning design, approval gate, monitoring, offline switch, interaction analysis
V4 Model Memory & Storage	6	conversation, RAG, vector store และ cache แยก user และป้องกัน unauthorized write/read หรือไม่	tenant isolation test, ACL, embedding pipeline, poisoning test, retention policy
V5 Secure LLM Integration	17	prompt/output ถูกถือเป็น untrusted, validate structure และคุม cost/error/leak หรือไม่	server-side prompt flow, JSON schema test, injection test, rate limit, sanitized error
V6 Agents & Plugins	12	expose tool เท่าที่ต้องใช้, validate parameter, scope credential, sandbox และ approval หรือไม่	tool registry, IAM policy, validation tests, network policy, approval record, sandbox profile
V7 Dependency & Component	6	dependency และ model artifact มาจาก trusted source และตรวจ supply chain อย่างไร	SCA report, SBOM, digest/signature, patch SLA, private registry configuration
V8 Monitoring & Anomaly Detection	2	detect usage anomaly และ prompt leak signal ได้หรือไม่	baseline, alert rule, canary event, incident ticket, retention/access policy

จำนวน requirement ไม่ใช่ coverage score หนึ่ง requirement อาจลดหลาย threat และหนึ่ง threat อาจต้องใช้หลาย requirements ตัวอย่างเช่น prompt injection เกี่ยวข้องกับ V5.11–V5.13 แต่ผลกระทบของ agent ยังขึ้นกับ V6.1, V6.4, V6.7 และ V6.10–V6.12

Requirements สำคัญที่ควรรู้

V5: integration ต้อง validate มากกว่า “เป็น JSON”

5.5 (L1–L3): output ต้องตรงโครงสร้างและ properties ที่คาดหวัง หากเป็น JSON ต้อง validate schema และ reject field ที่ไม่อนุญาต Structured output เป็น defense-in-depth ไม่แทน validation
5.10 (L1–L3): client ต้องไม่เห็น raw provider error, stack trace, prompt หรือ credential แต่ server-side log ยังต้องพอสำหรับ operation โดยไม่บันทึก secret ดิบ
5.12 (L2–L3): prompt จากทุกแหล่งเป็น untrusted รวมข้อมูลจาก storage, third-party API และ previous completion
5.13 (L1–L3): downstream system ต้องถือ completion เป็น untrusted ห้าม concatenate เข้า SQL หรือ interpreter
5.14 และ 5.15: rate limiting บังคับตั้งแต่ L2 ส่วน cost alert อยู่ทุกระดับ ทั้งนี้ alert ไม่ใช่ hard budget stop

V6: agent controls ต่างกันตาม level

6.1 (L1–L3): agent เห็นเฉพาะ tool ของ task ปัจจุบัน และ task หนึ่งใช้ tool ของอีก task ไม่ได้
6.4 (L2–L3): validate parameter ก่อน execute อย่างน้อยต้องมี type check ระบบจริงควรเพิ่ม business-rule และ resource authorization
6.7 (L2–L3): custom tool ต้องทำงานใน scope ของ principal ปัจจุบัน
6.8 และ 6.9 (L3): แยก execution host และจำกัด arbitrary egress
6.10 (L2–L3): API token ต้องแคบเท่าที่ agent ต้องใช้ เช่น agent ที่อ่าน Slack channel หนึ่งไม่ควร post หรืออ่าน channel อื่น
6.11 และ 6.12 (L3): พิจารณา manual approval สำหรับ sensitive operation และใช้ ephemeral sandbox

ข้อ 6.11 ใช้คำว่า “consider” จึงควรบันทึกเหตุผลหากไม่ใช้ และ approval ต้องผูกกับ payload จริง มิฉะนั้นยังมีความเสี่ยงตาม ASI09

วิธีทำ assessment

กำหนด scope — ระบุ model, provider, RAG, memory, agent, tool, MCP server, environment และ user role ที่รวมและไม่รวม
เลือก level พร้อมเหตุผล — อ้าง data classification, transaction impact, autonomy และ regulatory obligation
ทำ applicability matrix — ระบุ requirement ที่ applicable, not applicable หรือ inherited พร้อมเหตุผลและ owner
กำหนด evidence ก่อนทดสอบ — ระบุ config, code, diagram, screenshot, log และ negative test ที่ใช้ตัดสิน
ทดสอบทั้ง design และ runtime — เอกสารอย่างเดียวไม่พิสูจน์ว่า authorization หรือ isolation ถูกบังคับใช้จริง
บันทึกผลแบบทำซ้ำได้ — pass/fail/NA, วันที่, environment, tester, evidence reference และขั้นตอน reproduce
ผูก finding กับ risk — severity มาจาก exploitability และ business impact ไม่ใช่หมายเลข requirement
แก้ไขและทดสอบซ้ำ — เก็บหลักฐานก่อนและหลัง พร้อม version หรือ build ของระบบที่ตรวจ

OWASP แนะนำ open-book review ที่ผู้ประเมินเข้าถึงสถาปนิก นักพัฒนา เอกสาร source code และ authenticated interface ตาม role ได้ และระบุว่า automated-tool result เพียงอย่างเดียวไม่เพียงพอ

ตัวอย่าง verification record

Field	ตัวอย่าง
Requirement	`LLMSVS v2.0-6.10`
Scope	support-agent production, `read_ticket` tool
Expected	token อ่านได้เฉพาะ tenant และ ticket ที่ user มีสิทธิ์; เขียนหรืออ่าน tenant อื่นไม่ได้
Evidence	IAM policy commit, decoded token claims, authorization logs
Test	user A อ่าน ticket A สำเร็จ; อ่าน ticket B ได้ 403; เรียก write endpoint ได้ 403
Result	Pass / Fail / N/A พร้อมเหตุผล
Owner และ retest	Platform IAM, วันที่ และ build SHA

ควรอ้าง requirement พร้อมเวอร์ชัน เช่น LLMSVS v2.0-6.10 เพราะข้อความและหมายเลขอาจเปลี่ยนในอนาคต

ชุดหลักฐานขั้นต่ำตาม architecture

Hosted-model chatbot

data-flow และ provider data-retention setting
secret handling และ server-side prompt construction
output schema และ encoding tests
rate limit, hard quota หรือ operational response ต่อ cost alert
prompt injection และ sensitive-data leakage tests

RAG application

document provenance และผู้มีสิทธิ์ ingest
authorization ก่อน retrieval ไม่ใช่กรองหลัง document chunk ถูกส่งให้โมเดล
tenant isolation ของ vector store, cache และ backup
poisoning test และขั้นตอน remove/reindex
log ที่บอก document IDs โดยไม่คัดลอกข้อมูลลับเกินจำเป็น

Agent หรือ MCP system

tool inventory และ task-scoped exposure
per-user และ per-resource authorization
parameter validation และ side-effect classification
network, egress และ sandbox policy
approval payload และ audit correlation
step, recursion, time, cost และ fan-out limits
kill, revoke และ rollback exercise

สิ่งที่ LLMSVS ไม่ได้ครอบคลุมทั้งหมด

Application security: authentication, session, access control, SSRF, SQL injection และ secret management ทั่วไปต้องใช้ ASVS หรือมาตรฐานที่เกี่ยวข้อง
Agentic threat coverage: LLMSVS มี control สำคัญใน V6 แต่ไม่ได้แจกแจง ASI07–ASI10 เป็น test procedure ต้องเพิ่มตาม architecture
Business correctness: schema ถูกไม่ได้แปลว่าจำนวนเงิน ผู้รับ หรือ state transition ถูก ต้องมี domain invariant
Operational resilience: V8 มีเพียงสอง requirements จึงควรเพิ่ม incident response, immutable audit, SLO, rollback และ containment ตามผลกระทบ
Certification: OWASP ไม่รับรอง vendor, verifier, software หรือ trust mark ที่อ้าง LLMSVS certification

แนวทางการใช้งาน

ใช้ LLM, Agentic และ MCP Top 10 สร้าง threat model ก่อน ใช้ LLMSVS เป็น requirement baseline แล้วเพิ่ม test case ที่ผูกกับ data flow, capability และผลกระทบของระบบจริง วิธีนี้ช่วยป้องกันการประเมินแบบติ๊ก checklist โดยไม่ลดความเสี่ยง