---
read_when:
    - Реагування на повідомлення про проблему безпеки або підозру на інцидент безпеки
    - Підготовка координованого розкриття інформації або випуску безпеки з виправленнями
    - Перегляд очікувань щодо подальших дій після інциденту
summary: Як OpenClaw класифікує інциденти безпеки, реагує на них і виконує подальші дії
title: Реагування на інциденти
x-i18n:
    generated_at: "2026-05-03T11:35:32Z"
    model: gpt-5.5
    provider: openai
    source_hash: ef39b037cf3574a61fd67b356654f1ea0b91d84f89345c22aae93c1db7694df8
    source_path: security/incident-response.md
    workflow: 16
---

# Реагування на інциденти

## 1. Виявлення та тріаж

Ми відстежуємо сигнали безпеки з:

- GitHub Security Advisories (GHSA) та приватних звітів про вразливості.
- Публічних issues/discussions GitHub, коли звіти не є чутливими.
- Автоматизованих сигналів (наприклад Dependabot, CodeQL, рекомендацій npm і сканування секретів).

Початковий тріаж:

1. Підтвердити зачеплений компонент, версію та вплив на межу довіри.
2. Класифікувати як проблему безпеки або посилення захисту/без дій, використовуючи область дії та правила поза областю дії з `SECURITY.md` репозиторію.
3. Власник інциденту відповідає відповідно.

## 2. Оцінювання

Орієнтири щодо серйозності:

- **Критична:** Компрометація пакета/релізу/репозиторію, активна експлуатація або обхід межі довіри без автентифікації з високим впливом на керування або розкриттям даних.
- **Висока:** Підтверджений обхід межі довіри, що потребує обмежених передумов (наприклад автентифікована, але неавторизована дія з високим впливом), або розкриття чутливих облікових даних, що належать OpenClaw.
- **Середня:** Значна слабкість безпеки з практичним впливом, але обмеженою експлуатованістю або суттєвими передумовами.
- **Низька:** Знахідки щодо багаторівневого захисту, вузько обмежена відмова в обслуговуванні або прогалини посилення захисту/паритету без продемонстрованого обходу межі довіри.

## 3. Реагування

1. Підтвердити отримання звіту репортеру (приватно, якщо інформація чутлива).
2. Відтворити на підтримуваних релізах і найновішій `main`, потім реалізувати та перевірити патч із регресійним покриттям.
3. Для критичних/високих інцидентів підготувати виправлені релізи настільки швидко, наскільки практично можливо.
4. Для середніх/низьких інцидентів виправити в межах звичайного процесу релізу та задокументувати рекомендації щодо пом’якшення.

## 4. Комунікація

Ми комунікуємо через:

- GitHub Security Advisories у зачепленому репозиторії.
- Примітки до релізу/записи changelog для виправлених версій.
- Прямі подальші повідомлення репортеру щодо статусу та вирішення.

Політика розкриття:

- Критичні/високі інциденти мають отримувати координоване розкриття з випуском CVE, коли це доречно.
- Знахідки посилення захисту з низьким ризиком можуть бути задокументовані в примітках до релізу або рекомендаціях без CVE, залежно від впливу та експозиції користувачів.

## 5. Відновлення та подальші дії

Після постачання виправлення:

1. Перевірити усунення в CI та артефактах релізу.
2. Провести короткий післяінцидентний огляд (хронологія, першопричина, прогалина виявлення, план запобігання).
3. Додати подальші завдання з посилення захисту/тестів/документації та відстежувати їх до завершення.
