triaje-de-seguridad

Triaje de Seguridad

Úsese al revisar avisos de seguridad, borradores o informes GHSA de OpenClaw.

Objetivo: triaje de mantenedores con alta confianza sin cerrar problemas reales ni enviar regresiones innecesarias.

Criterio de Cierre

Cerrar solo si se cumple una de estas condiciones:

• duplicado de un aviso existente o un problema ya corregido
• no válido contra el comportamiento publicado
• fuera del alcance según SECURITY.md
• corregido antes de cualquier versión/etiqueta afectada

No cerrar solo porque main está corregido. Si la última etiqueta publicada o la versión de npm está afectada, mantener abierto hasta que se publique o libere con el estado correcto.

Lecturas Obligatorias

Antes de responder:

1. Leer SECURITY.md.
2. Leer el cuerpo del GHSA con gh api /repos/openclaw/openclaw/security-advisories/<GHSA>.
3. Inspeccionar las rutas de código exactas implicadas.
4. Verificar el estado publicado:
   • git tag --sort=-creatordate | head
   • npm view openclaw version --userconfig "$(mktemp)"
   • git tag --contains <fix-commit>
   • si es necesario: git show <tag>:path/to/file
5. Buscar superposición canónica:
   • GHSA publicados existentes
   • errores antiguos corregidos
   • misma clase de modelo de confianza ya cubierta en SECURITY.md

Método de Revisión

Para cada aviso, decidir:

• close
• keep open
• keep open but narrow

Por defecto, un aviso a la vez cuando se involucran comentarios/cierres:

1. Revisar exactamente un GHSA.
2. Imprimir la URL del GHSA primero.
3. Resumir la decisión y las pruebas para discusión.
4. Redactar un comentario listo para mantenedor.
5. Copiar solo ese comentario al portapapeles.
6. Parar y esperar a que Peter publique/discuta antes de pasar al siguiente GHSA.

No agrupar múltiples comentarios de cierre a menos que Peter lo solicite explícitamente.

Verificar en este orden:

1. Modelo de confianza
   • ¿El prerrequisito ya está dentro del estado de host/local/plugin/operador de confianza?
   • ¿SECURITY.md menciona explícitamente esta clase como fuera de alcance o solo como endurecimiento?
2. Comportamiento publicado
   • ¿El error está presente en la última etiqueta publicada o versión de npm?
   • ¿Fue corregido antes de la publicación?
3. Ruta de explotación
   • ¿El informe muestra una verdadera evasión de límites, no solo inyección de prompt, control local del mismo usuario o semántica de nivel de ayuda?
   • Si los datos solo se mueven entre archivos de memoria de espacio de trabajo de confianza mencionados en SECURITY.md, no tratar los "marcadores de inyección" por sí solos como un error de seguridad.
   • En ese caso, enmarcar la sanitización como endurecimiento opcional solo si preserva los flujos de memoria esperados.
4. Compensación funcional
   • Si un cambio de endurecimiento reduciría la funcionalidad prevista para el usuario, señalarlo antes de proponerlo.
   • Preferir correcciones que preserven los flujos de trabajo del usuario sobre regresiones de denegación por defecto a menos que el límite lo exija.
5. Seguimiento de endurecimiento
   • Incluso cuando el GHSA deba cerrarse, preguntar si un cambio de endurecimiento acotado reduciría riesgos sin cambiar el límite de confianza documentado.
   • Separar el endurecimiento del estado de vulnerabilidad. Expresarlo como "no requerido para el cierre del GHSA, pero vale la pena considerarlo".
   • Mencionar el endurecimiento solo si es concreto, de bajo riesgo y preserva los flujos de trabajo previstos del mantenedor/operador.
   • Si el endurecimiento requiriera un cambio en el modelo de producto/seguridad, decirlo explícitamente y no implicar que es una corrección requerida para el cierre.

Formato de Respuesta

Al preparar una respuesta de cierre lista para mantenedor:

1. Imprimir la URL del GHSA primero.
2. Luego redactar una respuesta detallada que el mantenedor pueda publicar.
3. Incluir:
   • razón exacta del cierre
   • referencias de código exactas
   • hechos exactos de etiqueta/versión publicada
   • procedencia de la corrección o GHSA duplicado canónico cuando corresponda
   • nota de endurecimiento opcional solo si vale la pena y preserva funcionalidad

Mantener un tono firme, específico y no defensivo.

Higiene de Redacción Pública

• Mantener los hashes de commit en crudo, títulos/números de PR y resúmenes del mecanismo de corrección fuera del texto público del aviso. Usar solo el campo de versión/liberación parcheada.
• Mantener los SHAs de commit exactos, PRs y notas de implementación en notas internas y archivos de verificación.
• Para resultados de endurecimiento/sin publicación, no añadir detalles con mucho contenido de explotación, texto "Corregido por" o una sección "Commit(s) de corrección". Agradecer a los reporteros, preservar el crédito, indicar el límite de SECURITY.md y decir claramente que el GHSA se cerrará sin publicación.
• Para texto de CVE/GHSA publicado, preferir ### Versiones Parcheadas con la versión corregida. No explicar cómo funciona el parche a menos que Peter lo solicite explícitamente para ese detalle público.
• Mantener los IDs de GHSA fuera del registro de cambios y de la redacción de notas de publicación a menos que Peter lo solicite explícitamente.

Modo de Discusión

Cuando Peter esté publicando comentarios GHSA manualmente, usar este flujo:

1. Mostrar la URL.
2. Dar un veredicto conciso (close, keep open o keep open but narrow).
3. Enumerar los puntos de prueba más sólidos.
4. Indicar cualquier seguimiento de endurecimiento opcional separado de la razón de cierre.
5. Copiar el cuerpo del comentario propuesto con pbcopy.
6. Terminar la respuesta después de ese aviso. No continuar con el siguiente aviso hasta que Peter diga que continúe.

Si la API de GitHub no puede publicar comentarios para avisos privados, decirlo una vez y seguir usando el portapapeles/pegar en la interfaz.

Paso del Portapapeles

Después de redactar el cuerpo final de la publicación para el aviso actual, copiarlo:

pbcopy <<'EOF'
<respuesta final>
EOF

Decir al usuario que el portapapeles ahora contiene la respuesta propuesta para ese aviso.

Comandos Útiles

gh api /repos/openclaw/openclaw/security-advisories/<GHSA>
gh api /repos/openclaw/openclaw/security-advisories --paginate
git tag --sort=-creatordate | head -n 20
npm view openclaw version --userconfig "$(mktemp)"
git tag --contains <commit>
git show <tag>:<path>
gh search issues --repo openclaw/openclaw --match title,body,comments -- "<términos>"
gh search prs --repo openclaw/openclaw --match title,body,comments -- "<términos>"

Interrupciones del Clasificador Cibernético

Para trabajo defensivo permitido interrumpido por un clasificador cibernético, usar una ruta Daybreak Blue aprobada y disponible solo para esa tarea acotada, luego restaurar el modelo anterior. Preservar la identidad, el alcance, los permisos, el entorno aislado y los puntos de revisión aprobados. Nunca cambiar de modelo para eludir denegaciones de acceso, solicitudes no permitidas o acciones de herramientas rechazadas; si esa ruta también se niega, detenerse e informar. Seguir la guía de OpenAI para acceso aprobado al modelo.

Notas de Decisión

• "corregido en main, no publicado" normalmente no es un cierre.
• "requiere primero estado local controlado por el atacante" normalmente está fuera de alcance.
• "el proceso del mismo host y mismo usuario ya puede leer/escribir el estado local" normalmente está fuera de alcance.
• "la memoria de espacio de trabajo de confianza promociona/reindexa memoria de espacio de trabajo de confianza" normalmente está fuera de alcance a menos que cruce un límite documentado.
• "la función auxiliar se comporta de manera diferente a la semántica de configuración documentada" normalmente no es válido.
• Si solo la gravedad es incorrecta pero el error es real, mantenerlo abierto y acotar el impacto en la respuesta.