La CNCF publicó el 7 de septiembre de 2026 una tarjeta de orientación titulada «Gestión de informes de vulnerabilidades» (Handling vulnerability reports: Recipe card), dirigida a proyectos de código abierto pequeños y medianos que no se centran principalmente en la seguridad. El material fue preparado por Marina Moore, de Edera, copresidenta de TAG Security, y por Sherine Khoury, de Red Hat, líder de TAG Security.
La idea principal de la guía es reducir el trabajo adicional para los mantenedores y usuarios, evitando al mismo tiempo que el informe de seguridad se convierta en un debate público antes de que la corrección esté lista. La CNCF explica que una vulnerabilidad de seguridad es un fallo que puede explotarse para afectar a la confidencialidad, integridad o disponibilidad del sistema, pero no todo fallo de software es explotable ni se clasifica como vulnerabilidad.
Comienza con un canal de informes claro y privado
Las directrices recomiendan que el archivo README.md incluya una sección de seguridad clara y fácil de encontrar, con las instrucciones directamente en el archivo o una referencia a un archivo SECURITY.md en la raíz del repositorio. El objetivo es dirigir a los investigadores a un proceso privado en lugar de publicar los detalles del problema en una issue pública que todos puedan leer.
Las instrucciones para informar deberían aclarar varios elementos, entre ellos el modelo de amenazas o el umbral mínimo aceptable para considerar que el informe describe una vulnerabilidad, el lugar de envío, el formato del informe, el plazo previsto para revisarlo y el tiempo aproximado hasta su divulgación. Puede utilizarse el mecanismo privado de informes de vulnerabilidades de GitHub o una lista de correo privada. En cambio, un programa de recompensas no es obligatorio para los proyectos pequeños y medianos si no tienen capacidad para gestionarlo.
Verifica la naturaleza del informe antes de tratarlo como una vulnerabilidad
Tras recibir el informe, primero debe determinarse si realmente señala una vulnerabilidad explotable, o si se trata de un fallo no explotable, una interpretación errónea del comportamiento esperado o un error de documentación. La CNCF propone debatir el informe con su autor y con los expertos adecuados del proyecto, manteniendo limitado el número de participantes y exigiendo a todos confidencialidad hasta que el informe se haga público.
Entre las preguntas prácticas que pueden plantearse están las siguientes: ¿Existe algún mecanismo de mitigación disponible para los usuarios? ¿Podría el fallo provocar una intrusión, una filtración de datos u otra actividad maliciosa? ¿El problema se limita a la documentación? Si se determina que el informe no describe una vulnerabilidad, puede indicarse a su autor que cree una issue pública, utilizando los procedimientos de publicación adecuados para informar a los usuarios cuando sea necesario.
En caso de incertidumbre, las directrices señalan que puede solicitarse orientación a TAG Security and Compliance o al personal de la CNCF, manteniendo los detalles del informe fuera de los canales públicos. También debe seleccionarse cuidadosamente a los participantes durante el periodo de confidencialidad e involucrar únicamente a quienes realmente necesiten ayudar a resolver el problema, para evitar que la información llegue a atacantes antes de que se proporcione la corrección.
Desarrolla y prueba la corrección fuera del ámbito público
La CNCF advierte que publicar la corrección o debatirla en una pull request pública puede revelar la naturaleza de la vulnerabilidad antes de que los usuarios tengan la oportunidad de actualizarse. Si se utiliza el mecanismo privado de informes de GitHub, puede crearse una rama privada a partir del informe. De lo contrario, la corrección puede desarrollarse y revisarse mediante un canal privado.
La corrección debe probarse, incluso si el entorno habitual de integración continua no funciona con ramas privadas. En ese caso, las pruebas pueden realizarse localmente según el criterio de los mantenedores y el alcance del cambio. Tras confirmar que la corrección resuelve el problema y que las pruebas son suficientes, las directrices recomiendan integrarla rápidamente y contar con un número suficiente de mantenedores para crearla y probarla. Antes de la publicación general, el código debe revisarse de nuevo y debe confirmarse que la vulnerabilidad se ha cerrado realmente.
Coordina la versión con la divulgación del CVE
Una vez completada la corrección, la CNCF considera una práctica habitual divulgarla en un plazo de 90 días desde la recepción del informe. Si sus recursos lo permiten, el proyecto puede avisar previamente a una lista privada de usuarios, pero mantener actualizada una lista de contactos supone una carga que la mayoría de los proyectos pequeños no puede asumir.
Por ello, la tarjeta propone un enfoque más sencillo: poner a disposición la versión que incluye la corrección y anunciar la vulnerabilidad al mismo tiempo, para que los usuarios obtengan la solución cuando se anuncie el problema. Esto requiere crear una nueva versión inmediatamente después de introducir la corrección y, a continuación, publicar el CVE. Si se utiliza el mecanismo privado de GitHub, todo ello puede hacerse desde la interfaz de GitHub.
El número CVE debe ser asignado por una CNA, es decir, una autoridad de numeración de CVE. GitHub es una de estas autoridades y puede realizar el proceso; asimismo, el proyecto y el investigador pueden comunicarse directamente con una de las autoridades CNA incluidas en la lista. La gravedad del CVE se determina mediante un conjunto de preguntas, y el proyecto debería trabajar con el investigador para verificar la exactitud de las respuestas y acordar la puntuación asignada.
¿Por qué son importantes estas directrices?
En la práctica, la tarjeta transforma la gestión de una vulnerabilidad, pasando de una reacción improvisada a un proceso ejecutable: canal privado, verificación limitada, corrección no anunciada y, después, una publicación y divulgación coordinadas. Tras publicar el CVE, la información aparece en OSV y en otras bases de datos de vulnerabilidades, lo que ayuda a las herramientas de análisis de los usuarios a detectar la necesidad de actualizarse.
Sin embargo, el alcance de la receta está claramente limitado: se dirige a proyectos pequeños y medianos no especializados en seguridad y no sustituye a un programa más complejo para proyectos de alto riesgo o sensibles desde el punto de vista de la seguridad. La CNCF también propone considerar la publicación de una prueba de concepto después de que la corrección haya estado disponible durante un tiempo, para ofrecer a los usuarios una oportunidad adicional de actualizarse, aunque reconoce que hacerlo puede ser difícil cuando se utiliza el mecanismo de informes privados.