---
read_when:
    - การตอบสนองต่อรายงานด้านความปลอดภัยหรือเหตุการณ์ด้านความปลอดภัยที่ต้องสงสัย
    - การเตรียมการเปิดเผยข้อมูลแบบประสานงานหรือรุ่นเผยแพร่ด้านความปลอดภัยที่มีแพตช์แล้ว
    - ทบทวนความคาดหวังในการติดตามผลหลังเหตุการณ์
summary: วิธีที่ OpenClaw คัดแยก ตอบสนอง และติดตามผลเหตุการณ์ด้านความปลอดภัย
title: การรับมือเหตุการณ์
x-i18n:
    generated_at: "2026-05-06T09:30:49Z"
    model: gpt-5.5
    provider: openai
    source_hash: 546b69242fc4674e3d27e79e4c7b5cfecb83bcb17e8edb2a4b62f1a7498fb84f
    source_path: security/incident-response.md
    workflow: 16
    postprocess_version: locale-links-v1
---

## 1. การตรวจจับและการคัดแยก

เราตรวจสอบสัญญาณด้านความปลอดภัยจาก:

- GitHub Security Advisories (GHSA) และรายงานช่องโหว่ส่วนตัว
- ประเด็น/การสนทนาสาธารณะบน GitHub เมื่อรายงานไม่ใช่เรื่องละเอียดอ่อน
- สัญญาณอัตโนมัติ (เช่น Dependabot, CodeQL, คำแนะนำจาก npm และการสแกนความลับ)

การคัดแยกเบื้องต้น:

1. ยืนยันคอมโพเนนต์ เวอร์ชัน และผลกระทบต่อขอบเขตความไว้วางใจที่ได้รับผลกระทบ
2. จัดประเภทเป็นปัญหาด้านความปลอดภัยเทียบกับการเสริมความแข็งแกร่ง/ไม่ต้องดำเนินการ โดยใช้ขอบเขตและกฎสิ่งที่อยู่นอกขอบเขตใน `SECURITY.md` ของรีโพสิทอรี
3. เจ้าของเหตุการณ์ตอบสนองตามความเหมาะสม

## 2. การประเมิน

แนวทางระดับความรุนแรง:

- **Critical:** การประนีประนอมแพ็กเกจ/รีลีส/รีโพสิทอรี การถูกใช้โจมตีอยู่จริง หรือการข้ามขอบเขตความไว้วางใจโดยไม่ต้องยืนยันตัวตน ซึ่งมีผลกระทบสูงต่อการควบคุมหรือการเปิดเผยข้อมูล
- **High:** การข้ามขอบเขตความไว้วางใจที่ยืนยันแล้วและต้องมีเงื่อนไขเบื้องต้นจำกัด (เช่น ยืนยันตัวตนแล้วแต่ไม่ได้รับอนุญาตให้ทำการกระทำที่มีผลกระทบสูง) หรือการเปิดเผยข้อมูลลับที่ละเอียดอ่อนซึ่ง OpenClaw เป็นเจ้าของ
- **Medium:** จุดอ่อนด้านความปลอดภัยที่สำคัญและมีผลกระทบในทางปฏิบัติ แต่มีความสามารถในการโจมตีที่จำกัดหรือต้องมีเงื่อนไขเบื้องต้นจำนวนมาก
- **Low:** ข้อค้นพบด้านการป้องกันเชิงลึก การปฏิเสธการให้บริการที่มีขอบเขตจำกัด หรือช่องว่างด้านการเสริมความแข็งแกร่ง/ความเท่าเทียมกันโดยไม่มีการแสดงให้เห็นถึงการข้ามขอบเขตความไว้วางใจ

## 3. การตอบสนอง

1. ยืนยันการรับเรื่องกับผู้รายงาน (เป็นการส่วนตัวเมื่อเป็นเรื่องละเอียดอ่อน)
2. ทำซ้ำปัญหาบนรีลีสที่รองรับและ `main` ล่าสุด จากนั้นปรับใช้และตรวจสอบแพตช์พร้อมความครอบคลุมการทดสอบการถดถอย
3. สำหรับเหตุการณ์ระดับ Critical/High ให้เตรียมรีลีสที่แพตช์แล้วให้เร็วที่สุดเท่าที่ทำได้ในทางปฏิบัติ
4. สำหรับเหตุการณ์ระดับ Medium/Low ให้แพตช์ในกระบวนการรีลีสปกติและบันทึกคำแนะนำการบรรเทาผลกระทบ

## 4. การสื่อสาร

เราสื่อสารผ่าน:

- GitHub Security Advisories ในรีโพสิทอรีที่ได้รับผลกระทบ
- บันทึกรีลีส/รายการ changelog สำหรับเวอร์ชันที่แก้ไขแล้ว
- การติดตามผลโดยตรงกับผู้รายงานเกี่ยวกับสถานะและการแก้ไข

นโยบายการเปิดเผยข้อมูล:

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

## 5. การกู้คืนและการติดตามผล

หลังจากจัดส่งการแก้ไขแล้ว:

1. ตรวจสอบการแก้ไขใน CI และอาร์ติแฟกต์รีลีส
2. ดำเนินการทบทวนหลังเหตุการณ์แบบสั้น (ไทม์ไลน์ สาเหตุรากเหง้า ช่องว่างในการตรวจจับ แผนการป้องกัน)
3. เพิ่มงานติดตามผลด้านการเสริมความแข็งแกร่ง/การทดสอบ/เอกสาร และติดตามจนเสร็จสมบูรณ์