Get started
Respuesta a incidentes
1. Detección y triage
Las señales de seguridad provienen de:
- GitHub Security Advisories (GHSA) e informes privados de vulnerabilidades.
- Issues/discussions públicos de GitHub cuando los informes no son sensibles.
- Señales automatizadas: Dependabot, CodeQL, avisos de npm, escaneo de secretos.
Triage inicial:
- Confirmar el componente afectado, la versión y el impacto en el límite de confianza.
- Clasificarlo como un problema de seguridad frente a refuerzo/sin acción, usando las reglas de alcance y fuera de alcance de
SECURITY.md. - Un responsable del incidente responde según corresponda.
2. Severidad
| Severidad | Definición |
|---|---|
| Crítica | Compromiso de paquete/lanzamiento/repositorio, explotación activa o evasión no autenticada del límite de confianza con control de alto impacto o exposición de datos. |
| Alta | Evasión verificada del límite de confianza que requiere precondiciones limitadas (por ejemplo, una acción autenticada pero no autorizada de alto impacto), o exposición de credenciales sensibles propiedad de OpenClaw. |
| Media | Debilidad de seguridad significativa con impacto práctico, pero con explotabilidad limitada o requisitos previos sustanciales. |
| Baja | Hallazgos de defensa en profundidad, denegación de servicio de alcance reducido o brechas de refuerzo/paridad sin una evasión demostrada del límite de confianza. |
3. Respuesta
- Confirmar la recepción al informante (en privado cuando sea sensible).
- Reproducir en versiones compatibles y en la última versión de
main, luego implementar y validar un parche con cobertura de regresión. - Crítica/alta: preparar versiones parcheadas tan rápido como sea práctico.
- Media/baja: parchear en el flujo normal de lanzamiento y documentar la guía de mitigación.
4. Comunicación y divulgación
Comunicar a través de GitHub Security Advisories en el repositorio afectado, notas de lanzamiento/entradas del registro de cambios para las versiones corregidas y seguimiento directo con el informante sobre el estado y la resolución.
Los incidentes críticos/altos reciben divulgación coordinada, con emisión de CVE cuando corresponda. Los hallazgos de refuerzo de bajo riesgo pueden documentarse en notas de lanzamiento o avisos sin un CVE, según el impacto y la exposición del usuario.
5. Recuperación y seguimiento
Después de publicar la corrección:
- Verificar las remediaciones en CI y en los artefactos de lanzamiento.
- Realizar una breve revisión posterior al incidente: cronología, causa raíz, brecha de detección, plan de prevención.
- Agregar tareas de seguimiento de refuerzo/pruebas/docs y hacerles seguimiento hasta completarlas.
Relacionado
- Política de seguridad — alcance de los informes y modelo de confianza.
- Modelo de amenazas
Was this useful?
