---
read_when:
    - Реагування на повідомлення про проблему безпеки або підозрюваний інцидент безпеки
    - Підготовка скоординованого розкриття або релізу безпеки з виправленням
    - Перегляд очікувань щодо подальших дій після інциденту
summary: Як OpenClaw оцінює пріоритетність інцидентів безпеки, реагує на них і виконує подальші дії
title: Реагування на інциденти
x-i18n:
    generated_at: "2026-05-06T04:53:26Z"
    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) і приватних звітів про вразливості.
- Публічних issues/discussions GitHub, коли звіти не є чутливими.
- Автоматизованих сигналів (наприклад Dependabot, CodeQL, порад npm і сканування секретів).

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

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

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

Настанова щодо серйозності:

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

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

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

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

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

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

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

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

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

Після випуску виправлення:

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