---
read_when:
    - پاسخ‌گویی به گزارش امنیتی یا رخداد امنیتی مشکوک
    - آماده‌سازی افشای هماهنگ‌شده یا انتشار امنیتی وصله‌شده
    - بررسی انتظارات پیگیری پس از حادثه
summary: نحوهٔ تریاژ، پاسخ‌گویی و پیگیری رخدادهای امنیتی در OpenClaw
title: پاسخ به حادثه
x-i18n:
    generated_at: "2026-05-06T09:42:24Z"
    model: gpt-5.5
    provider: openai
    source_hash: 546b69242fc4674e3d27e79e4c7b5cfecb83bcb17e8edb2a4b62f1a7498fb84f
    source_path: security/incident-response.md
    workflow: 16
    postprocess_version: locale-links-v1
---

## 1. تشخیص و تریاژ

ما سیگنال‌های امنیتی را از این منابع پایش می‌کنیم:

- مشاوره‌های امنیتی GitHub (GHSA) و گزارش‌های خصوصی آسیب‌پذیری.
- مسائل/گفت‌وگوهای عمومی GitHub وقتی گزارش‌ها حساس نیستند.
- سیگنال‌های خودکار (برای مثال Dependabot، CodeQL، مشاوره‌های npm و اسکن اسرار).

تریاژ اولیه:

1. مؤلفه، نسخه و تأثیر بر مرز اعتمادِ تحت تأثیر را تأیید کنید.
2. با استفاده از دامنه و قواعد خارج از دامنه در `SECURITY.md` مخزن، مورد را به‌عنوان مسئله امنیتی در برابر سخت‌سازی/بدون اقدام طبقه‌بندی کنید.
3. مالک رخداد مطابق با آن پاسخ می‌دهد.

## 2. ارزیابی

راهنمای شدت:

- **بحرانی:** به‌خطر افتادن بسته/انتشار/مخزن، بهره‌برداری فعال، یا دور زدن احرازنشده مرز اعتماد با کنترل یا افشای داده با اثرگذاری بالا.
- **بالا:** دور زدن تأییدشده مرز اعتماد که به پیش‌شرط‌های محدود نیاز دارد (برای مثال اقدام احرازشده اما غیرمجاز با اثرگذاری بالا)، یا افشای اعتبارنامه‌های حساس متعلق به OpenClaw.
- **متوسط:** ضعف امنیتی مهم با اثر عملی، اما با بهره‌برداری محدودشده یا پیش‌نیازهای قابل‌توجه.
- **پایین:** یافته‌های دفاع در عمق، انکار سرویس با دامنه محدود، یا شکاف‌های سخت‌سازی/برابری بدون دور زدن اثبات‌شده مرز اعتماد.

## 3. پاسخ

1. دریافت گزارش را به گزارش‌دهنده تأیید کنید (در صورت حساس بودن، به‌صورت خصوصی).
2. روی انتشارهای پشتیبانی‌شده و آخرین `main` بازتولید کنید، سپس وصله‌ای را با پوشش رگرسیون پیاده‌سازی و اعتبارسنجی کنید.
3. برای رخدادهای بحرانی/بالا، انتشار(های) وصله‌شده را تا حد عملی در سریع‌ترین زمان آماده کنید.
4. برای رخدادهای متوسط/پایین، در جریان انتشار عادی وصله کنید و راهنمای کاهش اثر را مستند کنید.

## 4. ارتباطات

ما از طریق این مسیرها ارتباط برقرار می‌کنیم:

- مشاوره‌های امنیتی GitHub در مخزن تحت تأثیر.
- یادداشت‌های انتشار/ورودی‌های تغییرات برای نسخه‌های اصلاح‌شده.
- پیگیری مستقیم با گزارش‌دهنده درباره وضعیت و حل‌وفصل.

سیاست افشا:

- رخدادهای بحرانی/بالا باید افشای هماهنگ‌شده دریافت کنند و در صورت مناسب بودن CVE صادر شود.
- یافته‌های سخت‌سازی کم‌ریسک، بسته به اثر و میزان مواجهه کاربران، ممکن است بدون CVE در یادداشت‌های انتشار یا مشاوره‌ها مستند شوند.

## 5. بازیابی و پیگیری

پس از انتشار اصلاح:

1. اصلاحات را در CI و آرتیفکت‌های انتشار تأیید کنید.
2. یک بازبینی کوتاه پس از رخداد انجام دهید (خط زمانی، علت ریشه‌ای، شکاف تشخیص، برنامه پیشگیری).
3. وظایف پیگیری سخت‌سازی/آزمون‌ها/مستندات را اضافه کنید و آن‌ها را تا تکمیل پیگیری کنید.