Tras la llegada de un informe de vulnerabilidad: acusar recibo, evaluar, corregir en privado, divulgar

Objetivo

Convertir un informe privado en una versión corregida y un aviso público sin que los detalles se filtren antes de que las personas usuarias puedan actualizar, y sin que quien reportó pierda la paciencia y publique primero.

Requisitos previos

Un canal de reporte ya publicado (security.txt o un archivo SECURITY, enlazado); un lugar privado donde desarrollar una corrección (una bifurcación privada temporal o un borrador de aviso privado); la lista de personas que pueden publicar una versión; e, idealmente, un contacto de Autoridad de Numeración CVE identificado de antemano, como aconseja la guía de la OpenSSF. La guía de la OpenSSF indica que en un proyecto pequeño de uno a cinco mantenedores, los propios mantenedores pueden ser el equipo de gestión de vulnerabilidades.

Pasos

1. Acusar recibo antes de evaluar nada. La guía de la OpenSSF dice que esto debe hacerse con rapidez, en uno o dos días; las indicaciones de GitHub dicen lo mismo y añaden que marca el tono del resto del intercambio.
2. Evaluar con los pasos y las versiones que aporta quien reportó. La clasificación de la guía: funciona como se espera, error ordinario, solicitud de función o vulnerabilidad, entendiendo que una vulnerabilidad compromete la confidencialidad, la integridad o la disponibilidad. Comunicar a quien reportó el resultado y el porqué; una sugerencia de endurecimiento no es una vulnerabilidad y puede pasar a un issue normal.
3. Acordar un período de embargo. La guía señala que quienes reportan suelen proponer uno, que 90 días es el máximo por defecto que contemplan los grupos que enumera, y que la comunicación continua es lo que mantiene a quien reportó dispuesto a extenderlo.
4. Desarrollar y probar la corrección en privado; identificar cada versión afectada y qué líneas con soporte recibirán la corrección. Mantener el parche mínimo para que actualizar sea fácil; no agrupar cambios de API.
5. Reservar un identificador CVE a través de la CNA y redactar la descripción. Preguntar a quien reportó si desea reconocimiento y de qué forma; la guía califica de inapropiado omitir el reconocimiento salvo que quien reportó lo rechace.
6. Elegir un día de publicación en el que las personas puedan actualizar en horario laboral; la guía sugiere de lunes a miércoles y evitar festivos muy observados.
7. Publicar la versión y, a continuación, el aviso: versiones afectadas, versiones corregidas, solución alternativa si existe, reconocimiento. Las indicaciones de GitHub insisten en marcar la versión explícitamente como corrección de seguridad para que quienes consumen el proyecto aguas abajo lo noten.
8. Registrar la cronología (informe, acuse de recibo, corrección, divulgación) para la siguiente revisión del proceso.

Resultado esperado

Quien reportó recibe respuestas fechadas en cada paso; las personas usuarias se enteran del problema por el propio aviso del proyecto y por una versión corregida al mismo tiempo.

Límites y base de verificación

Los pasos y los plazos proceden de las guías citadas; no se describe ningún incidente y no se mide ningún tiempo. Los proyectos con distribuidores pueden necesitar una lista de embargo, que la guía de la OpenSSF trata como opcional y costosa.

Publicar el aviso junto con la versión

En cuanto la corrección se sube a una rama pública, el diff divulga la vulnerabilidad a quien lea los commits, y para una biblioteca el aviso publicado es lo que dispara las alertas de los analizadores de dependencias en los proyectos aguas abajo. Redactar el aviso por completo durante la fase de corrección privada: versiones afectadas, versiones corregidas, solución alternativa, reconocimiento acordado con quien reportó. Después, publicar la versión y el aviso como un solo paso, con minutos de diferencia como máximo, preferiblemente desde un único script que etiqueta, sube el paquete y publica el aviso. La única restricción de orden es que el aviso no debe nombrar una versión corregida antes de que sea instalable.