01VDP y bug bounty: relacionados, pero no idénticos
Una política de divulgación de vulnerabilidades (VDP) crea un canal de reporte regulado: define el alcance, las reglas del juego y las garantías legales para quienes reportan desde fuera, sin promesa de remuneración. Un programa de bug bounty se apoya sobre esa base y remunera los hallazgos válidos para dirigir de forma deliberada el esfuerzo de prueba hacia los propios sistemas. Los programas públicos están abiertos a todos y maximizan el alcance, pero generan un esfuerzo de triaje considerable; los programas privados invitan a investigadores seleccionados y verificados y permiten un control más estrecho del alcance y de la calidad. La secuencia que ha demostrado su eficacia es: primero la VDP y el proceso interno de gestión, después el programa de bounty.
02La divulgación coordinada de vulnerabilidades como proceso
La divulgación coordinada de vulnerabilidades (CVD) designa la actuación concertada entre descubridores, fabricantes u operadores y, si es necesario, un coordinador, hasta que la vulnerabilidad queda corregida y se publica de forma controlada. El proceso comprende típicamente el acuse de recibo, el triaje y la verificación, la corrección y la publicación coordinada de un aviso de seguridad. Como convención de plazos se han consolidado ampliamente los 90 días; Google Project Zero, por ejemplo, trabaja con un modelo «90+30». En Alemania, el BSI actúa como coordinador cuando los fabricantes no reaccionan o el proceso de CVD corre riesgo de fracasar; la Directiva NIS2 obliga además a los Estados miembros de la UE a adoptar políticas nacionales de CVD.
03Las normas: ISO/IEC 29147 e ISO/IEC 30111
Dos normas complementarias estructuran la materia. ISO/IEC 29147:2018 describe la interfaz hacia el exterior: cómo las organizaciones reciben reportes de vulnerabilidades, se comunican con quienes reportan y publican la información de remediación. ISO/IEC 30111:2019 regula el proceso interno: verificar los reportes, evaluar el impacto, desarrollar y desplegar las correcciones. Ambas ediciones están actualmente vigentes (confirmadas por última vez en 2024 y 2025, respectivamente) y resultan idóneas como marco de referencia para el diseño de políticas y procesos, también con vistas a los requisitos del Cyber Resilience Act.
04security.txt según la RFC 9116
La RFC 9116 (Informational, 2022) define con security.txt un formato legible por máquina mediante el cual quienes reportan encuentran el canal de contacto correcto: un archivo de texto en /.well-known/security.txt, servido por HTTPS. Los campos obligatorios son Contact y Expires; se recomienda una validez inferior a un año para que los datos se mantengan actualizados. Campos opcionales como Policy, Encryption, Preferred-Languages y Acknowledgments remiten a la política de divulgación, al material criptográfico o a los idiomas preferidos. Este archivo es el primer paso más rápido hacia una VDP operativa, siempre que el contacto indicado se supervise realmente.
05Modelos de remuneración y de operación
Las recompensas de bug bounty suelen orientarse por la severidad, generalmente sobre la base del Common Vulnerability Scoring System (CVSS) de FIRST, actualmente en la versión 4.0 (2023). Son habituales los importes fijos o los rangos por nivel de severidad; por regla general solo se remunera el primer reporte válido de una vulnerabilidad, mientras que los duplicados y los hallazgos fuera de alcance no se remuneran. En cuanto a la operación existen tres modelos básicos: la operación propia (control total, pero con el esfuerzo de triaje y de pago a cargo propio), las plataformas comerciales (gran alcance, pero más ruido en el triaje) y los programas gestionados con investigadores curados e identificados y triaje a cargo del proveedor. VamiSec, por ejemplo, opera un programa privado y curado de bug bounty como servicio gestionado.
06Cyber Resilience Act: la gestión de vulnerabilidades como obligación
El Cyber Resilience Act (Reglamento (UE) 2024/2847) hace obligatoria la gestión ordenada de vulnerabilidades para los fabricantes de productos con elementos digitales. El anexo I, parte II, exige entre otras cosas una lista de materiales de software (SBOM), la corrección sin demora de las vulnerabilidades mediante actualizaciones de seguridad gratuitas, una política de divulgación coordinada de vulnerabilidades y una dirección de contacto para los reportes de vulnerabilidades. A partir del 11 de septiembre de 2026 rigen además las obligaciones de notificación del art. 14: las vulnerabilidades explotadas activamente deben notificarse en un plazo de 24 horas (alerta temprana) y de 72 horas (notificación) al CSIRT designado como coordinador y a ENISA a través de la plataforma central de notificación, y el informe final debe presentarse a más tardar 14 días después de que esté disponible una medida correctora. Las demás obligaciones se aplican en lo esencial a partir del 11 de diciembre de 2027: quien construye ahora su VDP y su proceso de CVD ya está cubriendo un componente central del cumplimiento del CRA.
