Los desarrolladores necesitan escáneres de código estático más utilizables para …



A medida que las empresas «se desplazan a la izquierda», imponiendo una mayor responsabilidad de la seguridad a los desarrolladores, las herramientas disponibles se están quedando cortas, dicen los investigadores de usabilidad.

Si bien a los programadores se les pide cada vez más que solucionen problemas de seguridad durante el desarrollo, los escáneres de seguridad de software program 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, según una investigación presentada en USENIX. Simposio sobre privacidad y seguridad utilizables (SOUPS) el 11 de agosto.

La investigación, realizada por investigadores de Lafayette College or university y Google, descubrió que las herramientas no proporcionaron acciones obvias para administrar los resultados de un análisis o corregir vulnerabilidades, no proporcionaron recomendaciones para priorizar la corrección de vulnerabilidades y tenían problemas importantes para escalar para representar un gran número de resultados. Otros problemas incluyeron resultados inexactos y problemas para identificar con precisión en qué parte del software program ocurrió el defecto.

La investigación no pretende señalar esas herramientas específicas, sino identificar problemas comunes en los escáneres de código estático que podrían impedir que los desarrolladores puedan acceder a ellos, dijo Justin Smith, profesor asistente de ciencias de la computación en Lafayette College or university, durante su sesión digital en el simposio. .

«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», dijo.

La investigación se deliver cuando 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 basic 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 easy para resaltar posibles defectos de código. Las herramientas de prueba de seguridad de aplicaciones estáticas (SAST) más amplias realizan una variedad de análisis utilizando código fuente para identificar posibles vulnerabilidades de seguridad.

Sin embargo, independientemente del rendimiento de las herramientas, su facilidad de uso suele ser una ocurrencia tardía, dijo Smith, quien realizó la investigación mientras period estudiante de doctorado en la Universidad Estatal de Carolina del Norte. El periódico, titulado «Por qué Johnny no puede arreglar las vulnerabilidades: una evaluación de usabilidad de las herramientas de análisis estático para la seguridad, «explain un método de recorrido heurístico para analizar el software package, así como una encuesta a los usuarios.

«Muchas veces, cuando la gente diseña estas herramientas de análisis estático, su prioridad es ayudarles a encontrar un problema», dijo. «Pero esa mentalidad los lleva a construir los escáneres que encuentran cientos de problemas y no hacen que sea muy fácil solucionarlos. Por lo tanto, al alentar a las personas a realizar estos recorridos heurísticos económicos o evaluaciones de usabilidad, pueden ver sus herramientas desde una perspectiva diferente «.

Los investigadores se centraron en cuatro herramientas: tres herramientas SAST de código abierto y una herramienta comercial. Seleccionaron herramientas que tenían una foundation de usuarios significativa pero que son lo suficientemente diferentes entre sí como para proporcionar una variedad de problemas potenciales para estudiar. Los investigadores consideraron 61 herramientas diferentes, pero se decidieron por los cuatro programas SAST para permitir encontrar una variedad de problemas y porque tenían interfaces de usuario lo suficientemente complejas como para tener problemas potenciales.

Las herramientas de código abierto incluyeron Obtain 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 ++. La única herramienta comercial no se mencionó en la investigación debido a los requisitos del acuerdo de licencia.

«Estábamos tratando de seleccionar diferentes tipos de interfaces de usuario», dijo Smith. «Podríamos haber elegido cuatro herramientas de linter que tuvieran todas las mismas interfaces, pero una vez que llegamos a la cuarta (linter), es probable que no encontremos nuevos problemas de usabilidad».

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 y la falla en proporcionar elementos de interfaz intuitivos, o «prestaciones», para transmitir información de manera basic 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.

Para servir mejor a los desarrolladores, las herramientas de seguridad deben comunicar mejor los problemas descubiertos y cómo solucionar las vulnerabilidades, así como colocar tales alertas dentro del editor de código, para evitar cambiar entre dos contextos, afirmaron los investigadores en su artículo. Además, las herramientas deben agregar más contexto, como el uso de nombres de variables reales, para marcar más claramente los problemas para los desarrolladores.

contenido relacionado

Periodista tecnológico veterano de más de 20 años. Ex ingeniero de investigación. Escrito para más de dos docenas de publicaciones, incluidas CNET Information.com, Dim Looking through, MIT&#39s Technologies Evaluation, Popular Science y Wired Information. Cinco premios de periodismo, incluido el de Mejor fecha límite … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia authentic