¿Qué es la divulgación coordinada de vulnerabilidades y cómo debería funcionar?
Respuesta breve
La divulgación coordinada de vulnerabilidades es un proceso en el que un investigador reporta un fallo en privado al fabricante, ambas partes acuerdan la remediación y un plazo, y los detalles se publican solo cuando hay un parche disponible (o vence el plazo acordado). Equilibra dar tiempo a los defensores para parchear con el derecho del público a saber. Un fichero security.txt y una política clara hacen que reportar sea sin fricciones; los programas de bug bounty añaden recompensas estructuradas encima.
Encontrar una vulnerabilidad es solo la mitad del trabajo; conseguir que se corrija sin poner en riesgo a los usuarios es la otra mitad. Los entrevistadores preguntan sobre la divulgación para poner a prueba tu ética y madurez de proceso — un investigador que suelta un zero-day en Twitter es un riesgo, no un activo.
El espectro de la divulgación
- La divulgación completa publica todo de inmediato. Presiona a los fabricantes pero arma a los atacantes antes de que exista un parche.
- La no divulgación mantiene el fallo en secreto. Los defensores nunca llegan a corregirlo, y la «seguridad por oscuridad» falla en cuanto alguien más lo encuentra.
- La divulgación coordinada (responsable) se sitúa en medio y es la opción profesional por defecto: reportar en privado, dar tiempo para corregir y luego publicar.
El proceso coordinado
- Reportar. El investigador contacta al fabricante por un canal conocido — idealmente una política publicada y un fichero security.txt (RFC 9116) que anuncie un contacto y un alcance.
- Acuse de recibo y triaje. El fabricante confirma la recepción, reproduce y evalúa la gravedad (a menudo asignando un CVE).
- Remediar. Ambas partes acuerdan un parche y un plazo de divulgación — comúnmente alrededor de 90 días, ajustable según la complejidad.
- Coordinar la publicación. El parche sale primero; el fabricante y el investigador publican luego los avisos, a menudo dando crédito al reportante.
- Divulgar en el plazo pase lo que pase. Si el fabricante se demora, un plazo acordado de antemano dispara igualmente la publicación, de modo que un fabricante no puede enterrar un fallo para siempre.
Por qué existe el plazo
El plazo protege a los usuarios de dos maneras: detiene la inacción indefinida del fabricante y reconoce que otros pueden descubrir el mismo fallo de forma independiente. Acotar en el tiempo fuerza el avance sin dejar de priorizar un resultado de «corregir primero».
Bug bounties y safe harbor
Los programas de bug bounty formalizan esto con alcance, recompensas y — algo crucial — cláusulas de safe harbor que prometen no emprender acciones legales contra los investigadores de buena fe, que es lo que hace que los investigadores estén dispuestos a reportar.
Qué buscan los entrevistadores
Quieren el punto intermedio coordinado por encima de la divulgación completa o la no divulgación, la secuencia reportar-corregir-publicar, conciencia de los plazos y por qué existen, y los habilitadores prácticos: security.txt, CVE y términos de safe harbor.
Posibles preguntas de seguimiento
- ¿En qué se diferencia la divulgación coordinada de la divulgación completa y de la no divulgación?
- ¿Qué es un fichero security.txt y qué debería contener?
- ¿Por qué los programas de divulgación fijan un plazo incluso cuando el fabricante coopera?