métricas de seguridad en softwares desarrollados

Diga que todas las métricas que anotó en su pregunta indican cero. ¿Eso significa que su software es seguro? ¿Encontrar 0 errores significa que no hay errores?

La razón por la que le cuesta mucho encontrar métricas de solo software es porque el software no existe en un vacío. Aquí hay una pregunta que es igual de difícil: ¿Cuánto vale una pieza de software ?

Hay varias preguntas que me gustaría preguntar si alguien me entregó un informe con las métricas que enumeró aquí.

¿Con qué políticas de seguridad se comparan sus métricas? Por mucho que desprecie el tema (BOOOOORING !!!!), la seguridad en cualquier organización, y por lo tanto su software, debe basarse en una política de seguridad sólida. Y concentrarse en el software solo como quiere hacer en su pregunta es eludir una pieza que no debería ser eludir. Y tenga en cuenta que las políticas pueden determinar cuán graves son ciertos errores en comparación entre sí.

Dicho esto:

OWASP tiene una presentación here que te pueda interesar.

Advertencias de la presentación: Métricas de seguridad del software

• Las métricas son sensibles al contexto y dependen del entorno
• dependiente de la arquitectura
• La agregación puede no llevar a la fortaleza

Aquí hay algunas métricas que listan:

• Tamaño y complejidad
• Debilidad / LOC (CWE)
• Debilidad (gravedad, tipo) a lo largo del tiempo (CVSSv2, CWE)
• Costo por defecto
• Superficie de ataque (# de interfaces)
• Capas de seguridad
• defectos de diseño (CWE)

Y este documento , aunque no es una referencia única, sí presente un método para ponderar tipos específicos de fallas de seguridad, que podrían usarse para desarrollar un sistema de puntuación que pueda aplicar a los desarrolladores / aplicaciones.

Y, por último, una estadística muy importante que creo que debería tener en cuenta es el número de falsos positivos, tanto por herramientas de prueba como por evaluadores humanos.

Y luego está CVSS .

Andy Ozment ha propuesto una métrica de seguridad interesante para el software en su artículo Bug Auction: Reconsideración de mercados de vulnerabilidad (WEIS 2004) . En términos generales, su idea es que un proveedor de software establezca un premio por la próxima vulnerabilidad que se encuentre. El premio comienza desde una cantidad fija (por ejemplo, 100 $) y crece cada día (por ejemplo, 10 $ / día). Cuando un cazador de vulnerabilidades (sombrero blanco / negro) encuentra una nueva vulnerabilidad, se le otorga la cantidad actual de dinero y el premio se devuelve a la cantidad inicial y vuelve a crecer. Ahora, después de un tiempo, el proveedor de software puede usar el premio actual como la métrica de seguridad para su software . Entonces, si el premio ahora es de 10000 $, significa que incluso con este incentivo, los cazadores aún no pueden encontrar una nueva vulnerabilidad y, por lo tanto, el software es bastante seguro. Hay algunos análisis económicos en el documento para mostrar las ventajas y desventajas de esta idea.

El documento también tiene algunas citas relacionadas con las métricas de seguridad del software que podrían ser útiles para usted. Aunque podrían ser viejos.

Gracias.