¡Gran pregunta! He escrito algunos de estos, pero siempre tuve una forma muy formal de hacerlo, de modo que nunca tuve la opción de pensar en lo que realmente se necesita ...
Desde la perspectiva de las personas que tienen que usar, respaldar y actualizar su producto, creo que debe cubrir:
-
Información de alto nivel (y un puntero, si es posible, a los detalles), sobre por qué fue necesaria la corrección. Algo así como "el manejo del buffer de cadena corregido en el componente XYZ" es útil.
-
Problemas conocidos: cualquier cosa que no haya podido solucionar y que todavía esté allí.
-
Actualizaciones de software de terceros y un lugar para encontrar la línea de base actual de todo el software de terceros, ya sea que se haya actualizado o no.
En esencia, necesitan saber qué es lo que arreglaste y cuál es tu línea de base. Particularmente en el mundo de Java, puede haber suficientes conflictos y problemas, por lo que una compañía inteligente debe mantener un registro de qué servidores ejecutan qué versiones de las JVM y otros componentes.
Algunas otras respuestas específicas para sus preguntas:
-
¿Deberíamos enumerar las vulnerabilidades corregidas en Apache Httpd? ¿O suficiente enlace al sitio de Apache?
- Un enlace sería una amabilidad. No desordene SUS notas de publicación con los detalles de otros productos.
-
¿Debemos gestionar la lista de software de terceros con versiones?
- Debería estar disponible en algún lugar, no estoy seguro de que tenga que estar en las notas de la versión, pero si no, debería estar en su sitio web en algún lugar.
-
¿Qué pasa con nuestras vulnerabilidades de seguridad internas? ¿Debemos enumerar la lista de vulnerabilidades de seguridad fijas? Puede poner en peligro a aquellos clientes que no se actualicen a la última versión.
- Tenga en cuenta que el hecho de no divulgar vulnerabilidades conocidas podría considerarse una responsabilidad legal. Este es uno para sus abogados. En mi opinión, decirles a los clientes que sepan por qué que una solución de seguridad es tan importante es más que compensar el valor de ocultarla por la seguridad de aquellos que no pueden realizar la actualización lo suficientemente rápido. Dicho esto, no tiene que decir "si X, Y, Z obtendrá privilegios de administrador". Decir "vulnerabilidad dañada en el sistema de control de acceso" debería ser lo suficientemente bueno.
-
¿Cómo debemos anunciar las vulnerabilidades de seguridad? ¿Deberíamos agregar nuestro proveedor a la base de datos de CVE enlace y crear un nuevo CVE cada vez que lo encontremos? ¿O es suficiente para enumerar nuestro número de error interno?
- No estoy realmente seguro de lo que quiere decir con "nuestro proveedor". Personalmente, no registraría a un tercero para los hallazgos de CVE sin estar de acuerdo con ellos.
-
¿Deberíamos agregar a la base de datos CVE solo las vulnerabilidades descubiertas por nuestros clientes? ¿Deberíamos agregar a la base de datos CVE también las vulnerabilidades descubiertas por el control de calidad?
- Todavía no he oído hablar de ningún proveedor que utilice CVE para la documentación de prueba / corrección interna. Creo que si lo encontraste primero, enlazar a tu propio repositorio de errores corregidos debería estar bien, pero no he hecho tanto software comercial.