การตรวจสอบความปลอดภัยใน Claude Code: คู่มือทีละขั้นตอนและระบบอัตโนมัติด้วย GitHub Action ในปี 2026

ผู้เขียนเนื้อหาต้นฉบับเล่าถึงประสบการณ์ของตนว่า “ฉันเพิ่งรัน security-review กับโปรเจกต์ vibe ของตัวเอง แล้วทีมก็พบปัญหาจริงหลายจุดภายใน 4 นาที ซึ่งแก้ไขไปแล้ว” งานแบบเดียวกันนี้เคยใช้เวลาทั้งวันสำหรับที่ปรึกษาภายนอก

เนื้อหาเพิ่มเติมเกี่ยวกับการกำหนดค่าเครื่องมืออยู่ในเอกสารประกอบของ Ailoot

/security-review ใน Claude Code คืออะไร?#

คำสั่งนี้ทำงานได้สองรูปแบบ แบบในเครื่อง: รัน /security-review ในเทอร์มินัล แล้ว Claude จะอ่าน repository และสร้างรายงาน แบบฝั่งเซิร์ฟเวอร์: ติดตั้ง engine เดียวกันเป็น GitHub Action เพื่อให้แสดงความคิดเห็น inline ในทุก Pull Request โดยอัตโนมัติ

ต่างจากเครื่องมือสแกน SAST แบบดั้งเดิม (Snyk Code, Semgrep, SonarQube) /security-review ไม่ได้ทำงานตามกฎตายตัว แต่จะอ่านโค้ดเหมือนวิศวกรที่กำลังตรวจสอบอยู่จริง โดยติดตามการไหลของข้อมูล ทำความเข้าใจว่าคุณใช้ framework ใดและขอบเขตความเชื่อถืออยู่ตรงไหน พร้อมตรวจพบช่องโหว่ที่ไม่มีกฎข้อใดอธิบายไว้

ไม่ได้หมายความว่า /security-review จะใช้แทนการทดสอบเจาะระบบจากภายนอกหรือการทดสอบจริงในสภาพแวดล้อม staging ได้ ช่วยทำส่วนหนึ่งของรีวิวโค้ดเบื้องต้นอัตโนมัติได้ แต่บทความไม่ได้วัดสัดส่วนความครอบคลุม audit ต่อไปนี้ฉันจะอธิบายวิธีใช้งานให้ถูกต้องและสิ่งที่ Claude จะพบในโปรเจกต์ของคุณ

รัน /security-review ใน 5 ขั้นตอนได้อย่างไร?#

ขั้นตอนที่ 1. อัปเดต Claude Code คำสั่งนี้ใช้งานได้ตั้งแต่รุ่นที่เผยแพร่เมื่อวันที่ 20 กุมภาพันธ์ 2026

claude update

หากติดตั้ง Claude Code ผ่าน npm คุณก็ทำได้เช่นกัน:

npm install -g @anthropic-ai/claude-code@latest

ตรวจสอบว่า /security-review ปรากฏขึ้นแล้ว:

claude /help | grep security

ขั้นตอนที่ 2. เปิดโปรเจกต์และลงชื่อเข้าใช้ Claude Code

cd ~/projects/my-vibe-project
claude

ขั้นตอนที่ 3. รันคำสั่ง ใน Claude Code ให้พิมพ์คำสั่งนี้:

/security-review

Claude จะดำเนินการวิเคราะห์ 3 ระยะโดยอัตโนมัติ:

1. การสำรวจบริบทของ repository (Repository Context Research) - อ่านโครงสร้างและระบุ stack, routes และคำสั่งค้นฐานข้อมูล
2. การวิเคราะห์เปรียบเทียบ (Comparative Analysis) - เปรียบเทียบสถานะปัจจุบันกับรูปแบบช่องโหว่ที่พบบ่อยใน stack นี้
3. การประเมินช่องโหว่ (Vulnerability Assessment) - แสดงข้อสงสัยแต่ละรายการพร้อมระดับความเชื่อมั่นในสเกล 1-10 โดยรวมเฉพาะผลการตรวจพบที่มีระดับความเชื่อมั่น ≥ 8 ไว้ในรายงาน

ขั้นตอนที่ 4. อ่านรายงาน ผลลัพธ์อยู่ในรูปแบบตาราง Markdown สำหรับแต่ละปัญหา Claude จะระบุ:

• ไฟล์และหมายเลขบรรทัด (เช่น src/auth/login.ts:42)
• ระดับความรุนแรง (HIGH / MEDIUM / LOW)
• หมวดหมู่ (sql_injection, xss, auth_bypass, insecure_storage)
• คำอธิบาย - มีอะไรผิดพลาด
• สถานการณ์การโจมตี - ผู้โจมตีอาจนำไปใช้ประโยชน์อย่างไร
• คำแนะนำ - วิธีแก้ไข

ขั้นตอนที่ 5. ขอให้ Claude แก้ไขปัญหา หลังจากนั้น คุณสามารถทำงานกับ Claude เหมือน agent ทั่วไปได้:

“แก้ไขปัญหาระดับ HIGH จากรายงานทีละรายการ พร้อมคำอธิบาย PR”

Claude จะเปิดแต่ละไฟล์และเสนอการเปลี่ยนแปลง จากนั้นคุณยืนยัน ในโปรเจกต์จริง ฉันปิดผลการตรวจพบ 5 รายการได้ภายใน 40 นาที แทนที่จะใช้เวลา 3 ชั่วโมงตามที่วางแผนไว้

/security-review ตรวจพบช่องโหว่อะไรบ้าง?#

รายการทั้งหมดที่รวมอยู่ในการวิเคราะห์โดยค่าเริ่มต้นอธิบายไว้ในเอกสารอย่างเป็นทางการของ Anthropic:

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

• Command injection - เรียกใช้ข้อมูลจากผู้ใช้ใน shell (child_process.exec(userInput))
• Path traversal - โหลดไฟล์ด้วย ../../etc/passwd
• XXE - XML ที่มี external entities
• Template injection - SSTI ใน Jinja/Handlebars/EJS
• NoSQL injection - operators $ne, $gt ในคำสั่งค้น MongoDB
• การใช้คริปโตกราฟีผิดวิธี - ใช้ MD5, โหมด ECB หรือ IV แบบคงที่

Claude กำหนดระดับความรุนแรงให้ผลการตรวจพบแต่ละรายการ โดยใช้สเกลง่าย ๆ ดังนี้:

• HIGH - โจมตีจากระยะไกลได้โดยไม่ต้องยืนยันตัวตน หรือข้อมูลรั่วไหลที่กระทบผู้ใช้ทั้งหมด
• MEDIUM - ต้องมีเงื่อนไขเพิ่มเติมจึงจะโจมตีได้ (ต้องมี session / ต้องใช้ข้อมูลนำเข้าเฉพาะ)
• LOW - เป็นช่องทางที่อาจใช้โจมตีได้ ยังไม่วิกฤตในตอนนี้ แต่ควรแก้ไข

ควรรู้ไว้ว่าในการตั้งค่ามาตรฐาน Claude จะไม่รายงาน DoS, rate limiting, memory exhaustion, open redirects ที่ไม่มีผลกระทบพิสูจน์ได้, regex injection / ReDoS หรือการปลอมแปลง log ทั้งนี้ตั้งใจทำเช่นนี้เพื่อไม่ให้คุณได้รับข้อมูลรบกวนมากเกินไป หากหมวดหมู่เหล่านี้สำคัญ ให้เพิ่มกฎเอง (ดูหัวข้อการกรองผลบวกลวงด้านล่าง)

ตั้งค่า GitHub Action ให้ตรวจสอบอัตโนมัติอย่างไร?#

ขั้นตอนที่ 1. รับ API key ไปที่ console.anthropic.com สร้าง API key แล้วคัดลอก

ขั้นตอนที่ 2. ใส่ key ไว้ใน repository secrets ใน GitHub ไปที่: Settings → Secrets and variables → Actions → New repository secret ตั้งชื่อ CLAUDE_API_KEY; ค่าให้ใส่ key ของคุณ

ขั้นตอนที่ 3. สร้าง workflow file บันทึกเป็น .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

ขั้นตอนที่ 4. รวม branch เข้า main action จะเริ่มทำงานโดยอัตโนมัติเมื่อมี PR ถัดไป

สิ่งที่ action ทำ:

• ทำงานเมื่อมี Pull Request ที่เปิดอยู่ / มีการ synchronize
• นำ diff ระหว่าง branch ของ PR กับ main
• เรียกใช้ engine เดียวกับ /security-review ในเครื่อง
• โพสต์ความคิดเห็น inline ตรงบรรทัดโค้ดที่พบข้อสงสัย
• ทำสำเนารายงานฉบับเต็มไว้ใน Job Summary

รายละเอียดสำคัญใน permissions:

• pull-requests: write - เพื่อโพสต์ความคิดเห็น inline
• contents: read - เพื่ออ่านโค้ด ไม่มี write action ไม่แก้ไขโค้ดเอง แต่รายงานผลเท่านั้น

สิทธิ์ชุดนี้เพียงพอสำหรับ repository ส่วนตัว สำหรับ repo สาธารณะ คุณอาจระบุ actions: read เพิ่มได้หากใช้ reusable workflows

กรองผลบวกลวงและเปลี่ยนระดับความไวได้อย่างไร?#

ตาราง inputs ทั้งหมดของ GitHub Action (แหล่งที่มา: README ของ repository):

ตัวอย่างการตั้งค่าการกรองผลบวกลวง สร้างไฟล์ .claude/security/false-positives.md:

# กฎการกรองผลบวกลวงสำหรับโปรเจกต์ของเรา

- การใช้ `dangerouslySetInnerHTML` ทุกกรณีภายใน `src/lib/email/layout.ts` ปลอดภัย -
  HTML ประกอบขึ้นจากเทมเพลตที่เชื่อถือได้ และผ่าน `sanitize-html`
  ตอนเขียนลงฐานข้อมูล ไม่ใช่ตอนแสดงผล
- อย่ารายงาน API keys สำหรับทดสอบที่ฝังไว้ใน `__tests__/fixtures/*.ts`
  keys ทั้งหมดขึ้นต้นด้วย `sk-test-fake-`
- การต่อ SQL ใน `src/lib/admin/migrations.ts` ยอมรับได้ - ไฟล์นี้ทำงาน
  ในฐานะ root เท่านั้น และข้อมูลนำเข้ามาจาก environment variables

เชื่อมต่อไฟล์นี้ใน workflow:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

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

# การตรวจสอบเพิ่มเติมสำหรับโปรเจกต์ของเรา

- endpoint ทุกตัวภายใต้ `/api/admin/*` ต้องตรวจสอบบทบาทผู้ดูแลระบบ
  ผ่าน wrapper ที่ใช้ร่วมกัน หากไม่มี wrapper นี้ ให้จัดเป็นระดับ HIGH
- webhooks ของ YooKassa / CloudPayments ทุกตัวต้องตรวจสอบลายเซ็นก่อน
  แยกวิเคราะห์ body หากไม่ทำ ให้จัดเป็นระดับ HIGH
- magic-link tokens ต้องใช้ได้ครั้งเดียว (ทำเครื่องหมายว่าใช้แล้วหลังจาก
  คำขอที่ถูกต้องครั้งแรก) tokens ที่ใช้ซ้ำได้ให้จัดเป็นระดับ MEDIUM

นี่ไม่ใช่ preset ของ Anthropic อีกต่อไป แต่เป็นการถ่ายทอดความเชี่ยวชาญเกี่ยวกับโปรเจกต์ของคุณลงในกฎที่ Claude ใช้ทุกครั้ง นี่คือหัวใจของ “ให้ความสำคัญกับวิธีการมากกว่าโมเดล”

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีจัดการ context สำหรับ Claude ได้ในคู่มือ “วิธีกำหนดค่า CLAUDE.md” และ “Second Brain ใน Claude Code”

Claude ตรวจไม่พบอะไร และเพราะเหตุใด: ข้อจำกัดตามจริง#

Anthropic ระบุชัดเจนว่าสิ่งใดถูกปิดไว้โดยค่าเริ่มต้นและเพราะเหตุใด (แหล่งที่มา: README ของ repository):

• Denial of Service - สร้างข้อมูลรบกวนมากเกินไปและแทบไม่มีผลกระทบรุนแรง
• ข้อกังวลเรื่อง Rate limiting - จัดการในระดับโครงสร้างพื้นฐาน ไม่ใช่ในโค้ด
• การใช้หน่วยความจำ / CPU จนหมด - เช่นเดียวกัน
• การตรวจสอบข้อมูลนำเข้าทั่วไปโดยไม่มีผลกระทบที่พิสูจน์ได้ - การตรวจสอบทุกฟิลด์ทำให้เกิดผลบวกลวงจำนวนมาก
• Open redirect - มักเป็นพฤติกรรมที่ตั้งใจไว้

สิ่งที่รีวิวโค้ดอย่างเดียวตรวจให้ครบไม่ได้หากไม่มีหลักฐาน runtime หรือ deployment:

• การตั้งค่าเซิร์ฟเวอร์ production NGINX headers, CORS policies, TLS settings และพอร์ตที่เปิดรับการเชื่อมต่อ ต้องตรวจสอบด้วยตนเองในสภาพแวดล้อม staging
• Race conditions เช่น การจ่ายเงินคืนซ้ำซ้อนเมื่อมีคำขอคืนเงินพร้อมกัน การวิเคราะห์ static ชี้รูปแบบน่าสงสัยได้ แต่พฤติกรรมพร้อมกันยังต้องทดสอบ
• ข้อบกพร่องในตรรกะธุรกิจด้านการชำระเงิน หากคำนวณยอดรวมคำสั่งซื้อที่ฝั่ง client แล้วส่งไปยังผู้ให้บริการชำระเงินตรง ๆ นั่นมีระดับความรุนแรง HIGH แต่ Claude อาจมองไม่เห็นรูปแบบนี้เสมอไปหากไม่มีบริบทชัดเจนเกี่ยวกับวิธีการทำงานของการชำระเงิน
• IDOR ระดับฐานข้อมูล หากคำสั่งค้น SELECT * FROM orders WHERE id = $1 ไม่ตรวจ WHERE user_id = $session.userId Claude มักตรวจพบ แต่หากตรวจสอบผ่าน ORM middleware และ Claude มองไม่เห็นการไหลของข้อมูลทั้งหมด ก็อาจพลาดได้
• การต้านทาน social engineering / phishing เรื่องนี้ไม่เกี่ยวกับโค้ด

ใช้ /security-review เป็นรีวิว static เริ่มต้น ตามด้วยการทดสอบ dynamic ใน staging การตรวจบทบาทกับสิทธิ์ SAST ที่เกี่ยวข้อง และตรวจ config ที่ deploy จริง เช่น Coolify / Nginx / Redis / S3 ที่นี่ยังไม่ยืนยันเปอร์เซ็นต์ครอบคลุมที่วัดแล้ว

กำหนดขอบเขตและเวลาประเมินภายนอกจากความเสี่ยงกับการเปลี่ยนระบบ ทั้งคำสั่งเดียวและ audit ภายนอกเป็นระยะไม่ยืนยันความปลอดภัยครอบคลุม 100%

ผู้เขียนเนื้อหาต้นฉบับตรวจสอบความปลอดภัยของโปรเจกต์ vibe อย่างไร#

พบอะไรบ้าง ภาพโดยทั่วไปของโปรเจกต์ vibe ทั่วไปในขั้น “ทำงานบน production ได้แล้ว แต่ยังไม่ได้ตรวจสอบ”: มีข้อสงสัยหลายจุดเกี่ยวกับขั้นตอนการยืนยันตัวตน ตรรกะการประมวลผล webhooks จากระบบชำระเงิน การจัดการอัปโหลดไฟล์ และข้อสังเกตเฉพาะอีกสองสามจุดเกี่ยวกับการจัดการ HTML ขณะ render ฉันจะไม่เปิดเผยรายละเอียดต่อสาธารณะ เพราะมีคำแนะนำบางส่วนที่นำไปใช้แล้ว ส่วนที่เหลือยังอยู่ใน PR การสแกนแรกในโปรเจกต์ที่รายงานมีประโยชน์และเร็ว แต่ไม่ยืนยันเปอร์เซ็นต์ audit หรือเวลาจบทั่วไป

สิ่งที่ฉันตัดออกว่าเป็นผลบวกลวง:

• ผลการตรวจพบเกี่ยวกับ DoS จาก regex ในการตรวจสอบข้อมูลนำเข้า - ภาระงานจริงไม่ได้ตกอยู่กับ regex เหล่านั้น
• ผลการตรวจพบหนึ่งรายการเกี่ยวกับ API key ที่ฝังไว้ในโค้ด - เป็น key สำหรับทดสอบที่มี prefix fake- ระบุชัดเจนใน fixtures

ใช้เวลานานเท่าไร การรันเองใช้เวลา 4 นาที อ่านรายงานใช้เวลา 25 นาที การแก้ไขใช้เวลาประมาณหนึ่งชั่วโมงรวมการทดสอบ ทั้งหมดประมาณหนึ่งชั่วโมงครึ่งตั้งแต่ “เริ่มต้น” จนถึง “ทุกอย่างอยู่ใน main” การทดสอบเจาะระบบจากภายนอกบนพื้นที่เดียวกันใช้เวลาหนึ่งสัปดาห์ตามปฏิทินและมีค่าใช้จ่ายสูงกว่าหลายสิบเท่า

/security-review ให้ข้อค้นพบระดับโค้ดที่มีประโยชน์ได้ ดังที่ผู้เขียนรายงานสแกนสี่นาที ต้องรีวิวและทดสอบการแก้ แล้วตรวจ runtime กับ config ที่ deploy แยก การสแกนไม่ได้กำจัดความเสี่ยงความปลอดภัยของโปรเจกต์

ผสาน /security-review เข้ากับขั้นตอน pre-commit อย่างไร?#

hook เดิมที่ใช้ git_commit, --severity HIGH และ --fail-on-find ไม่ใช่สูตรทำงานที่มีเอกสารรองรับ ห้ามใช้เป็น security gate บทความนี้ไม่มี hook บล็อก commit ในเครื่องที่ยืนยันแล้ว GitHub Action ทางการด้านบนให้ข้อค้นพบ PR อัตโนมัติ อย่าอนุมานว่าบล็อก commit หรือ merge เพียงเพราะแสดงความคิดเห็นใน PR

อ่านคำอธิบาย hooks ฉบับเต็มได้ในคู่มือ “Hooks ใน Claude Code”

อีกทางเลือกหนึ่งคือใช้ routines สร้าง routine ชื่อ pre-deploy-check ที่รัน /security-review + npm run build + npm run test ด้วยคำสั่งเดียว ดูเนื้อหาเพิ่มเติมได้ในเอกสารประกอบของ Ailoot

หากใช้ MCP servers คุณสามารถเชื่อมผลการตรวจพบจาก /security-review เข้ากับระบบจัดการเหตุการณ์ (Sentry, Linear, Notion) เพื่อให้ผลการตรวจพบระดับ HIGH แต่ละรายการกลายเป็น ticket โดยอัตโนมัติ

คำถามที่พบบ่อยเกี่ยวกับ /security-review#

รันหนึ่งครั้งมีค่าใช้จ่ายเท่าไร? ขึ้นอยู่กับขนาดโปรเจกต์ สำหรับโค้ด 30K บรรทัดของฉัน การรันหนึ่งครั้งใช้ยอดคงเหลือ API ประมาณ $0.30-0.50 ส่วน repository องค์กรขนาดใหญ่ที่มีหนึ่งล้านบรรทัดอาจมีค่าใช้จ่ายสูงถึง $5-8 ต่อครั้ง ซึ่งถูกกว่าค่าสมัครใช้บริการ SaaS scanner หลายสิบเท่า

ควรรันในเครื่องบ่อยแค่ไหน? อย่างน้อยที่สุด ก่อนเผยแพร่ขึ้น production ทุกครั้ง พิจารณารันก่อน commit และ PR ที่สำคัญด้วย แต่บทความนี้ไม่มี hook อัตโนมัติบล็อก commit ที่ยืนยันแล้ว

ใช้กับ stack ใดได้บ้าง? ใช้ได้กับทุก stack ที่ Claude อ่านได้ จากการสังเกตของผู้เขียน มีการทดสอบกับ Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel) และ Ruby on Rails คุณภาพจะต่ำกว่าในภาษาเฉพาะทางมาก ๆ (Erlang, Elixir, Clojure) แต่ก็ยังตรวจพบปัญหาได้บ้าง

ควรทำอย่างไรหาก Claude พบ “ช่องโหว่” เดิมทุกครั้ง ทั้งที่จริงแล้วไม่ใช่ช่องโหว่? เพิ่มรายการนั้นใน false-positive-filtering-instructions พร้อมอธิบายว่า “ทำไมจึงปลอดภัย” Claude จะหยุดรายงานในการรันครั้งต่อ ๆ ไป

รันเฉพาะบางไฟล์ได้ไหม? ได้ เมื่อรันในเครื่อง ให้เรียก /security-review src/lib/auth/*.ts ส่วน GitHub Action ตรวจเฉพาะ diff ของ PR ปัจจุบัน ซึ่งโดยทั่วไปก็คือความหมายของ “ไฟล์เฉพาะ”

แหล่งที่มา#

ดูเนื้อหาเพิ่มเติมได้ในเอกสารประกอบของ Ailoot