Seguridad de Software de Código Abierto

• Más personas pueden inspeccionar el código fuente para encontrar y solucionar una posible vulnerabilidad. Esto puede llevar tanto al descubrimiento de vulnerabilidad de seguridad intencional rápidamente como a la prevención de vulnerabilidades intencionales (puertas traseras) localizadas en el código, el cual es puesto allí por los propios desarrolladores.
• El Software propietario obliga al usuario a aceptar el nivel de seguridad que el proveedor de software está dispuesto a ofrecer y a aceptar la cantidad de "parches" y actualizaciones disponibles.[1]
• El usuario final del código abierto tiene la capacidad de cambiar y modificar la fuente para implementar cualquier "característica" extra de seguridad que quiera para un uso específico, que puede extenderse hasta el nivel de kernel si así lo desea.
• Se asume que cualquier compilador que es utilizado crea código confiable, pero se ha demostrado por Ken Thompson que un compilador puede ser subvertido utilizando un Thompson hack para crear ejecutables defectuosos que se producen involuntariamente por un desarrollador sin malas intenciones.[2] Con el acceso al código fuente para el compilador, el desarrollador tiene por lo menos la capacidad de descubrir si hay alguna mala intención.
  • David A. Wheeler demuestra que la existencia de dos diferentes compiladores de auto-compilación de código abierto (que deben de ser capaz de compilar entre sí) se puede utilizar para establecer un binario para uno de ellos que es conocido por no ser subvertido por el Thompson hack.[3]
• El principio de Kerckhoffs se basa en la idea de que un enemigo puede robar un sistema militar seguro, pero no es capaz de poner en peligro la información. Sus ideas fueron la base para muchas de las prácticas modernas de seguridad , y dice que la seguridad por obscuridad son malas prácticas.[4]

• Los atacantes pueden encontrar vulnerabilidades más fáciles con el código fuente.
• Simplemente, al crear un código fuente no se garantiza que exista una revisión. Un buen ejemplo de que esto ocurre fue cuando Marcus Ranum, un experto en el diseño de sistemas de seguridad y aplicaciones, lanzó su primer kit de herramientas firewall públicas. Hubo una época en la que había más de 2,000 sitios que usaban este kit de herramientas, pero solo 10 personas dieron algún comentario de retroalimentación o algún parche.[5]
• Tener una gran cantidad de ojos revisando el código puede "hacer que un usuario tenga una falsa sensación de seguridad".[6] Tener muchos usuarios mirando el código fuente no garantiza que los problemas de seguridad se vayan a encontrar y arreglar.

Se discute que un sistema es más vulnerable después de que se descubre una vulnerabilidad potencial, pero antes de que se ponga un parche. Al medir el número de días entre la vulnerabilidad, cuando la vulnerabilidad es arreglada, se puede determinar una base en la seguridad del sistema. Hay algunas advertencias en este enfoque: no toda vulnerabilidad es igual de mala; arreglar muchos errores rápidamente puede ser peor que buscar y arreglar solamente unos pocos y que se tome un poco más de tiempo en cada uno de ellos, tomando en cuenta el sistema operativo o la efectividad del parche.[2]

El proceso de Poisson se puede utilizar para medir las tasa de cambio con la que diferentes personas encuentran fallos de seguridad entre el software de código abierto y cerrado. El proceso puede ser dividido entre el número de voluntarios N_v y revisores pagados N_p. Las tasas de cambio con la que los voluntarios encuentran un defecto se mide por λ_v y la tasa con la que revisores pagados se encuentran un defecto se mide por λ_p. El tiempo que se espera para que un grupo de voluntarios encuentre un error es 1/(N_v λ_v) y el tiempo que se espera para que un grupo pagado encuentre un defecto es 1/(N_p λ_p).[2]

Mediante la comparación de una gran variedad de códigos abiertos y cerrados con un sistema de estrellas, se puede analizar la seguridad del proyecto, similar a la empresa Morningstar, Inc. la cual valora los fondos de inversión. Con un conjunto de datos suficientemente grande, las estadísticas se podrían utilizar para medir la eficacia global de un grupo sobre otro. Un ejemplo de como funciona el sistema es el siguiente:[7]

• 1 Estrella: Muchas vulnerabilidades de seguridad.
• 2 Estrellas: Problemas de fiabilidad.
• 3 Estrellas: Sigue las mejores prácticas de seguridad.
• 4 Estrellas: Proceso documentado de desarrollo de seguro.
• 5 Estrellas: Pase de revisión de seguridad independiente.

Coverity en colaboración con la Universidad de Stanford ha establecido un nuevo punto de referencia para la calidad y seguridad del código abierto. El desarrollo se completa a través de un contrato con el Departamento de Seguridad Nacional. Ellos están utilizando las innovaciones en la detección automática de defectos para identificar los tipos de errores críticos encontrados en el software.[8] El nivel de calidad y de seguridad se mide en los escalones. Los escalones no tienen un sentido definitivo, y pueden cambiar a medida que Coverity lanza sus nuevas herramientas. Los escalones se basan en el progreso de desarrollo de parches encontrados en los resultados del análisis de Coverity y con el grado de colaboración, en conjunto con Coverity.[9] Comienzan con el escalón 0 y actualmente llega al escalón 2.

• Escalón 0

El proyecto ha sido analizado por la infraestructura de escaneo de Coverity, pero no hay representantes del software de código abierto que se hayan presentado a revisar los resultados.[9]

• Escalón 1

En el escalón 1, existe colaboración entre Coverity y el equipo de desarrollo. El software se analiza con un subconjunto de funciones de escaneado para evitar que el equipo de desarrollo sea abrumado.[9]

• Escalón 2

Hay 11 proyectos que se han analizado y actualizado a la condición de escalón 2 al llegar a no tener ningún defecto en el primer año de exploración. Estos proyectos incluyen: AMANDA, ntp, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, y tcl.[9]