Реагирование на инциденты

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. Добавьте последующие задачи по усилению защиты/тестам/документации и отслеживайте их до завершения.