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

# 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. Додати подальші завдання з посилення захисту, тестів і документації та відстежувати їх до завершення.