La forma "normal" de hacer las cosas es:
- Quienquiera que descubra la falla contacta al proveedor.
- El proveedor crea el parche y lo publica, enviándolo a los clientes con una descripción vaga pero aterradora ("corrige un defecto que permite la ejecución remota de código").
-
Unas semanas más tarde , se publican los detalles. Si todo salió bien, el descubridor inicial hace la publicación, en total acuerdo con el proveedor, para que se atribuyan los créditos debidos; y el proveedor agrega un enlace a los detalles de la publicación en su propia documentación.
Por ejemplo, esto es lo que ocurrió con el error relacionado con SSL denominado "CRIME": se advirtió a los proveedores de navegadores con varias semanas de antelación y se enviaron parches. Ocasionalmente, la descripción vaga puede ser suficiente para que algunas personas adivina lo que está pasando unos días antes de la publicación real. El baile es una cuestión de delicadeza, especialmente con el software de código abierto, porque el parche código fuente a menudo es bastante revelador sobre la naturaleza exacta del problema.
Un aspecto psicológico del problema es que los cazadores de vulnerabilidades son una multitud dura que puede reaccionar, a veces, de una manera emocional acalorada, si sienten que los proveedores no reaccionan de manera adecuada o lo suficientemente rápida. Los proveedores de software generalmente prefieren mantener los defectos en secreto, pero si tienen que aceptar la publicación, entonces, al menos, realmente prefieren tener alguna advertencia previa. El "trueque de créditos por advertencia previa" es un acuerdo que tiene una alta probabilidad de convencer a la mayoría de los cazadores de errores no para impulsar el exploit de inmediato en los canales públicos, por lo que los proveedores de software apoyarán esta "forma normal ".
En última instancia , cuando el polvo se haya asentado, todos los detalles deben publicarse, ya que la divulgación completa es una excelente base para la confianza.
