# Lagune

> Security-Driven Hardening สำหรับทุกโค้ดเบส

Lagune คือเวิร์กโฟลว์ Security-Driven Hardening (SDH) แบบโอเพนซอร์สที่มีไว้เพื่อการป้องกันเท่านั้น ช่วยให้เอเจนต์ AI ของคุณเสริมความปลอดภัยให้โค้ดเบสใดก็ได้ ในภาษาใดก็ได้ และในทุกช่วงของงาน: charter กำหนดกฎด้านความปลอดภัยก่อนที่คุณจะเริ่มสร้าง คำสั่ง universal /lagune เสริมความปลอดภัยให้งานขณะที่เขียน และขั้นตอนแบบ Blue Team 5 เฟสตรวจจับว่าระบบของคุณทำอะไรจริง ๆ แล้วนำไปสู่การแก้ไขที่สำคัญสำหรับบริบทนั้น คุณติดตั้งคำสั่งของ Lagune ลงในเอเจนต์ได้ด้วย skills CLI และไม่ต้องใช้คีย์ API

---

# ติดตั้ง: security hardening สำหรับเอเจนต์ AI ทุกตัว

> ติดตั้ง Lagune ในโปรเจกต์ใดก็ได้ เป็นปลั๊กอินเมื่อเอเจนต์ของคุณรองรับ หรือผ่าน skills CLI สำหรับเอเจนต์อื่น จากนั้นเลือกความรู้เฉพาะทางด้านความปลอดภัยที่เหมาะกับโปรเจกต์

Canonical: https://lagune.ai/th-TH/docs
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs
อัปเดตล่าสุด: 2026-11-07

**Lagune** ช่วยให้เอเจนต์ AI ของคุณทำให้โปรเจกต์ปลอดภัยขึ้น คุณเพียงชี้ไปที่โค้ด แล้วเอเจนต์จะค้นหาว่าระบบของคุณทำอะไรจริง ๆ จากนั้นพาคุณทำงานด้านความปลอดภัยที่สำคัญกับระบบนั้น **Lagune** เป็นโปรเจกต์แรกของระเบียบวิธี [Security-Driven Hardening (SDH)](https://lagune.ai/th-TH/docs/references/paper)

**สนับสนุนโอเพนซอร์ส**

ชอบ **Lagune** ไหม [ให้ ⭐ เราบน **GitHub**](https://github.com/wellwelwel/lagune)

## เลือกเอเจนต์ของคุณ

- [Claude Code](https://lagune.ai/th-TH/docs/install/claude-code): เครื่องมือเขียนโค้ดแบบ agentic จาก Anthropic
- [Codex](https://lagune.ai/th-TH/docs/install/codex): เอเจนต์เขียนโค้ดจาก OpenAI
- [Cursor](https://lagune.ai/th-TH/docs/install/cursor): โค้ดเอดิเตอร์ที่ขับเคลื่อนด้วย AI
- [GitHub Copilot](https://lagune.ai/th-TH/docs/install/github-copilot-cli): AI pair programmer จาก GitHub
- [Gemini CLI](https://lagune.ai/th-TH/docs/install/gemini-cli): เอเจนต์บนเทอร์มินัลแบบโอเพนซอร์สจาก Google
- [Antigravity](https://lagune.ai/th-TH/docs/install/antigravity-cli): แพลตฟอร์มพัฒนาแบบ agentic จาก Google
- [OpenCode](https://lagune.ai/th-TH/docs/install/opencode): เอเจนต์เขียนโค้ดแบบโอเพนซอร์ส
- [Devin for Terminal](https://lagune.ai/th-TH/docs/install/devin-cli): เอเจนต์บนเทอร์มินัลจาก Cognition
- [Factory Droid](https://lagune.ai/th-TH/docs/install/factory-droid): เอเจนต์พัฒนาซอฟต์แวร์จาก Factory
- [Grok Build](https://lagune.ai/th-TH/docs/install/grok-build): เอเจนต์เขียนโค้ดจาก xAI
- [Qwen Code](https://lagune.ai/th-TH/docs/install/qwen-code): เอเจนต์เขียนโค้ดบนเทอร์มินัลจาก Qwen
- [Kimi Code](https://lagune.ai/th-TH/docs/install/kimi-code): เอเจนต์เขียนโค้ดจาก Moonshot AI
- [Muse Code](https://lagune.ai/th-TH/docs/install/muse-code): เอเจนต์เขียนโค้ดจาก Meta
- [Pi](https://lagune.ai/th-TH/docs/install/pi): เอเจนต์เขียนโค้ดบนเทอร์มินัลแบบมินิมอล
- [Hermes Agent](https://lagune.ai/th-TH/docs/install/hermes-agent): เอเจนต์โอเพนซอร์สจาก Nous Research
- [Universal](https://lagune.ai/th-TH/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed และอีก 66 ตัว

**ข้อมูล**

- เบื้องหลัง **Lagune** ทำงานบน **Node.js** แต่คุณใช้ภาษาใดก็ได้ตามต้องการ
- หากต้องการรันแบบออฟไลน์ทั้งหมด ให้ติดตั้ง **Lagune** ในโปรเจกต์ด้วย `npm i -D lagune@0.18.1`

## หมวดหมู่

ความรู้ด้านความปลอดภัยของ **Lagune** มาในรูปแบบ [**ความรู้เฉพาะทาง**](https://lagune.ai/th-TH/docs/catalog) ที่จัดกลุ่มเป็น [**หมวดหมู่**](https://lagune.ai/th-TH/docs/categories)

- **OWASP** (`owasp`): เสริมความปลอดภัยให้แอปพลิเคชันรับมือกับความเสี่ยงที่ OWASP ติดตาม: injection การควบคุมการเข้าถึงที่บกพร่อง (Broken Access Control) และความล้มเหลวด้านการยืนยันตัวตนและการเข้ารหัส
- **โครงสร้างพื้นฐาน** (`infra`): เสริมความปลอดภัยให้การตั้งค่า container, workload และ serverless: Dockerfile และ Compose ความปลอดภัยของ Pod รวมถึง IAM และ trigger ของ FaaS
- **AI / LLM** (`ai`): เสริมความปลอดภัยให้ระบบที่ผสานรวม AI และ LLM รับมือกับ prompt injection และการเชื่อมต่อ tool เอเจนต์ retrieval และ MCP ที่ไม่ปลอดภัย
- **Lovable** (`lovable`): เสริมความปลอดภัยให้แอป Supabase ที่สร้างด้วย AI (Lovable และเครื่องมือที่คล้ายกัน): ช่องโหว่ใน RLS คีย์ service_role ที่รั่วไหล และค่าเริ่มต้นที่ไม่ปลอดภัย
- **JavaScript** (`javascript`): เสริมความปลอดภัยให้ JavaScript และรันไทม์ของภาษานี้รับมือกับ RCE ผ่าน eval และ child_process ปัญหา path traversal และ prototype pollution
- **Python** (`python`): เสริมความปลอดภัยให้ Python รับมือกับ RCE จากการ deserialize ด้วย pickle และ YAML ปัญหา traversal ผ่านสตริงของ str.format และ class pollution
- **Rust** (`rust`): เสริมความปลอดภัยให้ Rust รับมือกับ API แบบ unsafe ที่ไม่ sound การใช้ transmute ผิดวิธี ปัญหา integer overflow และ undefined behavior ที่ขอบเขต FFI
- **Java** (`java`): เสริมความปลอดภัยให้ Java รับมือกับ gadget chain จากการ deserialize ด้วย ObjectInputStream ที่นำไปสู่การรันโค้ดจากระยะไกล
- **Ruby** (`ruby`): เสริมความปลอดภัยให้ Ruby รับมือกับ gadget chain จากการ deserialize ด้วย Marshal.load และ YAML ที่นำไปสู่การรันโค้ดจากระยะไกล
- **PHP** (`php`): เสริมความปลอดภัยให้ PHP รับมือกับการเลี่ยงการยืนยันตัวตนด้วย type juggling ปัญหา gadget chain จาก object injection และค่าเริ่มต้นของการตั้งค่าที่ไม่ปลอดภัย
- **Go** (`go`): เสริมความปลอดภัยให้ Go รับมือกับบั๊ก interface แบบ typed-nil ปัญหา data races ระหว่าง goroutine และ concurrency ที่ไม่ปลอดภัยในโค้ดส่วนที่เกี่ยวกับความปลอดภัย
- **C / C++** (`c-cpp`): เสริมความปลอดภัยให้ C และ C++ รับมือกับบั๊ก format string ปัญหา buffer overflow และการเขียนข้อมูลเกินขอบเขตที่เปิดทางให้รันโค้ดได้
- **.NET** (`dotnet`): เสริมความปลอดภัยให้ .NET และ C# รับมือกับ RCE จากการ deserialize ด้วย BinaryFormatter และการเลี่ยง encoder ที่นำไปสู่ XSS

รัน `npx lagune write add --categories` พร้อมคีย์ของหมวดหมู่ที่คุณเลือก

**เคล็ดลับ**

ทุกโปรเจกต์เริ่มต้นด้วย `owasp` แล้วคำสั่ง [`/lagune-charter`](https://lagune.ai/th-TH/docs/commands/charter) จะเพิ่มหมวดหมู่ที่ผลการอ่านโปรเจกต์รองรับ

## สิ่งที่ต้องมี

ระบบของคุณต้องติดตั้ง [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) ไว้แล้ว

## ใช้ badge ✨

ใช้ **Lagune** อยู่ใช่ไหม เพิ่ม badge สักอันลงใน **README** ของคุณ:

**สองโทนสี**

![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)

```md
[![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)](https://lagune.ai)
```

![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)

```md
[![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)](https://lagune.ai)
```

![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)

```md
[![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)](https://lagune.ai)
```

**สีเดียว**

![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

## ถัดไป

ดูว่า [**skill**](https://lagune.ai/th-TH/docs/get-started/commands) แต่ละตัวของ **Lagune** ทำอะไรได้บ้าง

## คำถามที่พบบ่อย

### Lagune คืออะไร

Lagune คือเวิร์กโฟลว์ด้านความปลอดภัยแบบโอเพนซอร์สที่ใช้เพื่อการป้องกันเท่านั้น ช่วยให้เอเจนต์ AI ของคุณเสริมความปลอดภัยให้โค้ดเบสใดก็ได้ คุณชี้ไปที่โค้ด Lagune จะตรวจจับว่าระบบของคุณทำอะไรจริง ๆ แล้วนำทางการแก้ไขด้านความปลอดภัยที่สำคัญกับบริบทนั้น

### ติดตั้ง Lagune อย่างไร

เลือกเอเจนต์ของคุณ: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI และ Hermes Agent ติดตั้ง Lagune เป็นปลั๊กอิน Gemini CLI และ Qwen Code ติดตั้งเป็นส่วนขยาย Pi ติดตั้งเป็นแพ็กเกจ ส่วนเอเจนต์อื่นติดตั้งด้วย npx skills add wellwelwel/lagune โดย Lagune ใช้ได้ทั้งกับโปรเจกต์ใหม่และโปรเจกต์เดิม

### Lagune ต้องใช้คีย์ API ไหม

ไม่ต้อง Lagune ทำงานผ่านเอเจนต์ AI ของคุณเอง จึงไม่ต้องใช้คีย์ API

### ต้องมีอะไรบ้าง

ระบบของคุณต้องติดตั้ง Node.js (LTS) ไว้แล้ว

### Lagune รองรับภาษาโปรแกรมอะไรบ้าง

ทุกภาษา เบื้องหลัง Lagune ทำงานบน Node.js แต่ตรวจสอบและเสริมความปลอดภัยให้โปรเจกต์ที่เขียนด้วยภาษาโปรแกรมใดก็ได้

### Lagune เพิ่มอะไรลงในโปรเจกต์ของฉัน

ไดเรกทอรี .lagune/ ที่เก็บสถานะความปลอดภัยของโปรเจกต์ ซึ่งคำสั่งแรกที่เขียนข้อมูลจะสร้างขึ้น นอกจากนี้ skills CLI ยังติดตั้งคำสั่ง slash ไว้ในโปรเจกต์ให้เอเจนต์อ่าน ส่วนปลั๊กอินจะเก็บคำสั่งเหล่านั้นไว้ภายในเอเจนต์

### อัปเดต Lagune อย่างไร

ทำแบบเดียวกับตอนติดตั้ง หน้าการติดตั้งของแต่ละเอเจนต์บอกวิธีอัปเดต Lagune ในเอเจนต์นั้น ส่วน skills CLI อัปเดตด้วย npx skills update โดย charter อาร์ติแฟกต์ของแต่ละเฟส และความรู้เฉพาะทางของคุณเองจะไม่ถูกแตะต้อง

### โปรเจกต์หนึ่งใช้ความรู้เฉพาะทางอะไรบ้าง

ความรู้เฉพาะทางในตัวของหมวดหมู่ที่โปรเจกต์บันทึกไว้ รวมกับความรู้เฉพาะทางของโปรเจกต์เอง charter บันทึกหมวดหมู่ที่ผลการอ่านโปรเจกต์รองรับ และคุณเปลี่ยนหมวดหมู่ได้ด้วย npx lagune write add --categories

### ต้องสร้างโปรเจกต์ให้เสร็จก่อนจึงจะเสริมความปลอดภัยได้ไหม

ไม่ต้อง คำสั่ง /lagune เสริมความปลอดภัยให้งานไปพร้อมกับที่เขียน โดยรับ prompt ใดก็ได้ สร้างสิ่งที่คุณขอ และเสริมความปลอดภัยด้วยค่าเริ่มต้นที่ปลอดภัยตามแนวทางของ charter ส่วนขั้นตอนแบบ Blue Team ทั้ง 5 เฟสใช้ตรวจสอบสิ่งที่มีอยู่แล้ว

### Lagune ตรวจสอบโปรเจกต์ที่มีอยู่แล้วได้ไหม

ได้ ขั้นตอนแบบ Blue Team ทั้ง 5 เฟสตรวจสอบสิ่งที่มีอยู่แล้ว: charter กำหนดกฎความปลอดภัยของคุณ detect ทำแผนผังว่าระบบทำอะไรและความเสี่ยงอยู่ตรงไหน plan ให้คะแนนข้อตรวจพบแต่ละข้อและจับคู่กับการแก้ไข harden นำการแก้ไขไปใช้ และ verify พิสูจน์ว่าการแก้ไขใช้ได้จริงแล้วปิดให้จบ

### การใช้ Lagune ต่างจากการสั่งให้เอเจนต์หาช่องโหว่และจุดบกพร่องด้านความปลอดภัยเองอย่างไร

เอเจนต์ที่อ่านโค้ดเองจะเจอสิ่งที่ดูเหมือนช่องโหว่ และข้ามสิ่งที่ดูเหมือนมาตรการควบคุม รายการที่อยู่ที่ถูกบล็อกดูเหมือนมีคนจัดการความเสี่ยงไว้แล้ว จึงไม่มีใครตรวจว่ารายการนั้นพลาดที่อยู่ส่วนใหญ่ไป แล้วโค้ดก็ถูกปล่อยออกไป Lagune กลับค่าเริ่มต้นนั้น: กลไกป้องกันที่มีอยู่ในโค้ดถือว่ายังไม่ได้พิสูจน์จนกว่าจะได้ตรวจสอบ ความรู้เฉพาะทางทุกตัวในแคตตาล็อกได้รับผลตัดสินที่ชัดเจน และ verify ถามว่าความเสี่ยงหมดไปแล้วหรือยัง ไม่ใช่ถามว่ามีมาตรการควบคุมอยู่หรือไม่ ข้อตรวจพบแต่ละข้อยังคงเป็นรายการที่ติดตามรายการเดียวตลอดทุกการรัน จึงพิสูจน์ได้ว่าปิดแล้วและปิดออกจากห่วงโซ่ได้ ขณะที่คำขอธรรมดาให้รายงานที่ต่างกันทุกครั้งโดยไม่มีอะไรให้เทียบ

### การพัฒนาด้วย Lagune ต่างจากการสั่งให้เอเจนต์เขียนโค้ดที่ปลอดภัยอย่างไร

การขอโค้ดที่ปลอดภัยเป็นการปล่อยให้เอเจนต์นิยามคำว่าปลอดภัยเอง และถือว่าคุณรู้ว่าต้องขออะไร ข้อกำหนดมักแฝงอยู่ในคำขอของคุณแล้วโดยที่ทั้งคุณและเอเจนต์ไม่ทันเห็น: การขอหน้าที่แสดงคอร์สที่ผู้ใช้มีสิทธิ์เข้าถึงคือการระบุกฎการตรวจสอบสิทธิ์ และการตรวจที่ไม่เคยถูกเขียนก็ไม่ทิ้งอะไรไว้ในโค้ดให้สังเกตเห็น คำสั่ง /lagune โหลด charter ของคุณและความรู้เฉพาะทางที่ตรงกับสิ่งที่กำลังจะสร้างก่อนเขียนโค้ดบรรทัดแรก แล้วอ่านผลลัพธ์ซ้ำเทียบกับการป้องกันที่ใช้ รูปแบบที่ปลอดภัยแทบไม่เคยมีต้นทุนสูงกว่ารูปแบบที่ไม่ปลอดภัย สิ่งที่ตัดสินผลลัพธ์จึงอยู่ที่การรู้ว่าควรเลือกแบบไหน และนั่นคือสิ่งที่มาถึงตั้งแต่ต้น

### Lagune รัน DAST (Dynamic Application Security Testing) หรือทดสอบแอปพลิเคชันที่กำลังทำงานอยู่ได้ไหม

ไม่ได้ Lagune อ่านโค้ดและไม่เคยรันระบบของคุณหรือส่ง request ที่จงใจสร้างขึ้นไปยังระบบ ส่วนเฟส verify ยืนยันว่ามาตรการควบคุมมีอยู่และถูกต้องในซอร์สโค้ด ซึ่งเป็นคนละคำถามกับว่ามาตรการนั้นทนการโจมตีบนระบบที่กำลังทำงานได้หรือไม่ ดังนั้น "cannot tell from the code" จึงเป็นผลตัดสินที่ชอบธรรม ไม่ใช่การปล่อยผ่านอย่างเงียบ ๆ DAST ตอบคำถามขณะรันไทม์ ส่วน Lagune ตอบคำถามในซอร์สโค้ด จึงไม่มีฝ่ายใดแทนอีกฝ่ายได้ แม้แต่คำสั่ง prove ที่เป็นตัวเลือกเสริมก็ยึดเส้นนี้: การทดสอบของคำสั่งนี้ยืนยันพฤติกรรมที่ปลอดภัย และไม่เคยใช้ payload โจมตี

### Lagune ใช้แทน Pentest (penetration test) ได้ไหม

ไม่ได้อย่างแน่นอน! Pentest คือการทดสอบที่ได้รับอนุญาต ซึ่งผู้เชี่ยวชาญใช้วิจารณญาณของตนกับระบบที่กำลังทำงานจริงของคุณ ร้อยเรียงข้อตรวจพบเข้าด้วยกัน และเจาะลึกตรรกะทางธุรกิจที่ไม่มีกฎรายพื้นผิวการโจมตีข้อใดอธิบายไว้ ข้อตรวจพบจาก pentest เข้าสู่ขั้นตอนแบบ Blue Team ของ Lagune ได้ในฐานะข้อกังวลที่คุณส่งให้ detect เพื่อให้สิ่งที่ผู้เชี่ยวชาญรายงานได้รับการวางแผน เสริมความปลอดภัย และตรวจยืนยัน

## นโยบายความปลอดภัย

ดู [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md)

## สัญญาอนุญาต

**Lagune** เผยแพร่ภายใต้ [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE)

Copyright © 2026-ปัจจุบัน [Weslley Araújo](https://github.com/wellwelwel) และ [ผู้ร่วมพัฒนา](https://github.com/wellwelwel/lagune/graphs/contributors)

---

# วิธีติดตั้ง Lagune บน Antigravity CLI แบบปลั๊กอิน

> ติดตั้ง Lagune บน Antigravity CLI แบบปลั๊กอิน อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และอนุญาตเอนจินไว้ล่วงหน้า

Canonical: https://lagune.ai/th-TH/docs/install/antigravity-cli
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/antigravity-cli
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้ติดตั้งอีกครั้ง:

```bash
agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity
```

## คำสั่ง

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น `/lagune:lagune-charter` สำหรับ `/lagune-charter`

---

**สิทธิ์**

เอนจินทำงานผ่าน tool 2 ตัว: `lagune_read` อ่านโปรเจกต์ของคุณเท่านั้น และ `lagune_write` เขียนลงใน `.lagune/` เท่านั้น คำสั่งที่ส่งเป็นข้อความแรกของเซสชันจะรันก่อนที่ tool ทั้งสองจะโหลด จึงใช้ **npx** แทน หากต้องการอนุญาต tool ทั้งสองและ **npx** ไว้ล่วงหน้า ให้เพิ่มกฎเหล่านี้ลงใน `~/.gemini/antigravity-cli/settings.json`:

```json
{
  "permissions": {
    "allow": [
      "mcp(lagune_lagune/lagune_read)",
      "mcp(lagune_lagune/lagune_write)",
      "command(regex:npx --yes lagune@[0-9.]+)"
    ]
  }
}
```

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Antigravity CLI ได้อย่างไร

รัน agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity

### อัปเดต Lagune บน Antigravity CLI ได้อย่างไร

รัน agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity อีกครั้ง

### รันคำสั่งของ Lagune บน Antigravity CLI ได้อย่างไร

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น /lagune:lagune-charter

### Antigravity CLI รัน Lagune โดยไม่ต้องขออนุญาตได้ไหม

ได้ อนุญาต mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) และ command(regex:npx --yes lagune@[0-9.]+) ในการตั้งค่าของ Antigravity CLI กฎ npx ครอบคลุมคำสั่งที่ส่งเป็นข้อความแรกของเซสชัน

---

# วิธีติดตั้ง Lagune บน Claude Code แบบปลั๊กอิน

> ติดตั้ง Lagune บน Claude Code แบบปลั๊กอิน ทั้งในเทอร์มินัล ส่วนขยาย และแอปเดสก์ท็อป อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และอนุญาตเอนจินไว้ล่วงหน้า

Canonical: https://lagune.ai/th-TH/docs/install/claude-code
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/claude-code
อัปเดตล่าสุด: 2026-11-07

**เทอร์มินัล**

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
claude plugin install lagune --marketplace wellwelwel/lagune
```

หรือติดตั้งจากเซสชัน **Claude Code**:

```text
/plugin marketplace add wellwelwel/lagune
/plugin install lagune@lagune
```

**ส่วนขยาย**

- พิมพ์ `/plugin` แล้วเลือก **Manage plugins**
- เพิ่ม `wellwelwel/lagune` ในแท็บ **Marketplaces**
- ติดตั้ง `lagune` ในแท็บ **Plugins**

**เดสก์ท็อป**

- ติดตั้ง **Lagune** จากเทอร์มินัลหรือส่วนขยาย โดยเลือก **Install for you** เมื่อติดตั้งในส่วนขยาย
- เริ่มเซสชันใหม่ในแอปเดสก์ท็อป แอปจะโหลดปลั๊กอินที่คุณติดตั้งไว้สำหรับตัวคุณเอง

## การอัปเดต

**เทอร์มินัล**

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
claude plugin marketplace update lagune
claude plugin update lagune@lagune
```

หากต้องการให้อัปเดตเป็นเวอร์ชันล่าสุดเสมอ ให้เลือก **Enable auto-update** สำหรับ marketplace `lagune` ใน `/plugin`

**ส่วนขยาย**

- พิมพ์ `/plugin` แล้วเลือก **Manage plugins**
- เปิดแท็บ **Marketplaces**
- เลือกไอคอนรีเฟรชที่ `lagune`

**เดสก์ท็อป**

- อัปเดต **Lagune** จากเทอร์มินัลหรือส่วนขยาย
- เริ่มเซสชันใหม่ในแอปเดสก์ท็อป

## คำสั่ง

พิมพ์คำสั่งตามชื่อ เช่น `/lagune-charter` หรือพิมพ์โดยมีชื่อปลั๊กอินนำหน้า เช่น `/lagune:lagune-charter`

---

**สิทธิ์**

เอนจินทำงานผ่าน tool 2 ตัว: `lagune_read` อ่านโปรเจกต์ของคุณเท่านั้น และ `lagune_write` เขียนลงใน `.lagune/` เท่านั้น หากต้องการอนุญาตไว้ล่วงหน้า ให้เพิ่มกฎเหล่านี้ลงใน `.claude/settings.json` สำหรับโปรเจกต์เดียว หรือใน `~/.claude/settings.json` สำหรับทุกโปรเจกต์:

```json
{
  "permissions": {
    "allow": [
      "mcp__plugin_lagune_lagune__lagune_read",
      "mcp__plugin_lagune_lagune__lagune_write"
    ]
  }
}
```

เมื่อเอนจินทำงานผ่าน **npx** เช่นเมื่อติดตั้งด้วย **skills.sh** ให้อนุญาต `Bash(npx --yes lagune@*)` หากเปิด sandbox ไว้ ให้เพิ่ม `registry.npmjs.org` ลงใน `sandbox.network.allowedDomains` ด้วย

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Claude Code ได้อย่างไร

รัน claude plugin install lagune --marketplace wellwelwel/lagune หากใช้เซสชันหรือส่วนขยาย ให้เพิ่ม marketplace wellwelwel/lagune จากตัวจัดการปลั๊กอินแล้วติดตั้ง lagune แอปเดสก์ท็อปจะโหลดปลั๊กอินเมื่อคุณติดตั้งไว้สำหรับตัวคุณเองในเทอร์มินัลหรือส่วนขยาย

### อัปเดต Lagune บน Claude Code ได้อย่างไร

รัน claude plugin marketplace update lagune แล้วรัน claude plugin update lagune@lagune หรือเลือก Enable auto-update สำหรับ marketplace lagune ใน /plugin หากใช้ส่วนขยาย ให้เปิด Manage plugins จาก /plugin แล้วเลือกไอคอนรีเฟรชที่ marketplace lagune แอปเดสก์ท็อปจะโหลดเวอร์ชันที่อัปเดตในเซสชันถัดไป

### รันคำสั่งของ Lagune บน Claude Code ได้อย่างไร

พิมพ์คำสั่งตามชื่อ เช่น /lagune-charter หรือพิมพ์โดยมีชื่อปลั๊กอินนำหน้า เช่น /lagune:lagune-charter

### Claude Code รัน Lagune โดยไม่ต้องขออนุญาตได้ไหม

ได้ อนุญาต mcp__plugin_lagune_lagune__lagune_read และ mcp__plugin_lagune_lagune__lagune_write ในการตั้งค่าของ Claude Code รวมถึง Bash(npx --yes lagune@*) เมื่อเอนจินทำงานผ่าน npx

---

# วิธีติดตั้ง Lagune บน Codex CLI แบบปลั๊กอิน

> ติดตั้ง Lagune บน Codex CLI แบบปลั๊กอิน อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และรันเอนจินภายใน sandbox

Canonical: https://lagune.ai/th-TH/docs/install/codex
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/codex
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
codex plugin marketplace add wellwelwel/lagune
codex plugin add lagune@lagune
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
codex plugin marketplace upgrade lagune
```

## คำสั่ง

พิมพ์ `$` ตามด้วยคำสั่งที่มีชื่อปลั๊กอินนำหน้า แล้วต่อด้วยอินพุตของคุณ เช่น `$lagune:lagune-charter` สำหรับ `/lagune-charter` เมื่อพิมพ์ `$` รายการคำสั่งจะปรากฏขึ้น และเมื่อคุณเลือกคำสั่งใด ระบบจะแทรกชื่อเต็มของคำสั่งนั้นให้

---

**Sandbox**

Sandbox ของ **Codex** เข้าถึงเครือข่ายไม่ได้ ให้ติดตั้งเอนจินในโปรเจกต์จากเทอร์มินัลของคุณเอง ครั้งแรกหนึ่งครั้งและทุกครั้งหลังอัปเดต:

```bash
npm i -D lagune@0.18.1
```

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Codex CLI ได้อย่างไร

รัน codex plugin marketplace add wellwelwel/lagune แล้วรัน codex plugin add lagune@lagune

### อัปเดต Lagune บน Codex CLI ได้อย่างไร

รัน codex plugin marketplace upgrade lagune

### รันคำสั่งของ Lagune บน Codex CLI ได้อย่างไร

พิมพ์ $ ตามด้วยคำสั่งที่มีชื่อปลั๊กอินนำหน้า แล้วต่อด้วยอินพุตของคุณ เช่น $lagune:lagune-charter

### Lagune ทำงานใน sandbox ของ Codex ได้ไหม

ได้ เมื่อคุณติดตั้งเอนจินในโปรเจกต์ด้วย npm i -D lagune@0.18.1 จากเทอร์มินัลของคุณเอง ครั้งแรกหนึ่งครั้งและทุกครั้งหลังอัปเดต

---

# วิธีติดตั้ง Lagune บน Cursor แบบปลั๊กอิน

> ติดตั้ง Lagune บน Cursor และ Cursor CLI แบบปลั๊กอิน อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และอนุญาตเอนจินไว้ล่วงหน้า

Canonical: https://lagune.ai/th-TH/docs/install/cursor
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/cursor
อัปเดตล่าสุด: 2026-11-07

**Cursor**

- เปิด **Customize**
- เลือก **From GitHub Repository** แล้วป้อน `https://github.com/wellwelwel/lagune`
- เลือก **Install** ที่ **Lagune** แล้วเลือกขอบเขตระดับโปรเจกต์หรือระดับผู้ใช้

**Cursor CLI**

- เพิ่ม marketplace จากเทอร์มินัลของคุณ:

  ```bash
  agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor
  ```

- พิมพ์ `/plugins` ในเซสชัน `agent`
- ติดตั้ง **Lagune**

หากติดตั้ง **Lagune** ไว้ใน **Claude Code** อยู่แล้ว **Cursor CLI** จะโหลดจากที่นั่น

## การอัปเดต

**Cursor**

- เปิด **Customize**
- เลือก **Refresh** ที่ marketplace `lagune`

**Cursor CLI**

- แทนที่ marketplace จากเทอร์มินัลของคุณ:

  ```bash
  agent plugin marketplace remove lagune
  agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor
  ```

- พิมพ์ `/plugins` ในเซสชัน `agent`
- ติดตั้ง **Lagune** อีกครั้ง

## คำสั่ง

พิมพ์คำสั่งตามชื่อ เช่น `/lagune-charter`

---

**สิทธิ์**

ใน **Cursor** คำสั่งต่าง ๆ จะรันเอนจินผ่าน **npx** ซึ่งโหมด Auto-review ที่เป็นค่าเริ่มต้นอนุญาตโดยไม่ถาม

ใน **Cursor CLI** เอนจินทำงานผ่าน tool 2 ตัว: `lagune_read` อ่านโปรเจกต์ของคุณเท่านั้น และ `lagune_write` เขียนลงใน `.lagune/` เท่านั้น หากต้องการอนุญาตไว้ล่วงหน้า ให้เพิ่มกฎเหล่านี้ลงใน `.cursor/cli.json` สำหรับโปรเจกต์เดียว หรือใน `~/.cursor/cli-config.json` สำหรับทุกโปรเจกต์:

```json
{
  "permissions": {
    "allow": [
      "Mcp(plugin-lagune-lagune:lagune_read)",
      "Mcp(plugin-lagune-lagune:lagune_write)"
    ]
  }
}
```

เมื่อเอนจินทำงานผ่าน **npx** เช่นเมื่อติดตั้งด้วย **skills.sh** ให้อนุญาต `Shell(npx:--yes lagune@*)`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Cursor ได้อย่างไร

ใน Cursor ให้เปิด Customize เลือก From GitHub Repository ป้อน https://github.com/wellwelwel/lagune แล้วติดตั้ง Lagune ส่วนใน Cursor CLI ให้รัน agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor แล้วติดตั้ง Lagune จาก /plugins

### อัปเดต Lagune บน Cursor ได้อย่างไร

ใน Cursor ให้เลือก Refresh ที่ marketplace lagune ใน Customize ส่วนใน Cursor CLI ให้ลบ marketplace lagune แล้วเพิ่มกลับเข้าไปใหม่ จากนั้นติดตั้ง Lagune อีกครั้งจาก /plugins

### รันคำสั่งของ Lagune บน Cursor ได้อย่างไร

พิมพ์คำสั่งตามชื่อ เช่น /lagune-charter

### Cursor รัน Lagune โดยไม่ต้องขออนุญาตได้ไหม

ได้ โหมด Auto-review ที่เป็นค่าเริ่มต้นของ Cursor อนุญาตไว้อยู่แล้ว ส่วนใน Cursor CLI ให้อนุญาต Mcp(plugin-lagune-lagune:lagune_read) และ Mcp(plugin-lagune-lagune:lagune_write) รวมถึง Shell(npx:--yes lagune@*) เมื่อเอนจินทำงานผ่าน npx

---

# วิธีติดตั้ง Lagune บน Devin CLI แบบปลั๊กอิน

> ติดตั้ง Lagune บน Devin CLI แบบปลั๊กอิน และอัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ

Canonical: https://lagune.ai/th-TH/docs/install/devin-cli
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/devin-cli
อัปเดตล่าสุด: 2026-11-07

ลงชื่อเข้าใช้ **Devin** แล้วติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
devin auth login
devin plugins install wellwelwel/lagune
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
devin plugins update lagune
```

## คำสั่ง

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น `/lagune:lagune-charter` แทน `/lagune-charter` และเมนู `/` ก็แสดงรายการคำสั่งเหล่านี้ด้วย

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Devin CLI ได้อย่างไร

ลงชื่อเข้าใช้ด้วย devin auth login แล้วรัน devin plugins install wellwelwel/lagune

### อัปเดต Lagune บน Devin CLI ได้อย่างไร

รัน devin plugins update lagune

### รันคำสั่งของ Lagune บน Devin CLI ได้อย่างไร

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น /lagune:lagune-charter และเมนู / ก็แสดงรายการคำสั่งเหล่านี้ด้วย

---

# วิธีติดตั้ง Lagune บน Factory Droid แบบปลั๊กอิน

> ติดตั้ง Lagune บน Factory Droid แบบปลั๊กอิน อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และอนุญาต tool ของเอนจิน

Canonical: https://lagune.ai/th-TH/docs/install/factory-droid
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/factory-droid
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
droid plugin marketplace add wellwelwel/lagune
droid plugin install lagune@lagune
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
droid plugin marketplace update lagune
droid plugin update lagune@lagune
```

## คำสั่ง

พิมพ์คำสั่งตามชื่อ เช่น `/lagune-charter`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Factory Droid ได้อย่างไร

รัน droid plugin marketplace add wellwelwel/lagune แล้วรัน droid plugin install lagune@lagune

### อัปเดต Lagune บน Factory Droid ได้อย่างไร

รัน droid plugin marketplace update lagune แล้วรัน droid plugin update lagune@lagune

### รันคำสั่งของ Lagune บน Factory Droid ได้อย่างไร

พิมพ์คำสั่งตามชื่อ เช่น /lagune-charter

### Factory Droid รัน Lagune โดยไม่ต้องขออนุญาตได้ไหม

ได้ เมื่อ Factory Droid ขออนุญาต ให้เลือกอนุญาต lagune_read และ lagune_write เสมอ แต่ Factory Droid จะขออนุญาตอีกครั้งหลังซิงก์ commit ใหม่ของ marketplace lagune

---

# วิธีติดตั้ง Lagune บน Gemini CLI แบบส่วนขยาย

> ติดตั้ง Lagune บน Gemini CLI แบบส่วนขยาย อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และอนุญาตเอนจินไว้ล่วงหน้า

Canonical: https://lagune.ai/th-TH/docs/install/gemini-cli
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/gemini-cli
อัปเดตล่าสุด: 2026-11-07

ติดตั้งส่วนขยายจากเทอร์มินัลของคุณ:

```bash
gemini extensions install https://github.com/wellwelwel/lagune
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
gemini extensions update lagune
```

หากต้องการให้อัปเดตเป็นเวอร์ชันล่าสุดเสมอ ให้ติดตั้งพร้อม `--auto-update`

## คำสั่ง

พิมพ์คำสั่งโดยมีชื่อส่วนขยายนำหน้า เช่น `/lagune:lagune-charter` สำหรับ `/lagune-charter`

---

**สิทธิ์**

เอนจินทำงานผ่าน tool 2 ตัว: `lagune_read` อ่านโปรเจกต์ของคุณเท่านั้น และ `lagune_write` เขียนลงใน `.lagune/` เท่านั้น **Gemini CLI** จะเริ่ม tool ทั้งสองเฉพาะในโฟลเดอร์ที่เชื่อถือได้ หากต้องการอนุญาตไว้ล่วงหน้า ให้บันทึกกฎนี้เป็นไฟล์ `~/.gemini/policies/lagune.toml`:

```toml
[[rule]]
mcpName = "lagune"
toolName = ["lagune_read", "lagune_write"]
decision = "allow"
priority = 100
```

เมื่อเอนจินทำงานผ่าน **npx** เช่นเมื่อติดตั้งด้วย **skills.sh** ให้เพิ่มกฎนี้ลงในไฟล์เดียวกัน:

```toml
[[rule]]
toolName = "run_shell_command"
commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s'
decision = "allow"
priority = 100
```

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Gemini CLI ได้อย่างไร

รัน gemini extensions install https://github.com/wellwelwel/lagune

### อัปเดต Lagune บน Gemini CLI ได้อย่างไร

รัน gemini extensions update lagune หรือติดตั้งส่วนขยายพร้อม --auto-update

### รันคำสั่งของ Lagune บน Gemini CLI ได้อย่างไร

พิมพ์คำสั่งโดยมีชื่อส่วนขยายนำหน้า เช่น /lagune:lagune-charter

### Gemini CLI รัน Lagune โดยไม่ต้องขออนุญาตได้ไหม

ได้ เพิ่มกฎ policy ที่อนุญาต tool lagune_read และ lagune_write ของเซิร์ฟเวอร์ lagune รวมถึงกฎสำหรับ run_shell_command ที่มี npx --yes lagune@ ตามด้วยหมายเลขเวอร์ชัน เมื่อเอนจินทำงานผ่าน npx

---

# วิธีติดตั้ง Lagune บน GitHub Copilot CLI แบบปลั๊กอิน

> ติดตั้ง Lagune บน GitHub Copilot CLI แบบปลั๊กอิน และอัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ

Canonical: https://lagune.ai/th-TH/docs/install/github-copilot-cli
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/github-copilot-cli
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
copilot plugin marketplace add wellwelwel/lagune
copilot plugin install lagune@lagune
```

ใน editor ให้ติดตั้ง **Lagune** สำหรับ **GitHub Copilot** ด้วย [**skills.sh**](https://lagune.ai/th-TH/docs/install/universal)

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
copilot plugin marketplace update lagune
copilot plugin update lagune@lagune
```

## คำสั่ง

พิมพ์คำสั่งตามชื่อ เช่น `/lagune-charter`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน GitHub Copilot CLI ได้อย่างไร

รัน copilot plugin marketplace add wellwelwel/lagune แล้วรัน copilot plugin install lagune@lagune

### อัปเดต Lagune บน GitHub Copilot CLI ได้อย่างไร

รัน copilot plugin marketplace update lagune แล้วรัน copilot plugin update lagune@lagune

### รันคำสั่งของ Lagune บน GitHub Copilot CLI ได้อย่างไร

พิมพ์คำสั่งตามชื่อ เช่น /lagune-charter

### ใช้ Lagune กับ GitHub Copilot ใน VS Code ได้ไหม

ได้ ใน VS Code หรือ editor อื่น ให้ติดตั้ง Lagune ด้วย skills.sh แทนการติดตั้งแบบปลั๊กอิน

---

# วิธีติดตั้ง Lagune บน Grok Build แบบปลั๊กอิน

> ติดตั้ง Lagune บน Grok Build แบบปลั๊กอิน อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และอนุญาตเอนจินไว้ล่วงหน้า

Canonical: https://lagune.ai/th-TH/docs/install/grok-build
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/grok-build
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
grok plugin install wellwelwel/lagune@plugin-grok --trust
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
grok plugin update lagune
```

## คำสั่ง

พิมพ์คำสั่งตามชื่อ เช่น `/lagune-charter` หรือพิมพ์โดยมีชื่อปลั๊กอินนำหน้า เช่น `/lagune:lagune-charter`

---

**สิทธิ์**

เอนจินทำงานผ่าน tool 2 ตัว: `lagune_read` อ่านโปรเจกต์ของคุณเท่านั้น และ `lagune_write` เขียนลงใน `.lagune/` เท่านั้น หากต้องการอนุญาต tool ทั้งสองไว้ล่วงหน้า ให้เพิ่มกฎเหล่านี้ลงใน `~/.grok/config.toml`:

```toml
[permission]
allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"]
```

เมื่อเอนจินทำงานผ่าน **npx** เช่นเมื่อติดตั้งด้วย **skills.sh** ให้อนุญาต `Bash(npx --yes lagune@*)`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Grok Build ได้อย่างไร

รัน grok plugin install wellwelwel/lagune@plugin-grok --trust

### อัปเดต Lagune บน Grok Build ได้อย่างไร

รัน grok plugin update lagune

### รันคำสั่งของ Lagune บน Grok Build ได้อย่างไร

พิมพ์คำสั่งตามชื่อ เช่น /lagune-charter หรือพิมพ์โดยมีชื่อปลั๊กอินนำหน้า เช่น /lagune:lagune-charter

### Grok Build รัน Lagune โดยไม่ต้องขออนุญาตได้ไหม

ได้ อนุญาต MCPTool(lagune__lagune_read) และ MCPTool(lagune__lagune_write) ในการตั้งค่าของ Grok Build และอนุญาต Bash(npx --yes lagune@*) ด้วยเมื่อเอนจินทำงานผ่าน npx

---

# วิธีติดตั้ง Lagune บน Hermes Agent แบบปลั๊กอิน

> ติดตั้ง Lagune บน Hermes Agent แบบปลั๊กอิน และอัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ

Canonical: https://lagune.ai/th-TH/docs/install/hermes-agent
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/hermes-agent
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
hermes plugins install wellwelwel/lagune --enable
```

- เมื่อ **Hermes Agent** ขอให้คุณยืนยันปลั๊กอินที่มาจากนอกแคตตาล็อกของตัวเอง ให้ **ยืนยัน**
- เมื่อเอเจนต์เสนอให้ติดตั้ง dependency ของ **Node.js** ในรีโพสิทอรี ให้ **ปฏิเสธ**

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
hermes plugins update lagune
```

## คำสั่ง

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น `/lagune:lagune-charter` แทน `/lagune-charter` และ `/lagune:lagune` แทน `/lagune`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Hermes Agent ได้อย่างไร

รัน hermes plugins install wellwelwel/lagune --enable จากนั้นยืนยันปลั๊กอินเมื่อระบบถาม และปฏิเสธการติดตั้ง dependency ของ Node.js ในรีโพสิทอรี

### อัปเดต Lagune บน Hermes Agent ได้อย่างไร

รัน hermes plugins update lagune

### รันคำสั่งของ Lagune บน Hermes Agent ได้อย่างไร

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น /lagune:lagune-charter และ /lagune:lagune

---

# วิธีติดตั้ง Lagune บน Kimi Code แบบปลั๊กอิน

> ติดตั้ง Lagune บน Kimi Code แบบปลั๊กอิน และอัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ

Canonical: https://lagune.ai/th-TH/docs/install/kimi-code
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/kimi-code
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเซสชัน **Kimi Code** เลือก **Trust and install** แล้วเริ่มเซสชันใหม่เพื่อโหลดปลั๊กอิน:

```text
/plugins install https://github.com/wellwelwel/lagune
/new
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้ติดตั้งใหม่อีกครั้ง:

```text
/plugins install https://github.com/wellwelwel/lagune
/new
```

## คำสั่ง

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น `/lagune:lagune-charter` แทน `/lagune-charter` ส่วนเมนู `/` แสดงคำสั่งเป็น `/skill:lagune:lagune-charter` ซึ่งใช้ได้เช่นกัน

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Kimi Code ได้อย่างไร

ในเซสชัน Kimi Code ให้รัน /plugins install https://github.com/wellwelwel/lagune เลือก Trust and install แล้วรัน /new

### อัปเดต Lagune บน Kimi Code ได้อย่างไร

รัน /plugins install https://github.com/wellwelwel/lagune อีกครั้ง แล้วรัน /new

### รันคำสั่งของ Lagune บน Kimi Code ได้อย่างไร

พิมพ์คำสั่งโดยมีชื่อปลั๊กอินนำหน้า เช่น /lagune:lagune-charter หรือพิมพ์ตามที่เมนู / แสดง เช่น /skill:lagune:lagune-charter

---

# วิธีติดตั้ง Lagune บน Muse Code แบบปลั๊กอิน

> ติดตั้ง Lagune บน Muse Code แบบปลั๊กอิน อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และรันเอนจินภายใน sandbox

Canonical: https://lagune.ai/th-TH/docs/install/muse-code
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/muse-code
อัปเดตล่าสุด: 2026-11-07

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
muse plugins marketplace add lagune wellwelwel/lagune
muse plugins install lagune@lagune
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รีเฟรช marketplace แล้วติดตั้งปลั๊กอินใหม่:

```bash
muse plugins marketplace update lagune
muse plugins remove lagune
muse plugins install lagune@lagune
```

## คำสั่ง

พิมพ์คำสั่งตามชื่อ เช่น `/lagune-charter` หรือพิมพ์โดยมีชื่อปลั๊กอินนำหน้า เช่น `/lagune:lagune-charter`

---

**Sandbox**

sandbox ของ **Muse Code** ดาวน์โหลดเอนจินไม่ได้ ให้ติดตั้งเอนจินในโปรเจกต์จากเทอร์มินัลของคุณเองหนึ่งครั้ง และติดตั้งอีกครั้งหลังการอัปเดตทุกครั้ง:

```bash
npm i -D lagune@0.18.1
```

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Muse Code ได้อย่างไร

รัน muse plugins marketplace add lagune wellwelwel/lagune แล้วรัน muse plugins install lagune@lagune

### อัปเดต Lagune บน Muse Code ได้อย่างไร

รัน muse plugins marketplace update lagune แล้วติดตั้งใหม่ด้วย muse plugins remove lagune และ muse plugins install lagune@lagune

### รันคำสั่งของ Lagune บน Muse Code ได้อย่างไร

พิมพ์คำสั่งตามชื่อ เช่น /lagune-charter หรือพิมพ์โดยมีชื่อปลั๊กอินนำหน้า เช่น /lagune:lagune-charter

### Lagune ใช้งานใน sandbox ของ Muse Code ได้ไหม

ได้ เมื่อคุณติดตั้งเอนจินในโปรเจกต์ด้วย npm i -D lagune@0.18.1 จากเทอร์มินัลของคุณเองหนึ่งครั้ง และติดตั้งอีกครั้งหลังการอัปเดตทุกครั้ง

---

# วิธีติดตั้ง Lagune บน OpenCode แบบปลั๊กอิน

> ติดตั้ง Lagune บน OpenCode 1.x และ 2.x แบบปลั๊กอิน และอัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ

Canonical: https://lagune.ai/th-TH/docs/install/opencode
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/opencode
อัปเดตล่าสุด: 2026-11-07

**OpenCode 2.x**

ติดตั้งปลั๊กอินจากเทอร์มินัลของคุณ:

```bash
opencode plugin add lagune
```

หรือเพิ่มลงในรายการ `plugins` ของ `opencode.json`:

```json
{
  "plugins": ["lagune"]
}
```

**OpenCode 1.x**

ติดตั้งปลั๊กอินในโปรเจกต์ของคุณจากเทอร์มินัล หรือเพิ่ม `-g` เพื่อติดตั้งให้ทุกโปรเจกต์ของคุณ:

```bash
opencode plugin lagune
```

หรือเพิ่มลงในรายการ `plugin` ของ `opencode.json`:

```json
{
  "plugin": ["lagune"]
}
```

## การอัปเดต

**OpenCode 2.x**

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
opencode plugin update lagune
opencode reload
```

**OpenCode 1.x**

หากต้องการอัปเดต **Lagune** ให้ติดตั้งรีลีสใหม่ทับรีลีสเดิม โดยเพิ่ม `-g` หากคุณติดตั้งไว้ให้ทุกโปรเจกต์:

```bash
opencode plugin lagune@0.18.1 --force
```

## คำสั่ง

**OpenCode 2.x**

พิมพ์ `@` แล้วเลือกคำสั่ง เช่น `@lagune-charter` จากนั้นพิมพ์อินพุตของคุณในข้อความเดียวกัน

**OpenCode 1.x**

พิมพ์คำสั่งตามชื่อ เช่น `/lagune-charter` คำสั่งเหล่านี้แสดงอยู่ใน `/skills` ไม่ได้อยู่ในเมนู `/`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน OpenCode ได้อย่างไร

ใน OpenCode 2.x ให้รัน opencode plugin add lagune ส่วนใน OpenCode 1.x ให้รัน opencode plugin lagune โดยเพิ่ม -g เพื่อติดตั้งให้ทุกโปรเจกต์ของคุณ

### อัปเดต Lagune บน OpenCode ได้อย่างไร

ใน OpenCode 2.x ให้รัน opencode plugin update lagune แล้วรัน opencode reload ส่วนใน OpenCode 1.x ให้รัน opencode plugin lagune@0.18.1 --force

### รันคำสั่งของ Lagune บน OpenCode ได้อย่างไร

ใน OpenCode 2.x ให้พิมพ์ @ แล้วเลือกคำสั่ง เช่น @lagune-charter จากนั้นพิมพ์อินพุตของคุณในข้อความเดียวกัน ส่วนใน OpenCode 1.x ให้พิมพ์คำสั่งตามชื่อ เช่น /lagune-charter หรือหาคำสั่งได้ใน /skills

### OpenCode ขออนุญาตก่อนรัน Lagune ไหม

ไม่ขอ OpenCode รัน tool 2 ตัวของเอนจิน คือ lagune_read และ lagune_write โดยไม่ถาม

---

# วิธีติดตั้ง Lagune บน Pi แบบแพ็กเกจ

> ติดตั้ง Lagune บน Pi แบบแพ็กเกจ จาก npm หรือจาก GitHub และอัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ

Canonical: https://lagune.ai/th-TH/docs/install/pi
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/pi
อัปเดตล่าสุด: 2026-11-07

**npm**

ติดตั้งแพ็กเกจจากเทอร์มินัลของคุณ:

```bash
pi install npm:lagune
```

**GitHub**

ติดตั้ง commit ล่าสุดจาก **GitHub** ซึ่งรันเอนจินผ่าน **npx**:

```bash
pi install git:github.com/wellwelwel/lagune
```

## การอัปเดต

**npm**

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
pi update npm:lagune
```

**GitHub**

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
pi update git:github.com/wellwelwel/lagune
```

`pi update --extensions` อัปเดตทุกแพ็กเกจที่คุณติดตั้งไว้ ส่วน `pi update` เพียงอย่างเดียวจะอัปเดตแค่ **Pi**

## คำสั่ง

พิมพ์คำสั่งโดยมี `skill:` นำหน้า เช่น `/skill:lagune-charter` แทน `/lagune-charter`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Pi ได้อย่างไร

รัน pi install npm:lagune หรือรัน pi install git:github.com/wellwelwel/lagune เพื่อติดตั้ง commit ล่าสุดจาก GitHub

### อัปเดต Lagune บน Pi ได้อย่างไร

รัน pi update npm:lagune หรือรัน pi update git:github.com/wellwelwel/lagune หากติดตั้งจาก GitHub ส่วน pi update --extensions จะอัปเดตทุกแพ็กเกจที่คุณติดตั้งไว้

### รันคำสั่งของ Lagune บน Pi ได้อย่างไร

พิมพ์คำสั่งโดยมี skill: นำหน้า เช่น /skill:lagune-charter

---

# วิธีติดตั้ง Lagune บน Qwen Code แบบส่วนขยาย

> ติดตั้ง Lagune บน Qwen Code แบบส่วนขยาย อัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ และอนุญาตเอนจินไว้ล่วงหน้า

Canonical: https://lagune.ai/th-TH/docs/install/qwen-code
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/qwen-code
อัปเดตล่าสุด: 2026-11-07

ติดตั้งส่วนขยายจากเทอร์มินัลของคุณ:

```bash
qwen extensions install lagune
```

## การอัปเดต

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
qwen extensions update lagune
```

หากต้องการให้เป็นเวอร์ชันล่าสุดอยู่เสมอ ให้ติดตั้งด้วย `--auto-update`

## คำสั่ง

พิมพ์คำสั่งโดยมีชื่อส่วนขยายนำหน้า เช่น `/lagune:lagune-charter` แทน `/lagune-charter`

---

**สิทธิ์**

เอนจินทำงานผ่าน tool 2 ตัว: `lagune_read` อ่านโปรเจกต์ของคุณเท่านั้น และ `lagune_write` เขียนลงใน `.lagune/` เท่านั้น หากต้องการอนุญาต tool ทั้งสองไว้ล่วงหน้า ให้เพิ่มกฎเหล่านี้ลงใน `.qwen/settings.json` สำหรับโปรเจกต์เดียว หรือใน `~/.qwen/settings.json` สำหรับทุกโปรเจกต์:

```json
{
  "permissions": {
    "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"]
  }
}
```

เมื่อเอนจินทำงานผ่าน **npx** เช่นเมื่อติดตั้งด้วย **skills.sh** ให้อนุญาต `Shell(npx --yes lagune@*)`

## คำถามที่พบบ่อย

### ติดตั้ง Lagune บน Qwen Code ได้อย่างไร

รัน qwen extensions install lagune

### อัปเดต Lagune บน Qwen Code ได้อย่างไร

รัน qwen extensions update lagune หรือติดตั้งส่วนขยายด้วย --auto-update

### รันคำสั่งของ Lagune บน Qwen Code ได้อย่างไร

พิมพ์คำสั่งโดยมีชื่อส่วนขยายนำหน้า เช่น /lagune:lagune-charter

### Qwen Code รัน Lagune โดยไม่ต้องขออนุญาตได้ไหม

ได้ อนุญาต mcp__lagune__lagune_read และ mcp__lagune__lagune_write ในการตั้งค่าของ Qwen Code และอนุญาต Shell(npx --yes lagune@*) ด้วยเมื่อเอนจินทำงานผ่าน npx

---

# วิธีติดตั้ง Lagune ในเอเจนต์ใดก็ได้ด้วย skills.sh หรือ GitHub CLI

> ติดตั้ง Lagune ในเอเจนต์ AI ใดก็ได้ด้วย skills CLI หรือ GitHub CLI และอัปเดตให้เป็นเวอร์ชันล่าสุดเสมอ

Canonical: https://lagune.ai/th-TH/docs/install/universal
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/install/universal
อัปเดตล่าสุด: 2026-11-07

**skills.sh**

ติดตั้งคำสั่งของ **Lagune** ในโปรเจกต์ของคุณจากเทอร์มินัลด้วย [**skills.sh**](https://www.skills.sh/wellwelwel/lagune) โดยคงขอบเขตการติดตั้งไว้ที่ **Project**:

```bash
npx skills add wellwelwel/lagune --skill '*'
```

หรือวาง prompt นี้ในเอเจนต์ของคุณ:

```md
รัน `npx --yes skills add wellwelwel/lagune` แล้วเริ่มทำตามคำแนะนำของ skill ที่คำสั่งสร้างขึ้นทันที อ่านผลลัพธ์ให้ครบถ้วน หากจำเป็นให้ redirect ผลลัพธ์ไปยังไฟล์ชั่วคราวก่อน หา relative path โดยอิงจากไดเรกทอรีไฟล์ประกอบที่คำสั่งระบุไว้
```

**GitHub CLI**

ติดตั้งคำสั่งของ **Lagune** ในโปรเจกต์ของคุณจากเทอร์มินัลด้วย [**GitHub CLI**](https://cli.github.com/) เวอร์ชัน 2.90.0 ขึ้นไป:

```bash
gh skill install wellwelwel/lagune --all --scope project
```

หรือวาง prompt นี้ในเอเจนต์ของคุณ:

```md
รัน `gh skill install wellwelwel/lagune --all --scope project` แล้วอ่านผลลัพธ์ให้ครบถ้วน หากจำเป็นให้ redirect ผลลัพธ์ไปยังไฟล์ชั่วคราวก่อน
```

## การอัปเดต

**skills.sh**

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
npx skills update
```

หรือวาง prompt นี้ในเอเจนต์ของคุณ:

```md
รัน `npx --yes skills update -y` แล้วอ่านผลลัพธ์ให้ครบถ้วน หากจำเป็นให้ redirect ผลลัพธ์ไปยังไฟล์ชั่วคราวก่อน
```

**GitHub CLI**

หากต้องการอัปเดต **Lagune** ให้รัน:

```bash
gh skill update --all
```

หรือวาง prompt นี้ในเอเจนต์ของคุณ:

```md
รัน `gh skill update --all` แล้วอ่านผลลัพธ์ให้ครบถ้วน หากจำเป็นให้ redirect ผลลัพธ์ไปยังไฟล์ชั่วคราวก่อน
```

---

**Sandbox**

ใน sandbox ที่เข้าถึงเครือข่ายไม่ได้ คำสั่งต่าง ๆ จะดาวน์โหลดเอนจินไม่ได้ ให้ติดตั้งเอนจินในโปรเจกต์จากเทอร์มินัลของคุณเอง ครั้งแรกหนึ่งครั้งและทุกครั้งหลังอัปเดต:

```bash
npm i -D lagune@0.18.1
```

## คำถามที่พบบ่อย

### จะติดตั้ง Lagune ในเอเจนต์ AI ตัวไหนก็ได้ ต้องทำอย่างไร

รัน npx skills add wellwelwel/lagune --skill '*' หรือ gh skill install wellwelwel/lagune --all --scope project ในโปรเจกต์ของคุณ หรือวาง prompt สำหรับติดตั้งในเอเจนต์ของคุณ

### จะอัปเดต Lagune ในเอเจนต์ AI ตัวไหนก็ได้ ต้องทำอย่างไร

รัน npx skills update หากคุณติดตั้งด้วย skills.sh หรือรัน gh skill update --all หากคุณติดตั้งด้วย GitHub CLI นอกจากนี้คุณยังวาง prompt สำหรับอัปเดตในเอเจนต์ของคุณได้ด้วย

### ติดตั้ง Lagune มากกว่าหนึ่งช่องทางได้ไหม

ไม่ได้ หากติดตั้ง 2 ช่องทาง เอเจนต์จะแสดงทุกคำสั่งซ้ำ 2 ครั้ง หรือใช้ชุดหนึ่งและซ่อนอีกชุดไว้

---

# Skill ด้านความปลอดภัยสำหรับเอเจนต์ AI

> Skill ที่เอเจนต์ AI ของคุณได้รับจาก Lagune: ตรวจสอบโปรเจกต์ที่มีอยู่แล้ว หรือทำให้งานใหม่ปลอดภัยไปพร้อมกับที่สร้าง ทั้งหมดอยู่ภายใต้ charter

Canonical: https://lagune.ai/th-TH/docs/get-started/commands
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/get-started/commands
อัปเดตล่าสุด: 2026-11-07

เมื่อ [ติดตั้ง](https://lagune.ai/th-TH/docs) **Lagune** แล้ว เอเจนต์ **AI** ของคุณจะได้รับชุด skill ที่ใช้ได้ 2 แบบ และทั้งสองแบบอยู่ภายใต้ **charter**: ทำให้งานใหม่ปลอดภัยไปพร้อมกับที่สร้าง หรือรันการตรวจสอบเต็มรูปแบบกับโปรเจกต์

**⌨️ สร้างและพัฒนา**

คุณไม่จำเป็นต้องทำงานให้เสร็จก่อนจึงจะทำให้ปลอดภัย ใช้ [**`/lagune`**](https://lagune.ai/th-TH/docs/commands/lagune) กับงานที่คุณกำลังเขียน**อยู่ตอนนี้**:

| Skill                                         | สิ่งที่ทำให้คุณ                                                             |
| --------------------------------------------- | --------------------------------------------------------------------------- |
| [**/lagune-charter**](https://lagune.ai/th-TH/docs/commands/charter) | กำหนดกฎความปลอดภัยของโปรเจกต์ ซึ่งเป็นรากฐานที่ `/lagune` ยึดในการสร้าง     |
| [**/lagune**](https://lagune.ai/th-TH/docs/commands/lagune)          | สร้างสิ่งที่คุณขอและเสริมความปลอดภัยไปพร้อมกับที่เขียน ตามแนวทางของ charter |

**ใช้ได้ทุกเมื่อ**

[**`/lagune`**](https://lagune.ai/th-TH/docs/commands/lagune) ทำตามกฎใน charter ของคุณทุกครั้งที่รัน โดยรับ prompt ใดก็ได้ สร้างสิ่งที่คุณขอ และเสริมความปลอดภัยด้วยค่าเริ่มต้นที่ปลอดภัยไประหว่างทาง ไม่ใช่ทีหลัง

---

#### Skill พิเศษ

| Skill                                               | สิ่งที่ทำ                                                                        |
| --------------------------------------------------- | -------------------------------------------------------------------------------- |
| [**/lagune-specialize**](https://lagune.ai/th-TH/docs/commands/specialize) | สอนความรู้เฉพาะทางด้านความปลอดภัยใหม่ให้ **Lagune** จากบทความ exploit หรือหัวข้อ |

**🔬 ตรวจสอบ: ขั้นตอนแบบ Blue Team**

**ขั้นตอนแบบ Blue Team** เต็มรูปแบบ: อ่านว่าโปรเจกต์ทำอะไร ทำแผนผังความเสี่ยง แล้วปิดความเสี่ยงเหล่านั้น แต่ละ skill ต่อยอดจากตัวก่อนหน้า คุณจึงแค่ทำตามรายการจากบนลงล่าง:

| #   | Skill                                         | สิ่งที่ทำให้คุณ                                                                |
| --- | --------------------------------------------- | ------------------------------------------------------------------------------ |
| 1   | [**/lagune-charter**](https://lagune.ai/th-TH/docs/commands/charter) | กำหนดกฎความปลอดภัยของโปรเจกต์ โดยเสนอให้คุณหรือปรับตามสิ่งที่คุณบอก            |
| 2   | [**/lagune-detect**](https://lagune.ai/th-TH/docs/commands/detect)   | อ่านโค้ดของคุณและทำแผนผังว่าระบบทำอะไรและความเสี่ยงอยู่ตรงไหน                  |
| 3   | [**/lagune-plan**](https://lagune.ai/th-TH/docs/commands/plan)       | เปลี่ยนสิ่งที่ detect พบเป็นแผนการป้องกัน พร้อมการแก้ไขสำหรับข้อตรวจพบแต่ละข้อ |
| 4   | [**/lagune-harden**](https://lagune.ai/th-TH/docs/commands/harden)   | นำการแก้ไขในแผนไปใช้กับโค้ดของคุณอย่างปลอดภัยทีละรายการ                        |
| 5   | [**/lagune-verify**](https://lagune.ai/th-TH/docs/commands/verify)   | พิสูจน์ว่าการแก้ไขแต่ละรายการใช้ได้จริง แล้วปิดรายการที่พิสูจน์แล้ว            |

---

#### Skill พิเศษ

| Skill                                               | สิ่งที่ทำ                                                                                                           |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| [**/lagune-specialize**](https://lagune.ai/th-TH/docs/commands/specialize) | สอนความรู้เฉพาะทางด้านความปลอดภัยใหม่ให้ **Lagune** จากบทความ exploit หรือหัวข้อ                                    |
| [**/lagune-prove**](https://lagune.ai/th-TH/docs/commands/prove)           | เปลี่ยนข้อตรวจพบแต่ละข้อเป็นการพิสูจน์ที่รันได้และใช้เพื่อการป้องกันเท่านั้น สำหรับการเปิดเผยช่องโหว่อย่างรับผิดชอบ |

---

#### Skill ภายใน

| Skill                                       | สิ่งที่ทำ                           |
| ------------------------------------------- | ----------------------------------- |
| [**/lagune-repair**](https://lagune.ai/th-TH/docs/commands/repair) | ซ่อมแซมการติดตามภายในของ **Lagune** |

**เคล็ดลับ**

ความปลอดภัยไม่ใช่ต้นทุน แต่เป็นการลงทุน: สิ่งที่คุณลงไว้ตั้งแต่ต้นจะคืนกลับมาหลายเท่าจากเหตุการณ์ที่ไม่เคยเกิดขึ้น 🙋🏻‍♂️

## คำถามที่พบบ่อย

### Lagune เพิ่ม skill อะไรบ้าง

คำสั่ง /lagune สำหรับเสริมความปลอดภัยให้งานไปพร้อมกับที่สร้าง และขั้นตอนการตรวจสอบแบบ Blue Team ทั้ง 5 เฟส: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify รวมถึง /lagune-specialize และ /lagune-prove

### ขั้นตอนแบบ Blue Team ของ Lagune คืออะไร

การตรวจสอบ 5 เฟส: charter (กำหนดกฎ) detect (ทำแผนผังความเสี่ยง) plan (ให้คะแนนและวางแผนการแก้ไข) harden (นำการแก้ไขไปใช้) และ verify (พิสูจน์ว่าการแก้ไขใช้ได้จริงแล้วปิดให้จบ)

### /lagune ต่างจากขั้นตอนการตรวจสอบอย่างไร

คำสั่ง /lagune ทำให้งานใหม่ปลอดภัยไปพร้อมกับที่คุณเขียน โดยไม่ต้องทำตามขั้นตอนใด ส่วนขั้นตอนการตรวจสอบรันทั้ง 5 เฟสตามลำดับกับโปรเจกต์ที่มีอยู่แล้ว

---

# แดชบอร์ด

> ดู charter ข้อตรวจพบ และแคตตาล็อกของโปรเจกต์ในมุมมองแบบเรียลไทม์บนเครื่องของคุณ ซึ่งเปิดได้ด้วยคำสั่งเดียว

Canonical: https://lagune.ai/th-TH/docs/get-started/dashboard
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/get-started/dashboard
อัปเดตล่าสุด: 2026-11-07

รัน **Lagune** โดยตรงโดยไม่ระบุคำสั่งย่อย เพื่อเปิดมุมมองแบบเรียลไทม์ที่โต้ตอบได้ของ `.lagune/` **Lagune** จะรันแดชบอร์ดบนพอร์ตแบบสุ่มแล้วเปิดให้คุณ:

```bash
npx lagune
```

- [x] **Live Reload**
- [x] **เป็นส่วนตัว** และ **ทำงานบนเครื่อง**
- [x] แสดงทุกอย่างที่อยู่ใน `.lagune/` ตั้งแต่ charter แรกเป็นต้นไป
- [x] **จัดการ** หมวดหมู่ของโปรเจกต์และสิ่งที่ hook จะสแกน ผ่านเบราว์เซอร์ได้โดยตรง
- [x] ไม่ต้องมี `node_modules` หรือ `package.json` 📦

![charter ในแดชบอร์ด Lagune](https://lagune.ai/img/dashboard/02.webp)

![ข้อตรวจพบในแดชบอร์ด Lagune](https://lagune.ai/img/dashboard/03.webp)

![side quest ในแดชบอร์ด Lagune](https://lagune.ai/img/dashboard/04.webp)

![รายละเอียดข้อตรวจพบในแดชบอร์ด Lagune](https://lagune.ai/img/dashboard/05.webp)

![แคตตาล็อกในแดชบอร์ด Lagune](https://lagune.ai/img/dashboard/06.webp)

**เคล็ดลับ**

- 🚪 ใช้ `--port` เพื่อกำหนดพอร์ตเอง
- ⏏️ กด `Ctrl+C` เพื่อหยุด

## คำถามที่พบบ่อย

### เปิดแดชบอร์ดของ Lagune อย่างไร

รัน npx lagune โดยไม่ระบุคำสั่งย่อยที่รากของโปรเจกต์ คำสั่งนี้จะรันมุมมองแบบเรียลไทม์ของ .lagune/ บนพอร์ตแบบสุ่ม แล้วเปิดในเบราว์เซอร์ของคุณ

### แดชบอร์ดเป็นส่วนตัวไหม

ใช่ แดชบอร์ดทำงานบนเครื่องของคุณเท่านั้น โดยใช้ที่อยู่ภายในเครื่องที่คอมพิวเตอร์เครื่องอื่นเข้าถึงไม่ได้

### แก้ไขโปรเจกต์จากแดชบอร์ดได้ไหม

ได้เฉพาะหมวดหมู่ของโปรเจกต์และสิ่งที่ hook ละเว้น ผ่านเบราว์เซอร์ของคุณ ส่วนข้อมูลอื่นทั้งหมดที่แดชบอร์ดแสดงเป็นแบบอ่านอย่างเดียว

---

# /lagune: โค้ดปลอดภัยตั้งแต่ตอนที่ AI เขียน

> สร้างสิ่งที่คุณขอและเสริมความปลอดภัยไปพร้อมกับตอนเขียนโค้ด โดยมี charter เป็นแนวทาง และไม่ต้องทำตามเวิร์กโฟลว์ใด

Canonical: https://lagune.ai/th-TH/docs/commands/lagune
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/lagune
อัปเดตล่าสุด: 2026-11-07

⌨️ ทำงานที่คุณขอ โดยเสริมความปลอดภัยไปพร้อมกับตอนเขียน **`/lagune`** รับ prompt ใดก็ได้ในทุกช่วงของงาน สร้างสิ่งที่คุณต้องการ และเสริมความปลอดภัยด้วยค่าเริ่มต้นที่ปลอดภัยก่อนส่งงานคืนให้คุณ

## วิธีใช้

ใส่ **`/lagune`** ไว้ใน prompt ใดก็ได้ แล้วอธิบายงานตามที่คุณทำเป็นปกติ

**📘 คำสั่งสำหรับเอเจนต์**

```md
# คำสั่งของโปรเจกต์ฉันสำหรับเอเจนต์

<!-- ... -->

## ความปลอดภัย

- ใช้ skill `/lagune` ทุกครั้งที่คุณสร้างหรือแก้ไขโค้ด เพื่อให้ความปลอดภัยดีขึ้นตั้งแต่ค่าเริ่มต้น
```

    - ตัวอย่างเช่น **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** และอื่น ๆ

**💬 ฟีเจอร์**

```prompt
/lagune ให้ผู้ใช้อัปโหลดรูปของตัวเองในหน้าโปรไฟล์ได้
```

**💬 การแก้บั๊ก**

```prompt
/lagune ผู้ใช้กดส่งฟอร์มแล้วไม่มีอะไรเกิดขึ้น ช่วยหาสาเหตุแล้วแก้ไขให้
```

**💬 การรีแฟกเตอร์**

```prompt
/lagune แยกส่วนและปรับปรุงลอจิกของ payload
```

**ไม่มี charter ก็ใช้ได้ แต่มีจะดีกว่า**

**`/lagune`** ทำงานได้ทั้งแบบมีและไม่มี charter ถ้ามี กฎของโปรเจกต์คุณเองจะกำหนดทิศทางของงานทุกชิ้นที่สร้าง ตั้งกฎเหล่านั้นครั้งเดียวด้วย [`/lagune-charter`](https://lagune.ai/th-TH/docs/commands/charter)

## หลักการทำงาน

คำสั่งนี้ครอบงานไว้ด้วย 3 ขั้นตอน โดยไม่เขียนอะไรลงใน Lagune เลย:

1. โหลด charter ของคุณถ้ามีอยู่ และใช้หลักการด้านความปลอดภัยในนั้นกำกับงานทั้งหมด ถ้าคุณยังไม่มี ก็ใช้เกณฑ์พื้นฐานที่ปลอดภัยตั้งแต่ค่าเริ่มต้นแทน
2. แสดง [แคตตาล็อก](https://lagune.ai/th-TH/docs/catalog) ของโปรเจกต์คุณ แล้วโหลดเฉพาะความรู้เฉพาะทางที่งานของคุณเกี่ยวข้อง ซึ่งเป็นความรู้ชุดเดียวกับที่เวิร์กโฟลว์การตรวจสอบโหลดเฉพาะเมื่อจำเป็น
3. ใส่การป้องกันลงไปขณะเขียนโค้ด แล้วอ่านผลงานของตัวเองอีกรอบเพื่อยืนยันว่ามาตรการควบคุมใช้ได้จริงก่อนส่งงานคืน

ผลลัพธ์คือโค้ดที่ใช้งานได้ในโปรเจกต์ของคุณ และปลอดภัยตั้งแต่บรรทัดแรก

**ใช้ได้ทุกเมื่อ**

ไม่ต้องมี detect ไม่ต้องมี plan และไม่ต้องตามเก็บงานทีหลัง **`/lagune`** เหมาะทั้งกับโปรเจกต์ที่เพิ่งตั้งต้นและการแก้ไขในโค้ดเบสที่โตเต็มที่แล้ว และเสริมความปลอดภัยไประหว่างทำงาน ไม่ใช่ทีหลัง

## สิ่งที่คำสั่งนี้ไม่ทำ

- ไม่เขียนอะไรลงในไดเรกทอรี `.lagune` ทั้งอาร์ติแฟกต์และการติดตาม สิ่งเดียวที่ได้จึงเป็นโค้ดที่เสริมความปลอดภัยแล้วตามที่คุณขอ
- ไม่ลดทอนกฎเพื่อให้ตรงกับ prompt ถ้าสิ่งที่คุณขอจะขัดกับหลักการใน charter คำสั่งนี้จะหยุดและแจ้งคุณก่อน แทนที่จะสร้างแบบไม่ปลอดภัยไปเลย

## คำถามที่พบบ่อย

### /lagune ทำอะไร

รับ prompt ใดก็ได้ในทุกช่วงของงาน สร้างสิ่งที่คุณขอ และเสริมความปลอดภัยด้วยค่าเริ่มต้นที่ปลอดภัยก่อนส่งงานคืน โดยใส่การป้องกันลงไปขณะเขียนโค้ด ไม่ใช่ทีหลัง

### ต้องมี charter ก่อนถึงจะใช้ /lagune ได้ไหม

ไม่ต้อง คำสั่งนี้ทำงานได้ทั้งแบบมีและไม่มี charter ถ้ามี กฎของโปรเจกต์คุณเองจะกำหนดทิศทางของงานทุกชิ้นที่สร้าง ถ้าไม่มี ก็ใช้เกณฑ์พื้นฐานที่ปลอดภัยตั้งแต่ค่าเริ่มต้นแทน

### /lagune ต่างจากขั้นตอนแบบ Blue Team อย่างไร

/lagune ทำให้งานใหม่ปลอดภัยไปพร้อมกับตอนที่คุณเขียน โดยไม่ต้องทำตามเวิร์กโฟลว์ใด ส่วนขั้นตอนแบบ Blue Team จะรันเฟสการตรวจสอบทั้ง 5 เฟสตามลำดับกับโปรเจกต์ที่มีอยู่แล้ว

### /lagune ติดตามข้อตรวจพบหรือเขียนอาร์ติแฟกต์ไหม

ไม่ คำสั่งนี้ไม่เขียนอะไรลงในไดเรกทอรี .lagune ทั้งอาร์ติแฟกต์และการติดตาม สิ่งเดียวที่ได้คือโค้ดที่เสริมความปลอดภัยแล้วตามที่คุณขอ

### ทำอย่างไรให้เอเจนต์ใช้ /lagune เองโดยอัตโนมัติ

เพิ่มคำสั่งลงในไฟล์คำสั่งของเอเจนต์ (AGENTS.md, CLAUDE.md, .cursorrules และไฟล์ทำนองเดียวกัน) ให้เอเจนต์ใช้ skill /lagune ทุกครั้งที่สร้างหรือแก้ไขโค้ด

---

# /lagune-charter: กำหนดหลักการด้านความปลอดภัยของคุณ

> กำหนดหลักการด้านความปลอดภัยของโปรเจกต์ ซึ่งเป็นกฎที่ทุกเฟสถัดไปต้องเคารพ และบันทึกหมวดหมู่ความรู้เฉพาะทางที่การอ่านโปรเจกต์รองรับ

Canonical: https://lagune.ai/th-TH/docs/commands/charter
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/charter
อัปเดตล่าสุด: 2026-11-07

🧬 บอก **Lagune** ว่าโปรเจกต์ของคุณคืออะไร แล้ว **Lagune** จะแปลงสิ่งนั้นเป็นกฎด้านความปลอดภัยของคุณ (หรือถ้าไม่มีคำอธิบาย ก็จะหากฎเหล่านั้นจากตัวโปรเจกต์อย่างเดียว)

charter คือชั้นที่กำกับทุกเฟส: ชุดหลักการที่ให้ความปลอดภัยมาก่อน ซึ่งทุกเฟสถัดไปต้องเคารพ ให้มองว่าเป็นการตรวจตอนคอมไพล์สำหรับสถานะความปลอดภัยโดยรวมของโปรเจกต์คุณ

## วิธีใช้

**อธิบายโปรเจกต์**

```prompt
/lagune-charter โปรเจกต์ของฉันเป็นร้านค้าออนไลน์ที่ขายวิดีโอเกม ลูกค้าเพิ่มสินค้าลงตะกร้าแล้วจ่ายด้วยบัตรเครดิตหรือใบแจ้งชำระเงินของธนาคาร ลูกค้าดูคำสั่งซื้อของตัวเองและสถานะของแต่ละรายการได้
```

**ให้ Lagune เสนอ**

```prompt
/lagune-charter
```

> _ฉันเห็นไลบรารีการชำระเงิน ระบบล็อกอิน และโมเดลคำสั่งซื้อที่ผูกกับลูกค้า ดูเหมือนเป็นร้านค้าออนไลน์ที่ขายสินค้าบางอย่าง ลูกค้าชำระเงินและติดตามคำสั่งซื้อของตัวเอง..._ ☁️

## สิ่งที่คำสั่งนี้วิเคราะห์

**Lagune** ใช้คำอธิบายหรือ **PRD** ของคุณเป็นทิศทาง แล้ววิเคราะห์ว่าสิ่งนั้นมีความหมายอย่างไรต่อความปลอดภัย จากนั้นอ่านโปรเจกต์เพื่อไปให้ไกลกว่าที่คุณระบุ ตัวอย่างเช่น:

- ตะกร้าที่เก็บคำสั่งซื้อแปลว่ามี **ฐานข้อมูล**:
  - เช่น `"ข้อมูลเก็บอยู่ที่ไหน"`, `"ใครเข้าถึงได้บ้าง"`, `"ข้อมูลรั่วไหม"`
- ลูกค้าที่ดูคำสั่งซื้อของตัวเองได้แปลว่ามี **การล็อกอินหรือการควบคุมการเข้าถึง** บางรูปแบบ:
  - เช่น `"ลูกค้าคนหนึ่งเข้าถึงคำสั่งซื้อของลูกค้าคนอื่นได้ไหม"`, `"เซสชันได้รับการป้องกันไหม"`
- การรับชำระเงินด้วยบัตรและใบแจ้งชำระเงินของธนาคารแปลว่า **มีเงินและข้อมูลอ่อนไหวเข้ามาเกี่ยวข้อง**:
  - เช่น `"มีการเก็บข้อมูลบัตรไหม"`, `"มีการตรวจสอบการชำระเงินไหม"`

คำอธิบายของคุณกับตัวโปรเจกต์เสริมกัน คำอธิบายกำหนดเจตนา ส่วนการอ่าน dependency ไฟล์ README และการตั้งค่าจะเผยสิ่งที่คุณไม่ได้พูดถึง ถ้ายังมีเรื่องสำคัญที่ไม่ชัดเจน **Lagune** จะถามคำถามสั้น ๆ ที่เข้าใจง่ายแทนการเดา

จากนั้น **Lagune** จะสร้างชุดกฎด้านความปลอดภัยที่ปรับให้เข้ากับโปรเจกต์ ซึ่งคุณตรวจทานและปรับแก้ได้ทุกเมื่อที่ต้องการ

**ใช้ให้ได้ประโยชน์สูงสุด**

- คุณกำหนดกฎด้านความปลอดภัยของโปรเจกต์เองได้ด้วย
- ยิ่งให้รายละเอียดที่เกี่ยวข้องมาก รายงานสุดท้ายก็ยิ่งดี:
  - อธิบายโปรเจกต์ วิธีการทำงาน และสิ่งที่เกิดขึ้นเบื้องหลัง
  - ผู้ใช้ปลายทางคือใคร ผู้ใช้ทำอะไรได้ และทำอะไรไม่ได้
  - รายละเอียดด้านพฤติกรรมมีค่าพอ ๆ กับรายละเอียดทางเทคนิค
- ความจำของ charter อยู่ที่ `.lagune/memory/charter.md`

## หมวดหมู่ที่คำสั่งนี้บันทึก

ความรู้เฉพาะทาง ซึ่งเป็นความรู้ด้านความปลอดภัยที่เฟสถัดไปโหลดเฉพาะเมื่อจำเป็น เข้ามาอยู่ใน [แคตตาล็อก](https://lagune.ai/th-TH/docs/catalog) ของโปรเจกต์คุณตาม [หมวดหมู่](https://lagune.ai/th-TH/docs/categories) ระหว่างที่โปรเจกต์ของคุณยังไม่ได้บันทึกหมวดหมู่ใด charter จะบันทึกทุกหมวดหมู่ที่การอ่านโปรเจกต์รองรับ เช่น ภาษาของโปรเจกต์ การเรียกใช้ LLM หรือคอนเทนเนอร์ แล้วระบุชื่อหมวดหมู่เหล่านั้นในสรุปผล

เมื่อบันทึกหมวดหมู่แล้ว charter จะไม่แตะต้องหมวดหมู่เหล่านั้น และจะระบุเพียงหมวดหมู่ที่โปรเจกต์ของคุณยังไม่ได้ใช้ คุณเปลี่ยนหมวดหมู่เองได้ทุกเมื่อ:

```bash
npx lagune write add --categories python
npx lagune write remove --categories python
```

## โฟลเดอร์ที่คำสั่งนี้เสนอให้ยกเว้น

เมื่อ charter อ่านแล้วพบโฟลเดอร์ที่ commit ไว้แต่ไม่ใช่โค้ดของโปรเจกต์ที่ต้องป้องกัน เช่น fixture สำหรับการทดสอบที่จงใจเขียนให้ดูมีช่องโหว่ charter จะแสดงรายการโฟลเดอร์เหล่านั้นเป็นหมายเลขไว้ท้ายสรุปผล charter ไม่เคยยกเว้นโฟลเดอร์ใดเอง เพราะ repository ที่ประสงค์ร้ายอาจทำให้โค้ดของตัวเองดูเหมือน fixture ได้ จึงบันทึกเฉพาะหมายเลขที่คุณตอบกลับมาเท่านั้น หน้า [ตั้งค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายวิธีเปลี่ยนรายการนี้ด้วยตัวเอง

## ถัดไป

เมื่อตั้งกฎแล้ว ให้ทำแผนผังสิ่งที่ระบบของคุณทำจริง: [`/lagune-detect`](https://lagune.ai/th-TH/docs/commands/detect)

## คำถามที่พบบ่อย

### charter ใน Lagune คืออะไร

charter คือชั้นที่กำกับทุกเฟสของ Lagune เป็นชุดหลักการที่ให้ความปลอดภัยมาก่อน ซึ่งทุกเฟสถัดไปต้องเคารพ ให้มองว่าเป็นการตรวจตอนคอมไพล์สำหรับสถานะความปลอดภัยโดยรวมของโปรเจกต์คุณ

### charter เก็บไว้ที่ไหน

ที่ .lagune/memory/charter.md

### เขียนกฎใน charter เองได้ไหม

ได้ Lagune เสนอกฎจากคำอธิบายและโค้ดของคุณ และคุณเปลี่ยนถ้อยคำ ตัดออก เพิ่ม หรือจำกัดขอบเขตของกฎได้

### charter เลือกหมวดหมู่ความรู้เฉพาะทางให้ไหม

เฉพาะตอนที่ยังไม่มีหมวดหมู่ที่บันทึกไว้ charter จะบันทึกทุกหมวดหมู่ที่การอ่านโปรเจกต์รองรับ เช่น ภาษาที่คุณใช้ หรือการเรียกใช้ LLM เมื่อบันทึกหมวดหมู่แล้ว charter จะไม่เปลี่ยนหมวดหมู่เหล่านั้นอีก

---

# /lagune-detect: ทำแผนผังระบบและความเสี่ยงของคุณ

> อ่านโค้ดของคุณ แล้วทำแผนผังว่าระบบทำอะไรบ้างและความเสี่ยงอยู่ตรงไหน

Canonical: https://lagune.ai/th-TH/docs/commands/detect
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/detect
อัปเดตล่าสุด: 2026-11-07

🔬 รู้ว่าระบบของคุณทำอะไรจริง ๆ และความเสี่ยงอยู่ตรงไหน

detect อ่านโค้ดและบันทึกเฉพาะสิ่งที่พบจริง พร้อมหลักฐานที่เฟสถัดไปต้องใช้ หลักที่กำกับเฟสนี้คือการตรวจหา ไม่ใช่การแต่งขึ้นเอง

## วิธีใช้

**สแกนทั้งโปรเจกต์**

```prompt
/lagune-detect
```

**ระบุ path**

```prompt
/lagune-detect src/routes/ src/auth.ts
```

**อธิบายข้อกังวล**

```prompt
/lagune-detect ตรวจให้แน่ใจว่าข้อมูลลูกค้าไม่มีทางรั่วไหล
```

## สิ่งที่คำสั่งนี้ทำแผนผัง

**Lagune** อ่านโค้ดและทำแผนผังสิ่งที่พบ ข้อตรวจพบแต่ละรายการบอกว่าคืออะไร ทำไมจึงสำคัญ และมีหลักฐานอะไร ตัวอย่างเช่น:

- **การอัปโหลดไฟล์** ระบบรับไฟล์จากผู้ใช้:
  - _ทำไมจึงสำคัญ:_ ไฟล์ที่ปลอมตัวเป็นรูปภาพอาจซ่อนโค้ดอันตรายไว้
  - _หลักฐาน:_ handler `POST /upload` เชื่อ MIME type ที่ไคลเอนต์ส่งมา โดยไม่ตรวจชนิดจริงของไฟล์
- **การล็อกอินและเซสชัน** ผู้ใช้ล็อกอินเพื่อเข้าบัญชีของตัวเอง:
  - _ทำไมจึงสำคัญ:_ การจัดการเซสชันที่อ่อนแอทำให้บัญชีหนึ่งถูกอีกบัญชีหนึ่งยึดได้
  - _หลักฐาน:_ ลอจิกการออกเซสชัน ซึ่งออกเซสชันโดยไม่กำหนดเวลาหมดอายุ

ระหว่างนั้น detect จะให้ผลตัดสินกับความรู้เฉพาะทางทุกรายการใน [แคตตาล็อก](https://lagune.ai/th-TH/docs/catalog) ของโปรเจกต์คุณโดยเทียบกับโค้ด นำรายการที่มีบริบทตรงกับโปรเจกต์ไปใช้ และบันทึกไว้ใต้ **Applied specializations** ซึ่งเป็นรายการที่ harden และ verify นำกลับมาใช้

จากนั้นคุณจะได้แผนผังที่ชัดเจนว่าระบบทำอะไรบ้างและความเสี่ยงอยู่ตรงไหน พร้อมให้ขั้นตอนถัดไปลงมือ

**เคล็ดลับ**

- รันซ้ำเพื่ออัปเดตแผนผัง: ข้อตรวจพบที่แก้แล้วจะหายไป และข้อตรวจพบใหม่จะเข้ามา
- แผนผังจาก detect อยู่ที่ `.lagune/memory/detect.md`

## ถัดไป

เปลี่ยนแผนผังเป็นแผน: [`/lagune-plan`](https://lagune.ai/th-TH/docs/commands/plan)

## คำถามที่พบบ่อย

### /lagune-detect ทำอะไร

อ่านโค้ดของคุณและทำแผนผังว่าระบบทำอะไรบ้างและความเสี่ยงอยู่ตรงไหน โดยบันทึกเฉพาะสิ่งที่พบจริง หลักของคำสั่งนี้คือการตรวจหา ไม่ใช่การแต่งขึ้นเอง

### ข้อตรวจพบใน Lagune คืออะไร

ข้อตรวจพบคือความเสี่ยงหนึ่งรายการที่ตรวจพบ ซึ่งบอกว่าคืออะไร ทำไมจึงสำคัญ และมีหลักฐานอะไรในโค้ด เป็นหน่วยที่ติดตามและส่งต่อไปยัง plan, harden และ verify

### แผนผังจาก detect เก็บไว้ที่ไหน

ที่ .lagune/memory/detect.md

### detect ใช้ความรู้เฉพาะทางรายการไหนบ้าง

ความรู้เฉพาะทางทุกรายการในแคตตาล็อกของโปรเจกต์คุณจะได้รับผลตัดสินโดยเทียบกับโค้ด detect นำรายการที่มีบริบทตรงกับโปรเจกต์ไปใช้ และบันทึกไว้ใต้ Applied specializations

---

# /lagune-plan: ให้คะแนนข้อตรวจพบและวางแผนการแก้ไข

> เปลี่ยนสิ่งที่ detect พบให้เป็นแผนการป้องกัน โดยให้คะแนนข้อตรวจพบแต่ละรายการด้วยหมวดหมู่และคะแนน CVSS v4.0 แล้วจับคู่กับการแก้ไข

Canonical: https://lagune.ai/th-TH/docs/commands/plan
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/plan
อัปเดตล่าสุด: 2026-11-07

🛡️ เปลี่ยนสิ่งที่ detect พบให้เป็นแผนการป้องกัน: ให้คะแนนข้อตรวจพบแต่ละรายการด้วยหมวดหมู่และคะแนน CVSS v4.0 แล้วจับคู่กับการแก้ไขที่ต้องนำไปใช้

## วิธีใช้

**วางแผนทั้งหมด**

```prompt
/lagune-plan
```

**ระบุ path**

```prompt
/lagune-plan src/routes/upload.ts
```

**เน้นข้อกังวล**

```prompt
/lagune-plan จุดที่ข้อมูลอ่อนไหวอาจรั่วไหล
```

## หลักการทำงาน

เฟสนี้ทำงานต่อจาก detect ซึ่งพบแล้วว่าระบบของคุณทำอะไรและแต่ละส่วนมีความเสี่ยงอะไร plan จึงไม่ระบุความเสี่ยงซ้ำ แต่ประเมินว่าความเสี่ยงนั้นร้ายแรงแค่ไหนและตัดสินว่าจะจัดการอย่างไร plan ไม่อ่านโค้ดเลย การแก้ไขทุกรายการจึงต้องชี้ไปที่สิ่งที่ detect ตรวจพบจริง plan ให้คะแนนข้อตรวจพบแต่ละรายการด้วยวิธี CVSS v4.0: หมวดหมู่หนึ่งหมวด เวกเตอร์ CVSS v4.0 ที่อนุมานจากสิ่งที่ detect และ charter บันทึกไว้แล้วให้ [hook `cvss`](https://lagune.ai/th-TH/docs/hooks/cvss) คำนวณคะแนน และระดับความสำคัญที่คะแนนนั้นตกอยู่ การแก้ไขแต่ละรายการยังระบุหลักการใน charter ที่การแก้ไขนั้นรักษาไว้ด้วย

ตัวอย่างเช่น:

- **การอัปโหลดไฟล์** (ความสำคัญ: **วิกฤต**)
  - _หมวดหมู่:_ การอัปโหลดไฟล์โดยไม่มีข้อจำกัด (CWE-434)
  - _CVSS:_ CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3, Critical)
  - _เหตุผลของระดับความสำคัญนี้:_ ใครก็เข้าถึงการอัปโหลดผ่านอินเทอร์เน็ตได้ และการอัปโหลดนี้อยู่บนเซิร์ฟเวอร์ที่เก็บไฟล์ของลูกค้า
  - _รักษาหลักการ:_ III. อินพุตทุกอย่างไม่น่าเชื่อถือจนกว่าจะผ่านการตรวจสอบความถูกต้อง
  - _การแก้ไข:_ ตรวจชนิดจริงและขนาดของไฟล์ เปลี่ยนชื่อไฟล์ตอนบันทึก และเก็บไฟล์ที่อัปโหลดไว้ในที่ที่รันเป็นโค้ดไม่ได้

จากนั้นคุณจะได้รายการการแก้ไขที่ให้คะแนนและจัดลำดับความสำคัญแล้ว แต่ละรายการผูกกับข้อตรวจพบหนึ่งรายการและพร้อมให้เฟสถัดไปนำไปใช้ คะแนนมาจากการคำนวณ ไม่ใช่การประมาณ: เวกเตอร์บรรจุระดับการเปิดเผยของโปรเจกต์และสิ่งที่เดิมพันไว้เป็น Environmental metrics และใครก็นำเวกเตอร์ไปวางในเครื่องคำนวณของ FIRST หรือ NVD แล้วได้คะแนนเดียวกัน

**เคล็ดลับ**

- คำสั่งนี้สร้างต่อจาก detect ทั้งหมด ถ้าไฟล์หรือข้อกังวลใดยังไม่เคยทำแผนผัง คำสั่งนี้จะบอกให้คุณรัน `/lagune-detect` กับสิ่งนั้นก่อน
- รันซ้ำเพื่ออัปเดตแผน: การแก้ไขที่ทำเสร็จแล้วจะหายไป และการแก้ไขใหม่จะเข้ามา
- แผนการป้องกันอยู่ที่ `.lagune/memory/plan.md`

**ต้องรัน detect ก่อน**

plan ทำงานจากสิ่งที่ [`/lagune-detect`](https://lagune.ai/th-TH/docs/commands/detect) ทำแผนผังไว้แล้วเท่านั้น จึงต้องรัน detect ก่อน

## ถัดไป

นำแผนไปใช้: [`/lagune-harden`](https://lagune.ai/th-TH/docs/commands/harden)

## คำถามที่พบบ่อย

### Lagune จัดลำดับความสำคัญของช่องโหว่อย่างไร

/lagune-plan ให้คะแนนข้อตรวจพบแต่ละรายการด้วยหมวดหมู่และคะแนน CVSS v4.0 ที่ hook cvss คำนวณ แล้วจับคู่กับการแก้ไขที่ต้องนำไปใช้

### Lagune ใช้ CVSS v4.0 ไหม

ใช้ ข้อตรวจพบแต่ละรายการได้เวกเตอร์และคะแนน CVSS v4.0 ที่ hook cvss คำนวณด้วยสูตรเดียวกับเครื่องคำนวณของ FIRST ใครก็นำเวกเตอร์ไปวางที่นั่นแล้วได้คะแนนเดียวกัน

### plan อ่านโค้ดของฉันไหม

ไม่ plan ไม่อ่านโค้ดเลย การแก้ไขทุกรายการจึงต้องชี้ไปที่สิ่งที่ detect ตรวจพบจริง

---

# /lagune-harden: นำการแก้ไขด้านความปลอดภัยไปใช้กับโค้ดของคุณ

> นำการแก้ไขจากแผนไปใช้กับโค้ดของคุณอย่างปลอดภัย ทีละรายการ

Canonical: https://lagune.ai/th-TH/docs/commands/harden
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/harden
อัปเดตล่าสุด: 2026-11-07

🔧 นำการแก้ไขจากแผนไปใช้กับโค้ดของคุณอย่างปลอดภัย ทีละรายการ

## วิธีใช้

**นำไปใช้ทั้งหมด**

```prompt
/lagune-harden
```

**ระบุ path**

```prompt
/lagune-harden src/routes/upload.ts
```

**ตามระดับความสำคัญ**

```prompt
/lagune-harden เฉพาะระดับวิกฤตและสูง
```

## หลักการทำงาน

plan ตัดสินการแก้ไขแต่ละรายการไว้แล้ว harden จึงแค่นำไปใช้ เฟสนี้เป็นเฟสเดียวที่แตะโค้ดของคุณ จึงทำงานอย่างระมัดระวัง: นำการแก้ไขไปใช้ทีละรายการเพื่อให้ตรวจทานการเปลี่ยนแปลงแต่ละครั้งได้ง่าย และไม่ลดทอนมาตรการควบคุมเพื่อให้การแก้ไขลงตัว ตัวอย่างเช่น การแก้ไขเรื่องการอัปโหลด:

- **การอัปโหลดไฟล์** (สถานะ: **Applied**)
  - _สิ่งที่เปลี่ยน:_ ตรวจชนิดจริงและขนาดของไฟล์ ปฏิเสธทุกอย่างที่ไม่ได้คาดไว้ เปลี่ยนชื่อไฟล์ตอนบันทึก และเก็บไว้ในที่ที่รันเป็นโค้ดไม่ได้
  - _ตำแหน่ง:_ ฟังก์ชัน `handleUpload` และ helper สำหรับจัดเก็บที่ฟังก์ชันนี้เรียกใช้

ถ้านำการแก้ไขไปใช้ได้ไม่ครบ harden จะทำส่วนที่ทำได้อย่างปลอดภัย แล้วทำเครื่องหมายส่วนที่เหลือเป็น **Partial** หรือ **Blocked** โดยเปิดค้างไว้

**นำไปใช้แล้วยังไม่เท่ากับผ่านการพิสูจน์**

Applied ยังไม่ได้แปลว่าพิสูจน์แล้ว นั่นคือหน้าที่ของ [verify](https://lagune.ai/th-TH/docs/commands/verify)

**เคล็ดลับ**

- คำสั่งนี้สร้างต่อจากแผนทั้งหมด ถ้าการแก้ไขหรือไฟล์ใดยังไม่เคยอยู่ในแผน คำสั่งนี้จะบอกให้คุณรัน `/lagune-plan` กับสิ่งนั้นก่อน
- รันซ้ำเพื่อปรับบันทึกให้ตรงกับสภาพปัจจุบัน: การเปลี่ยนแปลงที่ถูกย้อนกลับจะหายไป และการแก้ไขที่เพิ่งนำไปใช้จะเข้ามา
- บันทึก hardening อยู่ที่ `.lagune/memory/harden.md`

**ต้องรัน plan ก่อน และจะแก้ไขโค้ดของคุณ**

harden สร้างต่อจาก [`/lagune-plan`](https://lagune.ai/th-TH/docs/commands/plan) และเป็นเฟสเดียวที่แก้ไขโค้ดของคุณ

## ถัดไป

พิสูจน์ว่าการแก้ไขแต่ละรายการใช้ได้จริง: [`/lagune-verify`](https://lagune.ai/th-TH/docs/commands/verify)

## คำถามที่พบบ่อย

### /lagune-harden แก้ไขโค้ดของฉันไหม

ใช่ เป็นเฟสเดียวที่แตะโค้ดของคุณ โดยนำการแก้ไขจากแผนไปใช้ทีละรายการ

### Applied, Partial และ Blocked หมายถึงอะไร

เป็นสถานะที่ Lagune บันทึกให้การแก้ไขแต่ละรายการ Applied หมายถึงแก้ไขแล้ว Partial หมายถึงแก้ไขได้เพียงบางส่วน และ Blocked หมายถึงนำการแก้ไขไปใช้ไม่ได้ Applied ยังไม่ได้แปลว่าพิสูจน์แล้ว

### Lagune นำการแก้ไขไปใช้โดยไม่ถามก่อนไหม

การแก้ไขโค้ดแต่ละครั้งต้องรอให้คุณอนุมัติหรือไม่ ขึ้นอยู่กับเอเจนต์และโหมดสิทธิ์ที่คุณใช้รัน ไม่ใช่ Lagune ซึ่งไม่ได้เพิ่มขั้นตอนยืนยันของตัวเอง แต่ Lagune ก็ไม่ลดทอนมาตรการควบคุมเพื่อให้การแก้ไขลงตัว และถ้าการแก้ไขใดจะขัดกับกฎใน charter ก็จะหยุดและแจ้งคุณก่อน

---

# /lagune-verify: พิสูจน์ว่ามาตรการควบคุมความปลอดภัยใช้ได้จริง

> พิสูจน์ว่าการแก้ไขแต่ละรายการที่นำไปใช้แล้วได้ผลจริง แล้วปิดรายการที่ผ่านให้จบ

Canonical: https://lagune.ai/th-TH/docs/commands/verify
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/verify
อัปเดตล่าสุด: 2026-11-07

⚖️ พิสูจน์ว่าการแก้ไขแต่ละรายการที่นำไปใช้แล้วได้ผลจริง โดยอ่านโค้ดแล้วเทียบกับสิ่งที่ harden บันทึกไว้ จากนั้นปิดรายการที่ผ่านให้จบ

## วิธีใช้

**ตรวจสอบทั้งหมด**

```prompt
/lagune-verify
```

**ระบุ path**

```prompt
/lagune-verify src/routes/upload.ts
```

**ตามระดับความสำคัญ**

```prompt
/lagune-verify เฉพาะระดับวิกฤตและสูง
```

## หลักการทำงาน

คำสั่งนี้อ่านโค้ดทุกจุดที่ harden บันทึกไว้ และยืนยันว่าโค้ดตรงกับที่อ้างไว้จริง การพิสูจน์ก็คือการเทียบนี้ คือเทียบโค้ดกับบันทึก มาตรการควบคุมแต่ละรายการจะได้ผลตัดสินอย่างใดอย่างหนึ่งจาก 3 แบบ:

| ผลตัดสิน                     | ความหมาย                                                 |
| ---------------------------- | -------------------------------------------------------- |
| ✅ Risk closed               | โค้ดทำตามที่บันทึกอ้างไว้ทุกประการ                       |
| ❌ Risk not closed           | มาตรการควบคุมยังเปิดอยู่ verify จะส่งคุณกลับไปที่ harden |
| ❓ Cannot tell from the code | ดูหลักฐานจากโค้ดอย่างเดียวไม่ได้                         |

จากนั้น verify จะปิดความเสี่ยงที่พิสูจน์แล้วว่าปิดได้ออกจากทั้งห่วงโซ่เมื่อคุณยืนยัน ตัวอย่างเช่น:

- **การอัปโหลดไฟล์** (ผลตัดสิน: **✅ Risk closed**)
  - _วิธีพิสูจน์:_ อ่าน handler ของการอัปโหลดแล้วเห็นว่าตรวจชนิดจริงของไฟล์จากเนื้อหา บังคับขนาดสูงสุด และปฏิเสธทุกอย่างที่นอกเหนือจากนั้น ตรงตามที่บันทึกอ้างไว้ทุกประการ
  - _หลักฐาน:_ ฟังก์ชัน `handleUpload` ซึ่งตรวจชนิดจริงของไฟล์จากเนื้อหา

ถ้าความเสี่ยงยังไม่ปิด verify จะบอกตรง ๆ และส่งคุณกลับไปที่ [`/lagune-harden`](https://lagune.ai/th-TH/docs/commands/harden) เพราะการแก้ไขยังเปิดอยู่

**เคล็ดลับ**

- คำสั่งนี้สร้างต่อจากบันทึก hardening ทั้งหมด
- คำสั่งนี้อ่านโค้ดของคุณเพื่อตัดสินเท่านั้น และไม่ลดทอนมาตรการควบคุมหรือเขียนโค้ดใหม่เพื่อให้ผลตัดสินผ่าน
- รันซ้ำเพื่อปรับผลตัดสินให้ตรงกับสภาพปัจจุบัน: ผลตัดสินที่ล้าสมัยจะหายไป และความเสี่ยงที่ไม่ได้ปิดอยู่แล้วจะกลับมาถูกชี้ว่าเป็นปัญหาอีกครั้ง
- เมื่อพิสูจน์ได้ว่าความเสี่ยงปิดแล้ว คำสั่งนี้จะถามคุณหนึ่งครั้ง แล้วลบข้อตรวจพบนั้นออกจากทั้งห่วงโซ่ (detect, plan, harden และการติดตาม)
- คำสั่งนี้ไม่เขียนรายงานของตัวเอง: ผลตัดสินแต่ละรายการอยู่ในบล็อกของมาตรการควบคุมนั้นใน `.lagune/memory/harden.md` ซึ่ง harden จะอ่านในการรันครั้งถัดไป

**ต้องรัน harden ก่อน**

verify สร้างต่อจาก [`/lagune-harden`](https://lagune.ai/th-TH/docs/commands/harden)

## รอบการทำงานสิ้นสุด

เมื่อปิดทุกอย่างในขอบเขตแล้ว รอบการทำงานจึงสิ้นสุดลง และจะเปิดใหม่ก็ต่อเมื่อโค้ดเปลี่ยน ความปลอดภัยปิดให้จบได้ เวิร์กโฟลว์จึงมีจุดสิ้นสุด ไม่ใช่วนซ้ำไม่รู้จบ

## คำถามที่พบบ่อย

### Lagune ตรวจสอบการแก้ไขอย่างไร

/lagune-verify อ่านโค้ดแล้วเทียบกับสิ่งที่ harden บันทึกไว้ แล้วให้ผลตัดสินอย่างใดอย่างหนึ่งจาก 3 แบบ: Risk closed (ปิดความเสี่ยงแล้ว), Risk not closed (ยังไม่ปิดความเสี่ยง) หรือ Cannot tell from the code (ดูจากโค้ดอย่างเดียวไม่ได้)

### การปิดข้อตรวจพบคืออะไร

เมื่อ verify พิสูจน์ได้ว่าความเสี่ยงปิดแล้ว verify จะปิดข้อตรวจพบนั้น คือลบออกจากทั้งห่วงโซ่เมื่อคุณยืนยัน เพื่อไม่ต้องประมวลผลซ้ำอีก

### งานด้านความปลอดภัยทำให้เสร็จได้จริงไหม

ได้ SDH ปิดให้จบได้: ข้อตรวจพบที่พิสูจน์แล้วว่าปิดได้จะปิดออกจากห่วงโซ่ เวิร์กโฟลว์จึงมีจุดสิ้นสุด ไม่ใช่วนซ้ำไม่รู้จบ

---

# หมวดหมู่

> หมวดหมู่ความรู้เฉพาะทางที่โปรเจกต์ Lagune ใช้ได้ ตั้งแต่ OWASP ไปจนถึงการเสริมความปลอดภัยรายภาษาสำหรับ JavaScript, Python, Go และ Rust พร้อมวิธีเปลี่ยนหมวดหมู่

Canonical: https://lagune.ai/th-TH/docs/categories
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/categories
อัปเดตล่าสุด: 2026-11-07

**Lagune** จัด [**ความรู้เฉพาะทาง**](https://lagune.ai/th-TH/docs/catalog) ในตัวเป็น **13 หมวดหมู่** หมวดหมู่ที่โปรเจกต์ใช้เป็นตัวกำหนดว่าความรู้เฉพาะทางในตัวตัวใดจะเข้าสู่ [**แคตตาล็อก**](https://lagune.ai/th-TH/docs/catalog) ของโปรเจกต์ และแบ่งออกเป็น 2 กลุ่ม: สิ่งที่ระบบทำ และภาษาที่ใช้เขียนระบบ

ระหว่างที่ยังไม่มีหมวดหมู่ใดถูกบันทึก โปรเจกต์จะใช้ `owasp` อย่างเดียว คำสั่ง [`/lagune-charter`](https://lagune.ai/th-TH/docs/commands/charter) บันทึกทุกหมวดหมู่ที่ผลการอ่านโปรเจกต์รองรับ และคุณเปลี่ยนหมวดหมู่เองได้ทุกเมื่อ

## สิ่งที่ระบบทำ

| หมวดหมู่         | คีย์      | สิ่งที่เสริมความปลอดภัย                                                                                                                                               |
| ---------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| OWASP            | `owasp`   | ความเสี่ยงด้านความปลอดภัยของแอปพลิเคชันที่ OWASP ติดตาม: injection การควบคุมการเข้าถึงที่บกพร่อง (Broken Access Control) การยืนยันตัวตน และความล้มเหลวด้านการเข้ารหัส |
| โครงสร้างพื้นฐาน | `infra`   | การตั้งค่า container, workload และ serverless: Dockerfile, Compose, ความปลอดภัยของ Pod รวมถึง IAM และ trigger ของ FaaS                                                |
| AI / LLM         | `ai`      | การเชื่อมต่อกับ AI และ LLM เพื่อป้องกัน prompt injection และการเชื่อม tool เอเจนต์ ระบบ retrieval และ MCP อย่างไม่ปลอดภัย                                             |
| Lovable          | `lovable` | แอป Supabase ที่ AI สร้างขึ้น (Lovable และเครื่องมือที่คล้ายกัน): ช่องโหว่ของ RLS คีย์ `service_role` ที่รั่วไหล และค่าเริ่มต้นที่ไม่ปลอดภัย                          |

## ภาษาที่ใช้เขียน

| หมวดหมู่   | คีย์         | สิ่งที่เสริมความปลอดภัย                                                                                          |
| ---------- | ------------ | ---------------------------------------------------------------------------------------------------------------- |
| JavaScript | `javascript` | RCE ผ่าน `eval` และ `child_process`, path traversal และ prototype pollution ในทุก runtime                        |
| Python     | `python`     | RCE จาก deserialization ของ `pickle` และ YAML, string traversal ผ่าน `str.format` และ class pollution            |
| Rust       | `rust`       | API `unsafe` ที่ไม่ sound การใช้ `transmute` ผิดวิธี integer overflow และ undefined behavior ที่รอยต่อ FFI       |
| C / C++    | `c-cpp`      | บั๊ก format string, buffer overflow และการเขียนนอกขอบเขตหน่วยความจำที่เปิดทางให้รันโค้ดได้                       |
| PHP        | `php`        | การข้ามการยืนยันตัวตนด้วย type juggling, gadget chain ของ object injection และค่าเริ่มต้นการตั้งค่าที่ไม่ปลอดภัย |
| Go         | `go`         | บั๊ก interface แบบ typed-nil, data races ระหว่าง goroutine และ concurrency ที่ไม่ปลอดภัยบนเส้นทางด้านความปลอดภัย |
| Java       | `java`       | gadget chain จาก deserialization ของ `ObjectInputStream` ที่จบลงด้วยการรันโค้ดจากระยะไกล                         |
| Ruby       | `ruby`       | gadget chain จาก deserialization ของ `Marshal.load` และ YAML ที่นำไปสู่การรันโค้ดจากระยะไกล                      |
| .NET / C#  | `dotnet`     | RCE จาก deserialization ของ `BinaryFormatter` และการเลี่ยง encoder ที่นำไปสู่ XSS                                |

**เคล็ดลับ**

**Lagune** ไม่ผูกกับภาษาโปรแกรมใด: ทั้งเวิร์กโฟลว์อ่านโปรเจกต์ของคุณได้ไม่ว่าจะเขียนด้วยภาษาอะไร และหมวดหมู่เหล่านี้เพียงเพิ่มความลึกในจุดอ่อนที่เฉพาะกับแต่ละภาษา

## เพิ่มและลบได้ทุกเมื่อ

หมวดหมู่เป็นจุดเริ่มต้น ไม่ใช่ข้อผูกมัด ใช้หมวดหมู่ที่เหมาะกับโปรเจกต์ในตอนนี้ และเปลี่ยนได้ทุกเมื่อตามคีย์ด้วย `write add` และ `write remove` ในเทอร์มินัล `--categories` ที่ไม่ระบุค่าจะเปิดตัวเลือกแบบโต้ตอบ (กด space เพื่อเลือกหรือยกเลิก กด enter เพื่อยืนยัน หรือเว้นว่างไว้เพื่อข้าม) นอกเทอร์มินัล ให้ระบุหมวดหมู่ต่อท้ายตัวเลือกนั้น

**เพิ่ม**

```bash
npx lagune write add --categories # interactive
npx lagune write add --categories owasp
npx lagune write add --categories owasp rust
```

**ลบ**

```bash
npx lagune write remove --categories # interactive
npx lagune write remove --categories owasp
npx lagune write remove --categories owasp rust
```

`write add` หรือ `write remove` ครั้งแรกจะเริ่มจาก `owasp` ดังนั้นการลบทุกหมวดหมู่จะได้รายการว่าง ไม่ใช่กลับไปเป็นค่าเริ่มต้น ทุกการเปลี่ยนแปลงจะบันทึกลงใน `.lagune/configs.json` ทั้งทีมจึงทำงานกับชุดเดียวกัน

## ดูว่าโปรเจกต์ใช้หมวดหมู่ใด

`read list --categories` แสดงทุกหมวดหมู่และบอกว่าโปรเจกต์ใช้หมวดหมู่นั้นหรือไม่:

```bash
npx lagune read list --categories
# Categories
#   • owasp       [used]       Harden against the application security risks OWASP tracks
#   • javascript  [available]  Harden JavaScript and its runtimes
#   • php         [available]  Harden PHP against type-juggling auth bypass
#   • go          [available]  Harden Go against typed-nil interface bugs
#   ...
#
# No category is recorded yet, so this project uses the default: owasp.
```

ดู [**แคตตาล็อก**](https://lagune.ai/th-TH/docs/catalog) ว่าแต่ละหมวดหมู่มีความรู้เฉพาะทางอะไรบ้าง ความรู้เฉพาะทางของคุณเองที่เขียนด้วย [`/lagune-specialize`](https://lagune.ai/th-TH/docs/commands/specialize) จะเข้าสู่แคตตาล็อกเสมอไม่ว่าหมวดหมู่จะเป็นอะไร

## คำถามที่พบบ่อย

### เพิ่มหมวดหมู่อย่างไร

ส่งคีย์ของหมวดหมู่ให้ --categories เช่น npx lagune write add --categories javascript ระหว่างที่ยังไม่มีหมวดหมู่ใดถูกบันทึก charter ก็บันทึกหมวดหมู่ที่ผลการอ่านโปรเจกต์รองรับด้วย

### ใช้หลายหมวดหมู่พร้อมกันได้ไหม

ได้ ระบุหมวดหมู่ทั้งหมดต่อกันในบรรทัดเดียว

### โปรเจกต์ควรใช้หมวดหมู่ใด

เริ่มจาก owasp ซึ่งเป็นค่าเริ่มต้น แล้วเพิ่มหมวดหมู่ของภาษาหรือ stack ที่คุณใช้ ความรู้เฉพาะทางโหลดเฉพาะเมื่อจำเป็น หมวดหมู่จึงไม่มีต้นทุนใด ๆ จนกว่าเฟสหนึ่งจะต้องใช้ความรู้เฉพาะทางของหมวดหมู่นั้น

---

# แคตตาล็อก: ความรู้เฉพาะทางด้านความปลอดภัยที่โหลดเฉพาะเมื่อจำเป็น

> วิธีที่ความรู้เฉพาะทางในแคตตาล็อกของโปรเจกต์ถูกโหลด ทั้งโดยเฟสต่าง ๆ เฉพาะเมื่อจำเป็น และโดยคุณเองโดยตรง

Canonical: https://lagune.ai/th-TH/docs/catalog
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/catalog
อัปเดตล่าสุด: 2026-11-07

🧠 ความรู้เฉพาะทางของ **Lagune** คือโมดูลความรู้ด้านความปลอดภัยที่เจาะจงเป็นเรื่อง ๆ และไม่ผูกกับภาษาโปรแกรมใด โหลดเฉพาะเมื่อจำเป็นและไม่เคยโหลดเป็นค่าเริ่มต้น ความรู้เฉพาะทางไม่ใช่คำสั่ง แคตตาล็อกของโปรเจกต์คือชุดความรู้เฉพาะทางที่โปรเจกต์ใช้: ความรู้เฉพาะทางในตัวของ [หมวดหมู่](https://lagune.ai/th-TH/docs/categories) ของโปรเจกต์ รวมกับความรู้เฉพาะทางของโปรเจกต์เอง เฟส detect และ verify หยิบมาใช้ระหว่างที่รัน และคุณโหลดตัวใดก็ได้โดยตรงทุกเมื่อ

**ภาพรวม**

*ภาพรวมแคตตาล็อกแบบโต้ตอบได้อยู่ในหน้าเว็บ ความรู้เฉพาะทางในตัวทั้งหมดอยู่ในตารางด้านล่าง*

**หลักการทำงาน**

## ใช้งานด้วยตัวเอง

หากต้องการใช้ความรู้เฉพาะทางโดยตรง ให้สั่งเอเจนต์โหลดด้วย `read catalog <name>` และเขียนงานที่ต้องการไว้ใน prompt เดียวกัน ความรู้นั้นจะทำงานกับสิ่งที่คุณขอ วิธีนี้ใช้ได้กับทุก prompt แม้แต่ prompt ที่ไม่เกี่ยวกับขั้นตอนของ **Lagune**

ตัวอย่างเช่น prompt อิสระที่สั่งตรง ๆ ให้สร้างชุด **RegExp** ที่ปลอดภัยด้วย **Python**:

```prompt
โหลดความรู้เฉพาะทาง regex ด้วย `npx lagune read catalog regex` แล้วสร้างชุด regular expression ใน @src/utils/regex.py สำหรับตรวจสอบอีเมลและชื่อผู้ใช้
```

prompt นี้ใช้ hook แบบ deterministic ทดสอบ **RegExp** แต่ละตัวว่าเสี่ยงต่อ **ReDoS** หรือไม่ เก็บเฉพาะตัวที่ปลอดภัย และได้ผลลัพธ์ประมาณนี้:

```python
import re

EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")
USERNAME = re.compile(r"^[a-zA-Z0-9_]{3,20}$")

def is_email(value: str) -> bool:
    return EMAIL.match(value) is not None

def is_username(value: str) -> bool:
    return USERNAME.match(value) is not None
```

**ลองใช้ตัวตรวจ ReDoS**

ทดสอบรูปแบบด้วยตัวเองได้ที่ [**devina.io/redos-checker**](https://devina.io/redos-checker)

## ความรู้เฉพาะทางในตัว

ความรู้เฉพาะทางในตัวจัดกลุ่มเป็น [**หมวดหมู่**](https://lagune.ai/th-TH/docs/categories) และนี่คือชุดที่มาพร้อมกับ **Lagune**:

| ความรู้เฉพาะทาง       | หมวดหมู่                    | จุดเน้น                                                                                              |
| --------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------- |
| `regex`               | `owasp`                     | **ReDoS:** รูปแบบที่ทำงานช้าแบบทวีคูณเมื่อเจออินพุตที่จงใจสร้างขึ้น                                  |
| `network`             | `owasp`                     | **SSRF และ redirect:** ปลายทางของการ fetch หรือ redirect ที่ผู้ใช้กำหนด                              |
| `interpreter`         | `owasp`, `lovable`          | **Code injection:** `eval`, include แบบไดนามิก และการเรียกฟังก์ชันตามชื่อ                            |
| `sql`                 | `owasp`                     | **ฐานข้อมูลเชิงสัมพันธ์:** injection การเรียก ORM แบบ raw สิทธิ์ และสิ่งที่เอนจินฐานข้อมูลเข้าถึงได้ |
| `path`                | `owasp`                     | **path ในระบบไฟล์:** traversal, null-byte, NTFS stream และการฝังไฟล์                                 |
| `upload`              | `owasp`                     | **การอัปโหลดไฟล์:** ชนิดและ signature ของไฟล์ เนื้อหาอันตราย การจัดเก็บ และขีดจำกัด                  |
| `access-control`      | `owasp`, `lovable`          | **การยืนยันตัวตน การตรวจสอบสิทธิ์ และเซสชัน:** IDOR, mass assignment, tenant และเซสชัน               |
| `credential-endpoint` | `owasp`, `lovable`          | **การเดารหัสผ่านและบอต:** brute force, spraying, stuffing และ throttling                             |
| `federation`          | `owasp`                     | **ความน่าเชื่อถือของโทเค็น:** OAuth, OIDC, SAML, การตรวจสอบ JWT และการล็อกอินด้วย QR                 |
| `http-request`        | `owasp`                     | **ที่มาของ request:** CSRF, การตั้งค่า CORS ผิดพลาด และ IP ของไคลเอนต์ที่ถูกปลอม                     |
| `transport`           | `owasp`                     | **ความปลอดภัยของช่องทางสื่อสาร:** การตั้งค่า TLS การใช้ HTTPS แทนข้อความธรรมดา HSTS และ pinning      |
| `crypto`              | `owasp`, `lovable`          | **การเข้ารหัสข้อมูลที่จัดเก็บ:** อัลกอริทึมที่อ่อนหรือคิดขึ้นเอง CSPRNG และการจัดการคีย์             |
| `secrets`             | `owasp`, `lovable`          | **ข้อมูลรับรองที่ฮาร์ดโค้ด:** คีย์ โทเค็น และรหัสผ่านที่เขียนตรง ๆ ในซอร์สโค้ด                       |
| `api-endpoint`        | `owasp`                     | **พื้นผิวที่ไม่ใช่ REST:** GraphQL, gRPC, การตรวจสอบสิทธิ์ของ WebSocket, DoS และ schema              |
| `payment`             | `owasp`, `lovable`          | **ขั้นตอน checkout:** ตรวจสอบกับ gateway ฝั่งเซิร์ฟเวอร์ callback ที่มีลายเซ็น และ idempotency       |
| `xml`                 | `owasp`                     | **การ parse XML:** XXE, external entity และการขยายแบบ billion laughs                                 |
| `csv`                 | `owasp`                     | **Formula injection:** เซลล์ในสเปรดชีตที่ขึ้นต้นด้วย `=`/`+`/`-`/`@`                                 |
| `container`           | `owasp`, `infra`            | **การตั้งค่า container:** การรันเป็น root, capabilities, การ mount socket และ hardening ของ image    |
| `infra`               | `infra`                     | **Infrastructure as code:** Terraform, Dockerfile และ GitHub Actions                                 |
| `serverless`          | `owasp`, `infra`, `lovable` | **ฟังก์ชัน FaaS:** IAM แบบสิทธิ์น้อยที่สุด อินพุตจาก event บริบท และ secret                          |
| `llm`                 | `ai`, `lovable`             | **ความเสี่ยงของ AI และ LLM:** prompt injection, agency, RAG, MCP และเอาต์พุต                         |
| `supabase`            | `lovable`                   | **แบ็กเอนด์ Supabase:** RLS ที่ปิดไว้เป็นค่าเริ่มต้น policy ที่ AI สร้างผิด และโมเดลของคีย์          |
| `browser`             | `javascript`, `lovable`     | **ความเสี่ยงฝั่งไคลเอนต์:** XSS, CSP, framing, storage และอื่น ๆ                                     |
| `javascript`          | `javascript`                | **ความเสี่ยงระดับภาษา:** RCE, prototype pollution และอื่น ๆ                                          |
| `python`              | `python`                    | **ความเสี่ยงระดับภาษา:** RCE ผ่าน `pickle`, class pollution, `-O` และอื่น ๆ                          |
| `rust`                | `rust`                      | **ความถูกต้องของ `unsafe`:** UB ที่เกิดจากโค้ดเรียกแบบ safe, `transmute` และ overflow                |
| `java`                | `java`                      | **Deserialization และ mobile code:** chain ของ `readObject` และการยึดอ็อบเจกต์                       |
| `ruby`                | `ruby`                      | **Deserialization และ `open`:** การฟื้นอ็อบเจกต์ผ่าน `Marshal`/YAML และพฤติกรรมแปลกของ pipe          |
| `php`                 | `php`                       | **Type juggling และ `unserialize`:** magic hash และ POP chain                                        |
| `go`                  | `go`                        | **Typed-nil และ data races:** `nil != nil` และ goroutine ที่ใช้หน่วยความจำร่วมกัน                    |
| `c-cpp`               | `c-cpp`                     | **Format string:** `printf(user_input)` และการเขียนแบบ write-what-where ผ่าน `%n`                    |
| `dotnet`              | `dotnet`                    | **ความเสี่ยงระดับแพลตฟอร์ม:** RCE ผ่าน `BinaryFormatter`, `@Html.Raw` และช่องโหว่จาก enum            |

ความรู้ในตัวส่วนใหญ่กลั่นกรองมาจาก OWASP ดู [**แหล่งข้อมูล OWASP**](https://lagune.ai/th-TH/docs/references/owasp-sources) สำหรับการจับคู่ความรู้เฉพาะทางแต่ละตัวกับหน้าการโจมตีและ Cheat Sheet ต้นฉบับของ OWASP อย่างครบถ้วน มีโมดูลเฉพาะ stack ไม่กี่ตัวที่อิงแนวทางของผู้ให้บริการเองแทน เช่น `supabase` มาจากเอกสารของ Supabase และ CVE-2025-48757

## ความรู้เฉพาะทางของคุณเอง

ความรู้เฉพาะทางในตัวเพิ่มขึ้นด้วยไฟล์ความรู้ 1 ไฟล์และแถวในดัชนี 1 แถว ไม่เคยเพิ่มเป็นคำสั่งใหม่ คุณเพิ่มของคุณเองได้ด้วยวิธีเดียวกันผ่านคำสั่ง [`/lagune-specialize`](https://lagune.ai/th-TH/docs/commands/specialize): ชี้ไปที่บทความหรือหัวข้อ แล้วคำสั่งจะกลั่นกรองเป็นความรู้เฉพาะทางใหม่ลงในโปรเจกต์ของคุณ ได้แก่ไฟล์ใน `.lagune/catalog/` และรายการของไฟล์นั้นใน `.lagune/configs.json` ความรู้เฉพาะทางของคุณเองอยู่ในแคตตาล็อกเสมอไม่ว่าหมวดหมู่จะเป็นอะไร และหากตัวใดชื่อเดียวกับความรู้เฉพาะทางในตัว ตัวของคุณจะแทนที่ความรู้เฉพาะทางในตัวนั้น

**ภายใน Lagune โหลดความรู้เฉพาะทางให้อัตโนมัติเฉพาะเมื่อจำเป็น**

เมื่อเฟส detect หรือ verify เจอบริบทที่ความรู้เฉพาะทางตัวหนึ่งครอบคลุม เฟสนั้นจะโหลดความรู้เฉพาะทางตัวนั้นเองด้วย `read catalog <name>` ซึ่งเกิดขึ้นอัตโนมัติเป็นส่วนหนึ่งของเฟส คุณไม่ต้องทำเองเพื่อให้ทำงาน

## ดูว่ามีอะไรให้ใช้บ้าง

หากต้องการแสดงแคตตาล็อกของโปรเจกต์จากเทอร์มินัล โดยแสดงความรู้เฉพาะทางบรรทัดละตัวพร้อม tag:

```bash
npx lagune read catalog
# regex: Regular Expression [required]
# network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect
# interpreter: Evaluator, Sink, Shell, Dynamic Execution
# ...
```

ความรู้เฉพาะทางที่มี `[required]` ใช้เสมอไม่ว่างานจะเป็นอะไร ส่วนความรู้เฉพาะทางในตัวที่อยู่ในรายการขึ้นอยู่กับ [**หมวดหมู่**](https://lagune.ai/th-TH/docs/categories) ของโปรเจกต์

**ความรู้เฉพาะทางไม่ถูกโหลดเป็นค่าเริ่มต้น**

ความรู้ที่เกี่ยวข้องจะถูกดึงมาใช้ตามสิ่งที่โปรเจกต์เป็นจริง ๆ แทนที่จะรันการตรวจทุกอย่างเป็นค่าเริ่มต้น

## คำถามที่พบบ่อย

### ความรู้เฉพาะทางของ Lagune คืออะไร

โมดูลความรู้ด้านความปลอดภัยที่เจาะจงเป็นเรื่อง ๆ และไม่ผูกกับภาษาโปรแกรมใด โหลดเฉพาะเมื่อจำเป็นและไม่เคยโหลดเป็นค่าเริ่มต้น ความรู้เฉพาะทางไม่ใช่คำสั่งแบบ skill ของเอเจนต์

### แคตตาล็อกของโปรเจกต์คืออะไร

ชุดความรู้เฉพาะทางที่โปรเจกต์ใช้: ความรู้เฉพาะทางในตัวของหมวดหมู่ของโปรเจกต์ รวมกับความรู้เฉพาะทางของโปรเจกต์เอง ระหว่างที่ยังไม่มีหมวดหมู่ใดถูกบันทึก โปรเจกต์จะใช้ OWASP อย่างเดียว

### ความรู้เฉพาะทางถูกโหลดเป็นค่าเริ่มต้นไหม

ไม่ ความรู้เฉพาะทางโหลดเฉพาะเมื่อจำเป็น ตามสิ่งที่โปรเจกต์เป็นจริง ๆ

### โหลดความรู้เฉพาะทางโดยตรงได้อย่างไร

ใน prompt เดียวกับงานที่ต้องการ ให้สั่งเอเจนต์รัน npx lagune read catalog <name>

---

# /lagune-specialize: สร้างความรู้เฉพาะทางด้านความปลอดภัยด้วยข้อความธรรมดา

> กลั่นกรองแหล่งข้อมูลหรือหัวข้อด้านความปลอดภัยที่คุณให้มา ให้เป็นความรู้เฉพาะทางใหม่ที่โหลดเฉพาะเมื่อจำเป็น

Canonical: https://lagune.ai/th-TH/docs/commands/specialize
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/specialize
อัปเดตล่าสุด: 2026-11-07

🎓 สอนความรู้เฉพาะทางใหม่ให้ **Lagune** จากแหล่งข้อมูลหรือหัวข้อที่คุณให้มา

คำสั่งนี้อ่านเนื้อหาแล้วกลั่นกรองให้เป็นความรู้เฉพาะทางที่เจาะจงและใช้เพื่อการป้องกันเท่านั้น โดยมีรูปแบบเหมือน [ความรู้เฉพาะทางในตัว](https://lagune.ai/th-TH/docs/catalog) ทุกประการ เฟส detect และ verify จึงโหลดไปใช้ได้เหมือนรายการอื่น ๆ คำสั่งนี้ทำได้แค่ตรวจสอบและอธิบาย: ไม่เขียนอินพุตสำหรับโจมตีหรือ exploit และไม่แตะต้องโค้ดของคุณ

**จากบทความ**

```prompt
# ลิงก์หรือแหล่งอ้างอิง: Lagune กลั่นกรองให้เป็นการป้องกัน
/lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection
```

**จาก exploit**

```prompt
# ใช้การโจมตีเป็นแหล่งข้อมูล: ความรู้เฉพาะทางที่ได้ยังเป็นการป้องกัน
/lagune-specialize "' OR 1=1 -- แทรก SQL เข้าไปในข้อความของ query"
```

**จากหัวข้อ**

```prompt
# หรือแค่บอกว่าต้องการให้ครอบคลุมเรื่องอะไร
/lagune-specialize SQL injection
```

**การโจมตีเป็นแหล่งข้อมูลได้ แต่ไม่มีวันเป็นผลลัพธ์**

ชี้คำสั่งนี้ไปที่การโจมตีได้ถ้าเป้าหมายคือป้องกันการโจมตีนั้น: บทความที่อธิบาย exploit เป็นเนื้อหาให้ศึกษา ซึ่งคำสั่งนี้กลั่นกรองให้เป็นการป้องกัน ความรู้เฉพาะทางที่ได้จะตรวจสอบและอธิบายเสมอ และไม่สร้าง exploit ที่ใช้งานได้จริง payload หรือวิธีหลบเลี่ยงการตรวจจับ

## สิ่งที่คำสั่งนี้เขียน

ผลลัพธ์คือไฟล์ 2 ไฟล์ในโปรเจกต์ของคุณ ซึ่ง commit และตรวจทานไปพร้อมกับโค้ดของคุณได้:

- ความรู้เฉพาะทางที่ `.lagune/catalog/<name>.md` ซึ่งมีรูปแบบเหมือน [ความรู้เฉพาะทางในตัว](https://lagune.ai/th-TH/docs/catalog)
- รายการของความรู้นั้นใน `.lagune/configs.json` ซึ่งเป็นที่ที่โปรเจกต์ของคุณทำดัชนีความรู้เฉพาะทางของตัวเอง เพื่อให้แคตตาล็อกรวมเข้ากับรายการในตัว

จากนั้นคำสั่งนี้จะแสดงแคตตาล็อกเพื่อยืนยันว่ามีรายการใหม่อยู่แล้ว ความรู้เฉพาะทางของคุณเองอยู่ในแคตตาล็อกเสมอ ไม่ว่าแคตตาล็อกจะมีหมวดหมู่ใด คุณไม่ต้องเพิ่มคำสั่งหรือแตะต้องแพ็กเกจ: ความรู้เฉพาะทางใหม่คือไฟล์ความรู้หนึ่งไฟล์กับรายการดัชนีหนึ่งรายการ ซึ่งเขียนลงในโปรเจกต์ของคุณเอง

## ปรับปรุง ไม่ใช่เขียนทับ

การสร้างความรู้เฉพาะทางด้วยชื่อที่มีอยู่แล้ว ไม่ว่าจะเป็นรายการในตัวอย่าง `regex` หรือรายการที่คุณเคยสร้างไว้ จะ **ปรับไฟล์เดิมให้ตรงกับสภาพปัจจุบัน** แทนการแทนที่ไฟล์ คำสั่งนี้อ่านสิ่งที่มีอยู่ ผสานความรู้ใหม่เข้าไป เก็บส่วนที่ยังใช้ได้ และเขียนส่วนที่เปลี่ยนไปใหม่ คำสั่งนี้ไม่ทิ้งอะไรโดยไม่ได้อ่านก่อน ความรู้เฉพาะทางของคุณจะแทนที่รายการในตัวที่ชื่อเดียวกัน คุณจึงปรับรายการในตัวให้คมขึ้นสำหรับโปรเจกต์ของคุณเองได้โดยไม่สูญเสียรายการนั้น

**เคล็ดลับ**

- ความรู้เฉพาะทางใหม่โหลดเหมือนรายการในตัวทุกประการ: เฟส detect และ verify หยิบไปใช้เฉพาะเมื่อจำเป็น หรือคุณโหลดเองด้วย `npx lagune read catalog <name>` แล้วมอบงานให้
- เมื่อเนื้อหามีที่มาที่ระบุได้ (บทความ ผู้เขียน ลิงก์ หรือมาตรฐาน) ความรู้เฉพาะทางจะให้เครดิตที่มานั้น ส่วนหัวข้อเปล่า ๆ จะไม่มีแหล่งที่มา

**หมายเหตุ**

**คำสั่งนี้รันเฉพาะเมื่อคุณเรียกใช้เท่านั้น:** เอเจนต์ไม่เริ่มรันเอง

## คำถามที่พบบ่อย

### เพิ่มความรู้เฉพาะทางด้านความปลอดภัยของตัวเองได้อย่างไร

รัน /lagune-specialize พร้อมแหล่งข้อมูลหรือหัวข้อ คำสั่งนี้จะกลั่นกรองให้เป็นความรู้เฉพาะทางเพื่อการป้องกันเท่านั้น เขียนลงใน .lagune/catalog/<name>.md พร้อมรายการใน .lagune/configs.json

### Lagune เรียนรู้จากบทความที่อธิบาย exploit ได้ไหม

ได้ ในฐานะแหล่งข้อมูล แต่ไม่มีวันเป็นผลลัพธ์ การโจมตีเป็นแหล่งข้อมูลได้ แต่ไม่มีวันเป็นสิ่งที่สร้างออกมา specialize ไม่เขียนอินพุตสำหรับโจมตีหรือ exploit

### specialize เขียนทับความรู้เฉพาะทางในตัวไหม

ไม่ คำสั่งนี้ปรับปรุง ไม่ใช่เขียนทับ

---

# /lagune-prove: proof of concept เพื่อการป้องกันเท่านั้น

> เปลี่ยนข้อตรวจพบแต่ละรายการให้เป็น proof of concept (PoC) ที่รันได้และใช้เพื่อการป้องกันเท่านั้น พร้อมประกาศแจ้งเตือนด้านความปลอดภัยสำหรับการเปิดเผยช่องโหว่อย่างรับผิดชอบ

Canonical: https://lagune.ai/th-TH/docs/commands/prove
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/prove
อัปเดตล่าสุด: 2026-11-07

🧪 เปลี่ยนข้อตรวจพบแต่ละรายการให้เป็นหลักฐานที่รันได้และใช้เพื่อการป้องกันเท่านั้น สำหรับการเปิดเผยช่องโหว่อย่างรับผิดชอบ

สำหรับข้อตรวจพบทุกรายการในแผนผังจาก detect คำสั่งนี้จะเขียนประกาศแจ้งเตือนด้านความปลอดภัยที่อ่านจบในตัว และการทดสอบที่ยืนยัน **เส้นทางที่ปลอดภัย** การทดสอบจึงล้มเหลวตราบที่ปัญหายังอยู่ และผ่านเมื่อแก้โค้ดแล้ว

**เคล็ดลับ**

การทดสอบของ **Lagune** แยกอยู่ใน `.lagune/` ต่างหากจากชุดการทดสอบของคุณเอง

## วิธีใช้

**ข้อตรวจพบทุกรายการ**

```prompt
/lagune-prove
```

**ข้อตรวจพบที่ระบุชื่อ**

ดูชื่อข้อตรวจพบที่ติดตามอยู่แล้ว:

```prompt
npx lagune read list --findings

# Findings
#   ...
#   • SQL injection ในการค้นหาผู้ใช้
#   ...
```

```prompt
# จากนั้นพิสูจน์หนึ่งในนั้น
/lagune-prove SQL injection ในการค้นหาผู้ใช้
```

## หลักการทำงาน

คำสั่งนี้อ่านซอร์สโค้ดที่ข้อตรวจพบแต่ละรายการชี้ไป แล้วเขียนไดเรกทอรีหนึ่งไดเรกทอรีต่อข้อตรวจพบที่พิสูจน์ได้ไว้ใต้ `.lagune/proofs/` โดยแต่ละไดเรกทอรีมีไฟล์ 2 ไฟล์พอดี:

| ไฟล์                            | คืออะไร                                                                                                                       |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `report.test.mjs` (หรือ `.cjs`) | ตัวการทดสอบ รันบน Poku ถ้าโปรเจกต์ของคุณใช้อยู่แล้ว ถ้าไม่ใช้ก็รันบนตัวรันการทดสอบที่มากับ Node.js จึงไม่ต้องติดตั้งอะไรเพิ่ม |
| `report.md`                     | ประกาศแจ้งเตือนด้านความปลอดภัยที่อ่านจบในตัว: ระดับความรุนแรง ผลกระทบ วิธีทำให้ปัญหาเกิดซ้ำ และคำสั่งสำหรับรัน                |

การพิสูจน์เขียนด้วย JavaScript เสมอ จึงนำไปใช้ได้ทุกที่ไม่ว่าโปรเจกต์ของคุณจะเขียนด้วยภาษาใด ไฟล์ดัชนี `README.md` ลิงก์ไปยังการพิสูจน์ทุกรายการ และให้คำสั่งเดียวสำหรับรันทั้งหมด

**เคล็ดลับ**

- คำสั่งนี้ **ไม่บังคับและทำงานแยกเป็นอิสระ**: ไม่ได้เป็นหนึ่งใน 5 เฟส และไม่ได้เป็นส่วนหนึ่งของห่วงโซ่การติดตาม
- คำสั่งนี้เขียนลงใน `.lagune/proofs/` เท่านั้น และไม่แตะต้องอาร์ติแฟกต์ของเฟสหรือโค้ดของคุณ ซึ่งคำสั่งนี้อ่านอย่างเดียว
- ข้อตรวจพบที่การทดสอบทำให้ปัญหาเกิดซ้ำไม่ได้จะไม่ได้รับการพิสูจน์ และคำสั่งนี้จะบอกให้คุณรัน [`/lagune-detect`](https://lagune.ai/th-TH/docs/commands/detect) กับจุดนั้นเพื่อปรับให้ตรงกับสภาพปัจจุบัน
- รันซ้ำเพื่อปรับการพิสูจน์ให้ตรงกับสภาพปัจจุบัน: คำสั่งนี้จะลบไดเรกทอรีของข้อตรวจพบที่หายไปแล้วหรือทำให้เกิดซ้ำไม่ได้อีก

**หมายเหตุ**

**คำสั่งนี้รันเฉพาะเมื่อคุณเรียกใช้เท่านั้น:** เอเจนต์ไม่เริ่มรันเอง

**ต้องรัน detect ก่อน**

prove อ่านแผนผังจาก [`/lagune-detect`](https://lagune.ai/th-TH/docs/commands/detect) จึงต้องรัน detect ก่อน

## เพื่อการป้องกันเท่านั้น และต้องได้รับอนุญาต

ก่อนสร้างอะไรก็ตาม คำสั่งนี้จะยืนยันว่าคุณได้รับอนุญาตให้ทดสอบเป้าหมายนั้น และปฏิเสธทุกคำขอที่ต้องการ exploit ที่ใช้งานได้จริง payload สำหรับโจมตี หรือการหลบเลี่ยงการตรวจจับ การพิสูจน์แสดงพฤติกรรมที่ปลอดภัย และไม่สร้างอินพุตสำหรับโจมตีเลย

## จากการพิสูจน์สู่การเปิดเผยช่องโหว่

ไฟล์ทั้ง 2 ไฟล์ของข้อตรวจพบที่พิสูจน์ได้แต่ละรายการควรอยู่ด้วยกันใน **GitHub Gist แบบส่วนตัว** เพื่อรายงานช่องโหว่ ไฟล์เหล่านี้เป็นหลักฐานของปัญหาที่ยังมีอยู่และยังไม่เปิดเผย `.gitignore` ใน `.lagune/proofs/` จึงกันไฟล์เหล่านี้ไว้นอกทุก commit: แชร์ผ่าน Gist นั้นเท่านั้นจนกว่าผู้ดูแลจะแก้ปัญหาเสร็จ

การปิดข้อตรวจพบในห่วงโซ่ของ **Lagune** ยังเป็นหน้าที่ของ [`/lagune-harden`](https://lagune.ai/th-TH/docs/commands/harden) และ [`/lagune-verify`](https://lagune.ai/th-TH/docs/commands/verify): prove สร้างหลักฐาน แต่ไม่ได้ปิดอะไร

## คำถามที่พบบ่อย

### Lagune สร้าง exploit ไหม

ไม่ /lagune-prove เขียนหลักฐานเพื่อการป้องกันเท่านั้น: การทดสอบที่ยืนยันเส้นทางที่ปลอดภัย ซึ่งล้มเหลวตราบที่ปัญหายังอยู่และผ่านเมื่อแก้โค้ดแล้ว พร้อมประกาศแจ้งเตือนด้านความปลอดภัยสำหรับการเปิดเผยช่องโหว่อย่างรับผิดชอบ

### prove สร้างอะไรออกมา

ไฟล์ 2 ไฟล์ต่อข้อตรวจพบหนึ่งรายการ: การทดสอบ (report.test.mjs หรือ .cjs) และประกาศแจ้งเตือนด้านความปลอดภัย (report.md)

### จะเปิดเผยบั๊กที่ Lagune พบอย่างรับผิดชอบได้อย่างไร

prove เขียนประกาศแจ้งเตือนด้านความปลอดภัยที่อ่านจบในตัว ซึ่งคุณแชร์ผ่านช่องทางส่วนตัวได้ เช่น GitHub Gist แบบส่วนตัว ตามแนวทางการเปิดเผยช่องโหว่อย่างรับผิดชอบ

---

# กำหนดค่า hook: เลือกสิ่งที่จะสแกน

> เลือกว่า hook ที่สแกนไฟล์จะข้ามอะไรบ้าง ใช้กับทุก hook หรือเฉพาะ hook เดียวก็ได้

Canonical: https://lagune.ai/th-TH/docs/hooks/configure
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/configure
อัปเดตล่าสุด: 2026-11-07

บล็อก `checkers` ใน `.lagune/configs.json` กำหนดว่า hook ที่สแกนไฟล์จะข้ามอะไรบ้าง ใช้กับทุก hook หรือเฉพาะ hook เดียวก็ได้

## วิธีกำหนดค่า

เพิ่มหรือลบ path และรูปแบบได้จากบรรทัดคำสั่ง โดยครอบรูปแบบด้วยเครื่องหมายคำพูดเพื่อให้ shell คงรูปแบบนั้นไว้ตามที่เขียน:

```bash
npx lagune write add --ignore test/fixtures
npx lagune write add --ignore 'packages/*/dist' --checker secrets
npx lagune write remove --ignore test/fixtures
```

หรือเลือกได้ในหน้า Settings ของ [แดชบอร์ด](https://lagune.ai/th-TH/docs/get-started/dashboard) หรือกำหนดไว้ในไฟล์โดยตรง:

```json
{
  "checkers": {
    "ignore": ["test/fixtures"],
    "secrets": { "gitignore": false, "ignore": ["test/fixtures", "temp"] }
  }
}
```

### การตั้งค่า

| คีย์        | ค่า                                       | ค่าเริ่มต้น | คำอธิบาย                                                                                              |
| ----------- | ----------------------------------------- | ----------- | ----------------------------------------------------------------------------------------------------- |
| `gitignore` | `true` หรือ `false`                       | `true`      | ข้ามสิ่งที่ **Git** ละเว้นไว้ แต่ยังสแกนไฟล์ที่ **Git** ติดตามอยู่เสมอ                                |
| `ignore`    | path หรือรูปแบบที่นับจาก root ของโปรเจกต์ | `[]`        | ข้ามสิ่งที่ตรงกับแต่ละรายการและทุกอย่างที่อยู่ภายใต้รายการนั้น แม้เป็นไฟล์ที่ **Git** ติดตามอยู่ก็ตาม |

คีย์ที่ระดับบนสุดของ `checkers` ใช้กับทุกตัวตรวจ ส่วนคีย์ที่อยู่ใต้ชื่อตัวตรวจใดจะใช้กับตัวตรวจนั้นเท่านั้นและแทนที่คีย์ที่ใช้ร่วมกัน ในตัวอย่างนี้ `secrets` จึงสแกนสิ่งที่ **Git** ละเว้นไว้ และข้าม `test/fixtures` กับ `temp` เมื่อ `write add --ignore` สร้างรายการแรกให้ตัวตรวจใดเป็นของตัวเอง รายการนั้นจะเริ่มจากสำเนาของรายการที่ใช้ร่วมกัน

### รูปแบบ

รูปแบบเริ่มนับจาก root ของโปรเจกต์ ดังนั้น `*.generated.ts` จะครอบคลุมเฉพาะไฟล์ที่อยู่ตรงนั้น ส่วน `**/*.generated.ts` ครอบคลุมไฟล์เหล่านั้นในทุกระดับความลึก ชื่อต้องตรงกันทุกตัวอักษร รวมถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

| รูปแบบ              | สิ่งที่ข้าม                                   |
| ------------------- | --------------------------------------------- |
| `dist`              | `dist` ที่ root ของโปรเจกต์                   |
| `packages/*/dist`   | `dist` ในทุกโฟลเดอร์ภายใต้ `packages`         |
| `**/dist`           | `dist` ทุกตัวในทุกระดับความลึก                |
| `**/*.generated.ts` | ทุกไฟล์ที่ชื่อลงท้ายด้วย `.generated.ts`      |
| `fixture-?`         | `fixture-a`, `fixture-1` และชื่อทำนองเดียวกัน |
| `[ab]-cache`        | `a-cache` และ `b-cache`                       |
| `[*]x`              | `*x` โดยถือ `*` เป็นอักขระธรรมดา              |

## วิธีอ่านผลลัพธ์

ท้ายรายงานจะบอกจำนวน path ที่การสแกนข้ามไป แยกตามสิ่งที่ละเว้น path เหล่านั้น:

```text
Skipped 25 paths that Git ignores and 3 paths that .lagune/configs.json ignores. Name one with --dir or --file to scan it.
```

เอนจินจะสแกน path ที่ระบุด้วย `--dir` หรือ `--file` เสมอ ไม่ว่าการตั้งค่าจะเป็นอย่างไร ส่วนการตั้งค่าที่เอนจินอ่านไม่ได้จะทำให้ตัวตรวจหยุดพร้อม error ที่ระบุถึงการตั้งค่านั้น เช่น รูปแบบที่ขึ้นต้นด้วย `!` หรือช่องว่าง รูปแบบที่ชี้ออกไปนอกโปรเจกต์ รูปแบบที่เปิดวงเล็บเหลี่ยมค้างไว้ หรือรูปแบบที่ใช้เวลาจับคู่นานเกินไป

## คำถามที่พบบ่อย

### Lagune ตั้งค่าเหล่านี้ให้เองไหม

ไม่ เฟส charter จะแสดงรายการโฟลเดอร์ที่ commit ไว้ซึ่งผลการอ่านโปรเจกต์ชี้ว่าไม่ใช่โค้ดที่คุณต้องป้องกัน เช่น fixture สำหรับการทดสอบที่จงใจเขียนให้ดูมีช่องโหว่ แล้วบันทึกเฉพาะโฟลเดอร์ที่คุณเลือกตามหมายเลขเท่านั้น

### ตัวตรวจควรสแกนสิ่งที่ Git ละเว้นไว้เมื่อไร

เมื่อ repository นั้นไม่ใช่ของที่คุณไว้ใจได้ เพราะไฟล์ .gitignore ภายใน repository อาจซ่อนโค้ดไว้ หรือเมื่อโฟลเดอร์ build อาจมีคีย์ที่ฝังเข้าไปตอน build ตั้ง gitignore เป็น false ได้ทั้งกับทุก checker หรือเฉพาะ checker เดียว

---

# Hook agent: ตรวจหา loop ของเอเจนต์ที่ไม่มีขีดจำกัด

> สแกนโค้ดเบสหาการเรียกเอเจนต์และ LLM ที่ไม่มีขีดจำกัดจำนวนขั้นหรือเวลา หรือประเมินการเรียกใช้ครั้งเดียว ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/agent
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/agent
อัปเดตล่าสุด: 2026-11-07

hook `agent` ชี้ว่าเป็นปัญหาเมื่อพบ **runtime ของเอเจนต์ที่วน loop โดยไม่มีขีดจำกัดจำนวนรอบ งบประมาณ หรือเวลา** ซึ่งเป็นช่องโหว่ที่ปล่อยให้เอเจนต์ทำงานเองจนควบคุมไม่ได้ และเปลี่ยนอินพุตที่จงใจสร้างขึ้นให้กลายเป็นค่าใช้จ่ายที่ไม่มีขอบเขต หรือการยกระดับผ่าน prompt injection hook นี้ **เข้าใจภาษา** และครอบคลุมสองระบบนิเวศของเฟรมเวิร์กเอเจนต์: **JavaScript** (runtime `query` ของ agent SDK ของ **Claude**) และ **Python** (**LangChain**, **LangGraph**, **CrewAI** และ **OpenAI Agents**) hook นี้คือเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `llm`](https://lagune.ai/th-TH/docs/catalog) ซึ่งคุณรันเองได้ในโหมด **scan** หรือ **check**

## การรัน

**สแกนโค้ดเบส**

```bash
npx lagune read agent                # scans the whole project
npx lagune read agent --dir src/ai   # scans a directory
npx lagune read agent --file chat.ts # scans a single file
```

**ตรวจการเรียกใช้หนึ่งครั้ง**

```bash
npx lagune read agent --lang javascript --pattern 'query({ prompt })'                           # => uncapped
npx lagune read agent --lang javascript --pattern 'query({ prompt, options: { maxTurns: 5 } })' # => safe
npx lagune read agent --lang python --pattern 'AgentExecutor(agent=a, max_iterations=None)'     # => uncapped
```

ทุกบรรทัดใต้ **Uncapped agent loops found** ในไฟล์ที่ import agent SDK คือหนึ่งในสองกรณี: runtime `query` ของ agent SDK ของ Claude ที่เรียกโดยไม่มีขีดจำกัดจำนวนรอบ งบประมาณ หรือเวลา (JavaScript ซึ่งไม่มีขีดจำกัดโดยค่าเริ่มต้น) หรือการลบขีดจำกัดเริ่มต้นของเฟรมเวิร์กอย่างชัดเจน เช่น `max_iterations=None` / `max_turns=None` (Python ซึ่งมีขีดจำกัดโดยค่าเริ่มต้น) ทั้งสองกรณีทำให้จบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์ ส่วน `generateText`/`streamText` ของ Vercel AI SDK ทำงานเพียงขั้นเดียวโดยค่าเริ่มต้น (`stopWhen: stepCountIs(1)`) การเรียกแบบไม่ตั้งค่าใด ๆ จึงวน loop ไม่ได้ และ hook ไม่ชี้ว่าเป็นปัญหา นอกจากนี้ hook ไม่มีวันเข้าใจผิดว่า `db.query(...)` ธรรมดาเป็นการเรียกเอเจนต์ การรันที่ไม่พบปัญหาจะพิมพ์ `no uncapped agent loops found`

## วิธีอ่านผลตัดสิน

| ผลตัดสิน   | ความหมาย                                                                                                   |
| ---------- | ---------------------------------------------------------------------------------------------------------- |
| `uncapped` | การเรียก runtime `query` ที่ไม่มีขีดจำกัด (JS) หรือการลบขีดจำกัดอย่างชัดเจน (`=None`, Py)                  |
| `safe`     | การเรียก `query` ที่กำหนดขีดจำกัด การสร้างผลแบบขั้นเดียว หรือการเรียกเฟรมเวิร์กที่มีขีดจำกัดโดยค่าเริ่มต้น |
| `invalid`  | โค้ดตัวอย่างไม่มีการเรียกเอเจนต์ที่ระบุได้ให้ตัดสิน                                                        |

### ตัวเลือก CLI

| ตัวเลือก    | ค่า          | คำอธิบาย                                                                             |
| ----------- | ------------ | ------------------------------------------------------------------------------------ |
| `--pattern` | โค้ดตัวอย่าง | ตรวจการเรียกใช้หนึ่งครั้ง ใส่ซ้ำเพื่อตรวจหลายครั้ง โดยได้ผลตัดสินบรรทัดละหนึ่งรายการ |
| `--lang`    | ภาษา         | จำเป็นเมื่อใช้ `--pattern`: `javascript` หรือ `python`                               |
| `--dir`     | ไดเรกทอรี    | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้                 |
| `--file`    | ไฟล์         | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้                       |

หากไม่ระบุตัวเลือก hook จะสแกนทั้งโปรเจกต์ `--pattern` ต้องใช้คู่กับ `--lang` และใช้ร่วมกับ `--dir` หรือ `--file` ไม่ได้

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `agent` เอง:

```bash
npx lagune write add --ignore test/fixtures --checker agent
```

```json
{
  "checkers": {
    "agent": { "gitignore": false, "ignore": ["test/fixtures"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

**ตรวจให้ได้มากที่สุด แต่ไม่ครบทุกกรณี**

loop ของเอเจนต์ที่เขียนขึ้นเองในภาษาใดก็ตาม อยู่นอกเหนือสิ่งที่การสแกนแบบ static ทำได้ ให้ถือว่านี่เป็นพื้นฐานที่หนักแน่น ไม่ใช่รายการที่ครบถ้วน

**เคล็ดลับ**

hook ตัดสินเฉพาะเรื่องขีดจำกัด: การจำกัดขอบเขตความสามารถ การปะปนระดับความน่าเชื่อถือ และการตรวจสอบสิทธิ์ เป็นเรื่องที่ต้องใช้วิจารณญาณ ซึ่ง [ความรู้เฉพาะทาง `llm`](https://lagune.ai/th-TH/docs/catalog) ยังคงดูแลอยู่

## คำถามที่พบบ่อย

### ทำไมต้องจำกัด loop ของเอเจนต์

เอเจนต์ที่ไม่มีขีดจำกัดอาจถูกชักนำให้เกิดการเรียกซ้ำ ค่าใช้จ่าย หรือการยกระดับผ่าน prompt injection อย่างไม่มีขอบเขต การกำหนด maxTurns/maxBudgetUsd/stopWhen/signal ช่วยจำกัดไว้ได้ และ hook agent จะชี้ว่าการเรียก runtime query ที่ไม่ได้กำหนดค่าใดเลยเป็นปัญหา

---

# Hook cors: ตรวจสอบ origin ของ CORS

> สแกนซอร์สโค้ดหารายการ origin ที่อนุญาตของ CORS ที่ถูกเลี่ยงได้ หรือประเมินว่าค่า origin หนึ่งค่าเปิดสิทธิ์กว้างเกินไปหรือไม่ ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/cors
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/cors
อัปเดตล่าสุด: 2026-11-07

hook `cors` คือเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `http-request`](https://lagune.ai/th-TH/docs/catalog) และคุณรันเองได้ hook นี้ทำงานได้สองโหมดจากคำสั่งเดียว: โหมด **scan** ที่สแกนซอร์สโค้ดหา **รายการ origin ที่อนุญาตซึ่งถูกเลี่ยงได้** (regex ตรวจโฮสต์ที่โฮสต์ของผู้โจมตีเล็ดลอดผ่านไปได้) และโหมด **score** ที่ประเมินค่า **CORS origin** หนึ่งค่าว่าเป็น `wildcard`, `null` หรือ `safe`

## สแกนโค้ดเบส

หากไม่ใส่ flag hook จะสแกนทั้งโปรเจกต์

**ทั้งโปรเจกต์**

```bash
npx lagune read cors
```

**ไดเรกทอรีเดียว**

```bash
npx lagune read cors --dir src/server
```

**ไฟล์เดียว**

```bash
npx lagune read cors --file internal/auth/origin.go
```

hook จะแสดงรายการที่อนุญาตทุกรายการที่ถูกเลี่ยงได้ไว้ใต้หัวข้อเดียว โดยจัดกลุ่มตามไฟล์ validator ตรวจโฮสต์ที่มี `.+`/`.*` อยู่ในส่วน authority ก่อน suffix ของโฮสต์ที่เชื่อถือ (`^https?://.+\.trusted\.com`) จะปล่อยให้โฮสต์ของผู้โจมตีอย่าง `your-site.com.attacker.com` เล็ดลอดผ่านไปได้

```text
Origin-allowlist patterns with a greedy wildcard (bypassable, review):

internal/auth/origin.go
  ^https?://.+\.trusted\.com
```

รายการนี้เป็นเบาะแสให้ตรวจทาน ไม่ใช่ข้อตรวจพบที่ชี้ขาดแล้ว: จากข้อความเพียงอย่างเดียวตัดสินไม่ได้ว่า regex นั้นควบคุมการตัดสินใจเรื่องความน่าเชื่อถือจริงหรือไม่ การสแกนจึงไม่เปลี่ยน exit code อ่านแต่ละรายการและยืนยันว่ารายการที่อนุญาตเปรียบเทียบแบบตรงกันทั้งค่า เมื่อไม่พบอะไร hook จะพิมพ์ออกมาเพียงบรรทัดเดียว

```bash
npx lagune read cors --dir src/clean
# => no bypassable origin allowlist found
```

## ประเมิน origin

ส่ง origin แต่ละค่าด้วย `--origin` แล้ว hook จะพิมพ์คำหนึ่งคำต่อ origin หนึ่งค่า และจบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์เมื่อพบ `wildcard` หรือ `null`

**origin เดียว**

```bash
npx lagune read cors --origin '*'                       # => wildcard
npx lagune read cors --origin 'null'                    # => null
npx lagune read cors --origin 'https://app.example.com' # => safe
```

**หลาย origin**

ใส่ `--origin` ซ้ำเพื่อประเมินรายการที่อนุญาตทั้งชุดในการเรียกครั้งเดียว โดยได้ผลตัดสินบรรทัดละหนึ่งรายการตามลำดับ

```bash
npx lagune read cors \
  --origin 'https://app.example.com' \
  --origin '*' \
  --origin 'null'
# => safe
# => wildcard
# => null
```

| ผลตัดสิน   | ความหมาย                                                                                     |
| ---------- | -------------------------------------------------------------------------------------------- |
| `safe`     | ไม่ใช่ `*`, `null` หรือ glob แบบ `*` แต่ไม่ได้รับประกันว่า origin มีรูปแบบถูกต้อง            |
| `wildcard` | `*` หรือ glob แบบ subdomain/host/port: เว็บไซต์ใดก็ได้ (หรือกลุ่มที่กว้าง) อ่าน response ได้ |
| `null`     | origin `null` ซึ่ง iframe แบบ sandbox และการ redirect ปลอมขึ้นได้                            |

มีเพียง `safe` ที่หมายถึงอนุญาต และ `--origin` เป็นตัวตัดสินค่า (value oracle): ตัดสินที่ค่า ไม่ได้ตัดสินที่ handler ดังนั้นให้ยืนยัน handler ด้วยความรู้เฉพาะทาง `http-request`

### ตัวเลือก CLI

| ตัวเลือก   | ค่า       | คำอธิบาย                                                                      |
| ---------- | --------- | ----------------------------------------------------------------------------- |
| `--origin` | origin    | ประเมินค่า origin หนึ่งค่า ใส่ซ้ำเพื่อประเมินหลายค่า โดยได้ผลบรรทัดละหนึ่งค่า |
| `--dir`    | ไดเรกทอรี | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้          |
| `--file`   | ไฟล์      | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้                |

หากไม่ระบุตัวเลือก hook จะสแกนทั้งโปรเจกต์ `--origin` คือโหมด score และใช้ร่วมกับ `--dir` หรือ `--file` ไม่ได้

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `cors` เอง:

```bash
npx lagune write add --ignore test/fixtures --checker cors
```

```json
{
  "checkers": {
    "cors": { "gitignore": false, "ignore": ["test/fixtures"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

**สิ่งที่ไม่ครอบคลุม**

การสแกนอ่านรูปแบบ **regex ที่ถูกเลี่ยงได้** และ `--origin` ประเมิน **ค่า** ของ origin ยังมีรูปแบบระดับซอร์สโค้ดสองแบบที่อยู่นอกการตรวจ: การสะท้อน `Origin` ของ request (เซิร์ฟเวอร์ส่ง `Origin` ที่เข้ามากลับไป หรือส่งคู่กับข้อมูลรับรอง) และรายการที่อนุญาตแบบ `endsWith`/substring ที่หละหลวม ให้มองหารูปแบบเหล่านี้ในโค้ด และจัดการตามที่ [ความรู้เฉพาะทาง `http-request`](https://lagune.ai/th-TH/docs/catalog) อธิบายไว้

## คำถามที่พบบ่อย

### ทำไม origin ของ CORS ที่เป็น null จึงอันตราย

iframe แบบ sandbox และการ redirect บางแบบส่ง Origin: null ออกไป รายการที่อนุญาตที่เชื่อถือ null จึงให้สิทธิ์อ่านแก่บริบทเหล่านั้น hook cors ชี้ว่าค่านี้เป็นปัญหาเช่นเดียวกับ wildcard

### ตรวจจับรายการ origin ที่อนุญาตของ CORS ที่ถูกเลี่ยงได้อย่างไร

รัน npx lagune read cors กับโค้ดเบส hook จะชี้ว่า regex ตรวจโฮสต์ที่มี wildcard แบบ greedy อยู่ก่อน suffix ที่เชื่อถือเป็นปัญหา เพราะโฮสต์ของผู้โจมตีอย่าง your-site.com.attacker.com จะเล็ดลอดผ่านไปได้

---

# Hook crypto: ตรวจหาการเข้ารหัสที่อ่อนแอ

> สแกนโค้ดเบสหา primitive การเข้ารหัสที่อ่อนแอ หรือประเมินโค้ดตัวอย่างชิ้นเดียว ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/crypto
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/crypto
อัปเดตล่าสุด: 2026-11-07

hook `crypto` ชี้ว่าเป็นปัญหาเมื่อพบ **primitive การเข้ารหัสที่อ่อนแอ** ตรงจุดที่เรียกใช้: cipher ที่เลิกใช้แล้ว โหมดที่ไม่ปลอดภัย หรือ digest ที่ถูกเจาะได้แล้ว hook นี้ **เข้าใจภาษา** โดยอ่านแต่ละไฟล์ตามกฎของภาษานั้นเอง จึงไม่มีวันชี้ว่าโครงสร้างของ Python เป็นปัญหาในไฟล์ Rust และเป็นเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `crypto`](https://lagune.ai/th-TH/docs/catalog) ซึ่งคุณรันเองได้ในโหมด **scan** หรือ **check**

## การรัน

**สแกนโค้ดเบส**

```bash
npx lagune read crypto                # scans the whole project
npx lagune read crypto --dir src      # scans a directory
npx lagune read crypto --file hash.ts # scans a single file
```

**ตรวจโค้ดตัวอย่าง**

```bash
npx lagune read crypto --lang javascript --pattern 'createCipher("aes-256-cbc", k)' # => weak
npx lagune read crypto --lang python --pattern 'hashlib.md5(data)'                  # => review
npx lagune read crypto --lang go --pattern 'sha256.Sum256(data)'                    # => safe
```

การสแกนพิมพ์ผลออกมาได้สูงสุดสองส่วน **Weak cryptography found** คือชุดข้อตรวจพบ (DES/3DES/RC4/Blowfish/RC2 และโหมด ECB) ซึ่งแต่ละรายการเป็น primitive ของ cipher ที่ถูกเจาะได้แล้ว hook จึงจบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์ ส่วน **Cryptography to review manually** คือชุดเบาะแสที่ hook ตัดสินเองไม่ได้: digest แบบ MD5/SHA-1 (ไม่ปลอดภัยสำหรับงานด้านความปลอดภัย แต่ใช้เป็น checksum ธรรมดาได้ เจตนาของการใช้งานจึงเป็นตัวตัดสิน) RNG ที่ไม่ใช่แบบ cryptographic ในบริบทด้านความปลอดภัย หรือการเปรียบเทียบค่าที่ไม่ปลอดภัยต่อ timing attack การรันที่ไม่พบปัญหาจะพิมพ์ `no weak cryptography found`

## วิธีอ่านผลตัดสิน

| ผลตัดสิน  | ความหมาย                                                                                                            |
| --------- | ------------------------------------------------------------------------------------------------------------------- |
| `weak`    | โค้ดตัวอย่างใช้ primitive ของ cipher ที่ถูกเจาะได้แล้ว (DES/3DES, RC4, Blowfish, RC2 หรือโหมด ECB)                  |
| `review`  | primitive ที่ขึ้นกับเจตนาการใช้งาน: digest แบบ MD5/SHA-1 หรือ RNG ที่ไม่ใช่แบบ cryptographic ในบริบทด้านความปลอดภัย |
| `safe`    | โค้ดตัวอย่างใช้การเข้ารหัส และไม่พบ primitive ที่อ่อนแอ                                                             |
| `invalid` | โค้ดตัวอย่างไม่มีโครงสร้างการเข้ารหัสที่ระบุได้ให้ตัดสิน                                                            |

### ตัวเลือก CLI

| ตัวเลือก    | ค่า          | คำอธิบาย                                                                                                           |
| ----------- | ------------ | ------------------------------------------------------------------------------------------------------------------ |
| `--pattern` | โค้ดตัวอย่าง | ตรวจโค้ดตัวอย่างหนึ่งชิ้น ใส่ซ้ำเพื่อตรวจหลายชิ้น โดยได้ผลตัดสินบรรทัดละหนึ่งรายการ                                |
| `--lang`    | ภาษา         | จำเป็นเมื่อใช้ `--pattern`: เลือกหนึ่งใน javascript, python, go, java, kotlin, php, ruby, rust, csharp, c หรือ cpp |
| `--dir`     | ไดเรกทอรี    | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้                                               |
| `--file`    | ไฟล์         | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้                                                     |

หากไม่ระบุตัวเลือก hook จะสแกนทั้งโปรเจกต์ `--pattern` ต้องใช้คู่กับ `--lang` และใช้ร่วมกับ `--dir` หรือ `--file` ไม่ได้

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `crypto` เอง:

```bash
npx lagune write add --ignore test/fixtures --checker crypto
```

```json
{
  "checkers": {
    "crypto": { "gitignore": false, "ignore": ["test/fixtures"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

### ภาษาที่รองรับ

การสแกนอ่านภาษาเหล่านี้โดยแยกตามนามสกุลไฟล์ และตรวจแต่ละภาษาเทียบกับ API การเข้ารหัสของภาษานั้นเอง

| ภาษา                        | cipher ที่อ่อนแอ (ข้อตรวจพบ) และ digest หรือ RNG (ตรวจทาน)                                                              |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` ในเครื่องหมายคำพูด; MD5/SHA-1 `createHash`/`subtle.digest`; `Math.random()` |
| **Python**                  | pycryptodome `DES/ARC4/Blowfish.new`, `algorithms.TripleDES`, `MODE_ECB`; `hashlib.md5/sha1`; `random.*`                |
| **Go**                      | `des.NewCipher`, `rc4.NewCipher`, `blowfish.NewCipher`, `NewECBEncrypter`; `md5/sha1.Sum`; `math/rand`                  |
| **Java / Kotlin**           | `Cipher.getInstance("DES"/…/ECB")`; `MessageDigest.getInstance("MD5")`, `HmacMD5`; `java.util.Random`                   |
| **PHP**                     | `openssl_encrypt("des-…"/"…-ecb")`, `mcrypt_*`; `md5()`/`sha1()`, `hash("md5", …)`; `rand()`/`mt_rand()`                |
| **Ruby**                    | `OpenSSL::Cipher.new("des-…")`, `:ECB`; `Digest::MD5/SHA1`; `rand()`/`Random`                                           |
| **Rust**                    | `Rc4::`, `Blowfish::`, `des::`, `ecb::`; `Md5::`, `Sha1::`, `Hmac<Md5>`; `SmallRng`/`XorShiftRng`                       |
| **C#**                      | `DES/TripleDES/RC2.Create`, `CipherMode.ECB`; `MD5/SHA1.Create`, `HMACMD5`; `new Random()`                              |
| **C / C++**                 | OpenSSL `DES_*`/`RC4`/`EVP_des_*`, `EVP_*_ecb`; `MD5()`/`SHA1()`, `EVP_md5`; `rand()`/`random()`                        |

**ตรวจให้ได้มากที่สุด แต่ไม่ครบทุกกรณี**

hook นี้อ่านซอร์สโค้ดเป็นข้อความ ดังนั้น primitive ที่ประกอบขึ้นตอน runtime ซ่อนอยู่หลัง alias หรือเขียนในรูปแบบที่ hook ไม่รู้จัก อาจหลุดรอดไปได้ ให้ถือว่าตารางนี้เป็นจุดเริ่มต้นที่หนักแน่น ไม่ใช่รายการที่ครบถ้วน

**เคล็ดลับ**

hook รับประกันระดับพื้นฐาน (ว่าโครงสร้างเหล่านี้มีอยู่จริง): การจัดการคีย์ การใช้ IV ซ้ำ และ RSA padding เป็นเรื่องที่ต้องใช้วิจารณญาณ ซึ่ง [ความรู้เฉพาะทาง `crypto`](https://lagune.ai/th-TH/docs/catalog) ยังคงดูแลอยู่

## คำถามที่พบบ่อย

### สแกนโค้ดเบสหาการเข้ารหัสที่อ่อนแอได้อย่างไร

รัน hook crypto โดยไม่ใส่ flag ใด ๆ cipher ที่ถูกเจาะได้แล้วและโหมด ECB เป็นข้อตรวจพบที่ทำให้จบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์ ส่วน digest แบบ MD5/SHA-1 เป็นเบาะแสให้ตรวจทาน เพราะไม่ปลอดภัยสำหรับงานด้านความปลอดภัย แต่ใช้เป็น checksum ธรรมดาได้

### hook crypto ชี้ว่า Math.random() เป็นปัญหาไหม

ชี้เฉพาะในบริบทด้านความปลอดภัย และเป็นเพียงเบาะแสให้ตรวจทาน ไม่เคยเป็นข้อตรวจพบอัตโนมัติ เพราะการสุ่มค่าเป็นเรื่องปกติสำหรับ jitter หรือการจัดลำดับใน UI

---

# Hook cvss: ให้คะแนนเวกเตอร์ CVSS v4.0

> ให้คะแนนเวกเตอร์ CVSS v4.0 หนึ่งหรือหลายรายการจากบรรทัดคำสั่ง ด้วยวิธีคำนวณเดียวกับเครื่องคำนวณของ FIRST และอ่านคำอธิบายของแต่ละเวกเตอร์เป็นภาษาที่เข้าใจง่าย

Canonical: https://lagune.ai/th-TH/docs/hooks/cvss
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/cvss
อัปเดตล่าสุด: 2026-11-07

hook `cvss` ให้คะแนน **เวกเตอร์ CVSS v4.0** และพิมพ์คะแนนกับช่วงระดับความรุนแรงออกมา ซึ่งเป็นการให้คะแนนที่คำสั่ง [`/lagune-plan`](https://lagune.ai/th-TH/docs/commands/plan) เขียนไว้ในการแก้ไขแต่ละรายการ และคำสั่ง [`/lagune-prove`](https://lagune.ai/th-TH/docs/commands/prove) เขียนไว้ในประกาศแจ้งเตือนด้านความปลอดภัยแต่ละฉบับ hook นี้คือเอนจินแบบ deterministic เบื้องหลังการให้คะแนนเหล่านั้น โดยใช้วิธีคำนวณเดียวกับ [เครื่องคำนวณของ FIRST](https://www.first.org/cvss/calculator/4.0) และคุณรันเองได้

## การรัน

ส่งเวกเตอร์แต่ละรายการด้วย `--vector` แล้ว hook จะพิมพ์บรรทัดละหนึ่งเวกเตอร์: คะแนนและช่วงระดับความรุนแรงของเวกเตอร์นั้น

**เวกเตอร์เดียว**

```bash
npx lagune read cvss --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N'
# => 9.3, Critical
```

**หลายเวกเตอร์**

ใส่ `--vector` ซ้ำเพื่อให้คะแนนหลายรายการพร้อมกัน โดยได้ผลรายการละหนึ่งบรรทัดตามลำดับ

```bash
npx lagune read cvss \
  --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \
  --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A'
# => 9.3, Critical
# => 8.7, High
```

**อธิบายเป็นภาษาที่เข้าใจง่าย**

เพิ่ม `--explain` เพื่ออ่านคำอธิบายของแต่ละเมตริกเป็นภาษาที่เข้าใจง่าย เมื่อเมตริกกลุ่ม Threat หรือ Environmental ทำให้คะแนนเปลี่ยน hook จะแสดงคะแนน Base อย่างเดียวขึ้นก่อน

```bash
npx lagune read cvss --explain --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A'
# => 8.7, High
# =>   Base metrics alone: 9.3, Critical
# =>   Attack Vector: Network, modified to Adjacent
# =>   Attack Complexity: Low
# =>   ...
```

## วิธีอ่านผลลัพธ์

| ช่วง       | คะแนน        |
| ---------- | ------------ |
| `None`     | 0.0          |
| `Low`      | 0.1 ถึง 3.9  |
| `Medium`   | 4.0 ถึง 6.9  |
| `High`     | 7.0 ถึง 8.9  |
| `Critical` | 9.0 ถึง 10.0 |

เวกเตอร์ที่มีเฉพาะเมตริก Base จะให้คะแนนตัวช่องโหว่เองโดยสมมติกรณีเลวร้ายที่สุด: ข้อกำหนดด้านความปลอดภัยทุกข้อเป็น High และช่องโหว่ถูกโจมตีจริงในวงกว้างแล้ว เมตริก Environmental (`MAV` และเมตริกแบบ modified อื่น ๆ รวมถึง `CR`, `IR` และ `AR`) ปรับคะแนนให้ตรงกับการดีพลอยหนึ่งแห่ง และเมตริก Threat (`E`) ปรับตามสิ่งที่รู้เกี่ยวกับการนำช่องโหว่ไป exploit

เวกเตอร์ที่ไม่ถูกต้องจะพิมพ์ `invalid vector:` พร้อมบอกว่าผิดตรงไหน และ hook จะจบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์

### ตัวเลือก CLI

| ตัวเลือก    | ค่า                 | คำอธิบาย                                                                                        |
| ----------- | ------------------- | ----------------------------------------------------------------------------------------------- |
| `--vector`  | เวกเตอร์ `CVSS:4.0` | ให้คะแนนเวกเตอร์หนึ่งรายการ ใส่ซ้ำเพื่อให้คะแนนหลายรายการ โดยได้ผลเวกเตอร์ละหนึ่งบรรทัดตามลำดับ |
| `--explain` |                     | เพิ่มคำอธิบายของแต่ละเมตริกเป็นภาษาที่เข้าใจง่ายไว้ใต้ทุกบรรทัดผลการให้คะแนน                    |

ต้องมี `--vector` อย่างน้อยหนึ่งรายการ เอนจินไม่รับเวกเตอร์เป็นอาร์กิวเมนต์ตามตำแหน่งเปล่า ๆ จึงไม่มีทางสับสนเวกเตอร์กับ flag

**ทำไมต้องเป็นค่าของ flag**

เวกเตอร์แต่ละรายการส่งเข้าไปเป็นค่าของ flag และไม่เคยนำไปแทรกลงในคำสั่งโดยตรง ค่าที่มีเครื่องหมายคำพูดหรือ backtick จึงไม่มีผลใด ๆ และ inject เข้า shell ไม่ได้ ครอบค่าด้วยเครื่องหมายคำพูดเดี่ยวเสมอ เพื่อไม่ให้ shell ของคุณขยายค่านั้นก่อน

**สิ่งที่ไม่ครอบคลุม**

รองรับเฉพาะ CVSS v4.0: hook จะปฏิเสธเวกเตอร์ v2.0, v3.0 หรือ v3.1 แทนที่จะให้คะแนน เพราะ **Lagune** ให้คะแนนทุกข้อตรวจพบด้วย v4.0

**เคล็ดลับ**

การตรวจความถูกต้องของเฟส plan จะคำนวณแบบเดียวกันนี้ซ้ำกับทุกบรรทัด CVSS จึงตรวจพบคะแนนที่คลาดไปจากเวกเตอร์ของตัวเองได้ก่อนยอมรับแผน

## คำถามที่พบบ่อย

### Lagune คำนวณคะแนน CVSS อย่างไร

hook cvss ทำตามเครื่องคำนวณอ้างอิงของ FIRST สำหรับ CVSS v4.0 เวกเตอร์หนึ่ง ๆ จึงได้คะแนนตรงกับที่ได้บนเว็บไซต์ของ FIRST ทุกประการ

### ใช้ hook นี้ให้คะแนนเวกเตอร์ CVSS v3.1 ได้ไหม

ไม่ได้ Lagune ให้คะแนนทุกข้อตรวจพบด้วย CVSS v4.0 และ hook จะปฏิเสธเวอร์ชันอื่นทั้งหมดแทนที่จะให้คะแนน

### flag --explain ทำอะไร

flag นี้อธิบายแต่ละเมตริกเป็นภาษาที่เข้าใจง่าย และแสดงคะแนน Base ไว้ข้างคะแนนรวม ทุกคนจึงเห็นได้ว่าเวกเตอร์บอกอะไร และบริบทของโปรเจกต์ทำให้คะแนนเปลี่ยนไปอย่างไร

---

# Hook infra: ตรวจหาการตั้งค่า IaC ที่ผิดพลาด

> สแกน Terraform, Dockerfile และ GitHub Actions หาการตั้งค่าที่ผิดพลาด หรือประเมินโค้ดตัวอย่างชิ้นเดียว ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/infra
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/infra
อัปเดตล่าสุด: 2026-11-07

hook `infra` ชี้ว่าเป็นปัญหาเมื่อพบ **การตั้งค่า infrastructure-as-code ที่ผิดพลาด** ซึ่งตัดสินได้จากไฟล์เพียงอย่างเดียว: เครือข่ายที่เปิดสู่ทั้งโลก สิทธิ์แบบ wildcard secret ใน manifest คอนเทนเนอร์ที่รันด้วย root หรือค่าที่ไม่น่าเชื่อถือใน shell ของ CI hook นี้อ่านเฉพาะไฟล์ IaC (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`) และเป็นเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `infra`](https://lagune.ai/th-TH/docs/catalog) ในโหมด **scan** หรือ **check**

## การรัน

**สแกนโค้ดเบส**

```bash
npx lagune read infra                   # scans every IaC file
npx lagune read infra --dir infra       # scans a directory
npx lagune read infra --file Dockerfile # scans a single file
```

**ตรวจโค้ดตัวอย่าง**

ส่งโค้ดตัวอย่างด้วย `--pattern` และระบุชนิดของโค้ดด้วย `--kind` (`terraform`, `dockerfile` หรือ `github-actions`)

```bash
npx lagune read infra --kind terraform  --pattern 'actions = ["*"]' # => iam-wildcard
npx lagune read infra --kind dockerfile --pattern 'FROM node:20'    # => mutable-tag
```

การสแกนพิมพ์ผลออกมาได้สูงสุดสองส่วน **Infrastructure risks found** ทำให้จบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์ และแสดงข้อบกพร่องที่ตัดสินได้ (ingress `0.0.0.0/0` บนพอร์ตที่อ่อนไหว statement ของ IAM แบบ wildcard secret ใน manifest `encrypted = false` โมดูล git ที่ไม่ได้ตรึงเวอร์ชัน image ที่ระบุให้รันด้วย root อย่างชัดเจน `curl | sh` การ inject สคริปต์ใน CI และ `permissions: write-all`) ส่วน **Infrastructure hardening advisories** ไม่เปลี่ยน exit code (base tag ที่เปลี่ยนแปลงได้ หรือ action ที่ตรึงด้วย tag) การรันที่ไม่พบปัญหาจะพิมพ์ `no infrastructure risks found`

## วิธีอ่านผลตัดสิน

โหมด check พิมพ์ tag ที่มีระดับความรุนแรงสูงสุดที่ตรงกัน (เช่น `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`) tag ระดับคำแนะนำ (`mutable-tag`, `unpinned-action`) หรือ `safe` มีเพียง tag ระดับข้อตรวจพบเท่านั้นที่ทำให้จบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์

### ตัวเลือก CLI

| ตัวเลือก    | ค่า                                             | คำอธิบาย                                                                 |
| ----------- | ----------------------------------------------- | ------------------------------------------------------------------------ |
| `--pattern` | โค้ดตัวอย่าง                                    | ตรวจโค้ดตัวอย่างหนึ่งชิ้น ต้องใช้คู่กับ `--kind` ใส่ซ้ำเพื่อตรวจหลายชิ้น |
| `--kind`    | `terraform` \| `dockerfile` \| `github-actions` | ชนิดที่ใช้ตัดสินโค้ดตัวอย่าง                                             |
| `--dir`     | ไดเรกทอรี                                       | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้     |
| `--file`    | ไฟล์                                            | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้           |

หากไม่ระบุตัวเลือก hook จะสแกนไฟล์ IaC ทุกไฟล์ในโปรเจกต์ `--pattern` ใช้ร่วมกับ `--dir` หรือ `--file` ไม่ได้

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `infra` เอง:

```bash
npx lagune write add --ignore examples --checker infra
```

```json
{
  "checkers": {
    "infra": { "gitignore": false, "ignore": ["examples"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

**เคล็ดลับ**

hook จับกรณีที่ชัดเจนและตัดสินได้: การไม่มีการเข้ารหัส ความเสี่ยงจาก `pull_request_target` และขอบเขต IAM ที่เหมาะสม เป็นเรื่องที่ต้องใช้วิจารณญาณ ซึ่ง [ความรู้เฉพาะทาง `infra`](https://lagune.ai/th-TH/docs/catalog) ยังคงดูแลอยู่

## คำถามที่พบบ่อย

### hook infra อ่านไฟล์ infrastructure อะไรบ้าง

Terraform/HCL (.tf, .tf.json, .hcl), Dockerfile และไฟล์ YAML ของ workflow และ action ของ GitHub Actions ใต้ .github/ hook นี้เข้าถึงไฟล์เหล่านั้นได้ แม้ตัวสแกนซอร์สโค้ดจะข้ามไฟล์เหล่านั้นไป

---

# Hook interpreter: ชี้จุด sink ที่รันโค้ดแบบไดนามิก

> สแกนโค้ดเบสหา sink ที่รันโค้ดแบบไดนามิกในหลายภาษา หรือประเมินโค้ดตัวอย่างชิ้นเดียว ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/interpreter
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/interpreter
อัปเดตล่าสุด: 2026-11-07

hook `interpreter` ชี้ว่าเป็นปัญหาเมื่อพบ **sink ที่รันโค้ดแบบไดนามิก**: โครงสร้างที่เปลี่ยนข้อมูลให้กลายเป็นโค้ดที่ทำงานจริง หรือส่งข้อมูลต่อให้ shell ตั้งแต่ `eval` ไปจนถึงการ deserialize แบบเนทีฟ hook นี้เข้าใจภาษา โดยอ่านแต่ละไฟล์ตามกฎของภาษานั้นเอง และเป็นเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `interpreter`](https://lagune.ai/th-TH/docs/catalog) ซึ่งคุณรันเองได้ในโหมด **scan** หรือ **check**

## การรัน

**สแกนโค้ดเบส**

```bash
npx lagune read interpreter               # scans the whole project
npx lagune read interpreter --dir src     # scans a directory
npx lagune read interpreter --file app.py # scans a single file
```

**ตรวจโค้ดตัวอย่าง**

```bash
npx lagune read interpreter --lang javascript --pattern 'eval(x)'   # => careful
npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe
```

sink เหล่านี้มีทั้งการใช้งานที่ชอบธรรมและการใช้งานที่อันตราย การสแกนแบบ static ตัดสินไม่ได้ว่าอินพุตที่ผู้โจมตีควบคุมได้จะไปถึง sink หรือไม่ ทุกรายการที่ตรงจึงเป็น **ข้อควรระวังให้ตรวจทาน** ไม่ใช่ข้อตรวจพบที่ยืนยันแล้ว การสแกนพิมพ์ส่วน **Dynamic-execution sinks to review** เพียงส่วนเดียว โดยจัดกลุ่มตามไฟล์ การรันที่ไม่พบปัญหาจะพิมพ์ `no dynamic-execution sinks found`

**อ่านโค้ดที่ถูกทำเครื่องหมาย ห้ามรันเด็ดขาด!**

วิเคราะห์แต่ละ sink **แบบ static** โดยไล่ดูว่าอินพุตที่ไม่น่าเชื่อถือไปถึง sink นั้นหรือไม่ ห้ามรันหรือ `eval` โค้ดที่ถูกทำเครื่องหมาย รวมถึงโค้ดจากระยะไกลหรือโค้ดที่ดึงมาตอน runtime ซึ่งโค้ดนั้นนำเข้ามา เพื่อ "ทดสอบ" ว่าโค้ดทำอะไร

## วิธีอ่านผลตัดสิน

| ผลตัดสิน  | ความหมาย                                                                                     |
| --------- | -------------------------------------------------------------------------------------------- |
| `careful` | โค้ดตัวอย่างมี sink ที่รันโค้ดแบบไดนามิกของภาษานั้น ให้ตรวจทานด้วยการอ่าน ห้ามตรวจด้วยการรัน |
| `safe`    | ไม่พบ sink ที่รันโค้ดแบบไดนามิกสำหรับภาษาที่ระบุ                                             |

### ตัวเลือก CLI

| ตัวเลือก    | ค่า          | คำอธิบาย                                                                                                           |
| ----------- | ------------ | ------------------------------------------------------------------------------------------------------------------ |
| `--pattern` | โค้ดตัวอย่าง | ตรวจโค้ดตัวอย่างหนึ่งชิ้น ใส่ซ้ำเพื่อตรวจหลายชิ้น โดยได้ผลตัดสินบรรทัดละหนึ่งรายการ                                |
| `--lang`    | ภาษา         | จำเป็นเมื่อใช้ `--pattern`: เลือกหนึ่งใน javascript, python, php, ruby, java, kotlin, go, rust, c, cpp หรือ csharp |
| `--dir`     | ไดเรกทอรี    | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้                                               |
| `--file`    | ไฟล์         | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้                                                     |

หากไม่ระบุตัวเลือก hook จะสแกนทั้งโปรเจกต์ `--pattern` ต้องใช้คู่กับ `--lang` และใช้ร่วมกับ `--dir` หรือ `--file` ไม่ได้

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `interpreter` เอง:

```bash
npx lagune write add --ignore test/fixtures --checker interpreter
```

```json
{
  "checkers": {
    "interpreter": { "gitignore": false, "ignore": ["test/fixtures"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

### ภาษาที่รองรับ

การสแกนอ่านภาษาเหล่านี้โดยแยกตามนามสกุลไฟล์ และตรวจแต่ละภาษาเทียบกับชุด sink ที่รันโค้ดแบบไดนามิกของภาษานั้นเอง

| #   | ภาษา                        | นามสกุลไฟล์                                                                                                  | sink ที่ชี้ว่าเป็นปัญหา                                                                                                                                                                                                       |
| --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1   | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, Function constructor, `setTimeout`/`setInterval` ที่รับ body เป็นสตริง, โมดูล `vm`, exec ของ `child_process`, `require()` แบบไดนามิก, `import()` แบบไดนามิก                                                         |
| 2   | **Python**                  | `.py`, `.pyi`                                                                                                | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` ที่ใช้ `shell=True`, `pickle.load`/`loads`, `yaml.load` (แบบไม่ปลอดภัย)                                                                                   |
| 3   | **Ruby**                    | `.rb`                                                                                                        | กลุ่ม eval (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, backtick หรือ `%x`, `Kernel#open` / `IO.popen`/`read`/`binread` / `Open3`, `Process.spawn`, `Marshal.load`                                   |
| 4   | **Go**                      | `.go`                                                                                                        | `exec.Command`/`exec.CommandContext`, `plugin.Open`                                                                                                                                                                           |
| 5   | **PHP**                     | `.php`                                                                                                       | `eval()`, `assert()` กับสตริง, `create_function()`, การรัน shell (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` ที่ใช้ path ซึ่งกำหนดตอน runtime |
| 6   | **Rust**                    | `.rs`                                                                                                        | `Command::new`, `process::Command`                                                                                                                                                                                            |
| 7   | **Java**                    | `.java`                                                                                                      | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject`                                                                                                                                              |
| 8   | **Kotlin**                  | `.kt`, `.kts`                                                                                                | sink ของ JVM: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject`                                                                                                                                |
| 9   | **C#**                      | `.cs`                                                                                                        | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load`                                                                                                                                                           |
| 10  | **C**                       | `.c`, `.h`                                                                                                   | `system()`, `popen()`, กลุ่ม `exec*` (`execl`, `execve`, `execvp`, …)                                                                                                                                                         |
| 11  | **C++**                     | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx`                                                                 | `system()`, `popen()`, กลุ่ม `exec*` (`execl`, `execve`, `execvp`, …)                                                                                                                                                         |

**ตรวจให้ได้มากที่สุด แต่ไม่ครบทุกกรณี**

hook นี้อ่านซอร์สโค้ดเป็นข้อความ ดังนั้น sink ที่ประกอบขึ้นตอน runtime ซ่อนอยู่หลัง alias หรือเขียนในรูปแบบที่ hook ไม่รู้จัก อาจหลุดรอดไปได้ ให้ถือว่าตารางนี้เป็นจุดเริ่มต้นที่หนักแน่น ไม่ใช่รายการที่ครบถ้วน

**เคล็ดลับ**

hook รับประกันระดับพื้นฐาน (ว่า sink เหล่านี้มีอยู่และอยู่ตรงไหน): ส่วนการตัดสินว่าค่าที่ไม่น่าเชื่อถือไปถึง sink จริงหรือไม่ เป็นเรื่องที่ [ความรู้เฉพาะทาง `interpreter`](https://lagune.ai/th-TH/docs/catalog) ดูแล

## คำถามที่พบบ่อย

### hook interpreter ยืนยันช่องโหว่ได้ไหม

ไม่ได้ hook นี้ชี้ว่า sink ที่รันโค้ดแบบไดนามิกเป็นข้อควรระวังให้ตรวจทาน ไม่ใช่ข้อตรวจพบที่ยืนยันแล้ว เพราะการสแกนแบบ static ตัดสินไม่ได้ว่าอินพุตที่ผู้โจมตีควบคุมได้จะไปถึง sink หรือไม่

### hook interpreter รองรับภาษาอะไรบ้าง

hook นี้อ่านภาษาในตาราง "ภาษาที่รองรับ" โดยแยกตามนามสกุลไฟล์ และตรวจแต่ละภาษาเทียบกับชุด sink ของภาษานั้นเอง ส่วนภาษาอื่นจะไม่พบ sink ใด ๆ

---

# Hook jwt: ตรวจหาการตรวจสอบ JWT ที่ไม่ได้ตรึงอัลกอริทึม

> สแกนโค้ดเบสหาการตรวจสอบ JWT ที่ไม่ได้ตรึงอัลกอริทึม หรือประเมินการเรียกใช้ครั้งเดียว ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/jwt
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/jwt
อัปเดตล่าสุด: 2026-11-07

hook `jwt` ชี้ว่าเป็นปัญหาเมื่อพบ **การตรวจสอบ JWT ที่ไม่ได้ตรึงอัลกอริทึม** ซึ่งเป็นช่องโหว่ algorithm confusion ที่ตัวตรวจสอบเชื่อ header `alg` ของโทเค็นเอง และเมื่อพบ **การปิดการตรวจสอบไปทั้งหมด** hook นี้ **เข้าใจภาษา** โดยอ่านแต่ละไฟล์ตามไลบรารี JWT ที่ไฟล์นั้นใช้ และเป็นเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `federation`](https://lagune.ai/th-TH/docs/catalog) ซึ่งคุณรันเองได้ในโหมด **scan** หรือ **check**

## การรัน

**สแกนโค้ดเบส**

```bash
npx lagune read jwt                # scans the whole project
npx lagune read jwt --dir src      # scans a directory
npx lagune read jwt --file auth.ts # scans a single file
```

**ตรวจการเรียกใช้หนึ่งครั้ง**

```bash
npx lagune read jwt --lang javascript --pattern 'jwt.verify(token, secret)'                         # => unpinned
npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, options={"verify_signature": False})' # => unpinned
npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, algorithms=["HS256"])'                # => safe
```

ทุกบรรทัดใต้ **Unpinned JWT verification found** คือการเรียก verify ที่ไม่ได้กำหนดรายการที่อนุญาต `algorithms` (ในกรณีที่ไลบรารีต้องการ) ยอมรับรายการที่ไม่ปลอดภัย (`none` หรืออัลกอริทึมแบบอสมมาตรที่ปนกับ HMAC) หรือปิดการตรวจลายเซ็นไปเลย จึงเชื่อ `alg` ของโทเค็นเอง นี่คือช่องโหว่ที่ยืนยันแล้ว hook จึงจบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์ การรันที่ไม่พบปัญหาจะพิมพ์ `no unpinned JWT verification found`

## วิธีอ่านผลตัดสิน

| ผลตัดสิน   | ความหมาย                                                                                                       |
| ---------- | -------------------------------------------------------------------------------------------------------------- |
| `unpinned` | การเรียก verify ที่ไม่มีรายการอัลกอริทึมที่อนุญาต (ในกรณีที่จำเป็น) มีรายการที่ไม่ปลอดภัย หรือปิดการตรวจสอบไว้ |
| `safe`     | การเรียก verify ที่ตรึงรายการอัลกอริทึมที่อนุญาตไว้อย่างเหมาะสม หรือไลบรารีตรึงให้โดยปริยาย                    |
| `invalid`  | โค้ดตัวอย่างไม่มีการเรียก verify ที่ระบุได้ให้ตัดสิน                                                           |

### ตัวเลือก CLI

| ตัวเลือก    | ค่า          | คำอธิบาย                                                                                                   |
| ----------- | ------------ | ---------------------------------------------------------------------------------------------------------- |
| `--pattern` | โค้ดตัวอย่าง | ตรวจการเรียกใช้หนึ่งครั้ง ใส่ซ้ำเพื่อตรวจหลายครั้ง โดยได้ผลตัดสินบรรทัดละหนึ่งรายการ                       |
| `--lang`    | ภาษา         | จำเป็นเมื่อใช้ `--pattern`: เลือกหนึ่งใน javascript, python, go, java, kotlin, php, ruby, rust หรือ csharp |
| `--dir`     | ไดเรกทอรี    | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้                                       |
| `--file`    | ไฟล์         | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้                                             |

หากไม่ระบุตัวเลือก hook จะสแกนทั้งโปรเจกต์ `--pattern` ต้องใช้คู่กับ `--lang` และใช้ร่วมกับ `--dir` หรือ `--file` ไม่ได้

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `jwt` เอง:

```bash
npx lagune write add --ignore test/fixtures --checker jwt
```

```json
{
  "checkers": {
    "jwt": { "gitignore": false, "ignore": ["test/fixtures"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

### ภาษาที่รองรับ

การสแกนอ่านไลบรารีเหล่านี้โดยแยกตามนามสกุลไฟล์ เนื่องจากบางไลบรารีตรึงอัลกอริทึมให้โดยปริยาย (การไม่มีรายการที่ระบุชัดก็ยังปลอดภัย) กฎ "ไม่มีรายการที่อนุญาต ⇒ unpinned" จึงใช้เฉพาะเมื่อไลบรารีคาดหวังรายการที่ระบุชัด hook จึงไม่มีวันชี้ว่าการเรียกที่ตั้งค่าถูกต้องเป็นปัญหา

| ภาษา                        | ไลบรารี                 | ถือว่าการไม่มีรายการที่อนุญาตเป็น unpinned ไหม                              | ชี้ว่าเป็นปัญหาเสมอ                             |
| --------------------------- | ----------------------- | --------------------------------------------------------------------------- | ----------------------------------------------- |
| **JavaScript / TypeScript** | jsonwebtoken, jose      | ใช่                                                                         | `none`, การปนกันของอัลกอริทึมแบบอสมมาตรกับ HMAC |
| **Python**                  | PyJWT, python-jose      | ใช่ (PyJWT บังคับให้ระบุ ส่วน python-jose ใช้ค่าเริ่มต้น `algorithms=None`) | `none`, `verify_signature: False`               |
| **Go**                      | golang-jwt              | ใช่ (ไม่มี `WithValidMethods`)                                              | `none`, `ParseUnverified`                       |
| **Ruby**                    | ruby-jwt                | ใช่                                                                         | `none`, `verify = false`                        |
| **Java / Kotlin**           | jjwt, nimbus            | ไม่ (อนุมานจากคีย์)                                                         | `none`, parser แบบไม่ลงนามหรือแบบ `unsecured`   |
| **PHP**                     | firebase/php-jwt        | ไม่ (`Key` ระบุ alg ไว้แล้ว)                                                | `none`                                          |
| **Rust**                    | jsonwebtoken            | ไม่ (`Validation` บังคับให้ระบุอัลกอริทึม)                                  | `none`, `insecure_disable_signature_validation` |
| **C#**                      | Microsoft.IdentityModel | ไม่ (พารามิเตอร์เขียนแยกหลายบรรทัด)                                         | `none`, `RequireSignedTokens = false`           |

**เคล็ดลับ**

hook ตัดสินเฉพาะเรื่องการตรึงอัลกอริทึม: การตรวจ claim คีย์ และ flow เป็นเรื่องที่ต้องใช้วิจารณญาณ ซึ่ง [ความรู้เฉพาะทาง `federation`](https://lagune.ai/th-TH/docs/catalog) ยังคงดูแลอยู่

## คำถามที่พบบ่อย

### algorithm confusion ของ JWT คืออะไร

ตัวตรวจสอบที่อ่านอัลกอริทึมจาก header ของโทเค็นเปิดช่องให้ผู้โจมตีสลับ RS256 เป็น HS256 แล้วลงนามด้วย public key การตรึงรายการอัลกอริทึมที่อนุญาตอย่างเหมาะสมไว้ในโค้ดช่วยป้องกันได้ และ hook jwt จะชี้ว่าการเรียก verify ที่ไม่ได้กำหนดรายการไว้ หรือกำหนดรายการที่ไม่ปลอดภัย เป็นปัญหา

---

# Hook network: ประเมินความเสี่ยง SSRF ของ URL

> ประเมินความเสี่ยง SSRF ของปลายทางการ fetch หนึ่งหรือหลายรายการได้จากบรรทัดคำสั่งโดยตรง

Canonical: https://lagune.ai/th-TH/docs/hooks/network
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/network
อัปเดตล่าสุด: 2026-11-07

hook `network` ตัดสินว่าปลายทางที่เซิร์ฟเวอร์จะ fetch ปลอดภัยจาก **SSRF** หรือไม่ (request ที่อาจถูกเล็งไปยังบริการภายใน cloud metadata หรือโฮสต์ส่วนตัว) hook นี้คือเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `network`](https://lagune.ai/th-TH/docs/catalog) และคุณรันเองได้

## การรัน

ส่งปลายทางแต่ละรายการด้วย `--url` แล้ว hook จะพิมพ์คำหนึ่งคำต่อปลายทางหนึ่งรายการ ซึ่งอ่านความหมายได้จากตารางด้านล่าง

**ปลายทางเดียว**

```bash
npx lagune read network --url 'http://example.com/'
# => safe

npx lagune read network --url 'http://0x7f000001/'
# => private-target
```

**หลายปลายทาง**

ใส่ `--url` ซ้ำเพื่อประเมินรายการที่อนุญาตหรือรายการที่บล็อกทั้งชุดในการเรียกครั้งเดียว โดยได้ผลตัดสินบรรทัดละหนึ่งรายการตามลำดับ

```bash
npx lagune read network \
  --url 'http://example.com/' \
  --url 'http://[::1]/' \
  --url 'http://allowed.com@evil.example/'
# => safe
# => private-target
# => parser-divergent
```

hook จะ resolve โฮสต์แบบเดียวกับที่เครือข่ายทำ รูปแบบที่เข้ารหัสของที่อยู่ภายในจึงหลุดรอดไปไม่ได้: เลขฐานสิบหก เลขฐานแปด เลขฐานสิบแบบไม่มีจุด รูปแบบย่อ IPv6 และ IPv4-mapped จะได้ผลเป็น `private-target` ทั้งหมด และในกรณีที่ validator ที่หละหลวมกับตัว fetch จริงอ่านได้เป็นคนละโฮสต์ ผลตัดสินจะเป็น `parser-divergent`

## วิธีอ่านผลตัดสิน

| ผลตัดสิน           | ความหมาย                                                                                      |
| ------------------ | --------------------------------------------------------------------------------------------- |
| `safe`             | ปลายทางเชื่อมต่อไปยังโฮสต์สาธารณะ และ validator ที่หละหลวมก็จะอ่านได้เป็นโฮสต์เดียวกัน        |
| `private-target`   | โฮสต์ resolve ไปเป็นที่อยู่แบบ private, loopback, link-local, unspecified หรือ cloud metadata |
| `parser-divergent` | validator ข้อความที่หละหลวมจะอ่านได้เป็นโฮสต์จริงคนละตัวกับโฮสต์ที่ตัว fetch เชื่อมต่อ        |
| `invalid url`      | สตริงนั้นแปลงเป็น URL ไม่ได้ จึงไม่มีอะไรให้ fetch                                            |

มีเพียง `safe` ที่หมายถึงอนุญาต ให้ถือว่า `private-target`, `parser-divergent` และ `invalid url` หมายถึงบล็อกทั้งหมด

### ตัวเลือก CLI

| ตัวเลือก | ค่า           | คำอธิบาย                                                                           |
| -------- | ------------- | ---------------------------------------------------------------------------------- |
| `--url`  | URL หรือโฮสต์ | ตรวจปลายทางหนึ่งรายการ ใส่ซ้ำเพื่อตรวจหลายรายการ โดยได้ผลตัดสินบรรทัดละหนึ่งรายการ |

ต้องมี `--url` อย่างน้อยหนึ่งรายการ เอนจินไม่รับปลายทางเป็นอาร์กิวเมนต์ตามตำแหน่งเปล่า ๆ จึงไม่มีทางสับสนปลายทางกับ flag

**ทำไมต้องเป็นค่าของ flag**

ปลายทางแต่ละรายการส่งเข้าไปเป็นค่าของ flag และไม่เคยนำไปแทรกลงในคำสั่งโดยตรง ค่าที่มีเครื่องหมายคำพูดหรือ backtick จึงไม่มีผลใด ๆ และ inject เข้า shell ไม่ได้ ครอบค่าด้วยเครื่องหมายคำพูดเดี่ยวเสมอ เพื่อไม่ให้ shell ของคุณขยายค่านั้นก่อน

**สิ่งที่ไม่ครอบคลุม**

hook นี้เป็นแบบ pure และไม่เคย resolve DNS ช่องว่างสองอย่างที่เกิดตอน runtime จึงอยู่นอกขอบเขต: **DNS rebinding** (ชื่อที่ resolve เป็นที่อยู่สาธารณะตอนตรวจ แต่เป็นที่อยู่ภายในตอน fetch) และ **redirect chain** (hop แรกผ่านการตรวจ แล้ว redirect เข้าสู่ภายใน) ปิดช่องว่างเหล่านี้ด้วยการ resolve เพียงครั้งเดียวแล้วเชื่อมต่อไปยังที่อยู่ที่ตรวจแล้ว และด้วยการปฏิเสธ redirect hook นี้กำหนดให้ชื่อ loopback ที่สงวนไว้ (`localhost` และกลุ่ม `.localhost`) เป็นที่อยู่ภายในโดยไม่ต้อง lookup แต่ชื่อ DNS อื่นทั้งหมดจะได้ผลเป็น `safe` เพราะการยืนยันว่าชื่อนั้น resolve เข้าสู่ภายในต้องอาศัยการ resolve จริง: รายการที่อนุญาตเป็นตัวป้องกันชื่อเหล่านั้น และเป็นสิ่งที่ checker นี้ตรวจสอบ

**เคล็ดลับ**

นี่คือการตรวจแบบเดียวกับที่ [ความรู้เฉพาะทาง `network`](https://lagune.ai/th-TH/docs/catalog) ใช้พิสูจน์ว่าตัวกรองปลายทางยังได้ผล

## คำถามที่พบบ่อย

### ทดสอบ URL ว่ามีช่องโหว่ SSRF ได้อย่างไร

รัน hook network ซึ่งจะประเมินปลายทางการ fetch และคืนค่าเป็น safe, private-target, parser-divergent หรือ invalid url มีเพียง safe ที่หมายถึงอนุญาต

### URL แบบ parser-divergent คืออะไร

URL ที่ parser แต่ละตัวอ่านได้ต่างกัน ซึ่งเป็นวิธีเลี่ยงการป้องกัน SSRF แบบคลาสสิก hook network ชี้ว่า URL แบบนี้เป็นปัญหาแทนที่จะอนุญาต

---

# Hook regex: ตรวจหา pattern ที่เสี่ยงต่อ ReDoS

> สแกนโค้ดเบสหา regex ที่เสี่ยงต่อ ReDoS หรือประเมิน pattern เดียว ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/regex
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/regex
อัปเดตล่าสุด: 2026-11-07

hook `regex` คือเอนจินตรวจความปลอดภัยของ regex แบบ deterministic ที่ [ความรู้เฉพาะทาง `regex`](https://lagune.ai/th-TH/docs/catalog) ใช้ และคุณรันเองได้ hook นี้ทำงานได้สองโหมดจากคำสั่งเดียว: โหมด **scan** ที่สแกนโค้ดเบสหา pattern ที่เสี่ยงต่อ **ReDoS** และ pattern ที่สร้างขึ้นตอน runtime และโหมด **check** ที่ประเมิน pattern เดียวที่คุณส่งให้

## สแกนโค้ดเบส

หากไม่ใส่ flag hook จะสแกนทั้งโปรเจกต์ `--dir` จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว และ `--file` จำกัดไว้ที่ไฟล์เดียว ทั้งสองตัวเลือกใส่ซ้ำได้และรวมผลเป็นรายงานเดียว โดยแต่ละไฟล์จะแสดงเพียงครั้งเดียวแม้มีเป้าหมายมากกว่าหนึ่งรายการครอบคลุมไฟล์นั้น

**ทั้งโปรเจกต์**

```bash
npx lagune read regex
```

**ไดเรกทอรีเดียว**

```bash
npx lagune read regex --dir src/services
```

**ไฟล์เดียว**

```bash
npx lagune read regex --file bin/import.pl
```

**หลายเป้าหมาย**

```bash
npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift
```

**กำหนดขีดจำกัด**

`--limit` กำหนดเกณฑ์ ReDoS สำหรับการสแกน (ค่าเริ่มต้น 25) ซึ่งเป็นขีดจำกัดเดียวกับที่โหมด check ใช้ ขีดจำกัดที่ต่ำกว่าจะเข้มงวดกว่า

```bash
npx lagune read regex --dir src/services --limit 15
```

ผลลัพธ์เป็นข้อความดิบที่หัวข้อของแต่ละส่วนบอกวิธีอ่านส่วนนั้น และจะแสดงส่วนใดก็ต่อเมื่อส่วนนั้นมีข้อตรวจพบเท่านั้น

```text
Vulnerable regular expressions found:

cmd/server/main.go
  ([a-z]+)+$ (exponential, search)

Dynamically built regular expressions (review manually by simulating a constructed regex):

app/payments.php
crates/parser/lexer.rs
lib/validate.py

Static regex wrapped in a constructor (use a literal instead):

config/token.rb
```

เมื่อไม่พบอะไร hook จะพิมพ์ออกมาเพียงบรรทัดเดียว

```bash
npx lagune read regex --dir src/clean
# => no unsafe patterns found
```

### วิธีอ่านแต่ละส่วน

| ส่วน                                                                                        | ความหมาย                                                                                                                                                                                            |
| ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Vulnerable regular expressions found`                                                      | pattern ที่เสี่ยงต่อ ReDoS จัดกลุ่มตามไฟล์ โดยแต่ละ pattern เยื้องอยู่ด้านล่าง ตามด้วยเหตุผลที่ไม่ปลอดภัยในวงเล็บ และขอบเขตกับ flag ของ pattern นั้นหากมี ทุกบรรทัดไม่ปลอดภัย จึงไม่แสดงผลตัดสินซ้ำ |
| `Regular expressions the analysis could not settle (review manually)`                       | pattern ที่การวิเคราะห์สรุปไม่ได้ภายในขีดจำกัดการทำงาน แสดงในรูปแบบเดียวกัน                                                                                                                         |
| `Dynamically built regular expressions (review manually by simulating a constructed regex)` | ไฟล์ที่สร้าง regex จากตัวแปร การต่อสตริง หรือการแทรกค่า (interpolation)                                                                                                                             |
| `Static regex wrapped in a constructor (use a literal instead)`                             | ไฟล์ที่ส่งสตริง literal ธรรมดาให้ constructor ของ regex ในกรณีที่ regex literal เรียบง่ายกว่าและไม่ต้องคอมไพล์ตอน runtime                                                                           |

ส่วนแรกคือข้อตรวจพบด้านความปลอดภัย ส่วนที่สองและสามไม่ใช่ข้อตรวจพบในตัวเอง: ทั้งสองส่วนชี้ไปยังโค้ดที่การตรวจแบบ static สรุปไม่ได้ จึงต้องให้คนอ่าน ส่วนที่สี่เป็นคำแนะนำเพื่อให้โค้ดชัดเจนขึ้น ไม่ใช่ข้อตรวจพบด้านความปลอดภัย

### ตัวเลือก CLI

| ตัวเลือก    | ค่า                  | คำอธิบาย                                                                                          |
| ----------- | -------------------- | ------------------------------------------------------------------------------------------------- |
| `--pattern` | ซอร์สของ regex       | ตรวจ pattern เดียว ใส่ซ้ำเพื่อตรวจหลาย pattern โดยได้ผลตัดสิน pattern ละหนึ่งรายการตามลำดับ       |
| `--flags`   | flag ของ regex       | ตรวจทุก `--pattern` ด้วย flag เหล่านี้ เช่น `im` ใช้กับโหมด check เท่านั้น                        |
| `--dir`     | ไดเรกทอรี            | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้                              |
| `--file`    | ไฟล์                 | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้                                    |
| `--limit`   | จำนวนเต็มที่ไม่ติดลบ | กำหนดขีดจำกัดการทำซ้ำของ ReDoS (ค่าเริ่มต้น 25) ใช้กับทั้งสองโหมด ขีดจำกัดที่ต่ำกว่าจะเข้มงวดกว่า |

หากไม่ระบุตัวเลือก hook จะสแกนทั้งโปรเจกต์ `--pattern` คือโหมด check และใช้ร่วมกับ `--dir` หรือ `--file` ไม่ได้

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `regex` เอง:

```bash
npx lagune write add --ignore test/fixtures --checker regex
```

```json
{
  "checkers": {
    "regex": { "gitignore": false, "ignore": ["test/fixtures"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

### ภาษาที่รองรับ

การสแกนอ่านภาษาเหล่านี้โดยแยกตามนามสกุลไฟล์ และอ่านแต่ละภาษาตามกฎของภาษานั้นเอง hook จึงไม่มีวันทดสอบ pattern จากภาษาหนึ่งด้วยกฎของอีกภาษา และข้ามไฟล์อื่นทั้งหมดแทนที่จะสแกนด้วยกฎที่ผิด

| #   | ภาษา                        | นามสกุลไฟล์                                                                                                  |
| --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ |
| 1   | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` |
| 2   | **Python**                  | `.py`, `.pyi`                                                                                                |
| 3   | **Ruby**                    | `.rb`                                                                                                        |
| 4   | **Go**                      | `.go`                                                                                                        |
| 5   | **PHP**                     | `.php`                                                                                                       |
| 6   | **Rust**                    | `.rs`                                                                                                        |
| 7   | **Java**                    | `.java`                                                                                                      |
| 8   | **C#**                      | `.cs`                                                                                                        |
| 9   | **C**                       | `.c`, `.h`                                                                                                   |
| 10  | **C++**                     | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx`                                                                 |
| 11  | **Kotlin**                  | `.kt`, `.kts`                                                                                                |
| 12  | **Swift**                   | `.swift`                                                                                                     |
| 13  | **Scala**                   | `.scala`, `.sc`                                                                                              |
| 14  | **Dart**                    | `.dart`                                                                                                      |
| 15  | **PowerShell**              | `.ps1`, `.psm1`, `.psd1`                                                                                     |
| 16  | **Elixir**                  | `.ex`, `.exs`                                                                                                |
| 17  | **Objective-C**             | `.m`, `.mm`                                                                                                  |
| 18  | **R**                       | `.r`                                                                                                         |
| 19  | **Julia**                   | `.jl`                                                                                                        |
| 20  | **Clojure**                 | `.clj`, `.cljs`, `.cljc`, `.edn`                                                                             |
| 21  | **Crystal**                 | `.cr`                                                                                                        |
| 22  | **Nim**                     | `.nim`, `.nims`                                                                                              |
| 23  | **V**                       | `.v`                                                                                                         |
| 24  | **D**                       | `.d`                                                                                                         |
| 25  | **Perl**                    | `.pl`, `.pm`                                                                                                 |

**ตรวจให้ได้มากที่สุด แต่ไม่ครบทุกกรณี**

hook นี้อ่านซอร์สโค้ดเป็นข้อความ จึงตัดสิน pattern ที่ประกอบขึ้นตอน runtime ไม่ได้ และ pattern ที่เขียนแยกหลายบรรทัด ซ่อนอยู่หลัง alias หรือเขียนในรูปแบบที่ hook ไม่รู้จัก อาจหลุดรอดไปได้ ให้ถือว่าส่วนต่าง ๆ เหล่านี้เป็นจุดเริ่มต้นที่หนักแน่น ไม่ใช่รายการที่ครบถ้วน และอ่านโค้ดต่อในจุดที่ส่วนเหล่านี้เข้าไม่ถึง

## ตรวจ pattern เดียว

ส่ง `--pattern` พร้อมซอร์สของ pattern เพื่อประเมิน hook จะพิมพ์คำเดียว: `safe`, `unsafe`, `undetermined` เมื่อการวิเคราะห์ถึงขีดจำกัดการทำงานก่อนสรุป pattern ได้ หรือ `invalid regex` ใส่ `--pattern` ซ้ำเพื่อประเมินหลาย pattern พร้อมกัน โดยได้ผลตัดสิน pattern ละหนึ่งรายการตามลำดับ

**pattern เดียว**

```bash
npx lagune read regex --pattern '(a+)+$'
# => unsafe

npx lagune read regex --pattern '^[a-z0-9_]{3,20}$'
# => safe
```

**หลาย pattern**

```bash
npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$'
# => unsafe
# => safe
```

**ใส่ flag**

`--flags` ตรวจทุก `--pattern` ในการเรียกครั้งนั้นด้วย flag ที่ pattern ใช้จริงตอนทำงาน เพราะ flag เปลี่ยนว่า pattern จะจับคู่อักขระใดบ้าง

```bash
npx lagune read regex --pattern '^(?:a|A)+$'
# => safe

npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i'
# => unsafe
```

**กำหนดขีดจำกัด**

`--limit` กำหนดขีดจำกัดการทำซ้ำ (ค่าเริ่มต้น 25) และใช้กับทุก `--pattern` ในการเรียกครั้งนั้น ขีดจำกัดที่ต่ำกว่าจะเข้มงวดกว่า

```bash
npx lagune read regex --pattern 'a?a?a?' --limit 2
# => unsafe
```

**ทำไมต้องครอบอาร์กิวเมนต์ด้วยเครื่องหมายคำพูด**

pattern แต่ละรายการส่งเข้าไปเป็นค่าของ flag และไม่เคยนำไปแทรกลงในคำสั่งโดยตรง ค่าที่มีเครื่องหมายคำพูดหรือ backtick จึงไม่มีผลใด ๆ และ inject เข้า shell ไม่ได้ ครอบ pattern ด้วยเครื่องหมายคำพูดเดี่ยวเสมอ เพื่อไม่ให้ shell ของคุณขยายค่านั้นก่อน

**เคล็ดลับ**

นี่คือเอนจินเดียวกับที่ [ความรู้เฉพาะทาง `regex`](https://lagune.ai/th-TH/docs/catalog) ใช้: การสแกนเปิดรอบการตรวจ ReDoS และการตรวจแบบ check ยืนยัน pattern ที่การสแกนพบ

## คำถามที่พบบ่อย

### ตรวจ regex ว่าเสี่ยงต่อ ReDoS จาก CLI ได้อย่างไร

รัน npx lagune read regex --pattern '<pattern>' แล้ว hook จะคืนค่าเป็น safe, unsafe, undetermined หรือ invalid regex

### สแกนทั้งโปรเจกต์หา regex ที่ไม่ปลอดภัยได้อย่างไร

รัน hook regex ในโหมด scan กับโค้ดเบส แล้ว hook จะรายงาน pattern ที่เสี่ยงต่อ ReDoS ในภาษาที่รองรับทั้ง 25 ภาษา

---

# Hook secrets: ตรวจหา secret ที่ฮาร์ดโค้ดไว้

> สแกนโค้ดเบสหาข้อมูลรับรองที่ฮาร์ดโค้ดไว้ได้จากบรรทัดคำสั่ง

Canonical: https://lagune.ai/th-TH/docs/hooks/secrets
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/hooks/secrets
อัปเดตล่าสุด: 2026-11-07

hook `secrets` ชี้ว่าเป็นปัญหาเมื่อพบ **ข้อมูลรับรองที่ฝังอยู่ในซอร์สโค้ด** แทนที่จะอ่านจาก environment โดยดูจาก **ที่มาของค่า** (ค่า literal หรือการอ่านจาก environment) ไม่ได้ดูจากเนื้อหาของค่า จึงไม่ต้องมีแคตตาล็อก prefix ของผู้ให้บริการแบบครบถ้วน และแทบไม่เกิดผลบวกลวงเลย hook นี้คือเอนจินแบบ deterministic เบื้องหลัง [ความรู้เฉพาะทาง `secrets`](https://lagune.ai/th-TH/docs/catalog)

signature รูปแบบของผู้ให้บริการ ข้อมูลรับรองใน connection string และค่า literal ที่กำหนดให้ identifier ซึ่งชื่อบ่งว่าเป็น secret **ไม่ขึ้นกับภาษา**: สตริงเดียวกันมีความหมายเหมือนกันในทุกไฟล์ ส่วนฮิวริสติกสองแบบที่ขึ้นกับไวยากรณ์ ได้แก่ การอ่าน environment ที่มีค่าเริ่มต้นแบบฮาร์ดโค้ด และ secret ที่ไหลเข้าสู่ log sink นั้น **เข้าใจภาษา** เอนจินจึงไม่มองหา `console.log` ของ JavaScript ในไฟล์ Rust และตรวจ `os.getenv("X", "default")` ของ Python แยกเป็นของภาษานั้นเอง

## การรัน

```bash
npx lagune read secrets                  # scans the whole project
npx lagune read secrets --dir src        # scans a directory
npx lagune read secrets --file config.ts # scans a single file
```

การสแกนพิมพ์ผลออกมาได้สูงสุดสองส่วน **Hardcoded secrets found** คือชุดข้อตรวจพบ (ค่าเริ่มต้นแบบฮาร์ดโค้ดของตัวแปร environment ที่ชื่อบ่งว่าเป็น secret ข้อมูลรับรองที่ฝังอยู่ใน connection string หรือค่าที่ตรงกับรูปแบบของผู้ให้บริการที่คัดสรรไว้) hook จึงจบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์ ส่วน **Secret handling to review manually** คือชุดเบาะแส: ค่า literal ธรรมดาที่กำหนดให้ identifier ซึ่งชื่อบ่งว่าเป็น secret (ระบุที่มาได้ แต่บอกไม่ได้ว่าค่านั้นเป็น secret จริงหรือไม่) และค่าที่ชื่อบ่งว่าเป็น secret ซึ่งไหลเข้าสู่ log sink หรือ response sink การรันที่ไม่พบปัญหาจะพิมพ์ `no hardcoded secrets found`

### ตัวเลือก CLI

| ตัวเลือก | ค่า       | คำอธิบาย                                                             |
| -------- | --------- | -------------------------------------------------------------------- |
| `--dir`  | ไดเรกทอรี | จำกัดการสแกนไว้ที่ไดเรกทอรีเดียว ใช้ซ้ำได้และใช้ร่วมกับ `--file` ได้ |
| `--file` | ไฟล์      | จำกัดการสแกนไว้ที่ไฟล์เดียว ใช้ซ้ำได้และใช้ร่วมกับ `--dir` ได้       |

หากไม่ระบุตัวเลือก hook จะสแกนทั้งโปรเจกต์

### เลือกสิ่งที่จะสแกน

hook นี้ข้ามสิ่งที่ **Git** ละเว้นไว้ หากต้องการข้ามมากกว่านั้น หรือต้องการสแกนสิ่งที่ **Git** ละเว้นไว้ ให้กำหนดการตั้งค่าเฉพาะของ `secrets` เอง:

```bash
npx lagune write add --ignore test/fixtures --checker secrets
```

```json
{
  "checkers": {
    "secrets": { "gitignore": false, "ignore": ["test/fixtures"] }
  }
}
```

[กำหนดค่า hook](https://lagune.ai/th-TH/docs/hooks/configure) อธิบายการตั้งค่าทั้งหมด

### ภาษาที่รองรับ

ข้อตรวจพบเรื่องค่าเริ่มต้นของ environment และเบาะแสเรื่อง log sink อ่านรูปแบบโค้ดที่ต่างกันในแต่ละภาษา จึงครอบคลุมเฉพาะภาษาด้านล่างและไม่แจ้งอะไรในภาษาอื่น ส่วนสัญญาณอีกสามแบบทำงานกับ **ทุก** ไฟล์

| สัญญาณ                      | ภาษา                                                                            |
| --------------------------- | ------------------------------------------------------------------------------- |
| ค่าเริ่มต้นของ environment  | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# |
| log sink หรือ response sink | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C#    |

**นี่เป็นปัญหาด้านนโยบายหรือไม่**

ไม่ใช่ การตรวจหารูปแบบของ secret เพื่อเตือนว่ามีการ commit secret เข้าไปเป็นงานมาตรฐานของเครื่องมือความปลอดภัยเชิงป้องกัน และเป็นการทำงานแบบเดียวกับที่ gitleaks, trufflehog และ GitHub push-protection ทำ hook นี้มาพร้อม signature สำหรับตรวจจับ (**รูปแบบ** ของโทเค็นที่เปิดเผยต่อสาธารณะ) ไม่เคยมี secret จริง และทำหน้าที่ตรวจสอบและอธิบาย ไม่ได้ลักลอบนำข้อมูลออก

## คำถามที่พบบ่อย

### hook secrets หลีกเลี่ยงผลบวกลวงได้อย่างไร

hook นี้ดูจากที่มาของค่า ไม่ได้ดูจากเนื้อหาของค่า รูปแบบที่มีความมั่นใจสูง (โทเค็นของผู้ให้บริการ ค่าเริ่มต้นของ environment และ connection string) เป็นข้อตรวจพบที่ทำให้จบการทำงานด้วย exit code ที่ไม่ใช่ศูนย์ ค่า literal ธรรมดาที่กำหนดให้ identifier ซึ่งชื่อบ่งว่าเป็น secret เป็นเบาะแสให้ตรวจทานและยืนยัน ส่วน identifier เดียวกันที่อ่านค่าจาก process.env นั้น hook จะไม่ทำเครื่องหมายเลย

---

# ตัวอย่าง prompt ของ Lagune: ทำขั้นตอนแบบ Blue Team ให้เป็นอัตโนมัติ

> Prompt ของ Lagune ที่พร้อมคัดลอก: การสแกนแบบอ่านอย่างเดียว ขั้นตอนแบบ Blue Team เต็มรูปแบบ และการตรวจสอบแบบ Zero Trust รวมถึงการตรวจจับที่จำกัดขอบเขตไว้ที่ commit, diff ของ branch หรือ PR หรือเหตุการณ์จริง

Canonical: https://lagune.ai/th-TH/docs/examples/prompts
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/examples/prompts
อัปเดตล่าสุด: 2026-11-07

prompt ของ Lagune ที่พร้อมคัดลอกไปวางในเอเจนต์ AI ของคุณได้ทันที

## 💧 สแกนแบบรวดเร็ว

การสแกนแบบอ่านอย่างเดียวที่อ่านโค้ดด้วยตัวเองและรายงานจุดบกพร่องทุกจุดพร้อมการแก้ไข โดยไม่รันขั้นตอนแบบ Blue Team และไม่เขียนอะไรลงในการติดตามของ Lagune

**เคล็ดลับ**

ได้ผลดีกว่าในโหมดวางแผน และเมื่อกำหนด charter (`/lagune-charter`) ไว้แล้ว

**🪼 ค่าเริ่มต้น**

| ด้าน             | ข้อแลกเปลี่ยน                                           | ระดับ               |
| ---------------- | ------------------------------------------------------- | ------------------- |
| **ปริมาณงาน**    | เอเจนต์ 1 ตัวสแกนและรายงาน ไม่มีซับเอเจนต์              | 1/5 |
| **เวลา**         | เร็ว อ่านอย่างเดียวรอบเดียวและไม่นำอะไรไปใช้            | 2/5 |
| **การใช้ token** | ปานกลางและใช้บริบทร่วมกัน การสแกนทั้งหมดรันในบริบทเดียว | 2/5 |

```md
/lagune คุณคือนักวิจัยด้านความปลอดภัยไซเบอร์ที่เชี่ยวชาญด้านความปลอดภัยเชิงป้องกันอย่างลึกซึ้ง และใช้ Lagune เพื่อเพิ่มความรู้และความแม่นยำของคุณ

สแกนเวิร์กสเปซด้วยตัวเอง และจับคู่จุดบกพร่องทุกจุดที่พบกับการแก้ไขที่เป็นรูปธรรม นี่คือการสแกนแบบแยกเดี่ยว ไม่ใช่ขั้นตอนแบบ Blue Team: ห้ามรัน detect, plan, harden หรือ verify และห้ามเขียนอะไรลงในการติดตามของ Lagune

สุดท้าย แสดงรายการจุดบกพร่องทุกจุดที่พบ พร้อมระดับความรุนแรงและการแก้ไขที่เป็นรูปธรรมของแต่ละจุด
```

**🐬 หลายเอเจนต์**

| ด้าน             | ข้อแลกเปลี่ยน                                                   | ระดับ               |
| ---------------- | --------------------------------------------------------------- | ------------------- |
| **ปริมาณงาน**    | ซับเอเจนต์ 1 ตัวต่อ 1 ไฟล์ ปรับจำนวนตามขนาดโค้ดเบสของคุณ        | 2/5 |
| **เวลา**         | รันขนานกันรายไฟล์ แล้วรวมเป็นรายงานเดียว และยังคงอ่านอย่างเดียว | 3/5 |
| **การใช้ token** | สูงกว่า แต่แยกขาดจากกัน ซับเอเจนต์แต่ละตัวสแกนในบริบทของตัวเอง  | 3/5 |

````md
/lagune คุณคือ orchestrator ด้านความปลอดภัยไซเบอร์ที่ใช้ Lagune เพื่อแจกแจง path ส่งซับเอเจนต์ 1 ตัวต่อ 1 path และรวมรายงานของซับเอเจนต์ทั้งหมด (ซับเอเจนต์เป็นผู้อ่านเนื้อหาทั้งหมด)

คุณต้องมอบหมายงานให้ซับเอเจนต์ตามขนาดของโปรเจกต์ปัจจุบัน: ยิ่งโค้ดเบสใหญ่ ยิ่งต้องส่งซับเอเจนต์มากขึ้น โดยรันทั้งหมดขนานกัน และให้ prompt ด้านล่างนี้กับซับเอเจนต์แต่ละตัว:

```prompt
/lagune คุณคือนักวิจัยด้านความปลอดภัยไซเบอร์ที่เชี่ยวชาญด้านความปลอดภัยเชิงป้องกันอย่างลึกซึ้ง และใช้ Lagune เพื่อเพิ่มความรู้และความแม่นยำของคุณ

สแกน <path> ด้วยตัวเอง และจับคู่จุดบกพร่องทุกจุดที่พบกับการแก้ไขที่เป็นรูปธรรม นี่คือการสแกนแบบแยกเดี่ยว ไม่ใช่ขั้นตอนแบบ Blue Team: ห้ามรัน detect, plan, harden หรือ verify และห้ามเขียนอะไรลงในการติดตามของ Lagune

สุดท้าย แสดงรายการจุดบกพร่องทุกจุดใน <path> พร้อมระดับความรุนแรงและการแก้ไขที่เป็นรูปธรรมของแต่ละจุด
```

สุดท้าย รวมรายงานของซับเอเจนต์ทั้งหมดเป็นรายการจุดบกพร่องและการแก้ไขรายการเดียวที่เรียงตามลำดับความสำคัญ
````

**คำเตือน**

การสแกนแบบรวดเร็วคือ prompt เดียวที่กว้างและไม่จำกัดขอบเขต เอเจนต์บางตัวจึงมีแนวโน้มจะปฏิเสธหรือหยุดกลางคัน หากเอเจนต์ของคุณไม่ยอมทำ ให้รัน **ขั้นตอนแบบ Blue Team** เต็มรูปแบบด้านล่างแทน: เฟสต่าง ๆ ที่จำกัดขอบเขตและทำทีละขั้นถูกบล็อกน้อยกว่ามาก

---

## 🌊 การตรวจสอบแบบ Blue Team อัตโนมัติ

รัน [ขั้นตอนคำสั่งทั้งหมด](https://lagune.ai/th-TH/docs/get-started/commands) ตั้งแต่ต้นจนจบ

**🪼 ค่าเริ่มต้น**

| ด้าน             | ข้อแลกเปลี่ยน                                                                      | ระดับ               |
| ---------------- | ---------------------------------------------------------------------------------- | ------------------- |
| **ปริมาณงาน**    | เอเจนต์ 1 ตัว ไม่มีซับเอเจนต์ ไม่ว่าโค้ดเบสจะใหญ่แค่ไหน                            | 3/5 |
| **เวลา**         | ปานกลาง แต่ละเอียดน้อยลงในโค้ดเบสขนาดใหญ่ แต่ละคำสั่งรันครั้งเดียวต่อกันไปตามลำดับ | 4/5 |
| **การใช้ token** | น้อยกว่า แต่แยกขาดน้อยกว่า ทุกคำสั่งใช้บริบทเดียวกัน                               | 4/5 |

```md
รันคำสั่งต่อไปนี้ทีละคำสั่ง: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` และ `/lagune-verify`

## วนซ้ำ

เมื่อ `/lagune-verify` ปฏิเสธการแก้ไขตั้งแต่หนึ่งรายการขึ้นไป ให้รัน `/lagune-harden` แล้วตามด้วย `/lagune-verify` ซ้ำจนกว่าข้อตรวจพบทั้งหมดจะได้รับการแก้ไขอย่างถูกต้อง
```

**🐋 หลายเอเจนต์ (Deep Scan)**

| ด้าน             | ข้อแลกเปลี่ยน                                                                                         | ระดับ               |
| ---------------- | ----------------------------------------------------------------------------------------------------- | ------------------- |
| **ปริมาณงาน**    | จำนวนซับเอเจนต์ปรับตามขนาดโค้ดเบสของคุณ                                                               | 5/5 |
| **เวลา**         | นานกว่า แต่ละเอียดกว่า ส่งซับเอเจนต์หลายตัวไปตรวจจับ วางแผน และเสริมความปลอดภัยให้ข้อตรวจพบแบบขนานกัน | 5/5 |
| **การใช้ token** | สูงกว่า แต่ปลอดภัยกว่า ซับเอเจนต์แต่ละตัวมีบริบทแยกของตัวเองโดยไม่มีอคติ                              | 5/5 |

````md
รันคำสั่งต่อไปนี้ โดยให้ซับเอเจนต์ 1 ตัวต่อ 1 คำสั่ง ทีละตัว (ไม่ต้องใส่ backtick ส่งแค่คำสั่ง):

prompt ของซับเอเจนต์ 1: `/lagune-charter`
prompt ของซับเอเจนต์ 2: `/lagune-detect`
prompt ของซับเอเจนต์ 3: `/lagune-plan`
prompt ของซับเอเจนต์ 4: `/lagune-harden`
prompt ของซับเอเจนต์ 5: `/lagune-verify`

ในคำสั่ง `/lagune-detect`, `/lagune-plan`, `/lagune-harden` และ `/lagune-verify` คุณต้องมอบหมายงานให้ซับเอเจนต์ตามขนาดของโปรเจกต์ปัจจุบัน: ยิ่งโค้ดเบสใหญ่ ยิ่งต้องส่งซับเอเจนต์มากขึ้น ตัวอย่างเช่น:

```prompt
/lagune-detect <path>
```

```prompt
/lagune-plan <finding>
```

```prompt
/lagune-harden <finding>
```

```prompt
/lagune-verify <finding>
```

- เอเจนต์หลายตัวที่ทำคำสั่งเดียวกันต้องรันขนานกัน
- เมื่อซับเอเจนต์ `/lagune-detect` ทั้งหมดทำงานเสร็จ ให้รัน:

```prompt
/lagune-detect รวมข้อตรวจพบที่เทียบเท่ากัน ไม่ต้องตรวจหาข้อตรวจพบใหม่ และไม่ต้องสแกนโค้ดเบสซ้ำ
```

## วนซ้ำ

เมื่อ `/lagune-verify` ปฏิเสธการแก้ไขตั้งแต่หนึ่งรายการขึ้นไป ให้รัน `/lagune-harden` แล้วตามด้วย `/lagune-verify` ซ้ำจนกว่าข้อตรวจพบทั้งหมดจะได้รับการแก้ไขอย่างถูกต้อง
````

---

## 🪄 การตรวจจับแบบจำกัดขอบเขต

ชี้คำสั่ง [`/lagune-detect`](https://lagune.ai/th-TH/docs/commands/detect) ไปที่บางส่วนของโปรเจกต์แทนทั้งโปรเจกต์ อธิบายขอบเขตด้วยภาษาธรรมดา (commit, pull request หรือสถานการณ์จริง) แล้วคำสั่งจะทำแผนผังเฉพาะข้อตรวจพบที่เกี่ยวกับความปลอดภัยในส่วนนั้น

**เคล็ดลับ**

ทุกสิ่งที่ตรวจพบในที่นี้เป็นข้อตรวจพบปกติ คุณจึงนำไปใช้ต่อกับ `/lagune-plan`, `/lagune-harden` และ `/lagune-verify` ได้ทันที โดยจำกัดขอบเขตไว้เฉพาะรายการเหล่านั้น

**📌 ตั้งแต่ commit หนึ่ง**

ตรวจความปลอดภัยให้ชุด commit ใหม่โดยเฉพาะ จำกัดขอบเขตไว้แค่สิ่งที่ commit เหล่านั้นเปลี่ยน ตัวอย่างเช่น:

```prompt
/lagune-detect จำกัดขอบเขตการตรวจจับไว้ที่ทุกสิ่งที่เปลี่ยนไปตั้งแต่ commit `a1b2c3d`
```

**🔀 diff ของ branch หรือ PR**

ตรวจความปลอดภัยของ pull request ก่อน merge โดยจำกัดขอบเขตไว้แค่ diff ของ pull request นั้น ตัวอย่างเช่น:

```prompt
/lagune-detect จำกัดขอบเขตการตรวจจับไว้ที่การเปลี่ยนแปลงที่ branch นี้นำเข้ามาเมื่อเทียบกับ `main`
```

**⛑️ หลังเกิดเหตุ**

เล่าสิ่งที่เกิดขึ้นด้วยคำพูดของคุณเอง Lagune อ่านสถานการณ์ ไม่ใช่ flag แล้วเปลี่ยนเป็นการไล่ตรวจที่เจาะจง ตัวอย่างเช่น:

```prompt
/lagune-detect เว็บไซต์ของเราเกิดข้อมูลรั่วไหลเมื่อไม่กี่สัปดาห์ก่อน ไม่รู้แน่ชัดว่าเกิดขึ้นได้อย่างไร และกังวลว่ายังมีช่องโหว่ที่เปิดอยู่ซึ่งอาจทำให้ข้อมูลรั่วอีก ไล่ตรวจโค้ดอย่างละเอียด เน้นทุกจุดที่มีการอ่าน จัดเก็บ หรือเปิดเผยข้อมูลที่ละเอียดอ่อน และทำแผนผังทุกอย่างที่อาจยังเป็นทางให้ข้อมูลหลุดออกไปได้ ให้ถือว่านี่คือเหตุการณ์จริง ไม่ใช่การซ้อม
```

---

## 🚨 การตรวจสอบแบบ Zero Trust

ถือว่าทั้งเวิร์กสเปซและ dependency ทุกตัวเป็นปฏิปักษ์: การตรวจสอบนี้ไล่หา interpreter การเรียกเครือข่าย payload ที่ถูกเข้ารหัส และโค้ดที่ซ่อนอยู่ในที่ที่ไม่น่าเป็นไปได้เพื่อเล็ดลอดตัวสแกน แล้วจบด้วยผลตัดสิน go/no-go ว่าโปรเจกต์ปลอดภัยพอจะใช้หรือไม่

prompt เหล่านี้โหลดความรู้เฉพาะทางที่การตรวจสอบนี้ต้องใช้โดยตรง ไม่ว่าโปรเจกต์ของคุณจะใช้หมวดหมู่ใด สำหรับส่วนอื่นของแคตตาล็อกที่ `/lagune` จับคู่ ให้ตรวจว่าโปรเจกต์ใช้ **OWASP**, **AI/LLM** และหมวดหมู่ของ stack ที่ใช้ (เช่น **JavaScript**, **Python** และอื่น ๆ):

```bash
npx lagune write add --categories owasp ai javascript
```

ไฟล์ `.gitignore` และการตั้งค่าของ repository เองอาจซ่อนไฟล์จากตัวตรวจได้ จึงควรตั้งบล็อก `checkers` ใน `.lagune/configs.json` ให้ [สแกนทุกอย่าง](https://lagune.ai/th-TH/docs/hooks/configure) โดยแทนที่บล็อกใด ๆ ที่มากับ repository:

```json
{
  "checkers": { "gitignore": false }
}
```

**อันตราย**

ระวังเมื่อรันโปรเจกต์จากแหล่งที่ไม่น่าเชื่อถือในสภาพแวดล้อมบนเครื่องของคุณ ใช้สภาพแวดล้อมที่แยกออกมา เช่น **sandbox** (แนะนำ), **VM** หรือสภาพแวดล้อมที่คล้ายกัน เพื่อไม่ให้โค้ดอันตรายส่งผลต่อระบบของคุณ

**🪼 ค่าเริ่มต้น**

| ด้าน             | ข้อแลกเปลี่ยน                                                                            | ระดับ               |
| ---------------- | ---------------------------------------------------------------------------------------- | ------------------- |
| **ปริมาณงาน**    | เอเจนต์ 1 ตัวสแกนทั้งเวิร์กสเปซ ไม่มีซับเอเจนต์                                          | 2/5 |
| **เวลา**         | ปานกลาง เอเจนต์ 1 ตัวไล่ตรวจโค้ดและ dependency ตามลำดับ                                  | 3/5 |
| **การใช้ token** | ปานกลาง แต่ใช้บริบทร่วมกัน ความรู้เฉพาะทาง โค้ด และ dependency ทั้งหมดโหลดเข้าบริบทเดียว | 3/5 |

```md
/lagune คุณคือนักวิจัยด้านความปลอดภัยไซเบอร์ที่เชี่ยวชาญด้านความปลอดภัยเชิงป้องกันแบบ zero trust อย่างลึกซึ้ง และใช้ Lagune เพื่อเพิ่มความรู้และความแม่นยำของคุณ

ทำแผนผังทั้งเวิร์กสเปซโดยถือว่าเป็นแหล่งที่ไม่น่าเชื่อถือและเป็นขอบเขตที่อาจเป็นอันตราย ทุก interpreter, fetch, base64 และสิ่งที่คล้ายกัน ต้องถือว่าเป็นภัยคุกคามที่อาจเกิดขึ้น

ขยายการวิเคราะห์ไปถึง dependency และ dependency ย่อย: โปรเจกต์อาจพยายามซ่อนโค้ดอันตรายไว้ในที่ที่ไม่น่าเป็นไปได้เพื่อเล็ดลอดตัวสแกน

ความรู้เฉพาะทางที่ต้องใช้ (โหลดทีละตัวด้วย `npx lagune read catalog <name>`):

- interpreter
- secrets
- llm
- path

ย้ำให้ชัด: ช่องโหว่ทุกข้อที่ระบุได้ต้องถือว่าเป็นภัยคุกคามที่อาจเกิดขึ้น โดยไม่มีข้อยกเว้น

สุดท้าย ให้ผลตัดสินว่าโปรเจกต์นี้ปลอดภัยและน่าเชื่อถือพอให้ฉันใช้หรือไม่
```

**🐋 หลายเอเจนต์ (Deep Scan)**

| ด้าน             | ข้อแลกเปลี่ยน                                                                       | ระดับ               |
| ---------------- | ----------------------------------------------------------------------------------- | ------------------- |
| **ปริมาณงาน**    | ซับเอเจนต์ 1 ตัวต่อ 1 ไฟล์ ปรับจำนวนตามขนาดโค้ดเบสของคุณ                            | 5/5 |
| **เวลา**         | นานกว่า แต่ละเอียดกว่า สแกนไฟล์แบบขนานกัน แล้วรวมเป็นผลตัดสินเดียว                  | 4/5 |
| **การใช้ token** | สูงที่สุด แต่ปลอดภัยที่สุด ซับเอเจนต์แต่ละตัวอ่านความรู้เฉพาะทางในบริบทแยกของตัวเอง | 5/5 |

````md
/lagune คุณคือ orchestrator ด้านความปลอดภัยไซเบอร์ที่ใช้ Lagune เพื่อแจกแจงไฟล์ ส่งซับเอเจนต์ 1 ตัวต่อ 1 ไฟล์ และสร้างรายงาน (ซับเอเจนต์เป็นผู้อ่านเนื้อหาทั้งหมด)

ส่งซับเอเจนต์ 1 ตัวต่อ 1 ไฟล์ โดยรันทั้งหมดขนานกัน และให้ prompt ด้านล่างนี้กับซับเอเจนต์แต่ละตัว โดยจำกัดขอบเขตไว้ที่ไฟล์ของตัวเอง:

```prompt
/lagune คุณคือนักวิจัยด้านความปลอดภัยไซเบอร์ที่เชี่ยวชาญด้านความปลอดภัยเชิงป้องกันแบบ zero trust อย่างลึกซึ้ง และใช้ Lagune เพื่อเพิ่มความรู้และความแม่นยำของคุณ

ถือว่า <file> เป็นแหล่งที่ไม่น่าเชื่อถือและเป็นขอบเขตที่อาจเป็นอันตราย ทุก interpreter, fetch, base64 และสิ่งที่คล้ายกัน ต้องถือว่าเป็นภัยคุกคามที่อาจเกิดขึ้น

ขยายการวิเคราะห์ไปถึงทุกสิ่งที่ <file> import รวมถึง dependency และ dependency ย่อย ซึ่งเป็นที่ที่โค้ดอันตรายอาจซ่อนอยู่เพื่อเล็ดลอดตัวสแกน

ความรู้เฉพาะทางที่ซับเอเจนต์ทุกตัวต้องใช้ (โหลดทีละตัวด้วย `npx lagune read catalog <name>`):

- interpreter
- secrets
- llm
- path

ย้ำให้ชัด: ช่องโหว่ทุกข้อที่ระบุได้ต้องถือว่าเป็นภัยคุกคามที่อาจเกิดขึ้น โดยไม่มีข้อยกเว้น

สุดท้าย ให้ผลตัดสินว่าโปรเจกต์นี้ปลอดภัยและน่าเชื่อถือพอให้ฉันใช้หรือไม่
```

สุดท้าย รวมรายงานของซับเอเจนต์ทั้งหมดเป็นผลตัดสินสุดท้ายเพียงผลเดียว
````

---

# Security-Driven Hardening: แนวปฏิบัติสำหรับยุคการพัฒนาที่มี AI ช่วย

> ระเบียบวิธี Security-Driven Hardening (SDH): แนวปฏิบัติแบบ Blue Team ที่เข้าใจบริบท สำหรับตรวจสอบและเสริมความปลอดภัยให้ซอฟต์แวร์ที่เขียนด้วย AI และ vibe coding

Canonical: https://lagune.ai/th-TH/docs/references/paper
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/references/paper
อัปเดตล่าสุด: 2026-11-07

- **Weslley Araújo**
- **เอกสารระเบียบวิธี ปี 2026**

---

## บทคัดย่อ

Security-Driven Hardening (SDH) คือระเบียบวิธีด้านความปลอดภัยที่มีโครงสร้างชัดเจน ขับเคลื่อนด้วย AI และเพื่อการป้องกันเท่านั้น สำหรับยุคที่เอเจนต์ AI และผู้ที่ไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัยเป็นผู้เขียนซอฟต์แวร์มากขึ้นเรื่อย ๆ แทนที่จะไล่ตามเช็กลิสต์ทั่วไป SDH ตรวจจับก่อนว่าระบบทำอะไรจริง (การล็อกอิน การอัปโหลดไฟล์ การชำระเงิน การเปิดเผยข้อมูล และอื่น ๆ) แล้วจึงขับเคลื่อนงานด้านความปลอดภัยที่เฉพาะกับบริบทนั้น SDH ยึดหลักการที่ปลอดภัยตั้งแต่ค่าเริ่มต้น วางกรอบทั้งหมดไว้ที่การป้องกัน และสื่อสารด้วยภาษาที่เข้าใจง่าย ผู้ใช้ทุกคนจึงลงมือทำตามได้

เอกสารนี้เสนอว่า SDH คือแนวปฏิบัติที่ยังขาดหายไป ไม่ใช่เครื่องมือเพียงตัวเดียว ความรู้ด้านความปลอดภัยอยู่ในระเบียบวิธีและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น เป็นพื้นฐานที่ผู้ใช้ทุกคนต่อยอดได้ SDH จึงรองรับทั้งมือใหม่และผู้เชี่ยวชาญผ่านขั้นตอนเดียวกัน คุณสมบัติสองข้อทำให้ SDH ต่างจากแนวทาง spec-first ก่อนหน้า `[1]` ข้อแรก SDH **ไม่ขึ้นกับสถานะ** ของโปรเจกต์: ปรับใช้ได้กับไดเรกทอรีว่าง โปรเจกต์ที่กำลังพัฒนา pull request เดียว หรือโค้ดเบสเก่าขนาดใหญ่ ใน stack ใดก็ได้ ข้อสอง SDH **ปิดให้จบได้**: ความเสี่ยงที่ตรวจยืนยันแล้วว่าปิดแล้วจะปิดออกจากทั้งขั้นตอน ข้อตรวจพบนั้นจึงไปถึงสถานะสิ้นสุด และจะเปิดใหม่ก็ต่อเมื่อโค้ดเปลี่ยนเท่านั้น SDH ไม่ได้มาแทนผู้เชี่ยวชาญด้านความปลอดภัยหรือเครื่องมือ Blue Team เฉพาะทาง แต่ขยายความรู้ของนักพัฒนาเอง ยิ่งนักพัฒนาเข้าใจความปลอดภัยมากเท่าไร ก็ยิ่งกำหนดทิศทางของ SDH ได้มากเท่านั้น

**Lagune** คือต้นแบบอ้างอิง (reference implementation) ที่พิสูจน์ว่าระเบียบวิธีนี้สร้างได้จริงและย้ายไปใช้ที่อื่นได้ SDH เสนอตัวเป็นแนวปฏิบัติที่ผู้อื่นนำไปใช้ได้

> **คำสำคัญ**
>
> การพัฒนาที่มี AI ช่วย ความปลอดภัยของซอฟต์แวร์ ความปลอดภัยเชิงป้องกัน spec-driven development การเสริมความปลอดภัย (security hardening) เวิร์กโฟลว์ที่เอเจนต์ขับเคลื่อน การปิดให้จบได้ ความปลอดภัยที่เข้าใจบริบท ความรู้ที่โหลดเฉพาะเมื่อจำเป็น และเครื่องมือที่ไม่ผูกกับเอเจนต์

---

## I. บทนำ: ช่องว่างด้านความปลอดภัยที่การพัฒนาด้วย AI เปิดไว้

ซอฟต์แวร์ที่ปล่อยออกมาทุกวันนี้มาจากคนและเอเจนต์ AI ที่ดูไม่ออกอย่างน่าเชื่อถือว่ารูปแบบใดไม่ปลอดภัยมากขึ้นเรื่อย ๆ: secret ที่รั่วไหล การตรวจสอบสิทธิ์ที่ขาดหายไป หรือคิวรีที่เปิดช่องให้ injection ความเสี่ยงเหล่านี้ไม่ใช่เรื่องแปลกใหม่ แต่อยู่ในกลุ่มความเสี่ยงที่พบมากที่สุดในเหตุการณ์จริง และมีบันทึกไว้ในเอกสารอ้างอิงสาธารณะมาหลายปี `[6]`, `[7]` ขณะที่งานวิจัยล่าสุดรายงานว่าโค้ดที่ AI สร้างในสัดส่วนที่มีนัยสำคัญมีข้อบกพร่องแบบนี้ติดไปด้วย `[8]` ผู้ช่วยเขียนโค้ด AI ทำให้ปัญหานี้รุนแรงขึ้น เพราะเปิดให้คนที่ไม่ใช่นักพัฒนาปล่อยซอฟต์แวร์ใช้งานจริงได้ แต่ช่องว่างนี้กว้างกว่ากลุ่มผู้ใช้กลุ่มใดกลุ่มหนึ่ง โปรเจกต์ส่วนใหญ่ไม่เคยได้รับการตรวจด้านความปลอดภัยที่เจาะจงกับสิ่งที่โปรเจกต์ทำจริง ระบบนิเวศจึงเปราะบางขึ้นทุกครั้งที่มีการตัดสินใจ "ใช้ได้แล้ว ปล่อยเลย" ก่อนเวลาอันควร

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

SDH ตอบโจทย์นี้ด้วยการกลับด้านเพียงครั้งเดียว: **ความรู้ด้านความปลอดภัยอยู่ในสเปกและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น เป็นพื้นฐานที่ผู้ใช้ทุกคนต่อยอดได้** ระเบียบวิธีนี้ตรวจจับบริบท คัดกรองความเสี่ยงที่บริบทนั้นมี และชี้นำการแก้ไข นักพัฒนาและผู้ที่ไม่ใช่นักพัฒนาจึงได้รับการดูแลผ่านขั้นตอนเดียวกัน ข้อตรวจพบและคำแนะนำใช้ภาษาที่เข้าใจง่าย ผู้อ่านทุกระดับความรู้ทางเทคนิคจึงลงมือทำตามได้ แนวทางนี้ไม่ได้จำกัดผู้เชี่ยวชาญ แต่ช่วยเพิ่มพลังให้ เป็นสองด้านที่เราอธิบายต่อใน `§VI`

> **ข้อคิดสำคัญ**
>
> **การกลับด้านที่เป็นแก่น**: ความรู้ด้านความปลอดภัยอยู่ในสเปกและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น เป็นพื้นฐานที่ผู้ใช้ทุกคนต่อยอดได้ ระเบียบวิธีนี้เรียนรู้ว่าระบบทำอะไร แล้วจับคู่งานด้านความปลอดภัยให้ตรงกับสิ่งนั้น และขยายสิ่งที่ผู้ใช้รู้อยู่แล้ว

ลองนึกถึงนักพัฒนาที่บอกผู้ช่วย AI ว่า "แอปของฉันให้ผู้ใช้อัปโหลดรูปโปรไฟล์ได้" หากไม่มีการตรวจด้านความปลอดภัย ผู้ช่วยจะสร้างโค้ดที่ทำงานได้ แต่เชื่อทุกอย่างที่ไคลเอนต์ส่งมาอย่างเงียบ ๆ: ประเภทไฟล์ที่แจ้งมา ชื่อไฟล์ และขนาด ฟีเจอร์อัปโหลดออกสู่ผู้ใช้ แล้วไฟล์ที่ปลอมตัวเป็นรูปภาพก็อาจแฝงโค้ดมาได้ ชื่อไฟล์ที่จงใจสร้างขึ้นอาจหลุดออกนอก path ที่ใช้จัดเก็บ และไฟล์ขนาดใหญ่เกินไปอาจทำให้ทรัพยากรของเซิร์ฟเวอร์หมด ไม่มีปัญหาใดเลยที่มองเห็นได้ในการเดโม โค้ดจึงออกสู่ผู้ใช้ไปแบบนั้น

โค้ดเดียวกันเมื่อผ่าน SDH จะต่างออกไป SDH ตรวจพบว่าระบบรับไฟล์จากภายนอก (detect) คัดกรองสิ่งนั้นเป็นความเสี่ยงที่การอัปโหลดมี (triage) เสนอให้ตรวจประเภทและขนาดจริงของไฟล์ เปลี่ยนชื่อไฟล์ตอนบันทึก และจัดเก็บในที่ที่โค้ดรันไม่ได้ (remediate) จากนั้นอ่านผลลัพธ์และยืนยันว่ามาตรการควบคุมแต่ละรายการใช้ได้จริง (verify) นักพัฒนาไม่จำเป็นต้องรู้จักคำว่า "unrestricted file upload" เลย ระเบียบวิธีนี้เติมคำนั้นให้แทน

ผลงานของเอกสารนี้มีดังนี้:

- นิยามที่แม่นยำของ SDH ในฐานะระเบียบวิธีที่ไม่ขึ้นกับการนำไปสร้างแบบใดแบบหนึ่ง พร้อมหลักการออกแบบ (`§III`)
- วงจรการป้องกัน 5 เฟสที่การแบ่งหน้าที่คือผลงานในตัวเอง: การตรวจจับไม่แต่งเติม การวางแผนไม่อ่านโค้ด มีเพียงเฟสเดียวที่แก้โค้ด และการตรวจยืนยันไม่ผ่อนปรนการตัดสิน (`§IV`)
- **การปิดให้จบได้** ในฐานะจุดยืนเชิงระเบียบวิธี: ข้อตรวจพบแต่ละรายการมีสถานะสิ้นสุด ไม่ใช่วนไม่รู้จบ (`§V`)
- **ความเป็นสองด้านของการขยายความรู้นักพัฒนา** (dev-knowledge-extender duality): ขั้นตอนเดียวที่ปกป้องมือใหม่และเพิ่มพลังให้ผู้เชี่ยวชาญ (`§VI`)
- **ความรู้เฉพาะทางที่เรียกใช้โดยตรงไม่ได้และ prompt-on-demand**: ความรู้ด้านความปลอดภัยแบบเจาะจงที่เอเจนต์โหลดเมื่อบริบทของโปรเจกต์ต้องการ และไม่โหลดเป็นค่าเริ่มต้น (`§VII`)
- **ความไม่ขึ้นกับสถานะ** และ **การปรับตัวแบบไม่บังคับ**: SDH เข้ากับสถานะการพัฒนาใดก็ได้ และปรับตามสถานการณ์แทนการบังคับขอบเขตตายตัว (`§VIII`)
- **โหมดป้องกันล่วงหน้า**: การป้องกันชุดเดียวกันที่ทำงานขณะสร้างงานทั่วไป โค้ดจึงปลอดภัยตั้งแต่ค่าเริ่มต้นตั้งแต่แรก และเฟสต่าง ๆ มีสิ่งที่ต้องแก้น้อยลง (`§IX`)
- การเปรียบเทียบโดยเฉพาะกับ Spec-Driven Development สายวิวัฒนาการที่ SDH เติบโตมาแล้วแยกทางออกไป (`§X`)
- วินัยทางวิศวกรรมที่ทำให้ระเบียบวิธีอยู่รอดผ่านการ refactor และไม่ผูกกับเอเจนต์ใด: การติดตามด้วยอัตลักษณ์ตามชื่อ (`§XI`) และตัวนำส่งที่ไม่ผูกกับเอเจนต์ (`§XII`)

---

## II. ภูมิหลังและงานที่เกี่ยวข้อง

SDH ต่อยอดจากงานก่อนหน้า โดยรับโครงสร้างที่พิสูจน์แล้วมาจากการพัฒนาแบบ spec-first ที่เอเจนต์ขับเคลื่อน `[1]`, `[2]`, `[3]`: เทมเพลต คำสั่ง slash ที่เอเจนต์ใช้ เอกสารกำกับ และเอเจนต์ที่รันเฟสต่าง ๆ SDH นำโครงสร้างนั้นมาสร้างใหม่โดยมีเป้าหมายเพื่อการป้องกัน สายวิวัฒนาการนี้เป็นความตั้งใจ และหลักการทำงานข้อหนึ่งของ SDH ก็ระบุไว้ตรง ๆ: สร้างเวิร์กโฟลว์จากโครงสร้างที่พิสูจน์แล้ว จากนั้นวางกรอบให้เพื่อความปลอดภัย

SDH ไม่ใช่เช็กลิสต์ตายตัวที่รวมคำแนะนำทั่วไป เช็กลิสต์รู้เรื่องความปลอดภัยทั่วไปมาก แต่ไม่รู้อะไรเลยเกี่ยวกับโปรเจกต์ที่อยู่ตรงหน้า SDH กลับน้ำหนักนั้น โดยทุ่มแรงแรกไปที่การตรวจจับ คือการเรียนรู้ว่าระบบทำอะไร แล้วจึงหยิบความรู้ที่การตรวจจับนั้นทำให้เกี่ยวข้องขึ้นมาใช้

SDH ยังไม่ได้มาแทนคนทำงานด้านความปลอดภัยหรือเครื่องมือ Blue Team เฉพาะทาง แต่เป็นตัวขยายความรู้ของนักพัฒนา (`§VI`) ทีมที่มีฝ่ายความปลอดภัยโดยเฉพาะควรรักษาฝ่ายนั้นไว้ SDH มอบตัวนำส่งที่มีโครงสร้างให้ทีมนั้น และมอบพื้นฐานที่มีเหตุผลรองรับให้ทีมที่ไม่มี

SDH ยังอยู่เคียงข้างเครื่องมือสแกนความปลอดภัยแบบ deterministic (static analysis และ linter) `[4]`, `[5]` เครื่องมือเหล่านั้นมีคุณค่าก็เพราะเป็น deterministic และให้ผลซ้ำได้ SDH ส่วนใหญ่อาศัยการให้เหตุผลของเอเจนต์ ซึ่งแลกความเป็น deterministic อย่างเคร่งครัดกับความเข้าใจบริบท ระเบียบวิธีนี้ไม่แสร้งทำเป็นอย่างอื่น ในจุดที่ความเป็น deterministic สำคัญ SDH ฝังเอนจินแบบ deterministic ไว้ในการให้เหตุผล (`§VII`): เอเจนต์ตัดสินว่าอินพุตใดควรตรวจ และโปรแกรมแบบ deterministic ตัดสินว่าอินพุตนั้นอันตรายหรือไม่

งานก่อนหน้าที่ใกล้เคียงที่สุดคือ Spec-Driven Development (SDD) ตระกูลระเบียบวิธีแบบ spec-first ที่ขับเคลื่อนการสร้างไปข้างหน้าจากสเปกที่รันได้ เราถือว่า SDD เป็นกลุ่มหนึ่ง คำอธิบายที่ชัดเจนที่สุดในฐานะระเบียบวิธีสำหรับผู้ปฏิบัติงานคือรายงานของ Piskala `[1]` และชุดเครื่องมือที่เอเจนต์ขับเคลื่อนซึ่งเป็นที่รู้จักที่สุดคือ Spec Kit ของ GitHub `[2]` โดยมี OpenSpec `[3]` เป็นเครื่องมือที่สองจากตระกูลเดียวกัน ทั้งหมดนี้คือเอกสารอ้างอิงหลักสำหรับการเปรียบเทียบใน `§X`

---

## III. SDH: นิยามและหลักการออกแบบ

**Security-Driven Hardening** คือระเบียบวิธีด้านความปลอดภัยที่มีโครงสร้างและขับเคลื่อนด้วย AI ที่เปลี่ยนโค้ดเบสให้ปลอดภัยขึ้นด้วยการขับเคลื่อนงานจากสเปกที่เอเจนต์รัน แทนการแก้ไขแบบเฉพาะหน้า ชื่อนี้ได้แรงบันดาลใจจาก **Blue Teams** ฝ่ายผู้ป้องกันในวงการความปลอดภัย SDH มุ่งที่การป้องกัน การเสริมความปลอดภัย และการตรวจยืนยัน ไม่เคยเป็นการโจมตี

> **นิยาม**
>
> **Security-Driven Hardening (SDH)**: ระเบียบวิธีด้านความปลอดภัยที่มีโครงสร้าง ขับเคลื่อนด้วย AI และเพื่อการป้องกันเท่านั้น ที่ตรวจจับก่อนว่าระบบทำอะไรจริง แล้วจึงขับเคลื่อนงานด้านความปลอดภัยที่เฉพาะกับบริบทนั้น โดยยึดหลักการที่ปลอดภัยตั้งแต่ค่าเริ่มต้นและใช้ภาษาที่เข้าใจง่าย

SDH นิยามด้วยชุดหลักการที่มีผลผูกพัน แต่ละข้อเป็นกฎ และแต่ละข้อให้หลักประกันที่เจาะจงแก่ผู้ใช้

| หลักการ                                                                | กฎ                                                                                                                                                      | สิ่งที่ผู้ใช้ได้รับประกัน                                                                                                                              |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ปลอดภัยตั้งแต่ค่าเริ่มต้น ใช้ภาษาที่เข้าใจง่าย และเท่าเทียมสำหรับทุกคน | ค่าเริ่มต้น ข้อความ และการแก้ไขทุกอย่างปลอดภัยตั้งแต่แรกและเข้าใจได้สำหรับผู้อ่านทุกคน ไม่ว่าจะเป็นนักพัฒนาหรือไม่ ไม่มีผู้ใช้ระดับใดได้สิทธิพิเศษ      | มือใหม่ได้รับพื้นฐานที่ปลอดภัยโดยไม่ต้องร้องขอ และอ่านผลลัพธ์ได้ด้วยภาษาของตัวเอง                                                                      |
| เข้าใจบริบทดีกว่าใช้แบบทั่วไป                                          | ทุกเฟสเริ่มจากบริบทที่ตรวจพบในเฟส detect และลงมือกับสิ่งที่ระบบทำจริง                                                                                   | คำแนะนำเข้ากับโปรเจกต์ ไม่ใช่เข้ากับเช็กลิสต์ ความรู้ด้านความปลอดภัยอยู่ในสเปกและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น และขยายสิ่งที่ผู้ใช้มีอยู่แล้ว |
| ยืดหยุ่นดีกว่าตายตัว                                                   | หลักการ ข้อกำหนด และคำแนะนำเป็นจุดเริ่มต้น ผู้ใช้เขียนใหม่ ตัดออก เพิ่ม หรือจำกัดขอบเขตของสิ่งใดก็ได้                                                   | ระเบียบวิธีปรับตามโปรเจกต์และผู้ใช้ และไม่เคยเข้มงวดเกินกว่าที่ผู้ใช้ต้องการ ความยืดหยุ่นไม่เคยลดทอนพื้นฐานที่ปลอดภัยตั้งแต่ค่าเริ่มต้น                |
| ปรับให้ตรงกับสภาพปัจจุบัน ไม่ใช่แค่ต่อท้าย                             | อาร์ติแฟกต์เป็นเอกสารที่มีชีวิต ไม่ใช่ log การรันแต่ละครั้งตรวจทุกรายการซ้ำ: เก็บสิ่งที่ยังจริง เขียนใหม่ในสิ่งที่เปลี่ยน และลบสิ่งที่ไม่เกี่ยวข้องแล้ว | บันทึกสะท้อนปัจจุบันเสมอ จึงไม่เสื่อมกลายเป็น backlog ที่ล้าสมัย                                                                                       |
| เพื่อการป้องกันเท่านั้น                                                | SDH ตรวจสอบ เสริมความปลอดภัย และตรวจยืนยัน ไม่เคยสร้างเครื่องมือโจมตี exploit เพื่อใช้ในทางร้าย หรือเทคนิคหลบเลี่ยงการตรวจจับเพื่อก่อความเสียหาย        | ไม่มีใครเปลี่ยนระเบียบวิธีนี้เป็นอาวุธได้ เนื้อหาที่ใช้ได้สองทางปรากฏเฉพาะในกรอบที่ชัดเจนว่าเพื่อการป้องกัน                                            |
| spec-first ขับเคลื่อนด้วยเอเจนต์ และวางกรอบเพื่อความปลอดภัย            | เวิร์กโฟลว์สร้างจากเทมเพลต คำสั่ง charter ที่กำกับทุกเฟส และเอเจนต์ที่รันเฟสต่าง ๆ                                                                      | โครงสร้างการพัฒนาที่พิสูจน์แล้ว นำมาปรับใช้ใหม่ให้เอเจนต์ทำงานด้านความปลอดภัยที่เป็นเนื้อหาจริง                                                        |

**ตารางที่ 1** หลักการออกแบบของ SDH และหลักประกันที่แต่ละข้อมอบให้ผู้ใช้

หลักการเหล่านี้ไม่ใช่เครื่องประดับ แต่เป็นข้อจำกัดที่ทุกเฟสด้านล่างต้องเคารพ และการอภิปรายใน `§XV` จะกลับมาที่หลักการเหล่านี้เพื่อระบุข้อจำกัดของระเบียบวิธี

ส่วนที่เหลือของเอกสารพัฒนาเสาหลัก 9 ข้อที่มีชื่อเรียก เป็นส่วนที่ผู้อ่านควรจดจำได้ และเป็นส่วนที่ทีมอื่นต้องสร้างขึ้นใหม่หากจะอ้างว่ากำลังทำ SDH

| เสาหลัก                                            | สิ่งที่มอบให้                                                                                                         | ส่วน        |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------- |
| การกลับด้านที่เข้าใจบริบท                          | ความรู้ด้านความปลอดภัยอยู่ในสเปกและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น มือใหม่และผู้เชี่ยวชาญจึงใช้ขั้นตอนเดียวกัน | `§I`, `§VI` |
| วงจรการป้องกัน 5 เฟส                               | การแบ่งหน้าที่: นโยบาย ตรวจจับ คัดกรอง แก้ไข และตรวจยืนยัน แต่ละเฟสมีงานเดียว                                         | `§IV`       |
| การปิดให้จบได้                                     | ข้อตรวจพบมีสถานะสิ้นสุด ไม่ใช่วนไม่รู้จบ งานที่ปิดแล้วก็ปิดออกจากห่วงโซ่                                              | `§V`        |
| ความเป็นสองด้านของการขยายความรู้นักพัฒนา           | ขั้นตอนเดียวที่ปกป้องมือใหม่และเพิ่มพลังให้ผู้เชี่ยวชาญ โดยไม่แทนที่ใครเลย                                            | `§VI`       |
| prompt-on-demand และความรู้ที่เรียกใช้โดยตรงไม่ได้ | ความรู้ด้านความปลอดภัยที่เกี่ยวข้องโหลดตามสิ่งที่โปรเจกต์เป็น และไม่โหลดเป็นค่าเริ่มต้น                               | `§VII`      |
| ความไม่ขึ้นกับสถานะและการปรับตัวแบบไม่บังคับ       | เข้ากับสถานะการพัฒนาใดก็ได้ใน stack ใดก็ได้ และปรับตามสถานการณ์แทนการบังคับขอบเขต                                     | `§VIII`     |
| โหมดป้องกันล่วงหน้า                                | การป้องกันชุดเดียวกันทำงานขณะสร้างงานใหม่ โค้ดจึงปลอดภัยตั้งแต่ค่าเริ่มต้นทันทีที่เสร็จ                               | `§IX`       |
| การติดตามด้วยอัตลักษณ์ตามชื่อ                      | ข้อตรวจพบยังเป็นรายการเดียวตลอดทุกเฟส และการเปลี่ยนชื่อไฟล์ทำให้การเชื่อมโยงขาดในจุดเดียว                             | `§XI`       |
| ตัวนำส่งที่ไม่ผูกกับเอเจนต์                        | คุณค่าด้านความปลอดภัยเขียนขึ้นครั้งเดียวและไม่พึ่งพาเอเจนต์หรือ stack ใด                                              | `§XII`      |

**ตารางที่ 2** เสาหลัก 9 ข้อของ SDH และส่วนที่อธิบายแต่ละข้อ

---

## IV. ขั้นตอนแบบ Blue Team 5 เฟส

SDH จัดโครงสร้างงานเป็นวงจรการป้องกัน 5 เฟส (ภาพที่ 1) ทุกเฟสวางกรอบไว้ที่การป้องกัน แต่ละเฟสต่อยอดจากเฟสก่อนหน้า และลำดับเฟสเป็นไปตามกิจกรรมจริงของ Blue Team: กำหนดนโยบาย ตรวจจับ คัดกรอง แก้ไข และตรวจยืนยัน

```mermaid
flowchart TB
    charter["1 · charter (นโยบาย)<br/>อ่าน: โปรเจกต์ และคำอธิบายของผู้ใช้หากมี<br/>เขียน: charter<br/>หลักการแต่ละข้อระบุความเสี่ยงที่ป้องกัน ด้วยภาษาที่เข้าใจง่าย"]
    detect["2 · detect (ตรวจจับ)<br/>อ่าน: โค้ดของผู้ใช้<br/>เขียน: แผนผังจาก detect<br/>ตรวจจับ ไม่ใช่แต่งเติม: บันทึกเฉพาะสิ่งที่โค้ดรองรับ"]
    plan["3 · plan (คัดกรอง)<br/>อ่าน: แผนผังจาก detect ไม่อ่านโค้ด<br/>เขียน: แผนการป้องกัน<br/>การแก้ไขทุกรายการชี้ไปยังสิ่งที่ detect ทำแผนผังไว้จริง"]
    harden["4 · harden (แก้ไข)<br/>อ่าน: แผนการป้องกัน และโค้ดที่แผนแตะถึง<br/>เขียน: โค้ด และบันทึก hardening<br/>เฟสเดียวที่แก้โค้ด ทีละการแก้ไข ด้วยการเปลี่ยนแปลงเล็กที่สุดที่ยังได้ผล"]
    verify["5 · verify (ตรวจยืนยัน)<br/>อ่าน: โค้ด และบันทึก hardening<br/>เขียน: ผลตัดสินที่ยังเปิดอยู่ลงในบันทึก hardening<br/>เทียบโค้ดกับบันทึกแบบ static โดยไม่ผ่อนปรน"]
    charter --> detect --> plan --> harden --> verify
    verify -.->|"ไม่ผ่าน: งานที่เปิดใหม่ให้ harden<br/>นำไปใช้ซ้ำตามเหตุผลที่บันทึกไว้"| harden
    verify -.->|"ปิด: ปิดสิ่งที่พิสูจน์แล้วว่าปิดได้<br/>ออกจากทั้งห่วงโซ่<br/>หนึ่งบรรทัดในประวัติ"| detect
```

**ภาพที่ 1** ขั้นตอน 5 เฟส: สิ่งที่แต่ละเฟสอ่าน สิ่งที่เขียน และกฎที่ห้ามละเมิดของเฟสนั้น เฟส verify ขับเคลื่อนเส้นทางย้อนกลับทั้งสอง: มาตรการควบคุมที่ไม่ผ่านจะเปิดงานใน harden อีกครั้ง และข้อตรวจพบที่พิสูจน์แล้วว่าปิดได้จะปิดออกจากห่วงโซ่ พร้อมหนึ่งบรรทัดในประวัติ

การแบ่งหน้าที่คือผลงานสำคัญ เพราะแต่ละเฟสมีงานเดียว ความล้มเหลวจึงจำกัดอยู่ในจุดเดียว และผู้อ่านเชื่อถือสิ่งที่อาร์ติแฟกต์แต่ละชิ้นระบุได้

> **ข้อคิดสำคัญ**
>
> **Applied ไม่ได้แปลว่าตรวจยืนยันแล้ว**: harden บันทึกว่าได้นำการแก้ไขไปใช้แล้ว verify ตรวจยืนยันด้วยการเทียบโค้ดกับบันทึกนั้น และไม่เคยผ่อนปรนผลตัดสินให้ตรงกับบันทึก มาตรการควบคุมอาจมีอยู่ในโค้ดแต่ยังปล่อยให้ความเสี่ยงเข้าถึงได้ และในกรณีนั้นผลตัดสินที่ตรงไปตรงมาคือ "ความเสี่ยงยังไม่ปิด"

### charter (นโยบาย)

charter กำหนดหลักการด้านความปลอดภัยของโปรเจกต์ คือกฎที่ทุกเฟสถัดไปต้องเคารพ charter เป็นชั้นที่กำกับทุกเฟส เปรียบได้กับการตรวจตอนคอมไพล์ (compile-time check) สำหรับสถานะความปลอดภัยโดยรวมของโปรเจกต์ หลักการแต่ละข้อมีชื่อที่ชัดเจน มีกฎที่ต่อรองไม่ได้และตรวจกับโค้ดได้ และมีบรรทัด `Why:` ที่บอกความเสี่ยงที่หลักการนั้นป้องกัน ไม่ใช่แค่วิธีแก้ charter อ่านตัวโปรเจกต์เสมอ (manifest โครงสร้าง และ dependency) ส่วนคำอธิบายของผู้ใช้ (ถ้ามี) คือทิศทางที่การอ่านจะขยายต่อให้กว้างกว่าสิ่งที่ผู้ใช้ระบุ เมื่อไม่มีคำอธิบาย โปรเจกต์คือแหล่งข้อมูลเดียว ทั้งสองส่วนเสริมกันแทนที่จะแข่งกัน และ charter บันทึกนโยบายที่โปรเจกต์ควรยึดถือ ไม่ใช่สถานะของโค้ด ผู้ที่ไม่ใช่นักพัฒนาควรอ่านแล้วเข้าใจทั้งกฎและความเสี่ยง

### detect (ตรวจจับ)

detect อ่านโค้ดและทำแผนผังสิ่งที่ระบบทำจริงที่มีน้ำหนักด้านความปลอดภัย คำสั่งหลักคือ "ตรวจจับ ไม่ใช่แต่งเติม": บันทึกเฉพาะสิ่งที่โค้ดรองรับ พร้อมหลักฐานที่เฟสถัดไปต้องใช้ detect เป็นกลาง ไม่บังคับให้ข้อตรวจพบเข้ากับ charter เพราะการจับคู่ความเสี่ยงกับกฎของ charter เป็นงานของเฟส plan ข้อตรวจพบแต่ละรายการมี 3 ส่วน: คืออะไร (คำอธิบายด้วยภาษาที่เข้าใจง่าย) ทำไมจึงสำคัญ (ความเสี่ยง ไม่ใช่แค่ข้อเท็จจริง) และหลักฐาน (ฟังก์ชันหรือ route ที่ข้อตรวจพบอยู่) หลักฐานไม่มี path ของไฟล์ เพราะ path อยู่เฉพาะในแผนผังการติดตาม (`§XI`) ข้อความจึงไม่มี path ที่อาจล้าสมัย

### plan (คัดกรอง)

plan เปลี่ยนข้อตรวจพบแต่ละรายการเป็นการแก้ไข โดยตั้งชื่อตามประเภทความเสี่ยง (อ้างอิงมาตรฐานที่ยอมรับกัน คือ CWE และ OWASP ในจุดที่เป็นฐานรองรับ) และผูกกับหลักการใน charter ที่การแก้ไขนั้นยึดถือ ลำดับความสำคัญ (วิกฤต สูง ปานกลาง และต่ำ) ไม่ใช่การเลือกตามใจ: plan ให้คะแนนข้อตรวจพบแต่ละรายการด้วยวิธี Base-and-Environmental ของ CVSS v4.0 ระดับจึงเป็นคะแนนในรูปคำพูดธรรมดา พร้อมเหตุผลหนึ่งบรรทัดด้วยภาษาเข้าใจง่ายถึงโอกาสที่ถูกโจมตีและสิ่งที่อาจเสียหาย และการรันสองครั้งได้ลำดับเดียวกัน vector คือหลักยึดที่แม่นยำสำหรับผู้เชี่ยวชาญ ส่วนระดับและเหตุผลประกอบคือการให้คะแนนเดียวกันที่ใครก็ติดตามได้ plan ทำงานจากแผนผังจาก detect เท่านั้นและไม่อ่านโค้ด นี่คือข้อจำกัดที่ตั้งใจ ไม่ใช่ข้อด้อย: ข้อจำกัดนี้บังคับให้การแก้ไขทุกรายการชี้ไปยังสิ่งที่ detect ตรวจพบจริง หากขอบเขตใดไม่เคยมีแผนผัง plan จะหยุดและพาผู้ใช้กลับไปที่ detect แทนการเดา

### harden (แก้ไข)

harden เป็นเฟสเดียวที่แก้โค้ด จึงทำงานอย่างระมัดระวัง การแก้ไขแต่ละครั้งต้องได้รับอนุมัติจากผู้ใช้หรือไม่ ขึ้นอยู่กับเอเจนต์และโหมดสิทธิ์ที่เอเจนต์รันอยู่ harden จึงไม่เพิ่มขั้นยืนยันของตัวเอง harden นำการแก้ไขไปใช้ทีละรายการ เริ่มจากการแก้ไขที่รายการอื่นพึ่งพาก่อน แล้วจึงไล่ตามลำดับความสำคัญสูงสุด การเปลี่ยนแปลงแต่ละครั้งจึงเล็ก ตรวจทานง่าย และย้อนกลับได้ง่าย harden ไม่ลดทอนมาตรการควบคุมที่มีอยู่เพื่อให้การแก้ไขใหม่เข้ากันได้ และไม่ละเมิดหลักการใน charter หากการแก้ไขใดจะขัดกับหลักการ harden จะหยุดและแจ้งความขัดแย้งนั้นแทนการนำไปใช้ แต่ละบล็อกบันทึกเป็น Applied, Partial หรือ Blocked "Applied ยังไม่ได้แปลว่าตรวจยืนยันแล้ว" และนั่นคือเรื่องที่เฟสถัดไปจัดการ

### verify (ตรวจยืนยัน)

verify ตรวจยืนยันมาตรการควบคุมแต่ละรายการที่นำไปใช้แล้ว ด้วยการอ่านโค้ดแล้วเทียบกับสิ่งที่ harden บันทึกไว้ การตรวจยืนยันก็คือการเทียบโค้ดกับบันทึกนั้น และเป็นแบบ static: ยืนยันว่ามาตรการควบคุมมีอยู่และถูกต้องในโค้ด ไม่ได้ยืนยันว่าจะต้านการโจมตีได้บนระบบที่กำลังรัน การตรวจขณะรัน (runtime) แบบที่ยิงการโจมตีจริงหรือจำลองใส่ระบบที่ใช้งานอยู่ อยู่นอกขอบเขตโดยการออกแบบ verify ให้ผลตัดสินหนึ่งในสามแบบ: ความเสี่ยงปิดแล้ว ความเสี่ยงยังไม่ปิด หรือบอกไม่ได้จากโค้ด verify ไม่สร้างอาร์ติแฟกต์ของตัวเอง: harden และ verify ใช้บันทึก hardening ร่วมกัน โดย harden เป็นเจ้าของสิ่งที่ทำไป และ verify เป็นเจ้าของผลตัดสินและเหตุผล ทั้งสองไม่เคยเขียนลงในฟิลด์ของอีกฝ่าย มาตรการควบคุมที่ไม่ผ่านคืองานที่เปิดใหม่ให้ harden ซึ่งในการรันครั้งถัดไปจะถือว่าผลตัดสินนั้นอยู่เหนือการอ่านโค้ดของตัวเอง และนำการแก้ไขไปใช้ซ้ำตรงจุดบกพร่องที่เหตุผลระบุไว้พอดี verify เชื่อโค้ดมากกว่าบันทึก เพราะบันทึกอาจอ้างเกินกว่าที่โค้ดทำได้จริง verify อ่านโค้ดของผู้ใช้อย่างเดียว และไม่เคยผ่อนปรนผลตัดสินให้ตรงกับบันทึก มาตรการควบคุมอาจมีอยู่แต่ความเสี่ยงยังเข้าถึงได้ทางอื่น และในกรณีนั้นผลตัดสินที่ตรงไปตรงมาคือ "ความเสี่ยงยังไม่ปิด" หากระหว่างอ่าน verify สังเกตเห็นปัญหาด้านความปลอดภัยที่แผนผังจาก detect ไม่เคยครอบคลุม verify จะไม่แต่งผลตัดสินขึ้นมาเอง เพราะการตรวจจับเป็นงานของ detect: verify แจ้งปัญหาและพาผู้ใช้กลับไปที่ detect ข้อตรวจพบจึงเข้ามาผ่านขั้นตอนเดียวกันแทนการข้ามไป

> **ตัวอย่างต่อเนื่อง: การอัปโหลดไฟล์** ข้อตรวจพบเดียวแสดงแกนหลักของขั้นตอนตั้งแต่ต้นจนจบ
>
> - **detect** พบข้อตรวจพบนี้: ระบบรับไฟล์จากผู้ใช้ และ handler การอัปโหลดเชื่อ MIME type ที่ไคลเอนต์ส่งมาโดยไม่ตรวจประเภทจริงของไฟล์ _ทำไมจึงสำคัญ_: ไฟล์ที่ปลอมตัวเป็นรูปภาพอาจซ่อนโค้ดอันตรายไว้
> - **plan** กำหนดการแก้ไข ลำดับความสำคัญ **วิกฤต** โดยยึดหลักการ "อินพุตทุกอย่างไม่น่าเชื่อถือจนกว่าจะผ่านการตรวจสอบ": ตรวจประเภทและขนาดจริงของไฟล์ เปลี่ยนชื่อตอนบันทึก และจัดเก็บไฟล์อัปโหลดในที่ที่รันเป็นโค้ดไม่ได้
> - **harden** นำไปใช้ สถานะ **Applied**: ตอนนี้ handler ตรวจประเภทจริงจากเนื้อหาไฟล์ บังคับจำกัดขนาด ปฏิเสธสิ่งที่ไม่คาดคิด เปลี่ยนชื่อตอนบันทึก และจัดเก็บในที่ที่โค้ดรันไม่ได้
> - **verify** อ่าน handler เทียบกับบันทึก และให้ผล **ความเสี่ยงปิดแล้ว**: โค้ดทำตรงตามที่บันทึกอ้างทุกประการ
>
> ชื่อข้อตรวจพบเดียวกันส่งต่อผ่านแผนผังจาก detect แผนการป้องกัน และบันทึก hardening และ verify ลงมือกับบันทึกนั้นภายใต้ชื่อเดียวกัน: ผลตัดสินที่ยังเปิดอยู่เขียนลงในบล็อกของข้อตรวจพบ และ verify ปิดข้อตรวจพบที่พิสูจน์แล้วว่าปิดได้ออกจากห่วงโซ่ (`§V`) ชื่อร่วมนั้นคืออัตลักษณ์ของข้อตรวจพบ (`§XI`)

---

## V. การปิดให้จบได้: ข้อตรวจพบมีสถานะสิ้นสุด

เครื่องมือด้านความปลอดภัยส่วนใหญ่ทิ้งผู้ใช้ไว้กับ backlog ที่มีแต่จะยาวขึ้น SDH ยืนอีกจุดหนึ่ง: **ข้อตรวจพบปิดให้จบได้ จึงมีสถานะสิ้นสุดแทนการค้างอยู่ใน backlog ไม่รู้จบ** (ภาพที่ 2) จุดยืนนี้มาจากหลักการปรับให้ตรงกับสภาพปัจจุบันโดยตรง

> **นิยาม**
>
> **การปิดให้จบได้**: ความเสี่ยงที่ตรวจยืนยันแล้วว่าปิดแล้วจะปิดออกจากทั้งขั้นตอน ข้อตรวจพบนั้นจึงไปถึงสถานะสิ้นสุด และจะเปิดใหม่ก็ต่อเมื่อโค้ดเปลี่ยนเท่านั้น ข้อตรวจพบมีจุดสิ้นสุด แม้โปรแกรมด้านความปลอดภัยโดยรวมจะดำเนินต่อเนื่อง

อาร์ติแฟกต์ของ SDH เป็นเอกสารที่มีชีวิต ไม่ใช่ log ทุกครั้งที่เฟสรันซ้ำ เฟสนั้นจะตรวจรายการเดิมแต่ละรายการกับสภาพปัจจุบันแล้วทำอย่างใดอย่างหนึ่งในสามอย่าง: เก็บสิ่งที่ยังจริง เขียนใหม่ในสิ่งที่เปลี่ยน หรือลบสิ่งที่ไม่เกี่ยวข้องแล้ว ข้อตรวจพบที่โค้ดแสดงว่าแก้แล้วก็แค่ลบออก บันทึกการทำงานสะท้อนปัจจุบัน ไม่ใช่อดีต

การปิดคือการปรับให้ตรงกับสภาพปัจจุบันแบบเดียวกันที่ไปถึงข้อสรุป เมื่อ verify ยืนยันว่าความเสี่ยงปิดแล้ว ก็จะปิดข้อตรวจพบนั้นออกจากทั้งขั้นตอน ได้แก่ แผนผังจาก detect แผนการป้องกัน บันทึก hardening และแผนผังการติดตาม นี่คือเหตุผลที่ verify เป็นเฟสเดียวที่เขียนลงในอาร์ติแฟกต์ของเฟสอื่น: verify คือเฟสที่ปิดวงจร เมื่อข้อตรวจพบออกจากห่วงโซ่ การปิดจะกลั่นกรองข้อตรวจพบเป็นรายการสั้น ๆ ในบันทึกประวัติที่อยู่นอกห่วงโซ่การทำงานและไม่มีการประมวลผลซ้ำ นี่คือเส้นแบ่งระหว่างการหายไปกับการปิด: ข้อตรวจพบที่การปรับให้ตรงกับสภาพปัจจุบันลบออกเพราะไม่จริงอีกต่อไปจะไม่ทิ้งอะไรไว้ ขณะที่ข้อตรวจพบที่พิสูจน์แล้วว่าปิดได้จะได้หนึ่งบรรทัดในประวัติ ข้อตรวจพบที่ปิดออกแล้วจะไม่ปรากฏในอาร์ติแฟกต์การทำงานใดอีก และการไม่ปรากฏนั้นเป็นสิ่งที่คาดไว้ ไม่ใช่ห่วงโซ่ที่ขาด

```mermaid
stateDiagram-v2
    direction TB
    [*] --> OPEN: detect ตรวจพบ
    OPEN --> Plan: plan
    Plan --> Harden: harden
    Harden --> Verify: verify
    Verify --> StoodDown: ความเสี่ยงปิดแล้ว
    StoodDown --> SETTLED
    SETTLED --> OPEN: โค้ดที่เปลี่ยนเปิดข้อตรวจพบอีกครั้ง
    Plan: plan
    Harden: harden
    Verify: verify
    StoodDown: STOOD DOWN · หนึ่งบรรทัดในประวัติ
```

**ภาพที่ 2** state machine ของการปิดให้จบได้ ข้อตรวจพบเคลื่อนจาก OPEN → STOOD DOWN → SETTLED และเปิดใหม่ก็ต่อเมื่อโค้ดเปลี่ยนเท่านั้น

เมื่อทุกอย่างในขอบเขตปิดออกหมดแล้ว รอบการทำงานจึงสิ้นสุดลง และสถานะสิ้นสุดนั้นมีรูปแบบที่จับต้องได้: อาร์ติแฟกต์ที่ข้อตรวจพบสุดท้ายปิดแล้วจะลบออกทั้งไฟล์ ห่วงโซ่ที่ปิดครบจึงเหลือเพียง charter กับประวัติ คือนโยบายและการพิสูจน์ รอบการทำงานจะเปิดใหม่ก็ต่อเมื่อโค้ดเปลี่ยนเท่านั้น ระเบียบวิธีนี้ให้จุดจบที่ชัดเจนแก่ข้อตรวจพบแต่ละรายการ ซึ่งเป็นสิ่งที่ backlog ไม่รู้จบให้ไม่ได้

---

## VI. ความเป็นสองด้านของการขยายความรู้นักพัฒนา

SDH ไม่ได้มาแทนคน และไม่ได้มาแทนเครื่องมือ Blue Team เฉพาะทาง SDH **ขยายความรู้ของนักพัฒนาเอง** ยิ่งนักพัฒนาเข้าใจความปลอดภัยมากเท่าไร ก็ยิ่งกำหนดทิศทางของขั้นตอนได้แม่นยำและมีอิสระมากขึ้นเท่านั้น นักพัฒนาที่เข้าใจน้อยก็ยังได้ผลลัพธ์ที่ปลอดภัย เพราะโหมดอัตโนมัติคอยปกป้อง

การกลับด้านจาก `§I` ที่ว่าความรู้ด้านความปลอดภัยอยู่ในสเปก ใช้ได้ทั้งสองทิศทาง สำหรับมือใหม่ นี่คือการปกป้อง: ไม่จำเป็นต้องรู้ว่าควรถามอะไร เพราะสเปกเสนอให้เอง สำหรับผู้เชี่ยวชาญ นี่คือการเพิ่มพลัง: สเปกเดียวกันช่วยให้กำหนดเป้าหมายของขั้นตอนได้อย่างแม่นยำแทนการทำงานฝืนเช็กลิสต์ตายตัว

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

```mermaid
flowchart TB
    inversion["การกลับด้านเดียว สองทิศทาง:<br/>ความรู้ด้านความปลอดภัยอยู่ในสเปก"]
    inversion --> auto["โหมดอัตโนมัติ (ไม่มีอินพุต)<br/>เฟสเสนอและลงมือ<br/>กับขอบเขตทั้งหมด"]
    inversion --> directed["โหมดกำหนดทิศทาง (มีอินพุต)<br/>เฟสจำกัดให้เหลือเฉพาะ<br/>สิ่งที่ผู้ใช้เล็งไว้"]
    auto --> novice["มือใหม่ได้รับการปกป้อง:<br/>ได้ผลลัพธ์ที่ปลอดภัยโดยไม่ต้อง<br/>รู้ว่าควรถามอะไร"]
    directed --> expert["ผู้เชี่ยวชาญได้พลังเพิ่ม:<br/>กำหนดเป้าหมายของขั้นตอนได้แม่นยำ<br/>ไม่ใช่เช็กลิสต์ตายตัว"]
    novice -.-> phases["5 เฟสเดียวกันรองรับทั้งสองกลุ่ม:<br/>charter · detect · plan · harden · verify"]
    expert -.-> phases
```

**ภาพที่ 3** ความเป็นสองด้านของการขยายความรู้นักพัฒนา การกลับด้านเดียวรองรับผู้ใช้สองกลุ่ม: โหมดอัตโนมัติปกป้องมือใหม่ และโหมดกำหนดทิศทางเพิ่มพลังให้ผู้เชี่ยวชาญ ผ่าน 5 เฟสเดียวกัน

ความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น (`§VII`) ระบุความเป็นสองด้านนี้ไว้ชัดในเนื้อหาของตัวเอง แต่ละชิ้นบอกเอเจนต์ว่าความรู้ในนั้น "ขยายวิจารณญาณของคุณ" และให้ใช้เหตุผลต่อไปเกินกว่าที่ความรู้เฉพาะทางนั้นให้ไว้ ความรู้นี้เป็นพื้น ไม่ใช่เพดาน นี่คือสิ่งที่รองรับผู้ใช้ทั้งสองกลุ่มตามความสมดุลที่เอกสารนี้ตั้งใจ: ชุมชนนักพัฒนาได้เครื่องมือที่มีน้ำหนัก และผู้ปฏิบัติงาน Blue Team ได้ตัวนำส่งที่มีโครงสร้างที่ไม่แสร้งว่าทำงานแทนพวกเขาได้

---

## VII. ความรู้เฉพาะทางที่เรียกใช้โดยตรงไม่ได้และ prompt-on-demand

นี่คือรูปแบบที่ใหม่ที่สุดของระเบียบวิธีนี้ SDH เก็บความรู้ด้านความปลอดภัยแบบเจาะจงไว้เป็นความรู้เฉพาะทางที่โหลด **เฉพาะเมื่อจำเป็น** และเอเจนต์เป็นผู้ตัดสินเองว่าจะโหลดชิ้นใดด้วยการจับคู่กับบริบทของโปรเจกต์ เราเรียกสิ่งนี้ว่า **prompt-on-demand**: วิธีที่เอเจนต์เลือกว่าจะเปิดใช้ความรู้ใดตามขอบเขตของโปรเจกต์ที่อยู่ แทนการรันทุกการตรวจเป็นค่าเริ่มต้น ความรู้เฉพาะทางพัฒนาไปเรื่อย ๆ และชิ้นใดก็เปลี่ยนหรือมีชิ้นอื่นมาแทนได้ทุกเมื่อ ผลงานคือรูปแบบ ไม่ใช่ตัวความรู้เฉพาะทาง

> **นิยาม**
>
> **Prompt-on-demand**: เอเจนต์เลือกความรู้ด้านความปลอดภัยที่จะเปิดใช้โดยจับคู่กับขอบเขตของโปรเจกต์ตรงหน้า เอเจนต์จึงดึงความรู้ที่เกี่ยวข้องเข้ามาตามสิ่งที่โปรเจกต์เป็นจริง แทนการรันทุกการตรวจเป็นค่าเริ่มต้น

> **นิยาม**
>
> **ความรู้เฉพาะทางที่เรียกใช้โดยตรงไม่ได้**: หน่วยความรู้ด้านความปลอดภัยแบบเจาะจงที่ไม่ผูกกับภาษาโปรแกรม สำหรับบริบทเดียว เช่น การอัปโหลดไฟล์หรือโค้ดที่รันในเบราว์เซอร์ ความรู้นี้ตรวจสอบและอธิบาย ไม่เคยเขียนโค้ดใหม่ และไม่เคยสร้างอินพุตสำหรับโจมตี ความรู้นี้ไม่ใช่คำสั่ง: จะโหลดเมื่อบริบทที่ครอบคลุมอยู่ในขอบเขต หรือเมื่อ prompt ขอโดยระบุชื่อ

ความรู้เฉพาะทางแต่ละชิ้นระบุรูปแบบที่ปลอดภัยกว่าสำหรับความเสี่ยงที่ครอบคลุม และบอกเอเจนต์ว่าควรจัดการข้อตรวจพบอย่างไรในแต่ละเฟสที่ใช้ความรู้นั้น: ตัดสินอย่างไรตอนตรวจจับ นำการแก้ไขไปใช้อย่างปลอดภัยอย่างไรตอนแก้ไข และพิสูจน์อย่างไรตอนตรวจยืนยัน

ลักษณะเด่นคือความรู้เฉพาะทาง **เรียกใช้โดยตรงไม่ได้**: ไม่ใช่คำสั่ง และภายในขั้นตอน การจับคู่คือสิ่งที่ทำให้โหลด เฟสตรวจจับแสดงรายการแคตตาล็อกครั้งเดียว จับคู่บริบทของโปรเจกต์กับสิ่งที่แต่ละรายการครอบคลุม และโหลดเฉพาะความรู้เฉพาะทางที่บริบทปรากฏอยู่ในขอบเขต เฟสถัดไปใช้รายการที่จับคู่แล้วซ้ำแทนการแสดงรายการใหม่ การจับคู่ครั้งเดียวจึงใช้ได้ทั้งห่วงโซ่ และโหมดป้องกันล่วงหน้า (`§IX`) ก็จับคู่แบบเดียวกันกับงานที่กำลังจะสร้าง เอเจนต์ข้ามความรู้เฉพาะทางที่บริบทไม่ปรากฏ และการข้ามต้องตรวจสอบย้อนได้เท่ากับการโหลด: ทุกรายการในแคตตาล็อกได้รับผลตัดสินที่ชัดเจน คือนำไปใช้ หรือข้ามพร้อมเหตุผลที่อ่านได้จากโค้ด ความรู้สึกลาง ๆ ว่าไม่เกี่ยวจึงไม่มีวันใช้แทนการไม่มีอยู่จริงได้ การไม่พบรายการที่ใช้ได้เลยก็เป็นผลลัพธ์ที่ถูกต้อง

แคตตาล็อกคือข้อมูล และการเติบโตคือไฟล์ความรู้หนึ่งไฟล์บวกแถวแคตตาล็อกหนึ่งแถว ไม่ใช่คำสั่งใหม่ ความรู้เฉพาะทางในตัวจัดกลุ่มเป็นหมวดหมู่ เช่น OWASP ภาษาโปรแกรม หรือการผสานรวม AI และแคตตาล็อกที่โปรเจกต์ใช้ประกอบด้วยความรู้ในตัวของหมวดหมู่ที่เลือก บวกความรู้เฉพาะทางของโปรเจกต์เอง โปรเจกต์บันทึกตัวเลือกนั้นไว้กับสถานะส่วนอื่น ทั้งทีมจึงจับคู่กับแคตตาล็อกเดียวกัน นี่คือหลักการเข้าใจบริบทแบบเดียวกับเฟสต่าง ๆ ที่นำมาใช้กับความรู้: เอเจนต์ดึงความรู้ที่เกี่ยวข้องเข้ามาตามสิ่งที่โปรเจกต์เป็นจริง แทนการรันทุกการตรวจเป็นค่าเริ่มต้น คุณสมบัติเดียวกันนี้ทำให้ผู้ใช้ขยายแคตตาล็อกได้ด้วย ไม่ใช่เฉพาะผู้ดูแล (maintainer): แหล่งความรู้หรือหัวข้อด้านความปลอดภัยที่ผู้ใช้ให้มาจะกลั่นกรองออกมาเป็นความรู้เฉพาะทางใหม่ของโปรเจกต์ เข้าร่วมแคตตาล็อกไม่ว่าจะเลือกหมวดหมู่ใด และโหลดเหมือนความรู้ในตัวทุกประการ โดยแทนที่ความรู้ในตัวที่ใช้ชื่อเดียวกัน การเขียนความรู้เฉพาะทางเองก็เพื่อการป้องกันเท่านั้น และเคารพขอบเขตเดียวกับที่ความรู้เฉพาะทางบังคับใช้: บทความอธิบายการโจมตีอาจเป็นแหล่งข้อมูลได้ แต่ความรู้เฉพาะทางที่ได้ออกมาจะตรวจสอบและอธิบายเท่านั้น ไม่เคยให้ exploit ที่ใช้งานได้จริง การกลับด้านใน `§I` ที่ว่าความฉลาดอยู่ในสเปก จึงขยายไปถึงตัวแคตตาล็อกเอง ซึ่งผู้ใช้เพิ่มความลึกให้เข้ากับบริบทของตัวเองได้โดยไม่ต้องเขียนโค้ด

ตัวอย่างสั้น ๆ ของ prompt-on-demand: detect อ่านโฟลเดอร์โค้ดที่รันในเบราว์เซอร์ จับคู่บริบทนั้นในแคตตาล็อก โหลดความรู้เฉพาะทางที่ครอบคลุม และแสดงข้อตรวจพบฝั่งไคลเอนต์ผ่านขั้นตอนปกติของ detect ความรู้เฉพาะทางที่บริบทไม่ปรากฏในขอบเขตนี้ไม่ตรงกัน จึงไม่โหลดเลย และ detect บันทึกแต่ละชิ้นว่าข้าม โปรเจกต์เป็นตัวกำหนดว่าความรู้ใดเกี่ยวข้อง ไม่ใช่การตั้งค่าตายตัว

ความเป็น deterministic ปรากฏตรงจุดที่สำคัญพอดี ความรู้เฉพาะทางมีตัวตรวจ (checker) แบบ deterministic มาด้วยได้ ไม่ใช่แค่ข้อความ: ในจุดที่ประเภทความเสี่ยงมีขั้นตอนการตัดสินที่ชัดเจน โปรแกรมเล็ก ๆ จะคืนผลตัดสินตายตัวสำหรับอินพุตหนึ่ง ๆ เช่น คำสั้น ๆ อย่าง `safe`, `unsafe` หรือ `invalid input` ความเสี่ยงบางประเภทตัดสินได้แบบ deterministic ในลักษณะนี้พอดี โดยมีงานก่อนหน้าจำนวนมากรองรับขั้นตอนการตัดสิน `[9]`, `[10]`, `[11]` ตัวตรวจจะให้คะแนนตัวเลือกที่เอเจนต์ส่งมา หรือสแกนขอบเขตเพื่อหาตัวเลือกเอง และไม่ว่าแบบใด ตัวตรวจเป็นผู้คืนผลตัดสิน ไม่ใช่เอเจนต์ ความรู้เฉพาะทางที่ใช้ได้กว้างพอจะทำเครื่องหมายว่าจำเป็น (required) ในแคตตาล็อกได้ และจะนำไปใช้เสมอ โดยรันตัวตรวจทั่วทั้งขอบเขต นี่คือกรณีเดียวที่ความรู้โหลดโดยไม่ต้องจับคู่บริบท และประกาศไว้ในข้อมูลของแคตตาล็อก ไม่เคยให้เอเจนต์ตัดสินเอาเองในขณะนั้น นี่คือจุดที่ SDH ยึดการให้เหตุผลของเอเจนต์ไว้กับสิ่งที่ทำซ้ำได้ โดยไม่แสร้งว่าทั้งขั้นตอนเป็น deterministic

สุดท้าย ความรู้เฉพาะทาง **แยกใช้งานได้** เพราะความรู้ยืนได้ด้วยตัวเอง ผู้ใช้จึงรันชิ้นใดชิ้นหนึ่งได้โดยตรงใน prompt ที่ไม่เกี่ยวกับขั้นตอน SDH ทั้งหมด และคงความปลอดภัยไว้ควบคู่กับการพัฒนาทั่วไป ตัวอย่างเช่น ความรู้เฉพาะทางที่มีตัวตรวจแบบ deterministic สามารถคัดกรองตัวเลือกแต่ละตัวที่เกิดขึ้นระหว่างเขียนโค้ดทั่วไป แล้วเก็บไว้เฉพาะตัวที่ปลอดภัย การแยกใช้งานได้นี้เป็นส่วนหนึ่งที่ทำให้ SDH ปรับเข้ากับสถานการณ์ได้มากมาย ซึ่งเป็นหัวข้อของ `§VIII` และรูปแบบที่สมบูรณ์ที่สุดคือโหมดป้องกันล่วงหน้า (`§IX`) ที่ความรู้ชุดเดียวกันปกป้องการพัฒนาทั่วไปตั้งแต่ต้นจนจบ

---

## VIII. ความไม่ขึ้นกับสถานะและการปรับตัวแบบไม่บังคับ

มีคุณสมบัติสองข้อที่แยก SDH ออกจากระเบียบวิธีด้านสเปกที่ตายตัว

### ความไม่ขึ้นกับสถานะ

> **นิยาม**
>
> **ความไม่ขึ้นกับสถานะ** (state-independence): ระเบียบวิธีนี้ไม่ขึ้นกับสถานะการพัฒนา ใช้ได้กับไดเรกทอรีว่าง โปรเจกต์ที่กำลังพัฒนา pull request เดียว หรือโค้ดเบสเก่าขนาดใหญ่ ใน stack ใดก็ได้ เพราะ SDH เรียนรู้จุดเริ่มต้นจากการอ่านสิ่งที่มีอยู่

ทุกเฟสทำงานแบบเดียวกันไม่ว่าโปรเจกต์จะใหม่เอี่ยมหรือมีอยู่แล้ว charter อนุมานหลักการจากโค้ดเท่าที่มี detect ทำแผนผังโค้ดเท่าที่มี แม้จะมีน้อยมาก ไม่มีการสมมติจุดเริ่มต้นไว้ก่อน

### การปรับตัวแบบไม่บังคับ

> **นิยาม**
>
> **การปรับตัวแบบไม่บังคับ** (non-authoritative adaptivity): ระเบียบวิธีปรับตามสถานการณ์แทนการบังคับขอบเขตตายตัวให้ผู้ใช้ทำตาม เมื่อผู้ใช้ไม่รู้ว่าจะพูดอะไร SDH จะอ่านสภาพแวดล้อมที่ผู้ใช้เรียกใช้อยู่ สร้างบริบท และถามคำถามที่กำหนดว่าจะทำอะไรต่อ

โหมดเสนอของ charter คือกรณีที่ชัดที่สุด: SDH สร้าง charter ที่ปลอดภัยตั้งแต่ค่าเริ่มต้นด้วยการวิเคราะห์โปรเจกต์ ถามผู้ใช้เฉพาะเมื่อช่องว่างนั้นเปลี่ยนผลลัพธ์จริง จากนั้นเขียนและนำเสนอหลักการแต่ละข้อด้วยภาษาเข้าใจง่ายพร้อมความเสี่ยงที่ป้องกัน charter เป็นเอกสารที่มีชีวิตที่ผู้ใช้ปรับใหม่ได้ด้วยการรันซ้ำ ไม่ใช่สัญญาที่ต้องรอการอนุมัติ จึงไม่เคยบังคับให้ผู้ใช้ต้องรู้ว่าควรถามอะไร

การปรับตัวนี้แสดงออกเป็นความไวต่อรูปแบบของอินพุต: เฟสเดียวกันอ่านสิ่งที่ได้รับแล้วเลือกโหมด (ภาพที่ 4) ไฟล์ใน prompt ข้อตรวจพบจากรายการ ข้อกังวล ภารกิจที่เจาะจงไปยังจุดอ่อนที่รู้อยู่แล้ว หรือคำขอให้สแกนแบบไล่ทั้งหมด (brute-force): แต่ละแบบตอบความต้องการของผู้ใช้ เพราะขั้นตอนนี้ออกแบบมาให้ไม่บังคับ ไม่มีสิ่งใดในนี้ลดทอนพื้นฐานที่ปลอดภัยตั้งแต่ค่าเริ่มต้น ความยืดหยุ่นกำหนดวิธีใช้พื้นฐาน แต่ไม่เคยลดมาตรฐานลง

```mermaid
flowchart TB
    shape["เฟสอ่านรูปแบบ<br/>ของสิ่งที่ได้รับ"]
    shape --> none["ไม่มีอินพุต"]
    shape --> paths["path ตั้งแต่หนึ่งรายการขึ้นไป"]
    shape --> concern["ข้อกังวลที่อธิบายมา"]
    shape --> finding["ข้อตรวจพบที่ระบุชื่อ"]
    shape --> band["ระดับความสำคัญ"]
    none --> auto["โหมดอัตโนมัติ:<br/>เสนอ หรือสแกน<br/>ทั้งขอบเขต"]
    paths --> focus["โฟกัสเฉพาะไฟล์<br/>หรือไดเรกทอรีเหล่านั้น"]
    concern --> scoped["จำกัดขอบเขตไว้ที่<br/>ข้อกังวลนั้นเรื่องเดียว"]
    finding --> item["ลงมือกับรายการ<br/>ที่ติดตามรายการเดียวนั้น"]
    band --> priority["ลงมือเฉพาะระดับวิกฤต<br/>สูง ปานกลาง หรือต่ำ"]
```

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

---

## IX. โหมดป้องกันล่วงหน้าแบบ universal: การป้องกันชุดเดียวกันขณะสร้างงาน

SDH มีโหมดเสริมอีกหนึ่งโหมด: การพัฒนาทั่วไปที่ทำโดยเปิดการป้องกันชุดเดียวกันไว้ขณะเขียนโค้ด ผู้ใช้ขอตัวงาน เช่น หน้าล็อกอิน การอัปโหลด หรือ endpoint แล้วระเบียบวิธีจะคุ้มกันการสร้างระหว่างที่เกิดขึ้น ผลลัพธ์จึงปลอดภัยตั้งแต่ค่าเริ่มต้นทันทีที่เสร็จ แทนที่จะรอรอบ hardening ภายหลัง

> **นิยาม**
>
> **โหมดป้องกันล่วงหน้า**: การพัฒนาทั่วไปที่รันภายใต้ชั้นที่กำกับทุกเฟสและความรู้ของ SDH charter ผูกมัดการสร้าง ความรู้เฉพาะทางที่เกี่ยวกับสิ่งที่กำลังจะสร้างโหลดเฉพาะเมื่อจำเป็น และผลลัพธ์ต้องผ่านการเทียบกับการป้องกันที่ใช้ไปทุกประการก่อนจะถือว่างานเสร็จ

โหมดนี้ใช้ชิ้นส่วนที่เฟสต่าง ๆ มีอยู่แล้วซ้ำ แต่ชี้ไปที่โค้ดที่ยังไม่มีอยู่ การตรวจจับบริบทเปลี่ยนจากโค้ดไปเป็นเจตนา: เอเจนต์ให้เหตุผลถึงสิ่งที่กำลังจะสร้างและรอยต่อที่งานนั้นข้ามผ่าน (การล็อกอินหมายถึงข้อมูลรับรอง เซสชัน และอินพุตจากภายนอก) และการให้เหตุผลนั้นคือสิ่งที่นำไปจับคู่กับแคตตาล็อกความรู้ prompt-on-demand (`§VII`) ขยายวงกว้างขึ้นตรงนี้: ตรวจจับบริบทได้จากแผนสำหรับโค้ด ไม่ใช่เฉพาะในโค้ดที่มีอยู่ charter กำกับเช่นเคย และคำขอที่จะละเมิดหลักการจะแสดงเป็นความขัดแย้ง ไม่เคยสร้างออกมา การป้องกันนำไปใช้แบบ inline ในขณะที่เขียนแต่ละส่วน ตรวจสอบความถูกต้องที่รอยต่อ และเลือกโครงสร้างที่ปลอดภัยตั้งแต่ครั้งแรก เวอร์ชันที่ทำงานได้แต่ไม่ปลอดภัยจึงไม่เคยเกิดขึ้นให้ต้องแก้

โหมดนี้จบแบบเดียวกับที่ verify เริ่ม ก่อนจะถือว่างานเสร็จ ผู้สร้างเทียบผลลัพธ์ของตัวเองกับการป้องกันที่ใช้: มาตรการควบคุมต้องอยู่บนเส้นทางของความเสี่ยง ไม่ใช่อยู่ข้าง ๆ ต้องครบถ้วน และในจุดที่ความรู้เฉพาะทางมีตัวตรวจแบบ deterministic ผลตัดสินของตัวตรวจอยู่เหนือการอ่านของเอเจนต์เอง จุดบกพร่องที่พบตรงนี้ต้องปิดเป็นส่วนหนึ่งของงานชิ้นเดียวกัน เพราะการทำงานให้เสร็จหมายถึงทำให้เสร็จอย่างปลอดภัย

สิ่งที่โหมดนี้ปฏิเสธก็ตั้งใจพอ ๆ กับสิ่งที่ทำ โหมดนี้สร้างเฉพาะสิ่งที่ขอและไม่ตรวจสอบอะไรรอบข้าง: การตรวจสอบสิ่งที่มีอยู่เป็นหน้าที่ของเฟสต่าง ๆ โหมดนี้ไม่เขียนอาร์ติแฟกต์และไม่ติดตามข้อตรวจพบ เพราะข้อตรวจพบคือความเสี่ยงที่ตรวจพบในสิ่งที่มีอยู่ และเป้าหมายของโหมดนี้คือไม่ให้เวอร์ชันที่ไม่ปลอดภัยเกิดขึ้นเลย สองทิศทางนี้เติมเต็มกัน: เฟสต่าง ๆ ปิดสิ่งที่มีอยู่แล้ว (`§V`) และโหมดป้องกันล่วงหน้าไม่ให้งานใหม่เปิดสิ่งนั้นขึ้นมาอีก ห่วงโซ่ที่สิ้นสุดแล้วยังคงสิ้นสุดอยู่ ไม่ใช่เพราะการพัฒนาหยุดลง แต่เพราะสิ่งที่สร้างขึ้นระหว่างนั้นสร้างขึ้นพร้อมการป้องกัน

---

## X. Security-Driven Hardening เทียบกับ Spec-Driven Development

Security-Driven Hardening (SDH) เติบโตจากฐานของ Spec-Driven Development (SDD) แล้วแยกทางออกไปอย่างชัดเจน การสืบทอดโครงสร้างมีอยู่จริงและเรายอมรับ: spec-first เอเจนต์ขับเคลื่อน มีเอกสารกำกับ และมีชุดคำสั่งเป็นเฟสที่เอเจนต์รัน SDH นำโครงสร้างนั้นมาใช้ซ้ำโดยตั้งใจ สิ่งที่ต่างคือจุดประสงค์ รูปแบบอำนาจ สถานะที่สมมติไว้ และเงื่อนไขการจบ เราถือว่า SDD เป็นกลุ่มหนึ่ง โดยใช้รายงานของ Piskala `[1]` เป็นคำอธิบายหลักของระเบียบวิธี ใช้ Spec Kit ของ GitHub `[2]` เป็นชุดเครื่องมือเอเจนต์หลัก และ OpenSpec `[3]` เป็นเครื่องมือที่สองจากตระกูลเดียวกัน

SDD พลิกการพัฒนาแบบดั้งเดิมด้วยการทำให้สเปกรันได้: สเปกสร้างโค้ดที่ทำงานได้โดยตรง แทนที่จะเป็นแค่แนวทาง `[1]` ชุดเฟสของ SDD ขับเคลื่อนการสร้างไปข้างหน้า `[2]` (กำหนดหลักการกำกับ ระบุสิ่งที่จะสร้าง วางแผน tech stack แตกแผนเป็นงานย่อย แล้วลงมือสร้าง) เอกสารกำกับของ SDD คือธรรมนูญ (constitution) ที่รวมหลักการ เป็นชิ้นส่วนรากฐานที่เอเจนต์ต้องยึดถือตลอด นี่คือหัวใจของความแตกต่าง อำนาจของ SDD ไหลจากสเปกเข้าสู่การสร้าง และคาดหวังให้โค้ดที่สร้างออกมาเดินตามสเปก

SDH กลับด้านสัญญานั้นแทบทุกแกน (ตารางที่ 3)

> **ข้อคิดสำคัญ**
>
> **ความแตกต่างที่เป็นแก่น**: อำนาจของ SDD ไหลจากสเปกเข้าสู่การสร้าง และคาดหวังให้โค้ดที่สร้างออกมาเดินตามสเปก SDH ไม่บังคับและไหลไปอีกทาง คือไหลเข้าด้านในจากบริบทที่ตรวจพบของระบบ เพื่อเสริมความปลอดภัยให้สิ่งที่มีอยู่แล้ว

| แกน               | SDD                                                       | SDH                                                                                                                             |
| ----------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| เป้าหมาย          | ส่งมอบฟีเจอร์ สเปกกลายเป็นโค้ดที่ทำงานได้                 | เสริมความปลอดภัยให้สิ่งที่มีอยู่หรือกำลังสร้าง ทุกเฟสวางกรอบเพื่อการป้องกัน                                                     |
| รูปแบบอำนาจ       | บังคับ สเปกและธรรมนูญจำกัดการสร้างไว้ในขอบเขตที่ต้องทำตาม | ไม่บังคับ SDH ปรับตามสถานการณ์ และผู้ใช้เขียนใหม่ ตัดออก หรือจำกัดขอบเขตได้                                                     |
| สถานะที่สมมติไว้  | การสร้างไปข้างหน้าจากสเปก                                 | ไม่ขึ้นกับสถานะ: ไดเรกทอรีว่าง โปรเจกต์ที่กำลังพัฒนา PR เดียว หรือโค้ดเก่า                                                      |
| เงื่อนไขการจบ     | จบเมื่อสร้างฟีเจอร์เสร็จ                                  | ปิดให้จบได้ ข้อตรวจพบไปถึงสถานะสิ้นสุด และเปิดใหม่ก็ต่อเมื่อโค้ดเปลี่ยนเท่านั้น                                                 |
| เอกสารกำกับ       | ธรรมนูญที่รวมหลักการที่เอเจนต์ต้องยึดถือ                  | charter ที่รวมหลักการที่วางกรอบด้วยความเสี่ยง (แต่ละข้อมีบรรทัด `Why:`) และระบุชัดว่าไม่ใช่สัญญาตายตัว                          |
| วิธีขยายความรู้   | เพิ่มคำสั่ง (หรือขยายชุดเฟส)                              | เพิ่มความรู้เฉพาะทางที่เรียกใช้โดยตรงไม่ได้ที่เอเจนต์โหลดเฉพาะเมื่อจำเป็น: ไฟล์หนึ่งไฟล์บวกแถวแคตตาล็อกหนึ่งแถว ไม่มีคำสั่งใหม่ |
| ผู้ที่ได้ประโยชน์ | ผู้สร้างที่ผลักดันฟีเจอร์ไปข้างหน้า                       | ผู้ใช้ทุกคน จะเป็นนักพัฒนาหรือไม่ก็ตาม ผ่านขั้นตอนเดียวกัน                                                                      |
| สิ่งที่แก้โค้ด    | เฟส implement สร้างโค้ด                                   | มีเพียงเฟส harden ที่แก้โค้ด ทีละการแก้ไข                                                                                       |

**ตารางที่ 3** SDD เทียบกับ SDH ใน 8 แกน ยืมโครงสร้างมา แต่กลับด้านสัญญา

เพื่อความเป็นธรรมต่อสายวิวัฒนาการ: SDD คืองานก่อนหน้าที่พิสูจน์แล้ว และ SDH เป็นหนี้โครงสร้างที่ใช้รันอยู่ให้ SDD การแยกทางไม่ใช่คำวิจารณ์ SDD ซึ่งแก้ปัญหาอีกแบบหนึ่ง (การสร้างไปข้างหน้า) ได้ดี SDH นำกลไกที่พิสูจน์แล้วชุดเดียวกันมาชี้ไปที่การป้องกัน การปรับตัว และการปิดให้จบ OpenSpec `[3]` ซึ่งจัดโครงสร้างรอบข้อเสนอการเปลี่ยนแปลง รายการงาน และสเปกของแต่ละการเปลี่ยนแปลง ยืนยันรูปแบบนี้: ตระกูลนี้ขับเคลื่อนการสร้างไปข้างหน้าจากสเปก ขณะที่ SDH เสริมความปลอดภัยให้ระบบเข้าด้านในจากบริบทที่ตรวจพบ แม้แต่โหมดป้องกันล่วงหน้าของ SDH (`§IX`) จุดเดียวที่ทำงานคู่กับการสร้างไปข้างหน้า ก็ยังคงสัญญาที่กลับด้านไว้: กำกับวิธีสร้างงาน แต่ไม่เคยตัดสินว่าจะสร้างอะไร

---

## XI. ความเข้มงวดทางวิศวกรรม: วินัยการติดตาม

วินัยการปรับให้ตรงกับสภาพปัจจุบันแทนการต่อท้าย (`§V`) ต้องมีฐานรองรับที่อยู่รอดผ่านการ refactor ข้อตรวจพบต้องเป็นรายการเดียวตลอดทุกเฟสที่แตะต้อง และไฟล์ที่เปลี่ยนชื่อหรือย้ายต้องไม่ทำให้ห่วงโซ่ขาด SDH แก้ปัญหานี้ด้วย **อัตลักษณ์ตามชื่อ** และ **path ที่เก็บไว้เฉพาะในการติดตาม**

> **นิยาม**
>
> **อัตลักษณ์ตามชื่อ** (identity-by-name): อัตลักษณ์ของข้อตรวจพบคือชื่อ ที่เขียนเหมือนกันทุกตัวอักษรในทุกอาร์ติแฟกต์ ข้อความมีชื่อ ไม่เคยมี path path ของไฟล์อยู่เฉพาะในแผนผังการติดตาม การเปลี่ยนชื่อหรือย้ายไฟล์จึงทำให้การเชื่อมโยงขาดในจุดเดียวเท่านั้น

ข้อตรวจพบแต่ละรายการจาก detect คือรายการที่ติดตามหนึ่งรายการ อัตลักษณ์ของรายการคือ **ชื่อ** ซึ่งเป็นชื่อหัวข้อที่เขียนเหมือนกันทุกตัวอักษรในแผนผังจาก detect แผนการป้องกัน และบันทึก hardening เฟสถัดไปใช้ชื่อนั้นซ้ำแบบคำต่อคำขณะลงมือกับรายการเดียวกัน และ verify เขียนผลตัดสินลงในบันทึก hardening ภายใต้ชื่อเดียวกัน แผนผังการติดตามเก็บเฉพาะการติดตามเท่านั้น หนึ่ง entry ต่อหนึ่งรายการ:

```json
{ "name": "File uploads", "paths": ["src/routes/upload.ts"] }
```

แผนผังไม่บันทึกข้อความ ไม่มีหมายเหตุ ไม่มีตัวระบุแยก และไม่มีเฟส อาร์ติแฟกต์ที่เป็นข้อความเก็บถ้อยคำ ส่วนแผนผังเก็บเพียงอัตลักษณ์และ path ของไฟล์ path เป็นสิ่งเดียวที่เปลี่ยนแปลงง่าย และอยู่ที่นี่เท่านั้น การเปลี่ยนชื่อหรือย้ายไฟล์จึงทำให้การเชื่อมโยงขาดได้ในจุดเดียว ไม่ใช่ในสองสำเนาที่ไม่ตรงกัน

```mermaid
flowchart TB
    detect["แผนผังจาก detect"] --> name
    plan["แผนการป้องกัน"] --> name
    harden["บันทึก hardening<br/>verify เขียนผลตัดสินที่นี่"] --> name
    name["name = &quot;File uploads&quot;<br/>ข้อความมีชื่อ ไม่เคยมี path"]
    name -.-> tracking
    tracking["แผนผังการติดตาม<br/>{ name: &quot;File uploads&quot;,<br/>paths: [&quot;src/routes/upload.ts&quot;] }<br/>path อยู่ที่นี่เท่านั้น การเปลี่ยนชื่อจึงแก้แค่ entry นี้"]
```

**ภาพที่ 5** สายพานอัตลักษณ์ ชื่อข้อตรวจพบหนึ่งชื่อไหลผ่านทุกอาร์ติแฟกต์ ขณะที่ path อยู่เฉพาะในแผนผังการติดตาม การเปลี่ยนชื่อจึงแก้ในจุดเดียว

การกระทำสองอย่างดูแลแผนผังในขั้นตอนปกติ และอย่างที่สามแยกออกมาเป็นงานบำรุงรักษา **Track** คือการลงทะเบียนแบบเพิ่มเข้า: เฟสรายงานข้อตรวจพบที่เขียน และเอนจินบันทึกรายการใหม่ แล้วติดตาม path ที่เปลี่ยนชื่อสำหรับรายการที่เหลือ โดยจัดแต่ละรายการเป็นใหม่ ย้าย หรือไม่เปลี่ยน Track ไม่ลบสิ่งใดที่เฟสไม่ได้รายงาน **Untrack** ปิดข้อตรวจพบที่ verify ปิดแล้วออก: ในรอบ deterministic เดียว untrack กลั่นกรองแต่ละรายการเป็นรายการประวัติ ลบทั้งส่วนออกจากอาร์ติแฟกต์ ลบอาร์ติแฟกต์ที่ข้อตรวจพบสุดท้ายหมดไป และลบ entry การติดตาม เอเจนต์จึงไม่ต้องทำสิ่งเหล่านี้ด้วยมือเลย ในจุดที่รอบ deterministic ไปต่ออย่างปลอดภัยไม่ได้ เช่น ชื่อที่ปิดแล้วแต่ข้อความของข้อตรวจพบอื่นยังอ้างถึง untrack จะทำเครื่องหมายจุดนั้นให้เอเจนต์แทนการเดาว่าจะแก้อย่างไร สองอย่างนี้คือสิ่งที่เฟสเรียกใช้ระหว่างรัน **Repair** คืองานบำรุงรักษา: เฟสจะส่งต่อให้ repair โดยอัตโนมัติเมื่อการปรับให้ตรงกับสภาพปัจจุบันของตัวเองพบว่าการติดตามไม่สอดคล้องกัน (path ที่บันทึกไว้ไม่มีอยู่แล้ว) และนอกจากนั้นจะรันเมื่อผู้ใช้สั่ง repair ปรับแผนผังทั้งหมดในครั้งเดียว โดยอ่านทุกอาร์ติแฟกต์และโค้ดปัจจุบัน แก้ path ของแต่ละรายการ และแจ้งสิ่งที่ตัดสินเองไม่ได้ คือ orphan (รายการที่ติดตามที่ไม่มีอาร์ติแฟกต์ใดเอ่ยชื่ออีกแล้ว) หรือ renamed-candidate (รายการที่ path ตรงกับชื่ออื่นที่มีการรายงาน)

repair คืองานบำรุงรักษา ไม่ใช่เฟสที่หก repair ไม่แตะทั้งโค้ดของผู้ใช้และอาร์ติแฟกต์ที่เป็นข้อความ แตะเฉพาะการติดตาม repair อ่านซอร์สของผู้ใช้ด้วยเหตุผลเดียว คือเพื่อหา path ใหม่ของไฟล์ที่เปลี่ยนชื่อ และไม่เคยเขียนเนื้อหาด้านความปลอดภัย มนุษย์คือผู้ตัดสินสุดท้ายในเรื่องเดียวที่เอนจินไม่ยอมเดา: รายการที่หายไปได้รับการแก้แล้วหรือแค่เปลี่ยนชื่อ ถามดีกว่าเดา เพราะรายการที่ลบผิดทำให้ห่วงโซ่ขาด

ระเบียบวิธีนำวินัยการป้องกันของตัวเองมาใช้กับตัวเองด้วย SDH เรียกเอนจินแบบ deterministic เป็นโปรแกรมบรรทัดคำสั่ง และส่งอินพุตแต่ละตัวเป็นอาร์กิวเมนต์ของโปรเซสแยกกัน อินพุตจึงคงสภาพเป็นข้อมูลเฉย ๆ และค่าที่มีเครื่องหมายคำพูดหรือ backtick ก็แทรกเข้าไปในคำสั่งไม่ได้ การตรวจที่ไม่รู้จักจะล้มเหลวแทนการตอบ การตรวจที่สะกดผิดจึงไม่มีวันอ่านเป็นผลว่าผ่าน SDH ไม่ยกเว้นระบบภายในของตัวเองจากหลักการปลอดภัยตั้งแต่ค่าเริ่มต้น

---

## XII. ตัวนำส่ง: สถาปัตยกรรมที่ไม่ผูกกับเอเจนต์ในฐานะข้อพิสูจน์ว่าย้ายไปใช้ที่อื่นได้

เพื่อให้ SDH เป็นแนวปฏิบัติที่ผู้อื่นนำไปใช้ SDH ต้องไม่ผูกกับเอเจนต์หรือ stack ใด ตัวนำส่งจึงแยกเรื่องสามเรื่องออกจากกัน (ภาพที่ 6) Lagune พิสูจน์ว่าทำได้จริง

**คุณค่าด้านความปลอดภัย** เขียนขึ้นครั้งเดียวและไม่รู้เลยว่าเอเจนต์ใดรันอยู่: คำแนะนำของแต่ละเฟสและเทมเพลตที่คำแนะนำเหล่านั้นเติม แคตตาล็อกความรู้ และเอนจินแบบ deterministic **การส่งมอบ** มีขนาดบาง: หน้าที่เดียวคือนำคุณค่านั้นไปถึงเอเจนต์แต่ละตัวในรูปแบบและตำแหน่งที่เอเจนต์คาดหวัง และไม่มีตรรกะด้านความปลอดภัยของตัวเอง **สถานะของโปรเจกต์** เป็นของโปรเจกต์: charter อาร์ติแฟกต์ของเฟส แผนผังการติดตาม หมวดหมู่ที่เลือก และความรู้เฉพาะทางของโปรเจกต์เอง ซึ่ง commit และตรวจทานได้เหมือนโค้ดส่วนอื่น

```mermaid
flowchart TB
    value["คุณค่าด้านความปลอดภัย เขียนครั้งเดียว<br/>คำแนะนำของเฟส · เทมเพลต · แคตตาล็อกความรู้ · เอนจินแบบ deterministic<br/>ไม่รู้ว่าเอเจนต์ใดรันอยู่"]
    delivery["การส่งมอบ<br/>นำคุณค่านั้นไปถึงเอเจนต์แต่ละตัวในรูปแบบที่เอเจนต์คาดหวัง<br/>ไม่มีตรรกะด้านความปลอดภัย"]
    agent["เอเจนต์<br/>รันเฟสต่าง ๆ"]
    project["สถานะของโปรเจกต์<br/>commit ไปพร้อมโค้ด<br/>charter · อาร์ติแฟกต์ของเฟส · การติดตาม · หมวดหมู่ · ความรู้เฉพาะทางของตัวเอง"]
    value --> delivery --> agent
    agent -->|"อ่านและเขียน"| project
```

**ภาพที่ 6** ตัวนำส่งที่ไม่ผูกกับเอเจนต์ คุณค่าด้านความปลอดภัยเขียนขึ้นครั้งเดียว การส่งมอบแบบบางนำคุณค่านั้นไปถึงเอเจนต์แต่ละตัว และสถานะยังเป็นของโปรเจกต์

เพราะการส่งมอบไม่มีตรรกะด้านความปลอดภัย วิธีสร้างการส่งมอบจึงไม่เปลี่ยนอะไรใน SDH ตัวนำส่งอาจสร้างการส่งมอบเอง หรือมอบให้ระบบนิเวศที่แจกจ่าย skill ของเอเจนต์อยู่แล้ว อย่างที่ต้นแบบอ้างอิงทำ โดยที่เฟส อาร์ติแฟกต์ และหลักประกันของเฟสยังคงเหมือนเดิม ทั้งหมดนี้ไม่ได้เจาะจงกับภาษาหรือ runtime ใดเช่นกัน ต้นแบบอ้างอิงบังเอิญเขียนด้วย stack หนึ่ง แต่ระเบียบวิธีคือเส้นแบ่งระหว่างเรื่องเหล่านี้ ไม่ใช่ toolchain ที่ใช้สร้าง การออกแบบเดียวกันนำไปสร้างใหม่ด้วยภาษาอื่นได้ทั้งหมดโดยไม่เปลี่ยนสิ่งที่ SDH เป็น

---

## XIII. กรณีศึกษา: SDH ตั้งแต่ต้นจนจบ

> **กรณีศึกษา**
>
> **การเสริมความปลอดภัยเชิงป้องกันให้ส่วนอัปโหลดและส่วนผู้ดูแลระบบ**
> **บริบท**: แอปขนาดเล็กที่รับไฟล์อัปโหลดจากผู้ใช้และแสดงรายการไฟล์ในหน้าผู้ดูแลระบบ
> **รูปแบบ**: charter → detect (พร้อมความรู้ที่บริบทเปิดใช้เฉพาะเมื่อจำเป็น) → plan → harden → verify โดยมีการปิดหนึ่งครั้งและความล้มเหลวจริงหนึ่งครั้ง
> **ผลลัพธ์ (ความสามารถ)**: ความเสี่ยงหนึ่งรายการตรวจยืนยันว่าปิดแล้วและปิดออกจากทั้งห่วงโซ่ และมาตรการควบคุมหนึ่งรายการตรวจยืนยันว่า _ยังไม่_ ปิด จึงส่งกลับไปที่ harden ผลตัดสินสะท้อนโค้ด ไม่ใช่บันทึก

_นี่คือตัวอย่างประกอบเพื่อแสดงกลไกของระเบียบวิธี ไม่ใช่การศึกษาที่วัดผลจากการใช้งานจริง และไม่ได้รายงานตัวชี้วัดด้านประสิทธิผลใด ๆ_

การไล่ดูต่อเนื่องครั้งเดียวแสดงให้เห็นระเบียบวิธีขณะทำงาน ไม่ใช่แค่ส่วนประกอบ เราขยายตัวอย่างการอัปโหลดไฟล์จาก `§IV` ด้วยการเปิดใช้ความรู้เฉพาะเมื่อจำเป็นและการปิดข้อตรวจพบ และรวมความล้มเหลวจริงหนึ่งครั้งไว้ด้วย

1. **charter** เสนอหลักการ "อินพุตทุกอย่างไม่น่าเชื่อถือจนกว่าจะผ่านการตรวจสอบ" พร้อมความเสี่ยงในภาษาเข้าใจง่าย: อินพุตที่ไม่ได้ตรวจคือสาเหตุที่พบบ่อยที่สุดที่ทำให้ระบบถูกเจาะ
2. **detect** สแกน route การอัปโหลดและหน้าผู้ดูแลระบบเล็ก ๆ ที่แสดงรายการไฟล์ที่อัปโหลด detect พบข้อตรวจพบเรื่องการอัปโหลด (handler เชื่อ MIME type ของไคลเอนต์) หน้าผู้ดูแลระบบรันในเบราว์เซอร์ ซึ่งเป็นบริบทที่ prompt-on-demand (`§VII`) จดจำได้ detect จึงโหลดความรู้เฉพาะทางสำหรับบริบทนั้นและพบข้อตรวจพบที่สอง: จุดที่โค้ดเขียนชื่อไฟล์ลงในหน้าเป็น markup แทนที่จะเป็นข้อความ ชื่อที่จงใจสร้างขึ้นจึงรันเป็นสคริปต์ในเบราว์เซอร์ของผู้เข้าชมได้ ความรู้เฉพาะทางที่บริบทไม่ปรากฏในขอบเขตนี้ไม่เคยโหลด และการข้ามแต่ละครั้งบันทึกไว้พร้อมหลักฐานจากโค้ดว่าบริบทนั้นไม่มีอยู่
3. **plan** กำหนดลำดับความสำคัญระดับวิกฤตให้การแก้ไขเรื่องการอัปโหลด โดยผูกกับหลักการ: ตรวจประเภทและขนาดจริงของไฟล์ เปลี่ยนชื่อตอนบันทึก และจัดเก็บในที่ที่โค้ดรันไม่ได้ และกำหนดลำดับความสำคัญระดับสูงให้การแก้ไขที่สอง: แสดงชื่อไฟล์เป็นข้อความ ไม่ใช่ markup
4. **harden** นำการแก้ไขเรื่องการอัปโหลดไปใช้ก่อน (ลำดับความสำคัญสูงสุด) และบันทึกเป็น Applied แล้วตามด้วยการแก้ไขที่สอง ซึ่งเป็น Applied เช่นกัน
5. **verify** อ่านแต่ละจุดและเทียบโค้ดกับบันทึก มาตรการควบคุมการอัปโหลดใช้ได้จริง: handler ตรวจประเภทจริงจากเนื้อหาไฟล์ บังคับจำกัดขนาด และปฏิเสธส่วนที่เหลือ ผลตัดสิน: ความเสี่ยงปิดแล้ว verify ปิดข้อตรวจพบเรื่องการอัปโหลดออกจากทั้งห่วงโซ่ และสรุปที่กลั่นกรองแล้วไปอยู่ในประวัติ

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

นี่คือลักษณะของระเบียบวิธีในตัวอย่างเดียว: การตรวจจับที่เข้าใจบริบท การแก้ไขที่จัดลำดับความสำคัญและผูกกับหลักการ การนำไปใช้อย่างระมัดระวัง และการตรวจยืนยันที่รายงานสถานะจริงของโค้ดไม่ว่าบันทึกจะเขียนไว้อย่างไร

---

## XIV. เมื่อใดควรใช้ SDH และข้อจำกัด

SDH แทบไม่เคยเกินความจำเป็นแบบที่กระบวนการหนัก ๆ มักเป็น เพราะ SDH ไม่ขึ้นกับสถานะและปิดให้จบได้: ย่อขนาดลงเหลือไฟล์เดียวและข้อกังวลเดียวได้ และไปถึงสถานะสิ้นสุดแทนการทิ้งภาระค้างไว้ ขอบเขตของ SDH ไม่ใช่ขนาดโปรเจกต์ แต่คือ **ระดับความลึกของการรับประกัน**

```mermaid
flowchart TB
    q1{"โค้ดทำอะไรที่เกี่ยวกับความปลอดภัยหรือไม่<br/>(อินพุต การยืนยันตัวตน ข้อมูล secret การเรียกระบบภายนอก)"}
    q1 -->|ไม่| little["SDH ช่วยได้น้อยในกรณีนี้"]
    q1 -->|ใช่| q2{"รัน SDH มีเกณฑ์ด้าน compliance<br/>หรือฝ่ายความปลอดภัยโดยเฉพาะหรือไม่"}
    q2 -->|ไม่| baseline["SDH คือพื้นฐานที่มีเหตุผลรองรับ"]
    q2 -->|ใช่| carrier["SDH คือตัวนำส่งที่มีโครงสร้าง:<br/>สนับสนุนการตรวจทานและการตรวจสอบโดยผู้เชี่ยวชาญ<br/>ไม่ได้มาแทนสิ่งเหล่านั้น"]
```

**ภาพที่ 7** เมื่อใดควรใช้ SDH ทางแยกแรกคือความเกี่ยวข้องกับความปลอดภัย ตามด้วยระดับความลึกของการรับประกัน ไม่เคยเป็นขนาดโปรเจกต์

จุดที่ SDH ถึงขอบเขต: พฤติกรรมที่ปรากฏเฉพาะเมื่อระบบรัน (verify อ่านโค้ด ไม่ได้รันระบบ) ความเสี่ยงที่ขึ้นกับการตั้งค่าหรือสภาพแวดล้อมที่เอเจนต์อ่านไม่ได้ และบริบทที่มีเดิมพันสูงที่ต้องมีการตรวจทานโดยผู้เชี่ยวชาญไม่ว่าอย่างไร ในแต่ละกรณี SDH ยังเพิ่มคุณค่าในฐานะการตรวจรอบแรกที่มีโครงสร้าง แต่เป็นพื้น ไม่ใช่เพดาน

> **ข้อคิดสำคัญ**
>
> **ขอบเขต**: ข้อจำกัดของ SDH คือระดับความลึกของการรับประกัน ไม่ใช่ขนาดโปรเจกต์ SDH เป็นพื้นฐานที่มีเหตุผลรองรับได้แทบทุกที่ และสนับสนุนการตรวจทานโดยผู้เชี่ยวชาญในจุดที่เดิมพันสูง แต่ไม่ได้มาแทนการทดสอบบนระบบที่กำลังรันหรือวิจารณญาณของผู้เชี่ยวชาญด้านความปลอดภัย

---

## XV. การอภิปราย: จุดยืน ข้อจำกัด และสิ่งที่ SDH ไม่ได้อ้าง

SDH ระบุขอบเขตของตัวเองอย่างแม่นยำ

### ขยาย ไม่ได้มาแทน

SDH ไม่ได้มาแทนผู้เชี่ยวชาญด้านความปลอดภัยหรือเครื่องมือ Blue Team เฉพาะทาง แต่ขยายความรู้ของนักพัฒนา (`§VI`) การอ้างอย่างพอประมาณคือการอ้างที่ถูกต้อง: เมื่อใช้อย่างดี SDH **สามารถ** ปิดความเสี่ยงจริงได้อย่างมีประสิทธิภาพ โดยเฉพาะสำหรับโปรเจกต์ที่ไม่เช่นนั้นจะไม่ได้รับการตรวจด้านความปลอดภัยเลย SDH ไม่ใช่หลักประกัน และไม่ใช่สิ่งทดแทนการตรวจทานโดยผู้เชี่ยวชาญในจุดที่เดิมพันต้องการ

### เพื่อการป้องกันเท่านั้นโดยโครงสร้าง

SDH ตรวจสอบ เสริมความปลอดภัย และตรวจยืนยัน ไม่เคยสร้างเครื่องมือโจมตี exploit หรือเทคนิคหลบเลี่ยงการตรวจจับเพื่อก่อความเสียหาย เนื้อหาด้านความปลอดภัยที่ใช้ได้สองทางยอมรับได้เฉพาะในกรอบที่ชัดเจนว่าเพื่อการป้องกันและได้รับอนุญาต นี่คือขอบเขตที่เด็ดขาด ไม่ใช่ความชอบส่วนตัว

### การตรวจยืนยันมีเนื้อหาจริง ไม่ใช่การแสดง

verify ตรวจยืนยันด้วยการอ่านโค้ดและเทียบกับบันทึก ไม่ใช่ด้วยการรันระบบ นี่คือการตรวจยืนยันแบบ static: ยืนยันว่ามาตรการควบคุมมีอยู่และถูกต้องในโค้ด และไม่ได้พิสูจน์ว่ามาตรการควบคุมต้านการโจมตีขณะรันได้ ดังนั้น "บอกไม่ได้จากโค้ด" จึงเป็นผลตัดสินที่ชอบธรรม ไม่ใช่ความล้มเหลวที่ซ่อนอยู่หลังผลว่าผ่าน เมื่อหลักฐานไม่ได้อยู่ในโค้ด (ขึ้นกับการตั้งค่า หรือ path ที่เอเจนต์อ่านไม่ได้) SDH จะบอกตรง ๆ แทนการเดา

### ความเป็น deterministic มีขอบเขตและระบุชัด

SDH ส่วนใหญ่อาศัยการให้เหตุผลของเอเจนต์ ซึ่งเป็นสิ่งที่ทำให้เข้าใจบริบทได้ ความเป็น deterministic สงวนไว้สำหรับเอนจินแบบ deterministic: ตัวตรวจที่ความรู้เฉพาะทางอาจมีมาด้วย (`§VII`) และเอนจินการติดตาม (`§XI`) เอกสารนี้ไม่ทำให้เส้นแบ่งนี้พร่ามัว ผลที่เป็น deterministic คือผลของโปรแกรม ผลที่มาจากการให้เหตุผลคือการอ่านโค้ดของเอเจนต์ โดยมีผู้ใช้เป็นผู้ตัดสินสุดท้าย

### ต้นทุนและขนาด

การสแกนเต็มรูปแบบใช้ token มาก โหมดที่ผู้ใช้กำหนดเอง (`§VI`, `§VIII`) มีขึ้นส่วนหนึ่งเพื่อให้ต้นทุนได้สัดส่วนกับข้อกังวล

### ผู้ใช้คือผู้ตัดสินสุดท้าย

SDH ให้มนุษย์ตัดสินว่ารายการเปลี่ยนชื่อหรือแก้แล้ว และการอนุมัติการแก้โค้ดยังอยู่ในจุดที่ผู้ใช้ควบคุมเอเจนต์อยู่แล้ว คือโหมดสิทธิ์ที่ใช้รันเอเจนต์ ระเบียบวิธีเสนอและตรวจยืนยัน แต่ไม่ลบล้างการตัดสินของคน

### ข้อโต้แย้งและคำตอบ

ผู้ที่สงสัยอย่างเป็นธรรมจะยกข้อโต้แย้งหลายข้อ ข้อที่มีสาระควรตั้งด้วยถ้อยคำของพวกเขาเอง

**"นี่ก็แค่ static analyzer ที่เอา LLM มาต่อพ่วงไม่ใช่หรือ"** ไม่ใช่ static analyzer รันกฎทุกข้อที่มีเป็นค่าเริ่มต้น SDH ตรวจจับก่อนว่าระบบเป็นอะไร แล้วจึงหยิบความรู้ที่เกี่ยวข้อง (`§II`, `§VII`) และ _ฝัง_ ตัวตรวจแบบ deterministic เฉพาะในจุดที่ประเภทความเสี่ยงมีขั้นตอนการตัดสินที่ชัดเจน การให้เหตุผลเริ่มจากบริบท ความเป็น deterministic ใช้อย่างเจาะจง

**"นี่ก็แค่เช็กลิสต์ความปลอดภัยไม่ใช่หรือ"** ไม่ใช่ SDH กลับด้านเช็กลิสต์: การตรวจจับมาก่อน แล้วจึงดึงความรู้เข้ามาตามสิ่งที่โปรเจกต์ทำจริง (`§II`, `§VII`)

**"นี่ก็แค่ SDD ที่เปลี่ยนชื่อใหม่มาทำเรื่องความปลอดภัยไม่ใช่หรือ"** ไม่ใช่ SDH ยืมโครงสร้างของ SDD และกลับด้านสัญญา: อำนาจ สถานะที่สมมติไว้ เงื่อนไขการจบ และผู้ที่ได้ประโยชน์ ต่างกันทั้งหมด (`§X`) กลไกเดียวกัน ทิศทางตรงข้าม

**"วิธีที่ใช้ AI ให้เหตุผลก็แค่หลอนข้อตรวจพบขึ้นมาเองไม่ใช่หรือ"** การออกแบบจำกัดการแต่งเติม แทนการเชื่อใจว่าโมเดลจะประพฤติดี detect บันทึกเฉพาะสิ่งที่โค้ดรองรับ ("ตรวจจับ ไม่ใช่แต่งเติม" `§IV`) verify เทียบโค้ดกับบันทึกและตอบได้ว่า "บอกไม่ได้จากโค้ด" (`§XV`) ตัวตรวจแบบ deterministic เป็นหลักยึดให้กรณีที่ตัดสินได้ (`§VII`) และผู้ใช้คือผู้ตัดสินสุดท้าย สิ่งนี้ไม่ได้ทำให้เอเจนต์ไม่มีวันผิด แต่ทำให้ข้อกล่าวอ้างของเอเจนต์ตรวจสอบได้

หมายเหตุเรื่องจุดยืน: เอกสารนี้นิยาม SDH โดยไม่ขึ้นกับต้นแบบอ้างอิง 5 เฟส charter ที่วางกรอบด้วยความเสี่ยง การปรับให้ตรงกับสภาพปัจจุบันแทนการต่อท้ายและการปิดให้จบได้ ความรู้แบบ prompt-on-demand โหมดป้องกันล่วงหน้า การติดตามด้วยอัตลักษณ์ตามชื่อ และขอบเขตเพื่อการป้องกันเท่านั้น คือตัวระเบียบวิธี ทีมอื่นอาจนำไปสร้างใน stack อื่นและระบบนิเวศเอเจนต์อื่น และผลลัพธ์ก็ยังเป็น SDH Lagune คือข้อพิสูจน์ ไม่ใช่นิยาม

---

## XVI. หลุมพราง และวิธีที่ SDH หลีกเลี่ยงด้วยโครงสร้าง

ระเบียบวิธีในตระกูลนี้มีชุดรูปแบบความล้มเหลวที่รู้กันอยู่ คำตอบของ SDH ต่อส่วนใหญ่เป็นเชิงโครงสร้าง ฝังอยู่ในขั้นตอน แทนที่จะปล่อยให้ขึ้นกับวินัย

| หลุมพราง                       | ความล้มเหลว                                        | คำตอบเชิงโครงสร้างของ SDH                                                                                                                |
| ------------------------------ | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| สเปกเสื่อม และ backlog ล้าสมัย | อาร์ติแฟกต์สะสมรายการที่ตายแล้วที่ไม่มีใครเชื่อถือ | ปรับให้ตรงกับสภาพปัจจุบันแทนการต่อท้าย (`§V`): การรันแต่ละครั้งตรวจทุกรายการซ้ำและลบสิ่งที่แก้แล้ว                                       |
| ความมั่นใจผิด ๆ จากผลว่าผ่าน   | สมมติเอาว่ามาตรการควบคุมที่มีอยู่ปิดความเสี่ยงแล้ว | verify เทียบโค้ดกับบันทึก "ความเสี่ยงยังไม่ปิด" และ "บอกไม่ได้" จึงเป็นผลตัดสินชั้นหนึ่ง (`§IV`, `§XV`)                                  |
| เช็กลิสต์ท่วมท้น               | รายการทั่วไปบดบังความเสี่ยงเดียวที่สำคัญ           | เข้าใจบริบทดีกว่าใช้แบบทั่วไป โดย prompt-on-demand โหลดเฉพาะสิ่งที่ขอบเขตต้องการ (`§VII`)                                                |
| ติดอยู่กับเครื่องมือ           | วิธีการผูกติดกับผู้ให้บริการหรือเอเจนต์รายเดียว    | ตัวนำส่งที่ไม่ผูกกับเอเจนต์: คุณค่าด้านความปลอดภัยเขียนขึ้นครั้งเดียว และการส่งมอบไปยังเอเจนต์แต่ละตัวไม่มีตรรกะด้านความปลอดภัย (`§XII`) |
| วงจรไม่รู้จบ                   | backlog ไม่เคยปิด งานไม่เคยสิ้นสุด                 | การปิดให้จบได้และสถานะสิ้นสุด (`§V`)                                                                                                     |

**ตารางที่ 4** หลุมพรางที่รู้กันในตระกูลระเบียบวิธีนี้ และคำตอบเชิงโครงสร้างของ SDH ต่อแต่ละข้อ

การระบุหลุมพรางและชี้ไปที่กลไกคือประเด็นสำคัญ: สิ่งเหล่านี้ไม่ใช่คำเตือนให้ระวัง แต่เป็นคุณสมบัติของขั้นตอน

---

## XVII. งานในอนาคต

ระเบียบวิธีและต้นแบบอ้างอิงมีขั้นต่อไปที่ชัดเจน

- **ขยายแคตตาล็อกความรู้**:
  การเพิ่มแต่ละครั้งคงรูปแบบของ `§VII`: ไฟล์ความรู้หนึ่งไฟล์และแถวแคตตาล็อกหนึ่งแถว ไม่มีคำสั่งใหม่ เส้นทางฝั่งผู้ใช้มีอยู่แล้วตรงนั้น: ผู้ใช้กลั่นกรองความรู้เฉพาะทางของตัวเองได้เมื่อต้องการ ภาษา runtime และประเภทความเสี่ยงในตัวที่มากขึ้น ซึ่งแต่ละอย่างเข้าร่วมหมวดหมู่หนึ่ง คือทิศทางฝั่งผู้ดูแล และคาดว่าความรู้เฉพาะทางจะพัฒนาต่อไป
- **ตัวตรวจแบบ deterministic เพิ่มขึ้น**:
  ในจุดที่ประเภทความเสี่ยงมีขั้นตอนการตัดสินที่ชัดเจน ความรู้เฉพาะทางมีตัวตรวจแบบ deterministic มาด้วยได้ เพื่อยึดการให้เหตุผลของเอเจนต์ไว้กับผลตัดสินที่ทำซ้ำได้ การขยายสิ่งนี้ไปยังประเภทความเสี่ยงอื่น ๆ เป็นทิศทางที่เป็นธรรมชาติ
- **การประเมินเชิงประจักษ์**:
  คำถามเปิดที่สำคัญที่สุดคือประสิทธิผลที่วัดได้: คุณภาพของการปิดและอัตราผลตัดสินผิดในโค้ดเบสจริง การศึกษาผลลัพธ์ด้านความปลอดภัยของ SDH เป็นงานในอนาคต และข้อกล่าวอ้างในเอกสารนี้จำกัดขอบเขตไว้ตามนั้น

---

## XVIII. บทสรุป

การพัฒนาที่มี AI ช่วยเปิดช่องว่างด้านความปลอดภัยที่เช็กลิสต์ทั่วไปเติมไม่เต็ม เพราะความเสี่ยงที่สำคัญเจาะจงกับสิ่งที่ระบบทำจริง และคนที่ปล่อยระบบอาจไม่รู้ว่าควรถามอะไร SDH ปิดช่องว่างนั้นด้วยขั้นตอนที่เข้าใจบริบท เพื่อการป้องกันเท่านั้น และปิดให้จบได้ โดยความรู้ด้านความปลอดภัยอยู่ในระเบียบวิธีและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น เป็นพื้นฐานที่ผู้ใช้ทุกคนต่อยอดได้ SDH ตรวจจับบริบทจริงของระบบ คัดกรองความเสี่ยงที่บริบทนั้นมี นำการแก้ไขไปใช้อย่างระมัดระวัง และตรวจยืนยันทีละรายการ จากนั้นปิดสิ่งที่ปิดได้แล้วออก ข้อตรวจพบแต่ละรายการจึงไปถึงสถานะสิ้นสุด การป้องกันชุดเดียวกันยังทำงานล่วงหน้าขณะสร้างงานใหม่ สิ่งที่ขั้นตอนปิดไปแล้วจึงยังคงปิดอยู่ SDH ปรับเข้ากับสถานะการพัฒนาใดก็ได้ใน stack ใดก็ได้ และขยายความรู้ของนักพัฒนาแทนที่จะมาแทนคนและเครื่องมือที่ทำงานนั้นอยู่แล้ว

Lagune คือข้อพิสูจน์ แต่ผลงานคือแนวปฏิบัติ SDH เสนอตัวเป็นขั้นตอนด้านความปลอดภัยที่จำเป็นสำหรับยุคการพัฒนาด้วย AI ให้ผู้อื่นนำไปใช้ ปรับปรุง และสร้างขึ้นใน stack ของตัวเอง

---

## เอกสารอ้างอิง

**[1]** D. B. Piskala, "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants," arXiv preprint arXiv:2602.00180v1 [cs.SE], Jan. 2026. (ส่งเข้าร่วม AIWare 2026) [ออนไลน์]. เข้าถึงได้ที่: https://arxiv.org/abs/2602.00180

**[2]** GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [ออนไลน์]. เข้าถึงได้ที่: https://github.com/github/spec-kit. เข้าถึงเมื่อ: 2026.

**[3]** Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [ออนไลน์]. เข้าถึงได้ที่: https://github.com/Fission-AI/OpenSpec. เข้าถึงเมื่อ: 2026.

**[4]** B. Chess และ G. McGraw, "Static Analysis for Security," IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79, 2004, doi: 10.1109/MSP.2004.111.

**[5]** OWASP Foundation, "Source Code Analysis Tools." [ออนไลน์]. เข้าถึงได้ที่: https://owasp.org/www-community/Source_Code_Analysis_Tools. เข้าถึงเมื่อ: 2026.

**[6]** OWASP Foundation, "OWASP Top 10:2021." [ออนไลน์]. เข้าถึงได้ที่: https://owasp.org/Top10/. เข้าถึงเมื่อ: 2026.

**[7]** MITRE, "Common Weakness Enumeration (CWE)." [ออนไลน์]. เข้าถึงได้ที่: https://cwe.mitre.org/. เข้าถึงเมื่อ: 2026.

**[8]** N. Perry, M. Srivastava, D. Kumar และ D. Boneh, "Do Users Write More Insecure Code with AI Assistants?," in Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS '23), 2023, pp. 2785-2799, doi: 10.1145/3576915.3623157. [ออนไลน์]. เข้าถึงได้ที่: https://arxiv.org/abs/2211.03622

**[9]** J. Davis และผู้ร่วมพัฒนา, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [ออนไลน์]. เข้าถึงได้ที่: https://github.com/davisjam/safe-regex. เข้าถึงเมื่อ: 2026.

**[10]** D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [ออนไลน์]. เข้าถึงได้ที่: https://github.com/DmitrySoshnikov/regexp-tree. เข้าถึงเมื่อ: 2026.

**[11]** T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [ออนไลน์]. เข้าถึงได้ที่: https://github.com/tjenkinson/redos-detector. เข้าถึงเมื่อ: 2026.

---

## ภาคผนวก A: หลักการฉบับเต็มตามต้นฉบับ

1. **ปลอดภัยตั้งแต่ค่าเริ่มต้น ใช้ภาษาที่เข้าใจง่าย และเท่าเทียมสำหรับทุกคน**:
   ค่าเริ่มต้น ข้อความ และการแก้ไขทุกอย่างต้องปลอดภัยตั้งแต่แรกและเข้าใจได้สำหรับผู้ใช้ทุกคน ไม่ว่าจะเป็นนักพัฒนาหรือไม่ ไม่มีผู้ใช้ระดับใดได้สิทธิพิเศษเหนือระดับอื่น
2. **เข้าใจบริบทดีกว่าใช้แบบทั่วไป**:
   ทุกเฟสต้องเริ่มจากบริบทที่ตรวจพบในเฟส detect และลงมือกับสิ่งที่ระบบทำจริง เลือกคำแนะนำที่เจาะจงกับบริบทนั้นมากกว่าเช็กลิสต์ทั่วไป ความรู้ด้านความปลอดภัยอยู่ในสเปกและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น และขยายสิ่งที่ผู้ใช้มีอยู่แล้ว
3. **ยืดหยุ่นดีกว่าตายตัว**:
   SDH ปรับตามโปรเจกต์และผู้ใช้ หลักการ ข้อกำหนด และคำแนะนำเป็นจุดเริ่มต้น ไม่ใช่สัญญาตายตัว ให้ผู้ใช้เขียนใหม่ ตัดออก เพิ่ม หรือจำกัดขอบเขตของสิ่งใดก็ได้ ความยืดหยุ่นไม่เคยลดทอนพื้นฐานที่ปลอดภัยตั้งแต่ค่าเริ่มต้น เพียงให้ผู้ใช้กำหนดวิธีนำพื้นฐานนั้นไปใช้
4. **ปรับให้ตรงกับสภาพปัจจุบัน ไม่ใช่แค่ต่อท้าย**:
   อาร์ติแฟกต์เป็นเอกสารที่มีชีวิต ไม่ใช่ log เมื่อเฟสรันซ้ำ ให้ปรับรายการเดิมแต่ละรายการให้ตรงกับสภาพปัจจุบัน: เก็บสิ่งที่ยังจริง เขียนใหม่ในสิ่งที่เปลี่ยน และลบสิ่งที่ไม่เกี่ยวข้องแล้ว การปิดคือการปรับให้ตรงกับสภาพปัจจุบันแบบเดียวกันที่ไปถึงข้อสรุป
5. **เพื่อการป้องกันเท่านั้น**:
   SDH ตรวจสอบ เสริมความปลอดภัย และตรวจยืนยัน ไม่เคยสร้างเครื่องมือโจมตี exploit เพื่อใช้ในทางร้าย หรือเทคนิคหลบเลี่ยงการตรวจจับเพื่อก่อความเสียหาย เนื้อหาด้านความปลอดภัยที่ใช้ได้สองทางยอมรับได้เฉพาะในกรอบที่ชัดเจนว่าเพื่อการป้องกันและได้รับอนุญาต
6. **spec-first ขับเคลื่อนด้วยเอเจนต์ และวางกรอบเพื่อความปลอดภัย**:
   สร้างเวิร์กโฟลว์จากโครงสร้างที่พิสูจน์แล้ว: เทมเพลต คำสั่ง charter ที่กำกับทุกเฟส และเอเจนต์ที่รันเฟสต่าง ๆ แล้วสร้างโครงสร้างนั้นขึ้นใหม่โดยมีเป้าหมายเพื่อการป้องกัน

---

# อภิธานศัพท์ Lagune: SDH, charter, ข้อตรวจพบ และมาตรการควบคุม

> คำอธิบายด้วยภาษาที่เข้าใจง่ายของทุกคำศัพท์ใน Lagune และ Security-Driven Hardening: SDH, charter, detect, harden, verify และ stand down รวมถึงข้อตรวจพบ มาตรการควบคุม การปิดให้จบได้ ความรู้เฉพาะทาง หมวดหมู่ และแคตตาล็อก

Canonical: https://lagune.ai/th-TH/docs/references/glossary
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/references/glossary
อัปเดตล่าสุด: 2026-11-07

คำศัพท์สำคัญทุกคำใน Lagune และระเบียบวิธี Security-Driven Hardening อธิบายไว้ในที่เดียวด้วยภาษาที่เข้าใจง่าย

### Security-Driven Hardening (SDH)

ระเบียบวิธีที่ Lagune นำมาสร้างเป็นเครื่องมือ: แนวปฏิบัติแบบ Blue Team ที่เข้าใจบริบท ซึ่งตรวจจับบริบทของระบบ คัดกรองความเสี่ยงที่บริบทนั้นมี และชี้นำการแก้ไข ความรู้ด้านความปลอดภัยอยู่ในสเปกและความรู้เฉพาะทางที่โหลดเฉพาะเมื่อจำเป็น นักพัฒนาและผู้ที่ไม่ใช่นักพัฒนาจึงได้รับการดูแลผ่านขั้นตอนเดียวกัน

### Lagune

ต้นแบบอ้างอิง (reference implementation) ของ SDH: คำสั่งสำหรับเอเจนต์ 9 คำสั่ง แต่ละคำสั่งมาพร้อมเทมเพลตที่คำสั่งนั้นเติม ซึ่งเอเจนต์ AI รันเพื่อเสริมความปลอดภัยให้โค้ดเบส เอเจนต์แต่ละตัวติดตั้งคำสั่งเหล่านี้ผ่านตัวติดตั้งปลั๊กอินของตัวเองหรือผ่าน [**skills.sh**](https://www.skills.sh/wellwelwel/lagune) ตามที่ [หน้าการติดตั้ง](https://lagune.ai/th-TH/docs) แสดงไว้ และคำสั่งเหล่านี้รันเอนจินของ Lagune สำหรับทุกขั้นตอนแบบ deterministic

### Charter

ชั้นที่กำกับทุกเฟสของ Lagune: ชุดหลักการที่ให้ความปลอดภัยมาก่อน ซึ่งทุกเฟสถัดไปต้องเคารพ เปรียบได้กับการตรวจตอนคอมไพล์สำหรับสถานะความปลอดภัยโดยรวมของโปรเจกต์ charter เก็บไว้ที่ `.lagune/memory/charter.md`

### ขั้นตอนการพัฒนา

คำสั่ง universal `/lagune` ที่เสริมความปลอดภัยให้งานขณะเขียน คำสั่งนี้รับ prompt ใดก็ได้ในทุกขั้นของงาน สร้างสิ่งที่คุณขอ และเสริมความปลอดภัยด้วยค่าเริ่มต้นที่ปลอดภัยก่อนส่งคืน โดยมี charter ชี้นำเมื่อมี charter อยู่แล้ว คำสั่งนี้ไม่เขียนอะไรลงในการติดตามของ Lagune ผลลัพธ์เดียวจึงเป็นโค้ดที่เสริมความปลอดภัยแล้ว เมื่อใช้ร่วมกับ charter (ก่อน) และขั้นตอนแบบ Blue Team (หลัง) นี่คือวิธีที่ Lagune ปกป้องระหว่างสร้างงาน

### ขั้นตอนแบบ Blue Team

การตรวจสอบ 5 เฟสที่เป็นแกนหลักของ Lagune: charter, detect, plan, harden, verify แต่ละเฟสต่อยอดจากเฟสก่อนหน้า "Blue Team" คือธรรมเนียมของฝ่ายผู้ป้องกันในวงการความปลอดภัย ตรงข้ามกับ Red Team ที่เป็นฝ่ายโจมตี

### ข้อตรวจพบ

ความเสี่ยงหนึ่งรายการที่ตรวจพบ ข้อตรวจพบแต่ละรายการระบุว่าคืออะไร ทำไมจึงสำคัญ และหลักฐานในโค้ด ข้อตรวจพบคือหน่วยเดียวที่ติดตามและที่ plan, harden และ verify ส่งต่อกัน โดยระบุด้วยชื่อในทุกอาร์ติแฟกต์

### มาตรการควบคุม

มาตรการด้านความปลอดภัยที่นำไปใช้เพื่อปิดความเสี่ยง harden นำมาตรการควบคุมไปใช้ และ verify พิสูจน์ว่ามาตรการนั้นยังได้ผล Lagune ไม่เคยลดทอนมาตรการควบคุมเพื่อทำตาม prompt

### Detect

เฟสที่อ่านโค้ดและทำแผนผังว่าระบบทำอะไรและความเสี่ยงอยู่ที่ไหน กฎที่กำกับเฟสนี้คือตรวจจับ ไม่ใช่แต่งเติม: บันทึกเฉพาะสิ่งที่โค้ดรองรับ

### Harden

เฟสเดียวที่แตะโค้ดของคุณ เฟสนี้นำการแก้ไขจากแผนไปใช้ทีละรายการ และบันทึกแต่ละรายการเป็น Applied, Partial หรือ Blocked Applied ยังไม่ได้แปลว่าพิสูจน์แล้ว

### Verify

เฟสที่พิสูจน์ว่าการแก้ไขแต่ละรายการที่นำไปใช้แล้วยังได้ผล ด้วยการอ่านโค้ดแล้วเทียบกับสิ่งที่ harden บันทึกไว้ เฟสนี้ให้ผลตัดสินหนึ่งในสามแบบ: Risk closed, Risk not closed หรือ Cannot tell from the code

### Stand down

เมื่อ verify พิสูจน์ว่าความเสี่ยงปิดแล้ว ข้อตรวจพบนั้นจะปิดลง (stand down): ลบออกจากทั้งห่วงโซ่เมื่อคุณยืนยัน และไม่มีการประมวลผลซ้ำอีก

### การปิดให้จบได้

คุณสมบัติที่ทำให้งานด้านความปลอดภัยมีสถานะสิ้นสุด เพราะข้อตรวจพบที่พิสูจน์แล้วว่าปิดได้จะปิดออกจากห่วงโซ่ ขั้นตอนจึงสิ้นสุดลงได้ และเปิดใหม่ก็ต่อเมื่อโค้ดเปลี่ยนเท่านั้น SDH ปิดให้จบได้ ไม่ใช่วงจรที่วนไม่รู้จบ

### เอนจิน

แพ็กเกจ `lagune` บน **npm** ที่คำสั่งต่าง ๆ รันผ่าน `npx` สำหรับทุกขั้นตอนแบบ deterministic: hook แคตตาล็อก และหมวดหมู่

### ความรู้เฉพาะทาง

โมดูลความรู้ด้านความปลอดภัยแบบเจาะจงที่ไม่ผูกกับภาษาโปรแกรม ซึ่งโหลดเฉพาะเมื่อจำเป็นและไม่โหลดเป็นค่าเริ่มต้น ความรู้เฉพาะทางไม่ใช่คำสั่ง โหลดความรู้เฉพาะทางเข้า prompt ใดก็ได้ด้วยคำสั่ง `read catalog <name>` ของเอนจิน เช่น `npx lagune read catalog regex`

### หมวดหมู่

กลุ่มความรู้เฉพาะทางในตัวที่มีชื่อเรียก ตั้งแต่ `owasp` ไปจนถึงหมวดหมู่ตามภาษาอย่าง `javascript`, `python`, `go` และ `rust` หมวดหมู่ที่โปรเจกต์ใช้ ซึ่งบันทึกไว้ใน `.lagune/configs.json` เป็นตัวกำหนดว่าความรู้ในตัวชุดใดเข้าร่วมแคตตาล็อกของโปรเจกต์ ระหว่างที่ยังไม่มีหมวดหมู่ใดบันทึกไว้ โปรเจกต์ใช้ `owasp` เพียงหมวดเดียว

### แคตตาล็อก

ชุดความรู้เฉพาะทางที่โปรเจกต์ใช้: ความรู้ในตัวของหมวดหมู่ที่โปรเจกต์เลือก บวกความรู้เฉพาะทางของโปรเจกต์เองที่เขียนด้วย `/lagune-specialize` คำสั่ง `read catalog` ของเอนจินแสดงรายการแคตตาล็อก และเฟสต่าง ๆ นำไปจับคู่กับโค้ด

### Prompt-on-demand

หลักการที่ดึงความรู้ด้านความปลอดภัยที่เกี่ยวข้องเข้ามาตามสิ่งที่โปรเจกต์เป็นจริง แทนการรันทุกการตรวจเป็นค่าเริ่มต้น

### อัตลักษณ์ตามชื่อ

รูปแบบการติดตามของ Lagune: ชื่อของข้อตรวจพบแต่ละรายการ ซึ่งเขียนเหมือนกันทุกตัวอักษรเป็นชื่อหัวข้อในทุกอาร์ติแฟกต์ คืออัตลักษณ์ของข้อตรวจพบตลอดทั้งห่วงโซ่ แผนผังการติดตาม (`.lagune/tracking.json`) เก็บเฉพาะการติดตาม ไม่เคยเก็บข้อความอธิบาย

## คำถามที่พบบ่อย

### Security-Driven Hardening (SDH) คืออะไร

SDH คือระเบียบวิธีด้านความปลอดภัยแบบ Blue Team ที่เข้าใจบริบท SDH ตรวจจับบริบทของระบบ คัดกรองความเสี่ยงที่บริบทนั้นมี และชี้นำการแก้ไข โดยเขียนข้อตรวจพบทุกรายการด้วยภาษาที่เข้าใจง่าย Lagune คือต้นแบบอ้างอิงของ SDH

### charter ใน Lagune คืออะไร

charter คือชั้นที่กำกับทุกเฟสของ Lagune เป็นชุดหลักการที่ให้ความปลอดภัยมาก่อน ซึ่งทุกเฟสถัดไปต้องเคารพ charter เก็บไว้ที่ .lagune/memory/charter.md

### การปิดข้อตรวจพบ (stand down) หมายความว่าอะไร

เมื่อ verify พิสูจน์ว่าความเสี่ยงปิดแล้ว ข้อตรวจพบนั้นจะปิดลง: ลบออกจากทั้งห่วงโซ่เมื่อคุณยืนยัน และไม่มีการประมวลผลซ้ำอีก

---

# สคีมาของ configs

> JSON Schema สำหรับ configs ของโปรเจกต์ Lagune ให้ editor เติมคำอัตโนมัติและตรวจความถูกต้องของไฟล์ได้ โดยอ้างอิง Lagune เวอร์ชันล่าสุดหรือตรึงไว้ที่เวอร์ชันใดเวอร์ชันหนึ่ง

Canonical: https://lagune.ai/th-TH/docs/references/configs-schema
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/references/configs-schema
อัปเดตล่าสุด: 2026-11-07

ไฟล์ `.lagune/configs.json` บันทึก [**หมวดหมู่**](https://lagune.ai/th-TH/docs/categories) ที่โปรเจกต์ใช้ ทำดัชนี [**ความรู้เฉพาะทาง**](https://lagune.ai/th-TH/docs/catalog) ของโปรเจกต์เอง และกำหนดสิ่งที่ [**ตัวตรวจ**](https://lagune.ai/th-TH/docs/hooks/configure) จะข้ามไป JSON Schema ของไฟล์นี้ช่วยให้ editor ของคุณเติมแต่ละฟิลด์อัตโนมัติ และทำเครื่องหมายคำที่พิมพ์ผิดหรือหมวดหมู่ที่ไม่รู้จักขณะที่คุณแก้ไขไฟล์

## สคีมาล่าสุด

ทุกครั้งที่ **Lagune** เขียนไฟล์นี้แล้วไม่พบ `$schema` ในไฟล์ **Lagune** จะชี้ไฟล์ไปที่สคีมาล่าสุด:

```json
{
  "$schema": "https://lagune.ai/schemas/configs.json",
  "categories": ["owasp", "javascript"]
}
```

ที่อยู่นี้อ้างอิง **Lagune** เวอร์ชันล่าสุดเสมอ ไฟล์ที่เขียนก่อน **Lagune** 0.16.0 จะได้ที่อยู่นี้เมื่อไฟล์เปลี่ยนครั้งถัดไป และทุกเฟสจะแจ้งเรื่องนี้จนกว่าจะถึงตอนนั้น

## ตรึงเวอร์ชัน

ทุกรีลีสของ **Lagune** ตั้งแต่ 0.16.0 เป็นต้นไปมีสคีมาตามที่เป็นในเวอร์ชันนั้น เผยแพร่บน **npm** และให้บริการผ่าน **jsDelivr** หากต้องการตรึงเวอร์ชัน ให้ใส่เวอร์ชันต่อจาก `lagune@` ในที่อยู่ `$schema`:

```json
{
  "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json"
}
```

เวอร์ชันรองรับช่วง semver ทุกรูปแบบ:

| เวอร์ชัน             | สคีมา                     |
| -------------------- | ------------------------- |
| `0.16.0`             | สคีมาจาก 0.16.0           |
| `0.16.x` หรือ `0.16` | สคีมาจากรีลีส 0.16 ล่าสุด |
| `0.x` หรือ `0`       | สคีมาจากรีลีส 0.x ล่าสุด  |
| `latest`             | สคีมาจากรีลีสล่าสุด       |

## คำถามที่พบบ่อย

### Lagune จำเป็นต้องใช้สคีมาไหม

ไม่จำเป็น สคีมาช่วยแค่ editor ของคุณ และ Lagune อ่านไฟล์แบบเดียวกันไม่ว่าจะมี $schema หรือไม่

### Lagune จะเขียนทับสคีมาที่ตรึงเวอร์ชันไว้ไหม

ไม่ Lagune เขียน $schema เฉพาะเมื่อไฟล์ยังไม่มี และคงที่อยู่ใดก็ตามที่คุณตั้งไว้

### ควรตรึงเวอร์ชันเมื่อไร

เมื่อโปรเจกต์รัน Lagune เวอร์ชันที่เจาะจง เพื่อให้ editor ตรวจไฟล์ตามสิ่งที่เวอร์ชันนั้นยอมรับ

---

# Lagune vs. Deepsec: เปรียบเทียบแนวทางความปลอดภัยที่ขับเคลื่อนด้วย AI สองแบบ

> เอกสารอ้างอิงที่เปรียบเทียบ Lagune กับ Deepsec ของ Vercel ทั้งด้านหลักการทำงาน วงจรชีวิต การตรวจจับ ค่าใช้จ่าย ข้อตรวจพบ และการปิดข้อตรวจพบ

Canonical: https://lagune.ai/th-TH/docs/references/deepsec
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/references/deepsec
อัปเดตล่าสุด: 2026-11-07

[Lagune](https://github.com/wellwelwel/lagune) และ [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) คือคำตอบเชิงป้องกันสองแบบต่อปัญหาเดียวกัน: ความปลอดภัยในยุคการพัฒนาที่มี AI ช่วย หลักคิด จุดเริ่มต้น ระหว่างทาง และจุดจบของทั้งสอง รวมถึงวิธีที่แต่ละตัวนำเสนอตัวเองต่อผู้ใช้ แตกต่างกันโดยการออกแบบ แม้ในจุดที่กลไกทับซ้อนกัน

**เคล็ดลับ**

Lagune ได้แรงบันดาลใจจาก Deepsec หรือเปล่า คำตอบคือไม่ Lagune เขียนขึ้นใหม่ทั้งหมดและได้แรงบันดาลใจจาก Spec-Driven Development และ Security Hardening ทั้งสองโปรเจกต์พัฒนาแยกจากกัน และการเปรียบเทียบนี้มีไว้ช่วยให้ผู้ใช้เข้าใจความแตกต่างของทั้งสอง

## ภาพรวม

| ด้าน           | Lagune                                                                                                           | Deepsec                                                               |
| -------------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| ประเภท         | ระเบียบวิธี (SDH) พร้อมต้นแบบอ้างอิง                                                                             | ผลิตภัณฑ์: เครื่องมือสแกนช่องโหว่ที่ขับเคลื่อนด้วยเอเจนต์             |
| จุดศูนย์ถ่วง   | หลักการด้านความปลอดภัยและความรู้ที่โหลดเฉพาะเมื่อจำเป็นเป็นตัวนำเอเจนต์ โดยมี hook แบบ deterministic เป็นหลักยึด | regex ที่หว่านแหกว้างป้อนงานให้การสืบสวนด้วย AI ที่ต้องทำทุกครั้ง     |
| สิ่งที่ได้     | โค้ดที่เสริมความปลอดภัยแล้ว การพิสูจน์ และห่วงโซ่ข้อตรวจพบที่ติดตามไว้                                           | รายงานข้อตรวจพบที่คัดกรองแล้วและจัดอันดับตามระดับความรุนแรง           |
| แตะโค้ดของคุณ  | ใช่: `harden` แก้ไขโค้ดของคุณ                                                                                    | ไม่: ทำ static analysis อย่างเดียว และให้ข้อตรวจพบกับข้อความคำแนะนำ   |
| Runtime        | รันบนเอเจนต์และโมเดลที่คุณใช้อยู่แล้ว ระดับใดก็ได้                                                               | รัน pipeline โมเดลของตัวเอง โดยใช้โมเดลระดับ frontier เป็นค่าเริ่มต้น |
| เริ่มต้นใช้งาน | ติดตั้งปลั๊กอินครั้งเดียวหรือ `npx skills add` แล้วสั่งงานด้วยภาษาธรรมดา ไม่ต้องตั้งเครื่องมือใหม่               | ตั้ง workspace `.deepsec/` ติดตั้ง dependency และเพิ่มคีย์ของโมเดล    |

## หลักการทำงาน

Lagune เน้นเอเจนต์เป็นหลัก (agent-first): เอเจนต์เป็นผู้ขับเคลื่อน ดึงความรู้เข้ามาเฉพาะเมื่อจำเป็นตามสิ่งที่โค้ดเป็น และมอบส่วนที่ตัดสินได้แน่นอนให้ hook แบบ deterministic

Deepsec เน้น deterministic เป็นหลัก (deterministic-first): การสแกนแบบกว้างทำเครื่องหมายตัวเลือก (candidate) ที่ชี้ให้โมเดลซึ่งต้องใช้ทุกครั้งรู้ว่าควรสืบสวนและตัดสินอะไร

| ด้าน                       | Lagune                                                                                                | Deepsec                                                          |
| -------------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| ลำดับ                      | หลักการด้านความปลอดภัยและความรู้ที่จับคู่แล้วนำทางเอเจนต์ ซึ่งมอบงานให้ hook และตัดสินส่วนที่เหลือเอง | matcher ทำเครื่องหมายตัวเลือก แล้วโมเดลสืบสวนและตัดสินทีละรายการ |
| บทบาทของส่วน deterministic | hook หลายภาษาที่ให้ผลตัดสินหรือชี้เป้าให้เอเจนต์ ทำงานร่วมกับความรู้ของหมวดหมู่                       | matcher ที่ทำเครื่องหมายตัวเลือกให้โมเดลที่ต้องใช้ทุกครั้งตัดสิน |
| ขั้นตอนการพัฒนา            | `/lagune` สร้างงานอย่างปลอดภัยไปพร้อมกับที่คุณเขียนโค้ด                                               | ตรวจทานโค้ด แต่ไม่ได้เขียนโค้ด                                   |
| ขั้นตอนการตรวจสอบ          | `charter` → `detect` → `plan` → `harden` → `verify`                                                   | `scan` → `process` → `triage` → `revalidate` → `report`          |
| หน้าที่ของ AI              | ให้เหตุผลจากความรู้ นำการแก้ไขไปใช้ และพิสูจน์ว่าใช้ได้จริง                                           | สืบสวนตัวเลือกทุกรายการและรายงานข้อตรวจพบ                        |

## วงจรชีวิต

Lagune ทำงานทั้งก่อน ระหว่าง และหลังเขียนโค้ด ส่วน Deepsec ตรวจทาน repository เมื่อมีโค้ดอยู่แล้ว

| ช่วงเวลา            | Lagune                                                                            | Deepsec                                                          |
| ------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| ก่อนมีโค้ด          | `charter` สร้างนโยบายความปลอดภัยจากเจตนาที่ระบุไว้                                | เริ่มจากโค้ดที่มีอยู่: `init` ต้องมีไดเรกทอรี                    |
| ระหว่างสร้าง        | `/lagune` สร้างงานที่ปลอดภัยตั้งแต่ค่าเริ่มต้นไปพร้อมกัน โดยไม่ทิ้งอาร์ติแฟกต์ไว้ | ตรวจทานหลังสร้างเสร็จ ไม่ใช่ระหว่างสร้าง                         |
| กับโค้ดที่มีอยู่    | `detect` → `plan` → `harden` → `verify`                                           | `scan` → `process` ซึ่งเป็นขั้นตอนหลัก                           |
| การตรวจทานต่อเนื่อง | รันเฟสซ้ำตามขอบเขต ไม่มี CI gate สำเร็จรูป                                        | สแกนซ้ำแบบเพิ่มส่วน และใช้ `process --diff` เป็น exit gate ใน CI |

## ชั้นการตรวจจับ

ชั้น deterministic ของทั้งสองมีธรรมชาติตรงข้ามกัน: ฝั่งหนึ่งตัดสิน อีกฝั่งทำเครื่องหมาย

| ด้าน        | Lagune                                                                               | Deepsec                                                                |
| ----------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| การจัดกลุ่ม | hook และความรู้เฉพาะทาง จัดกลุ่มเป็นหมวดหมู่                                         | matcher แยกตามรูปแบบหรือเฟรมเวิร์ก                                     |
| ผลลัพธ์     | ผลตัดสินที่ระบุตรงตัว (finding / review / advisory) พร้อมป้ายจัดประเภท               | ตัวเลือกที่ไม่มีผลตัดสิน (slug บรรทัด โค้ดตัวอย่าง และรูปแบบที่ตรงกัน) |
| การปรับจูน  | ความแม่นยำ (precision): รู้จักคอมเมนต์ และมีตัวกันสำหรับ placeholder และช่วงหน้าต่าง | ความครอบคลุม (recall): หว่านแหกว้าง แล้วให้ AI ตัดผลบวกลวงทีหลัง       |
| ความลึก     | ลึกกว่าในประเภทที่ทั้งสองครอบคลุมร่วมกัน                                             | กว้างกว่า แต่ลึกน้อยกว่าในประเภทที่ครอบคลุมร่วมกัน                     |
| ผลบวกลวง    | กดให้ต่ำตั้งแต่ต้นทาง แล้วตัดสินตามบริบท                                             | ตั้งใจสร้างออกมามากเกิน แล้วตัดลงด้วยรอบ `revalidate`                  |

## ความรู้และการตัดสิน

ทั้งสองมีความรู้ด้านความปลอดภัยที่ regex ให้ไม่ได้ ความต่างอยู่ที่ความรู้นั้นอยู่ที่ไหนและใครปรับแต่งได้

| ด้าน                | Lagune                                                                     | Deepsec                                                          |
| ------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| รูปแบบ              | โมดูล markdown ที่แก้ไขได้ บางโมดูลมี hook แบบ deterministic รองรับ        | prompt สั้น ๆ และจุดเน้นรายเทคโนโลยี โดยอาศัยความรู้ของโมเดลเอง  |
| การเลือก            | จับคู่กับโค้ด และโหลดเฉพาะเมื่อบริบทของโมดูลปรากฏ                          | ใส่เข้าไปในทุก batch ของ AI พร้อมจุดเน้นสำหรับเทคโนโลยีที่ตรวจพบ |
| ใครเป็นผู้เขียน     | ผู้ใช้แก้ไขโมดูลและเพิ่มโมดูลใหม่ด้วย `specialize`                         | ผู้ดูแลเป็นเจ้าของ prompt และผู้ใช้เติม `INFO.md`                |
| การตัดสินอยู่ที่ไหน | hook ตัดสินในระดับพื้นฐานของตัวเอง แล้วเอเจนต์ตัดสินส่วนที่เหลือจากความรู้ | รวมศูนย์: ตัวประมวลผล AI ตัวเดียวตัดสินทุกตัวเลือก               |
| การใช้ซ้ำ           | โมดูลเดียวนำทางทั้ง `detect` และ `verify`                                  | prompt เดียวขับเคลื่อนขั้น `process` ซึ่งมีอยู่ขั้นเดียว         |

## ข้อตรวจพบและการปิด

ทั้งสองต่างกันมากที่สุดตรงที่ข้อตรวจพบจะกลายเป็นอะไรเมื่อแก้ไขแล้ว

| ด้าน              | Lagune                                                                              | Deepsec                                                                                     |
| ----------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| ระดับความรุนแรง   | คะแนน CVSS v4.0 ที่ปรับตามโอกาสถูกโจมตีและสิ่งที่อาจเสียหาย                         | ระดับความรุนแรงจาก AI พร้อมการคัดกรอง P0 / P1 / P2 ตามความเป็นไปได้ในการ exploit และผลกระทบ |
| ผลตัดสิน          | Risk closed, Risk not closed หรือ Cannot tell from the code                         | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate                   |
| การเก็บรักษา      | ห่วงโซ่การทำงานปรับให้ตรงกับสภาพปัจจุบัน และข้อตรวจพบที่ปิดแล้วกลั่นกรองเป็นประวัติ | บันทึกรายไฟล์แบบต่อท้ายอย่างเดียว ไม่ลบอะไรออก                                              |
| สถานะสุดท้าย      | ปิดให้จบได้: ข้อตรวจพบที่พิสูจน์แล้วปิดออก และห่วงโซ่สิ้นสุดได้                     | เก็บข้อตรวจพบทุกรายการไว้ถาวร และซ่อนจากมุมมองเมื่อแก้ไขแล้ว                                |
| รายละเอียดประวัติ | สรุปสั้น ๆ ว่าความเสี่ยงคืออะไร                                                     | ร่องรอยผลตัดสินฉบับเต็ม รวมถึงวิธีแก้                                                       |

## ค่าใช้จ่าย

| ด้าน                         | Lagune                                                                                                                                 | Deepsec                                                                                                                                                                                                                            |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ชั้นพื้นฐานแบบ deterministic | ฟรี: hook รันโดยไม่ใช้ AI และไม่ต้องมีคีย์ และให้ผลตัดสินได้ทันที                                                                      | ฟรี: `scan` รันโดยไม่ใช้ AI แต่ไม่ให้ผลตัดสินด้วยตัวเอง                                                                                                                                                                            |
| ค่าใช้จ่ายทั่วไป             | รวมอยู่ในเอเจนต์ที่คุณใช้อยู่แล้ว ต่ำได้ถึง $0 บนโมเดลที่รันในเครื่อง ตามราคาแพ็กเกจที่คุณใช้อยู่ หรือคิดตามรอบสำหรับการใช้งานผ่าน API | [ประมาณ $25 ถึง $1,200 ต่อการรัน สำหรับ 100 ถึง 2,000 ไฟล์ และมากกว่านั้นเมื่อขนาดใหญ่ขึ้น](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) |
| ทางที่ถูกที่สุด              | โมเดลใดก็ได้ รวมถึงโมเดลฟรีที่รันในเครื่อง ปิดรอบการทำงานได้                                                                           | มีแพ็กเกจแบบเสียเงินที่ถูกกว่า แต่ข้อตรวจพบยังต้องใช้ขั้น AI ที่เสียเงิน                                                                                                                                                           |

## การขยายความสามารถและธรรมาภิบาล

แต่ละตัวเปิดชั้นที่อีกตัวปิดไว้

| ด้าน              | Lagune                                                  | Deepsec                                                 |
| ----------------- | ------------------------------------------------------- | ------------------------------------------------------- |
| สิ่งที่คุณขยายได้ | แก้ไขโมดูล หรือเพิ่มโมดูลใหม่ผ่าน `specialize`          | เพิ่ม matcher เอเจนต์ notifier และความเป็นเจ้าของ       |
| ชั้นนโยบาย        | หลักการด้านความปลอดภัยกำกับทุกเฟสและมีการควบคุมเวอร์ชัน | การตั้งค่าเป็นเรื่องปฏิบัติการ (matcher โมเดล และ path) |
| แทนที่ด้วยชื่อ    | โมดูลที่ปรับปรุงแล้วแทนที่โมดูลในตัว                    | เมื่อ slug ของ matcher ชนกัน matcher ของคุณจะชนะ        |

## อินเทอร์เฟซ

Deepsec สร้างสิ่งส่งมอบสำหรับองค์กรด้านความปลอดภัย ส่วน Lagune แสดงมุมมองแบบเรียลไทม์ให้ผู้ที่รัน

| ด้าน                          | Lagune                                                                                  | Deepsec                                                                |
| ----------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| ส่วนที่คนใช้งาน               | แดชบอร์ดแบบเรียลไทม์ในเครื่องของทั้งห่วงโซ่ ด้วยภาษาที่เข้าใจง่าย                       | ไฟล์รายงาน export เมตริก และคอมเมนต์ PR พร้อมเว็บไซต์เอกสาร            |
| ความรับผิดชอบ                 | แสดงไฟล์และความรู้เฉพาะทางที่นำไปใช้                                                    | ส่งต่อให้ผู้รับผิดชอบที่แนะนำ: เวร on-call ผู้จัดการ หรือผู้ commit    |
| การพิสูจน์ที่ทำซ้ำได้         | `prove` เขียนการทดสอบที่รันได้และประกาศแจ้งเตือนด้านความปลอดภัยสำหรับการเปิดเผยช่องโหว่ | คงความเป็น static โดยการออกแบบ และไม่เคยรันเป้าหมาย                    |
| การป้องกันตัวเองของเครื่องมือ | เสริมความปลอดภัยให้ API สำหรับเขียนข้อมูลในเครื่องบนแดชบอร์ด                            | เสริมความปลอดภัยให้การรัน AI ของตัวเองจากโค้ดเป้าหมายที่ไม่น่าเชื่อถือ |

## ขนาดและการดีพลอย

| ด้าน          | Lagune                                                                       | Deepsec                                                     |
| ------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------- |
| การติดตั้ง    | 9 คำสั่งจากปลั๊กอินของเอเจนต์หรือ **skills** CLI โดยไม่สร้างไฟล์ใดในโปรเจกต์ | workspace `.deepsec/` ที่มีแพ็กเกจและ dependency ของตัวเอง  |
| ทิศทางการขยาย | จำกัดขอบเขตได้ทุกส่วน ตั้งแต่บริบทหนึ่ง ไฟล์เดียว ไปจนถึงทั้งโปรเจกต์        | สแกนทั้ง repository ไปจนถึง monorepo ขนาดใหญ่               |
| การกระจายงาน  | ทำงานในเครื่องเท่านั้น และเซิร์ฟเวอร์ตัวเดียวผูกกับ loopback                 | กระจายงานไปยัง VM worker ของ Vercel Sandbox ได้ (ไม่บังคับ) |

## ประสบการณ์ผู้ใช้

วิธีที่แต่ละตัวพบกับผู้ที่รัน: การรันครั้งแรกต้องใช้อะไร และผู้ใช้กำหนดเป้าหมายได้อย่างไร

### การเริ่มต้น

Lagune รันผ่านเอเจนต์ที่เปิดอยู่แล้ว ส่วน Deepsec ต้องเตรียม workspace และสิทธิ์เข้าถึงโมเดลของตัวเองก่อน

| ด้าน                   | Lagune                                                                               | Deepsec                                                                                 |
| ---------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- |
| คำสั่งแรก              | ติดตั้งปลั๊กอินหรือ `npx skills add wellwelwel/lagune` แล้วใช้ `/lagune-*` ในเอเจนต์ | `npx deepsec init` แล้วตามด้วย `cd .deepsec`, `pnpm install`, `scan`, `process`         |
| ข้อมูลรับรองที่ต้องใช้ | ไม่ต้องมีคีย์แยก เพราะใช้เอเจนต์ปัจจุบันของคุณ                                       | คีย์ของโมเดล (เช่น AI Gateway, โทเค็น Vercel OIDC อายุ 12 ชั่วโมง หรือโทเค็น Anthropic) |

### การกำหนดทิศทาง

ทั้งสองรับการกำหนดทิศทางได้ Lagune อ่านรูปแบบของอินพุตในแต่ละเฟส ส่วน Deepsec จำกัดชุดไฟล์ที่การสืบสวนแบบเดียวกันจะรัน

| ด้าน           | Lagune                                                                                | Deepsec                                                   |
| -------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| ทั้งโปรเจกต์   | เฟสที่ไม่มีอินพุตจะสแกนทั้งขอบเขต                                                     | `scan` และ `process` สแกนทั้ง repository                  |
| บางส่วน        | ทุกเฟสจำกัดขอบเขตเฉพาะไฟล์หรือไดเรกทอรีที่ระบุได้                                     | `--files`, `--files-from` หรือ `--diff` จำกัดขอบเขตการรัน |
| ข้อกังวล       | เฟสจำกัดขอบเขตไว้ที่ข้อกังวลที่คุณอธิบาย                                              | prompt สำหรับการสืบสวนตายตัว                              |
| ระดับความสำคัญ | `harden` และ `verify` จำกัดขอบเขตได้เฉพาะระดับวิกฤต สูง ปานกลาง หรือต่ำ               | ข้อตรวจพบได้ป้ายกำกับหลังการรัน                           |
| ค่าเดียว       | hook ให้คะแนนโค้ดตัวอย่าง รูปแบบ หรือ URL หนึ่งรายการได้โดยตรง (`--pattern`, `--url`) | หน่วยของงานคือไฟล์                                        |

## คำถามที่พบบ่อย

### Lagune ต่างจาก Deepsec อย่างไร

Lagune เน้นเอเจนต์เป็นหลักและทำงานทั้งก่อน ระหว่าง และหลังเขียนโค้ด: กำหนดนโยบายก่อนมีโค้ด เสริมความปลอดภัยไปพร้อมกับการสร้างงาน และตรวจสอบ เสริมความปลอดภัย และตรวจยืนยันโค้ดที่เขียนไว้แล้ว Deepsec เน้น deterministic เป็นหลัก: การสแกนด้วย regex แบบกว้างป้อนงานให้การสืบสวนด้วยโมเดลระดับ frontier ที่ต้องทำทุกครั้ง ซึ่งตรวจทานโค้ดที่มีอยู่และรายงานข้อตรวจพบโดยไม่แก้โค้ด

### ใช้ตัวใดตัวหนึ่งได้ฟรีไหม

ขั้นตอนทั้งหมดของ Lagune รันได้ในราคา $0 บนโมเดลฟรีที่รันในเครื่อง และ hook แบบ deterministic ให้ผลตัดสินได้โดยไม่ใช้ AI เลย การสแกนของ Deepsec ฟรีแต่ไม่ให้ผลตัดสิน ข้อตรวจพบใด ๆ จึงต้องใช้ขั้น AI แบบเสียเงิน

### มีตัวไหนแก้โค้ดของฉันไหม

Lagune แก้: harden นำการแก้ไขไปใช้กับโค้ดของคุณ Deepsec ไม่แก้: Deepsec ทำ static analysis อย่างเดียว โดยให้ข้อตรวจพบและข้อความคำแนะนำที่คนหรือเอเจนต์ต้องนำไปใช้เองแยกต่างหาก

---

# แหล่งที่มาจาก OWASP

> ที่มาของความรู้ในความรู้เฉพาะทาง OWASP ในตัว โดยจับคู่กับหน้าการโจมตีและหน้า Cheat Sheet ต้นฉบับของ OWASP

Canonical: https://lagune.ai/th-TH/docs/references/owasp-sources
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/references/owasp-sources
อัปเดตล่าสุด: 2026-11-07

เอกสารนี้จับคู่ **การโจมตี** (`www-community`) และ **Cheat Sheet** (`CheatSheetSeries`) ทุกรายการของ OWASP เข้ากับหมวดความปลอดภัย โดยแต่ละรายการลิงก์ไปยังหน้าสาธารณะต้นฉบับ ภายในหมวดเดียวกัน รายการที่เทียบเท่ากันจะอยู่ในบรรทัดเช็กลิสต์เดียวกัน: การโจมตีและ cheat sheet ที่จัดการความเสี่ยงเดียวกันจะแสดงรวมกันโดยคั่นด้วยจุลภาค ส่วนรายการที่ไม่มีคู่เทียบโดยตรงจะอยู่ในบรรทัดของตัวเอง

- เครดิตเป็นของ OWASP หน้าการโจมตีอยู่ที่ `https://owasp.org/www-community/attacks/<attack>` และหน้า cheat sheet อยู่ที่ `https://cheatsheetseries.owasp.org/cheatsheets/<cheat>.html`

---

## 1. Injection (ทั่วไป)

- [x] [Code Injection](https://owasp.org/www-community/attacks/Code_Injection), [Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html), [Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.html) (interpreter)
- [x] [Direct Dynamic Code Evaluation (Eval Injection)](https://owasp.org/www-community/attacks/Direct_Dynamic_Code_Evaluation_Eval_Injection) (interpreter)
- [x] [Function Injection](https://owasp.org/www-community/attacks/Function_Injection) (interpreter)
- [x] [Resource Injection](https://owasp.org/www-community/attacks/Resource_Injection) (network)
- [x] [Special Element Injection](https://owasp.org/www-community/attacks/Special_Element_Injection) (interpreter)
- [x] [Custom Special Character Injection](https://owasp.org/www-community/attacks/Custom_Special_Character_Injection) (interpreter)
- [x] [Comment Injection Attack](https://owasp.org/www-community/attacks/Comment_Injection_Attack) (interpreter)
- [x] [Parameter Delimiter](https://owasp.org/www-community/attacks/Parameter_Delimiter) (interpreter)
- [x] [Server-Side Includes (SSI) Injection](https://owasp.org/www-community/attacks/Server-Side_Includes_%28SSI%29_Injection) (interpreter)
- [x] [Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [Bean Validation](https://cheatsheetseries.owasp.org/cheatsheets/Bean_Validation_Cheat_Sheet.html) (interpreter)

---

## 2. Injection ใน SQL และฐานข้อมูล

- [x] [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection), [SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), [Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) (sql)
- [x] [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) (sql)
- [x] [SQL Injection Bypassing WAF](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) (sql)
- [x] [RSQL Injection](https://owasp.org/www-community/attacks/RSQL_Injection) (interpreter)
- [x] [Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) (sql)
- [x] [NoSQL Security](https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html) (interpreter)

---

## 3. Injection คำสั่งระบบปฏิบัติการ

- [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter)

---

## 4. Injection ใน LDAP, XPath และ XML

- [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter)
- [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter)
- [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter)
- [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml)

---

## 5. Cross-Site Scripting (XSS)

- [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser)
- [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser)
- [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser)
- [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser)
- [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser)
- [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser)
- [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser)
- [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser)

---

## 6. Cross-Site Request Forgery (CSRF) และ clickjacking

- [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request)
- [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser)
- [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser)
- [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network)
- [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser)

---

## 7. การ redirect และ forward

- [x] [Open Redirect](https://owasp.org/www-community/attacks/open_redirect), [Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) (network)
- [x] [Execution After Redirect (EAR)](https://owasp.org/www-community/attacks/Execution_After_Redirect_%28EAR%29) (browser)

---

## 8. การควบคุมการเข้าถึงและการตรวจสอบสิทธิ์

- [x] [Insecure Direct Object Reference (IDOR)](https://owasp.org/www-community/attacks/insecure_direct_object_reference), [Insecure Direct Object Reference Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) (access-control)
- [x] [Forced browsing](https://owasp.org/www-community/attacks/Forced_browsing) (access-control)
- [x] [Web Parameter Tampering](https://owasp.org/www-community/attacks/Web_Parameter_Tampering) (access-control)
- [x] [Setting Manipulation](https://owasp.org/www-community/attacks/Setting_Manipulation) (access-control)
- [x] [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) (access-control)
- [x] [Transaction Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) (access-control)
- [x] [Mass Assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) (access-control)
- [x] [Multi-Tenant Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) (access-control)

---

## 9. การยืนยันตัวตนและข้อมูลรับรอง

- [x] [Brute Force Attack](https://owasp.org/www-community/attacks/Brute_force_attack), [Password Spraying Attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack), [Bot Management and Anti-Automation](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) (credential-endpoint)
- [x] [Credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing), [Credential Stuffing Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) (credential-endpoint)
- [x] [Qrljacking](https://owasp.org/www-community/attacks/Qrljacking) (federation)
- [x] [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) (access-control)
- [x] [Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (access-control)
- [x] [Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), [Choosing and Using Security Questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) (access-control)
- [x] [Email Validation and Verification in Identity Systems](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html) (access-control)

---

## 10. การจัดการเซสชัน

- [x] [Session fixation](https://owasp.org/www-community/attacks/Session_fixation), [Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack), [Session Prediction](https://owasp.org/www-community/attacks/Session_Prediction), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) (access-control)
- [x] [Cookie Theft Mitigation](https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html) (access-control)

---

## 11. Identity federation (OAuth, SAML และ JWT)

- [x] [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) (federation)
- [x] [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) (federation)
- [x] [JSON Web Token for Java](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (federation)

---

## 12. การเข้ารหัสและความปลอดภัยของการรับส่งข้อมูล

- [x] [Cryptanalysis](https://owasp.org/www-community/attacks/Cryptanalysis), [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) (crypto)
- [x] [Manipulator-in-the-Middle (MITM)](https://owasp.org/www-community/attacks/Man-in-the-middle_attack), [Transport Layer Security](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (transport)
- [x] [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (transport)
- [x] [Pinning](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) (transport)

---

## 13. Server-Side Request Forgery (SSRF)

- [x] [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery), [Server-Side Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) (network)

---

## 14. Path traversal และการจัดการไฟล์

- [x] [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) (path)
- [x] [Binary Planting](https://owasp.org/www-community/attacks/Binary_planting) (path)
- [x] [Windows ::DATA Alternate Data Stream](https://owasp.org/www-community/attacks/Windows_DATA_alternate_data_stream) (path)
- [x] [Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code) (path)
- [x] [File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) (upload)

---

## 15. การใช้โปรโตคอล HTTP ในทางที่ผิด (header, caching และ splitting)

- [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter)
- [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) (แยกไปที่: browser, transport, http-request, access-control)
- [x] [Cache Poisoning](https://owasp.org/www-community/attacks/Cache_Poisoning) (interpreter)
- [x] [IP Spoofing via HTTP Headers](https://owasp.org/www-community/attacks/ip_spoofing_via_http_headers) (http-request)

---

## 16. Encoding และ content spoofing

- [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter)
- [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter)
- [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser)

---

## 17. Injection ใน CSV และสเปรดชีต

- [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv)

---

## 18. CORS (Cross-Origin Resource Sharing)

- [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request)
- [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request)

---

## 19. Denial of service

- [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex)

---

## 20. ความปลอดภัยของหน่วยความจำและโค้ดเนทีฟ

- [x] [Buffer Overflow Attack](https://owasp.org/www-community/attacks/Buffer_overflow_attack), [Buffer Overflow via Environment Variables](https://owasp.org/www-community/attacks/Buffer_Overflow_via_Environment_Variables) (c-cpp)
- [x] [Format string attack](https://owasp.org/www-community/attacks/Format_string_attack) (c-cpp)

---

## 21. Mobile code และการรันโค้ดที่ไม่น่าเชื่อถือ

- [x] [Mobile code invoking untrusted mobile code](https://owasp.org/www-community/attacks/Mobile_code_invoking_untrusted_mobile_code) (interpreter)
- [x] [Mobile code non-final public field](https://owasp.org/www-community/attacks/Mobile_code_non-final_public_field) (java)
- [x] [Mobile code object hijack](https://owasp.org/www-community/attacks/Mobile_code_object_hijack) (java)

---

## 22. Deserialization

- [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (แยกไปที่: python, ruby, php, java, dotnet)

---

## 23. มัลแวร์และภัยคุกคามฝั่งไคลเอนต์

- [x] [Man-in-the-browser attack](https://owasp.org/www-community/attacks/Man-in-the-browser_attack), [Browser Extension Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html) (browser)
- [x] [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) (browser)

---

## 24. Logging, repudiation และการจัดการข้อผิดพลาด

- [x] [Log Injection](https://owasp.org/www-community/attacks/Log_Injection), [Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), [Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) (interpreter)
- [x] [Repudiation Attack](https://owasp.org/www-community/attacks/Repudiation_Attack) (interpreter)

---

## 25. ตรรกะทางธุรกิจและการใช้ฟังก์ชันในทางที่ผิด

ตรรกะทางธุรกิจและการใช้ฟังก์ชันในทางที่ผิดไม่มีพื้นผิวในโค้ดจุดเดียวที่ความรู้เฉพาะทางรายพื้นผิวจะป้องกันได้: การป้องกันคือการออกแบบเฉพาะของแต่ละแอปพลิเคชัน ซึ่งใช้เหตุผลแบบเดียวกับที่ threat modeling ของโปรเจกต์ขับเคลื่อน จึงย้ายไปไว้ที่ "อยู่นอกขอบเขต"

---

## 26. ความปลอดภัยของ AI, LLM และเอเจนต์

- [x] [Prompt Injection](https://owasp.org/www-community/attacks/prompt-injection), [LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) (llm)
- [x] [MCP Tool Poisoning](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning), [MCP (Model Context Protocol) Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) (llm)
- [x] [HITL Dialog Forging (Lies-in-the-Loop)](https://owasp.org/www-community/attacks/lies-in-the-loop) (llm)
- [x] [AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), [Secure Coding with AI](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html) (llm)
- [x] [Retrieval-Augmented Generation (RAG) Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) (llm)
- [x] [Secure AI/ML Model Ops](https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html) (llm)
- [x] [AML and Sanctions Compliance for AI Agent Payments](https://cheatsheetseries.owasp.org/cheatsheets/AML_Sanctions_AI_Agent_Payments_Cheat_Sheet.html) (llm)

---

## 27. Prototype pollution และ cross-site leaks

- [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript)
- [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser)

---

## 28. เฟรมเวิร์กและแพลตฟอร์มภาษา

- [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python)
- [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby)
- [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php)
- [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php)
- [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java)
- [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet)
- [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript)
- [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php)

---

## 29. เว็บฟรอนต์เอนด์และเบราว์เซอร์

- [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser)
- [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser)
- [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) (แยกไปที่: access-control, browser)

---

## 30. API และบริการ

- [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint)
- [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint)
- [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint)

---

## 31. คลาวด์ คอนเทนเนอร์ และโครงสร้างพื้นฐาน

การตั้งค่าคอนเทนเนอร์และ workload คือ config-as-code ที่นักพัฒนาส่งไปพร้อมแอป (`Dockerfile`, Compose และ `securityContext` ของ Pod) เป็นพื้นผิวจริงที่ `harden` แก้ไขและ `verify` พิสูจน์ได้ จึงอยู่ในขอบเขต ส่วนการดูแลคลัสเตอร์ (RBAC, etcd, API server, admission และ network segmentation) เป็นงานของผู้ดูแลระบบ (operator) และยังอยู่นอกขอบเขต

- [x] [Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html), [Node.js Docker](https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet.html) (container)
- [x] [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (container: ส่วนของ workload และ Pod การดูแลคลัสเตอร์ยังอยู่นอกขอบเขต)
- [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless)

---

## 32. ซัพพลายเชนและ CI/CD

- [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter)
- [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter)

---

## 33. Secret และการตั้งค่า

การจัดการ secret เป็นงานด้านปฏิบัติการ: vault, CI/CD การตั้งค่าคลาวด์ และการหมุนเวียน (rotation) แง่มุมเดียวที่อยู่ระดับโค้ด (secret ที่ฮาร์ดโค้ดในซอร์ส) เป็นการสแกนแบบ deterministic ไม่ใช่ความรู้เฉพาะทางด้านความเสี่ยง จึงย้ายไปไว้ที่ "อยู่นอกขอบเขต"

---

## 34. กระบวนการ การออกแบบ และธรรมาภิบาล

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

---

## 35. การชำระเงินและการปฏิบัติตามข้อกำหนด

- [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment)

---

## 36. ระบบฝังตัว IoT และโดเมนเฉพาะทาง

ความปลอดภัยของยานยนต์และโดรนเป็นโดเมนของระบบฝังตัว (CAN bus เฟิร์มแวร์ OTA ความถูกต้องของเซนเซอร์และวิทยุ และการเข้าถึงทางกายภาพ) ไม่ใช่ซอร์สโค้ดของแอปพลิเคชันเว็บหรือ API ที่ Lagune ตรวจสอบ จึงย้ายไปไว้ที่ "อยู่นอกขอบเขต"

---

## อยู่นอกขอบเขต (ไม่มีพื้นผิวในโค้ด)

รายการต่อไปนี้ไม่ใช่พื้นที่ของความรู้เฉพาะทางและไม่มีช่องทำเครื่องหมาย: เป็นเรื่องธรรมาภิบาล กระบวนการ hardening ด้านปฏิบัติการ หรือการใช้เฟรมเวิร์ก ที่ไม่มีพื้นผิวในโค้ดจุดเดียวที่ความรู้เฉพาะทางรายพื้นผิวจะป้องกันได้ คุณค่าด้านความปลอดภัยของรายการเหล่านี้มีอยู่จริง แต่อยู่ในกระบวนการและสถาปัตยกรรม (หรือสำหรับเฟรมเวิร์ก อยู่ใน skill ของภาษานั้นเอง) ไม่ใช่ในการป้องกันที่แคตตาล็อกนี้มีให้ จึงแสดงไว้เพื่ออ้างอิง ไม่ใช่เป็นงานที่ต้องทำ

- [Authorization Regression Testing](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Regression_Testing_Cheat_Sheet.html), [Authorization Testing Automation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html)
- [JAAS](https://cheatsheetseries.owasp.org/cheatsheets/JAAS_Cheat_Sheet.html)
- [Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service), [Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html)
- [HTTP/2 Reset Attack](https://owasp.org/www-community/attacks/HTTP2_Reset_Attack)
- [Traffic flood](https://owasp.org/www-community/attacks/Traffic_flood)
- [Web Service Amplification Attack](https://owasp.org/www-community/attacks/web_service_amplificaiton) (การขยายปริมาณทราฟฟิกผ่าน SOAP และ WS-Addressing ซึ่งเป็น DoS ด้านปฏิบัติการรูปแบบหนึ่งที่ไม่มีพื้นผิวในโค้ด)
- [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow)
- [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse) (มัลแวร์ฝั่งผู้ใช้ปลายทาง ไม่ใช่พื้นผิวในโค้ดของโปรเจกต์ที่ตรวจสอบ แง่มุมการแพร่ผ่านเบราว์เซอร์อยู่ใน `browser`)
- [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html)
- [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html)
- [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (การออกแบบและการชั่งข้อดีข้อเสีย: IAM เทียบกับ signed URL, VPC สาธารณะและส่วนตัว ขอบเขตความไว้วางใจ และความรับผิดชอบร่วม ต่างจาก `container` ตรงที่ไม่มีการตั้งค่าที่เป็นรูปธรรมให้ความรู้เฉพาะทางตรวจ)
- [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (แม้ชื่อจะเป็นเช่นนั้น แต่เนื้อหาคือกระบวนการ SDLC และเครื่องมือสำหรับ _จัดการ_ IaC: ปลั๊กอิน IDE, static analysis การสแกน image, CI/CD และการลงนาม ไม่ได้ให้รูปแบบที่ไม่ปลอดภัยพร้อมรูปแบบที่ปลอดภัยแทนในไฟล์ Terraform หรือ CloudFormation)
- [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_เฉพาะส่วนการดูแลคลัสเตอร์_: RBAC, etcd, API server และ admission ส่วนของ workload และ Pod อยู่ในขอบเขตภายใต้ `container`)
- [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (สถาปัตยกรรมเครือข่ายและนโยบาย firewall)
- [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (วงจรชีวิตและการเฝ้าระวัง DNS ไม่ใช่โค้ด)
- [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (vault, CI/CD และการหมุนเวียน แง่มุม secret ที่ฮาร์ดโค้ดเป็นการสแกนแบบ deterministic ไม่ใช่ความรู้เฉพาะทางด้านความเสี่ยง)
- [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (แฟล็กของคอมไพเลอร์ linker และการ build โดยไม่มี sink ในซอร์ส)
- [Microservices Security](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html), [Microservices based Security Arch Doc](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.html)
- [Zero Trust Architecture](https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html)
- [CI/CD Security](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html), [GitHub Actions Security](https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html)
- [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html)
- [Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), [Full Path Disclosure](https://owasp.org/www-community/attacks/Full_Path_Disclosure) (การตั้งค่า error handler ส่วนกลางของแต่ละ stack การรั่วไหลนี้คือการเปิดเผยข้อมูลแบบเดียวกับที่การจัดการข้อผิดพลาดดูแลอยู่แล้ว)
- [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case _(historical)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (การออกแบบเฉพาะของแต่ละแอปพลิเคชัน ไม่มี sink ในโค้ดจุดเดียว)
- [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (การเก็บข้อมูลเท่าที่จำเป็น ความโปร่งใส และนโยบายระยะเวลาการเก็บรักษา)
- [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html) (โดเมนของระบบฝังตัว: CAN bus เฟิร์มแวร์ OTA และความถูกต้องของเซนเซอร์และวิทยุ ไม่ใช่ซอร์สโค้ดเว็บหรือ API)
- [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (การเสริมความปลอดภัยแพลตฟอร์ม Android และ iOS: พื้นที่จัดเก็บ ไบโอเมตริก pinning และ PII ไม่มีพื้นผิวในโค้ดจุดเดียว และแง่มุมการโหลดโค้ดที่ไม่น่าเชื่อถือย้ายไปอยู่ที่ `interpreter`)
- [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(community page)_](https://owasp.org/www-community/Threat_Modeling)
- [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html)
- [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html)
- [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)
- [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html)
- [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)
- [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html)
- [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html)

---

# /lagune-repair: ซ่อมการติดตามข้อตรวจพบที่เสียหาย

> ซ่อมห่วงโซ่เมื่อการเปลี่ยนชื่อหรือย้ายไฟล์ทำให้การติดตามของ Lagune สับสน

Canonical: https://lagune.ai/th-TH/docs/commands/repair
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/repair
อัปเดตล่าสุด: 2026-11-07

🧰 ซ่อมห่วงโซ่เมื่อการเปลี่ยนชื่อหรือย้ายไฟล์ทำให้ห่วงโซ่สับสน

**งานบำรุงรักษาภายใน ไม่ใช่เฟสด้านความปลอดภัย**

repair ไม่ใช่เฟสที่ 6 ในเวิร์กโฟลว์ที่เรียงตามลำดับ หน้าที่ของ repair คือรักษาการติดตามให้สอดคล้องกัน

```prompt
# ไม่ต้องใส่อินพุต: ซ่อมทั้งห่วงโซ่เสมอ
/lagune-repair
```

## หลักการทำงาน

ข้อตรวจพบแต่ละรายการจาก detect คือรายการที่ติดตามหนึ่งรายการ ซึ่ง plan, harden และ verify ส่งต่อกันไป แต่ละเฟสจัดการกับรายการนั้นและรายงานกลับด้วยชื่อของรายการ ชื่อนี้เขียนเหมือนกันทุกตัวอักษรเป็นหัวข้อของส่วนในทุกอาร์ติแฟกต์ และเป็นตัวตนของรายการนั้นตลอดทั้งห่วงโซ่

สิ่งเดียวที่เปลี่ยนแปลงได้ง่ายซึ่งการติดตามเก็บไว้คือ path ของไฟล์ที่รายการชี้ไป path เหล่านี้ไม่ได้อยู่ที่อื่น การเปลี่ยนชื่อหรือย้ายไฟล์จึงทำให้ลิงก์ขาดได้เฉพาะที่นั่น และไม่มีทางเกิดสำเนา 2 ชุดที่ไม่ตรงกัน เมื่อเกิดเหตุนี้ repair จะแก้แผนผัง (`.lagune/tracking.json`) เพื่อให้ตัวตนของรายการยังอยู่หลังการเปลี่ยนชื่อ repair อ่านอาร์ติแฟกต์และแผนผังการติดตาม อ่านซอร์สโค้ดของคุณเพียงเพื่อหา path ใหม่ของไฟล์ที่เปลี่ยนชื่อ และไม่เขียนเนื้อหาด้านความปลอดภัยใดเลย

ในรอบเดียวกัน repair จะตรวจอาร์ติแฟกต์ความจำทุกรายการเทียบกับเทมเพลตของตัวเอง และรายงานส่วนที่คลาดเคลื่อน โดยชี้แต่ละรายการไปยังเฟสที่ต้องแก้ไข

**เคล็ดลับ**

- repair ไม่แตะต้องทั้งโค้ดของคุณและอาร์ติแฟกต์ที่เป็นเนื้อหา แตะเฉพาะการติดตาม
- คุณแทบไม่ต้องรันเอง เมื่อเฟสใดพบว่าห่วงโซ่ไม่สอดคล้องกัน เฟสนั้นจะรัน repair ให้คุณแล้วทำงานต่อ
- การติดตามที่ repair ดูแลอยู่ที่ `.lagune/tracking.json` ซึ่งเป็นสถานะภายในที่คุณไม่ต้องแก้ไขเอง

---

# Migrate: ย้ายโปรเจกต์ Lagune แบบ manifest ไปใช้ skill และปลั๊กอิน

> ย้ายโปรเจกต์ Lagune แบบ manifest ไปใช้ Lagune แบบ skill โดยเก็บ charter อาร์ติแฟกต์ การติดตาม และความรู้เฉพาะทางของคุณเองไว้ครบ

Canonical: https://lagune.ai/th-TH/docs/commands/migrate
ภาษา: th-TH
ต้นฉบับ: https://lagune.ai/docs/commands/migrate
อัปเดตล่าสุด: 2026-11-07

🔀 ย้ายโปรเจกต์ **Lagune** แบบ manifest ไปใช้ **Lagune** แบบ skill โดยเก็บทุกอย่างที่คุณเขียนไว้ครบ

**ประกาศเลิกใช้**

โปรเจกต์ที่มี manifest ยังทำงานได้ตามเดิมจนถึง `v1.x`: `npx lagune` ส่งต่อ `init`, `pull`, `update`, `add`, `remove`, `list` และแดชบอร์ดไปให้ `lagune@0.15.0` ซึ่งเป็นเวอร์ชันสุดท้ายที่ใช้ manifest

## วิธีย้าย

1. ตรวจให้แน่ใจว่า commit งานปัจจุบันแล้ว จากนั้นรัน migrate จาก root ของโปรเจกต์:

   ```bash
   npx lagune migrate
   ```

2. commit เฉพาะสิ่งที่ migrate เปลี่ยน เพื่อให้การย้ายเป็นการเปลี่ยนแปลงเดียวที่ตรวจทานได้
3. ติดตั้งคำสั่งสำหรับเอเจนต์ของคุณตามที่ [หน้าการติดตั้ง](https://lagune.ai/th-TH/docs) แสดงไว้
4. ถ้าโปรเจกต์มีอาร์ติแฟกต์ของ detect, plan หรือ harden อยู่แล้ว ให้ขอ [`/lagune-repair`](https://lagune.ai/th-TH/docs/commands/repair) ปรับการอ้างอิงแบบเดิมในอาร์ติแฟกต์เหล่านั้นและในความรู้เฉพาะทางของคุณเองให้ตรงกับสภาพปัจจุบัน:

   ```prompt
   /lagune-repair ปรับ applied specializations (ชื่อเดิมคือ sub-skills) ในอาร์ติแฟกต์ใต้ `.lagune/memory/` (`detect.md`, `plan.md` และ `harden.md`) ให้ตรงกับชื่อที่แคตตาล็อกใหม่แสดง และเขียนทุกการเรียกที่ความรู้เฉพาะทางของฉันใน `.lagune/catalog/` ใช้เรียก hook เดิมใน `.lagune/hooks/` ใหม่ ให้เป็นการเรียก tool `lagune_read` หรือ `lagune_write`
   ```

## สิ่งที่เปลี่ยนไป

| ก่อน                                                                    | หลัง                                                                          |
| ----------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| `.lagune/templates/`, `.lagune/hooks/` และ `.lagune/specializations.md` | ลบออก: แต่ละ skill มีเทมเพลตของตัวเอง และเอนจินเป็นผู้รัน hook                |
| สำเนาของความรู้เฉพาะทางในตัวที่อยู่ใน `.lagune/skills/`                 | ลบออก: เอนจินเป็นผู้ให้บริการรายการในตัว                                      |
| ความรู้เฉพาะทางของคุณเองใน `.lagune/skills/`                            | ย้ายไปที่ `.lagune/catalog/`                                                  |
| `.lagune/skills.json` ซึ่งเป็นดัชนีความรู้เฉพาะทางของคุณเอง             | รวมเข้าใน `.lagune/configs.json`                                              |
| หมวดหมู่ใน manifest                                                     | บันทึกไว้ใน `.lagune/configs.json`                                            |
| คำสั่งเอเจนต์แบบเดิม เช่น `/lagune.detect`                              | ลบออก: [การติดตั้ง **Lagune**](https://lagune.ai/th-TH/docs) จะเพิ่มคำสั่งใหม่ เช่น `/lagune-detect` |
| บล็อกของ **Lagune** ใน `.gitignore`                                     | ลบออก พร้อมลบไฟล์ด้วยถ้าไม่มีอะไรอื่นอยู่ในไฟล์                               |
| `.lagune/proofs/` ที่บล็อกนั้นละเว้นไว้                                 | กันไว้นอก commit ด้วย `.gitignore` ของตัวเอง                                  |
| `.lagune/manifest.json`                                                 | ลบทิ้งเป็นลำดับสุดท้าย                                                        |

งานด้านความปลอดภัยของคุณยังอยู่ครบตามเดิม: charter อาร์ติแฟกต์ที่แต่ละเฟสสร้างขึ้น และแผนผังการติดตามพร้อม path ที่ข้อตรวจพบแต่ละรายการชี้ไป

## คำถามที่พบบ่อย

### ต้องย้ายโปรเจกต์ไหม

ต้อง โปรเจกต์แบบ manifest เลิกใช้แล้วและทำงานได้ถึง v1.x เท่านั้น ให้รัน npx lagune migrate เพื่อย้ายโปรเจกต์ของคุณ

### migrate เก็บอะไรไว้บ้าง

charter ของคุณ อาร์ติแฟกต์ของทุกเฟส แผนผังการติดตาม หมวดหมู่ของคุณ และความรู้เฉพาะทางของคุณเอง ความรู้เฉพาะทางจะย้ายไปที่ .lagune/catalog/ และดัชนีของความรู้เหล่านั้นจะรวมอยู่กับหมวดหมู่ของคุณใน .lagune/configs.json

### ควรติดตั้งคำสั่งใหม่เมื่อไร

หลังรัน migrate ตามที่หน้าการติดตั้งแสดงไว้สำหรับเอเจนต์ของคุณ จะติดตั้งก่อนก็ได้เช่นกัน เพราะ migrate เก็บ /lagune ตัวใหม่ไว้

### เพื่อนร่วมทีมย้ายโปรเจกต์ไปแล้ว ต้องรันอะไร

pull การย้ายนั้นมาก่อน แล้วรัน npx lagune migrate หนึ่งครั้ง คำสั่งนี้จะลบสิ่งที่ Lagune แบบ manifest ทิ้งไว้ใน clone ของคุณ ซึ่ง version control ไม่เคยเก็บไว้ และกันการพิสูจน์ของคุณไว้นอก commit