Divulgación coordinada de vulnerabilidades: cómo gestionar un programa de divulgación

¿Qué es la divulgación coordinada de vulnerabilidades?

La divulgación coordinada de vulnerabilidades (CVD) es la práctica de gestionar una vulnerabilidad recién encontrada de forma privada entre quien la encuentra y el proveedor hasta que hay una corrección o mitigación disponible, y publicarla después. La CERT Guide to Coordinated Vulnerability Disclosure la describe como recopilar información de quienes encuentran vulnerabilidades, coordinar el intercambio de esa información entre las partes interesadas pertinentes y divulgar la vulnerabilidad y sus mitigaciones, también al público.

Para un proveedor de producto, la CVD tiene dos mitades. La mitad externa, recibir informes y publicar avisos, es la que cubre esta página. La mitad interna, verificar, corregir y publicar, es el ciclo de vida de la gestión de vulnerabilidades. Ambas suelen estar a cargo de un PSIRT.

CVD vs divulgación completa vs bug bounty

	Divulgación coordinada	Divulgación completa	Bug bounty
Qué es	Informe privado, corrección y publicación en un momento acordado	Quien la encuentra publica los detalles de inmediato, avise o no al proveedor	Un programa que paga por los hallazgos válidos
Quién controla el calendario	El proveedor y quien la encuentra, juntos, a veces con un coordinador	Quien la encuentra	Las condiciones del programa, que suelen seguir la CVD
Riesgo para los usuarios	El más bajo: los detalles se hacen públicos cuando existe una corrección o vence un plazo	El más alto: los atacantes se enteran a la vez que los defensores	Igual que la CVD
Coste	Tiempo del personal para el triaje y la respuesta	Trabajo de emergencia no planificado	Tiempo del personal más las recompensas y, a menudo, comisiones de plataforma

Un bug bounty no es una alternativa a un programa de divulgación de vulnerabilidades (VDP). Es un incentivo que se añade sobre él. Todo proveedor necesita una forma de que cualquiera pueda notificar una vulnerabilidad; una recompensa solo decide si algunos informes se pagan.

Qué incluye una política de divulgación de vulnerabilidades

Una política de divulgación de vulnerabilidades es el documento público que fija las condiciones de su programa. ISO/IEC 29147, el estándar internacional de divulgación de vulnerabilidades, hace obligatorio un elemento, un mecanismo de contacto preferido, y recomienda varios más. Una política completa cubre:

• Cómo notificar. Una dirección específica o un formulario web, y una forma de enviar detalles sensibles de manera segura, como una clave de cifrado publicada.
• Qué incluir. Producto y versión afectados, pasos para reproducirlo, impacto y cómo contactar con quien informa.
• Alcance. Qué productos, versiones y servicios están cubiertos y qué métodos de prueba están prohibidos, como la denegación de servicio o el acceso a datos de otros usuarios.
• Puerto seguro. Un compromiso de no emprender acciones legales contra la investigación de buena fe que siga la política.
• Qué pueden esperar quienes informan. Cuándo acusará recibo del informe, cómo les mantendrá al corriente y su plazo objetivo para una corrección.
• Calendario de divulgación. Cuándo se hacen públicos los detalles y qué ocurre si una corrección tarda más.
• Publicación. Dónde aparecen los avisos y si asigna identificadores CVE.
• Reconocimiento. Si reconoce a quienes informan y cómo, y si paga recompensas.

Mantenga la política breve y concreta. Quienes informan la leen para decidir si notificárselo a usted es seguro y merece la pena.

security.txt: haga que su contacto sea fácil de encontrar

Una política solo funciona si los investigadores pueden encontrarla. RFC 9116, publicado en abril de 2022, define security.txt, un pequeño archivo de texto servido en /.well-known/security.txt a través de HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Obligatorios: Contact y Expires. RFC 9116 recomienda una caducidad a menos de un año vista, para que el archivo no quede obsoleto.
• Opcionales: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical y Hiring.
• Firma: el RFC recomienda una firma OpenPGP en texto claro, con Canonical definido.

Ponga un recordatorio en el calendario antes de la fecha de Expires. Un archivo caducado indica a los investigadores que nadie lo lee.

Embargos y calendarios de divulgación

El embargo es el periodo entre el informe y la publicación. La norma más citada es la política de Google Project Zero: los proveedores disponen de 90 días para ofrecer un parche, y los detalles se publican 30 días después de que se distribuya. Un proveedor que necesite algo más de tiempo puede pedir un periodo de gracia, hasta un máximo de 104 días en total. Cuando una vulnerabilidad ya se está explotando en entornos reales, el plazo baja a 7 días.

Su propia política puede fijar otras condiciones, y muchos de quienes informan las aceptan. Lo que importa es que el calendario esté por escrito, que mantenga informados a quienes notifican y que pida una prórroga antes de la fecha límite y no después. Un aviso publicado a tiempo con una mitigación es mejor que el silencio.

Identificadores CVE y CNA

La mayoría de los avisos llevan un identificador CVE para que los clientes y las herramientas puedan cotejarlos. Los identificadores los asignan las CVE Numbering Authorities (CNA), organizaciones autorizadas a asignarlos dentro de un ámbito acordado. Muchos proveedores de software son CNA de sus propios productos, lo que les permite asignar el identificador y publicar el registro según su propio calendario. Si usted no lo es, lo asigna una CNA cuyo ámbito cubra su producto o una CNA of Last Resort.

Coordinación entre varias partes

Algunas vulnerabilidades afectan a muchos proveedores a la vez: un fallo en una biblioteca muy utilizada, un protocolo o un chip. En ese caso, un coordinador ayuda a llegar a todos los proveedores afectados y a acordar una única fecha de publicación.

• CERT/CC, en el Software Engineering Institute de la Universidad Carnegie Mellon, coordina casos con varios proveedores y publica la guía CVD del CERT.
• CSIRT nacionales en la UE. Con arreglo a NIS2, cada Estado miembro designa un CSIRT como su coordinador de CVD. Actúa como intermediario de confianza entre quienes informan y los proveedores, negocia calendarios de divulgación, gestiona las vulnerabilidades que afectan a varias entidades y acepta informes anónimos.
• La European Vulnerability Database (EUVD) de ENISA, creada en virtud de NIS2, está operativa desde mayo de 2025 y publica información sobre vulnerabilidades de conocimiento público, incluidas las coordinadas en la UE.

ISO/IEC 29147 también cubre el caso en que usted es ambas cosas: un proveedor cuyo producto contiene un componente vulnerable de otro proveedor, que tiene que informar upstream y avisar a sus propios clientes.

Cuando llega un informe

1. Acuse recibo en el plazo que promete su política y dé a quien informa un identificador de seguimiento.
2. Verifique el informe y califique su gravedad.
3. Encuentre lo afectado: cada producto, versión y rama con soporte que contenga el código o el componente vulnerable.
4. Corrija y publique para cada rama afectada, manteniendo al corriente a quien informó.
5. Publique el aviso, con un identificador CVE, las versiones afectadas, la corrección y el reconocimiento. Los avisos legibles por máquina utilizan CSAF, y VEX indica a los clientes qué productos no están afectados.

El proceso completo, con funciones, plazos y métricas, está en el ciclo de vida de la gestión de vulnerabilidades.

La regulación está haciendo obligatorias las políticas de CVD

El Cyber Resilience Act de la UE exige a los fabricantes establecer y aplicar una política de divulgación coordinada de vulnerabilidades y facilitar una dirección de contacto para notificar vulnerabilidades, incluidas las de componentes de terceros (anexo I, parte II). Estas obligaciones se aplican desde el 11 de diciembre de 2027; consulte qué exige el CRA. El artículo 21, apartado 2, letra e), de NIS2 incluye la gestión y divulgación de vulnerabilidades entre las medidas de seguridad que deben adoptar las entidades esenciales e importantes. En EE. UU., la Executive Order 14028 ordenó elaborar orientaciones sobre la cadena de suministro de software que incluyen participar en un programa de divulgación de vulnerabilidades.

Un informe solo es tan útil como su registro de lo distribuido

Todo informe plantea la misma primera pregunta: ¿cuáles de nuestras versiones contienen esto? CRACI ejecuta sus builds de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés de CI y las dependencias que ningún lockfile enumera. El historial de builds muestra qué builds anteriores contenían una dependencia vulnerable, de modo que usted conoce el periodo en que estuvo afectado, y la vista de inventario muestra qué versiones de software están desplegadas en qué productos.

CRACI agrega las SBOM de todos los builds y repositorios y reevalúa de forma continua las SBOM monitorizadas, de modo que, en cuanto se publica una vulnerabilidad en un componente de código abierto, usted ve todos los lugares donde aparece. Los equipos de seguridad hacen el triaje de los hallazgos y los envían a los equipos responsables de la corrección, CRACI es compatible con VEX, y los controles de política pueden bloquear los builds que contengan un CVE concreto una vez corregido. Consulte el seguimiento de vulnerabilidades.

Divulgación coordinada de vulnerabilidades: preguntas frecuentes

¿Qué es la divulgación coordinada de vulnerabilidades?

La divulgación coordinada de vulnerabilidades (CVD) es el proceso en el que quien encuentra una vulnerabilidad la notifica en privado al proveedor, el proveedor la corrige y los detalles se publican cuando los usuarios pueden protegerse, normalmente en una fecha que acuerdan las partes. Coordinadores como CERT/CC o un CSIRT nacional intervienen cuando no se puede contactar con un proveedor o hay varios afectados.

¿Cuál es la diferencia entre un VDP y un bug bounty?

Un programa de divulgación de vulnerabilidades (VDP) indica a cualquiera cómo notificar una vulnerabilidad y qué esperar, sin pagar por los hallazgos. Un bug bounty paga a los investigadores por los hallazgos válidos, normalmente dentro de un alcance definido y a menudo a través de una plataforma de recompensas. La mayoría de las organizaciones empiezan con un VDP; una recompensa es un añadido opcional sobre él, no un sustituto.

¿Qué debe incluir una política de divulgación de vulnerabilidades?

Como mínimo, cómo notificar: una dirección de contacto o un formulario. ISO/IEC 29147 también recomienda indicar qué debe contener un informe, cómo comunicarse de forma segura, qué pueden esperar quienes informan y cuándo, qué entra en el alcance, cómo publica los avisos y cómo reconoce a quienes informan. La mayoría de las políticas añaden una declaración de puerto seguro y un calendario de divulgación.

¿Qué es security.txt?

security.txt es un archivo de texto sin formato definido en RFC 9116 y servido en /.well-known/security.txt. Indica a los investigadores dónde notificar vulnerabilidades. Debe contener un campo Contact y otro Expires, y puede enlazar a su política, a su clave de cifrado y a su página de agradecimientos.

¿Cuánto dura una fecha límite de divulgación típica?

90 días es la norma más citada. Google Project Zero da a los proveedores 90 días para ofrecer un parche y publica los detalles 30 días después del parche, con un plazo de 7 días cuando una vulnerabilidad ya se está explotando en entornos reales. Su propia política puede fijar otras condiciones, y los coordinadores negocian caso por caso.

¿Es obligatoria una política de divulgación coordinada de vulnerabilidades?

Cada vez más, sí. El Cyber Resilience Act de la UE exige a los fabricantes de productos con elementos digitales establecer y aplicar una política de CVD y facilitar una dirección de contacto para los informes, y NIS2 incluye la gestión y divulgación de vulnerabilidades entre las medidas de seguridad obligatorias. En otros lugares, los clientes y las normas de contratación suelen pedir una.

¿Necesito ser una CNA para obtener un identificador CVE?

No. Una CVE Numbering Authority (CNA) asigna identificadores CVE dentro de su propio ámbito, y muchos proveedores se convierten en CNA de sus propios productos. Si usted no lo es, puede asignar el identificador una CNA cuyo ámbito cubra su producto o una CNA of Last Resort.