Balas de Plata para Fallos Informáticos

Zapatero a tus zapatos (joder! Vaya frase que he ido a elegir en periodo electoral…) quiero decir, que carpintero a tus carpinters… joder, vale, como dice la canción “si naciste pa martillo del cielo te caen los clavos”. Uff, creo que después de este párrafo nadie tiene ni puta idea de lo que quiero decir. Empecemos otra vez:

Coverity, la empresa encargada de comenzar en enero de 2006 el proyecto bug hunting, ha estado, está y estará analizando el código utilizado en muchos proyectos Open Source. Dicho análisis se realiza desde un punto de vista de seguridad de código (no de seguridad del producto). La herramienta utilizada por Coverity es una Analizador Estático de Código. El funcionamiento de estas herramientas es “sencillo” de entender. La idea principal es tener todos los fallos conocidos que provocan defectos, malfuncionamientos o bugs de seguridad patronizados en una base de datos.

La herramienta se lee el código del producto y busca los patrones dentro del código. Cuando la herramienta no ha encontrado ningún patrón dentro del código analizado, hemos de suponer que el analizador ha terminado su función. ¿Eso quiere decir que la aplicación es segura? Según el titular de la noticia escrita por este escritor, parece que Sí: 11 open-source projects certified as secure

Pero la realizad es que..¡Ni de broma! Por varios motivos:

- El código puede no tener ningún fallo y la aplicación tener cagadas de seguridad en cuando a concepto.

- Los analizadores son aplicaciones que no son perfectas y ninguno reconoce todos los fallos posibles. De hecho, son herramientas magnificas, que aumentan la calidad del software y reducen al mínimo el número de bugs que puede tener un código, pero la perfección está aún lejos. Un programa analizado reducirá más número de bugs cuanto mejor sea el analizador de código utilizado. Spectra utiliza desde al año 2003 un proceso de análisis de código estático (junto con otros de análisis dinámico) dentro del proceso de desarrollo marcado por el SDL y como se ha visto el número de bugs se ha reducido drásticamente, pero… ¿han desaparecido todos los fallos de seguridad? ¿Se puede decir que es seguro todo el código?. Ok, si fuera así, basta con comprar una herramienta y listo.

- Los desarrollos son cambiantes y con cada nueva línea de código metida en un nuevo proyecto se pueden introducir fallos, así que un escaneo solo sirve en un código concreto y deberá ser re-analizado en cada actualización.

- La seguridad cambia. Cada día aparecen nuevas formas de atacar un sistema, nuevas maneras de explotar algo, nuevas formas de saltarse las protecciones. No se pueden conocer los defectos que aún no se han detectado. ¿Cuántos habéis lanzado escanners de vulnerabilidades contra los Retos Hacking y no habéis sacado nada? 11 proyectos con 0 defectos encontrados es algo maravilloso y habla mucho y bien del esfuerzo que se está realizando, pero… tanto como que los proyectos sean seguros…¡Ojala fuera así de fácil el análisis de seguridad!

Si queréis más información de esto, uno que no sabe tampoco mucho de esto, el amigo Michael Howard, escritor de los libros: Writing Secure Code, 19 Deadly Sins of Software Security, The Security Development Lifecycle y Writing Secure Code for Windows Vista lo explica mucho mejor y en menos líneas:

"Open-source projects certified as secure" – huh?

Saludos Malignos!