---
read_when:
    - Реагирование на отчет об уязвимости или предполагаемый инцидент безопасности
    - Подготовка координированного раскрытия или исправленного релиза безопасности
    - Анализ ожиданий по последующим действиям после инцидента
summary: Как OpenClaw классифицирует инциденты безопасности, реагирует на них и выполняет последующие действия
title: Реагирование на инциденты
x-i18n:
    generated_at: "2026-06-28T23:47:31Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 546b69242fc4674e3d27e79e4c7b5cfecb83bcb17e8edb2a4b62f1a7498fb84f
    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, когда это уместно.
- Низкорисковые находки по усилению защиты могут быть задокументированы в примечаниях к релизу или advisories без CVE, в зависимости от влияния и воздействия на пользователей.

## 5. Восстановление и последующие действия

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

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