Desarrolladores: mirando la sustentabilidad del código fuente

Daniel Molina Vice President Of Business Development at Integrated Biometrics, en el día del desarrollador, analiza las herramientas de control de sustentabilidad del código fuente

Daniel Molina Vice President Of Business Development at Integrated Biometrics, en el día del desarrollador, analiza las herramientas de control de sustentabilidad del código fuente

Los desarrolladores requieren contar con escáneres de código estático más amigables para evitar errores no forzados de seguridad

A medida que las empresas “lateralizan su desplazamiento”, imponiendo una mayor responsabilidad de la seguridad a los desarrolladores, las herramientas disponibles a mi juicio se están quedando cortas, según un análisis que realizamos.

Si bien se solicita cada vez más a los programadores que solucionen problemas de seguridad durante el desarrollo.

Los escáneres de seguridad de software comunes, conocidos como herramientas de prueba de seguridad de aplicaciones estáticas (SAST), tienen una variedad de problemas de usabilidad que los hacen menos accesibles para los desarrolladores.

Para los desarrolladores son poco amigables

Las herramientas no proporcionan acciones obvias para administrar los resultados de un análisis o corregir vulnerabilidades, no proporcionan recomendaciones para priorizar la corrección de vulnerabilidades y tenían problemas importantes para escalar para representar una gran cantidad de resultados.

Otros problemas de estas herramientas es que incluyen resultados inexactos y problemas para identificar con precisión en qué parte del software ocurrió el defecto.

Estamos tratando de comprender los problemas de usabilidad específicos que restan valor a las herramientas de análisis estático para que eventualmente podamos construir herramientas más fáciles de usar que reducirán las barreras de entrada y permitirán que más desarrolladores contribuyan a la seguridad.

Foco en la atención

En la actualidad los desarrolladores tienen cada vez más la tarea de asumir la responsabilidad de la seguridad de su código, a menudo obteniendo resultados anteriores de los análisis de seguridad mientras escriben su código.

La forma más simple de tales herramientas son los linters, que llevan el nombre de “lint”, un escáner de código basado en Unix, que utiliza una variedad de coincidencia de patrones y análisis simple para resaltar posibles defectos de código.

Las herramientas de pruebas de seguridad de aplicaciones estáticas (SAST) más amplias realizan una variedad de análisis utilizando el código fuente para identificar posibles vulnerabilidades de seguridad.

Sin embargo, independientemente del rendimiento de las herramientas, su facilidad de uso es a menudo una ocurrencia tardía.

Analizamos tres herramientas: 3 herramientas SAST de código abierto

Todas las herramientas tienen una base de usuarios significativa pero que son lo suficientemente diferentes entre sí.

Esto nos da una base sólida para proporcionar una variedad de problemas potenciales para asimilar.

Entre las herramientas de código abierto que incluímos Find Security Bugs (FSB), un escáner de código Java que puede encontrar 125 tipos diferentes de vulnerabilidades; RIPS, un escáner de aplicaciones PHP que puede encontrar más de 80 tipos diferentes de vulnerabilidades; y Flawfinder, una herramienta de línea de comandos para descubrir código peligroso en C y C ++.

Los dos problemas de usabilidad más comunes para los lectores de código fueron la falta de información sobre los resultados y los próximos pasos.

Además la falla en proporcionar elementos de interfaz intuitivos, o “prestaciones”, para transmitir información de manera simple y eficiente.

El concepto de “prestaciones” es una parte importante del diseño de usabilidad.

Proporcionando elementos que simplemente muestran al usuario las acciones potenciales que puede realizar sin necesidad de conocimientos avanzados de la herramienta o aplicación.

Un escenario común es un elemento de interfaz de usuario de casilla de verificación que puede activar una función.

Varias de las herramientas no proporcionaron buenos elementos de interfaz para administrar la lista de resultados de vulnerabilidad.

La mayoría de las herramientas tampoco proporcionaron acciones simples de apuntar y hacer clic para realizar una corrección recomendada del código.

Mala comunicación

Para servir mejor a los desarrolladores, las herramientas de seguridad deberían comunicar mejor los problemas descubiertos y cómo solucionar las vulnerabilidades.

Además, las herramientas deben agregar más contexto, algo que no me canso de repetir.

Como propiciar el uso de nombres de variables reales, para señalar más claramente los problemas para los desarrolladores.

 

 

Por Daniel Molina – Vice President Of Business Development at Integrated Biometrics