Por qué las herramientas SAST que priorizan a los desarrolladores son el futuro de la seguridad del código

La seguridad de las aplicaciones abarca un amplio campo para los equipos que crean y lanzan aplicaciones nativas de la nube. El panorama incluye numerosos procesos, herramientas y miembros del equipo, desde la automatización de pipelines seguros (hola, DevSecOps) hasta la seguridad de código abierto y las pruebas de seguridad de la infraestructura en la nube. Algunas de estas metodologías de pruebas de seguridad de aplicaciones se enfocan en la seguridad del código y se conocen oficialmente como herramientas de pruebas estáticas de seguridad de aplicaciones (SAST), a veces llamadas herramientas de análisis estático de código.

Si no conoces el término técnico SAST, empecemos con una introducción a los conceptos básicos y luego veamos cómo las herramientas SAST que priorizan a los desarrolladores darán forma a toda la industria de la seguridad.

¿Qué son las herramientas SAST?

Las herramientas SAST son herramientas de pruebas estáticas de seguridad de aplicaciones que analizan el código fuente para ver cómo fluyen los datos desde posibles vectores de entrada del usuario hasta operaciones sensibles de la interfaz de programación de aplicaciones. Por ejemplo, una herramienta SAST puede identificar si una entrada del usuario en un cuadro de búsqueda podría activar una función relacionada con la base de datos que ejecuta una consulta de forma insegura, sin sanitizar y no prevista (es decir, una vulnerabilidad de seguridad de inyección SQL).

Las herramientas SAST tradicionales y por qué fracasaron

Las pruebas estáticas de seguridad de aplicaciones no son un concepto nuevo. De hecho, hace décadas que muchas herramientas y empresas incursionaron en este campo. Para entender cómo será el futuro de la seguridad del código, primero debemos ver cómo funcionan las herramientas SAST tradicionales y por qué no se adoptaron de forma más generalizada, como esperábamos.

Las herramientas SAST tradicionales tardan mucho en ejecutarse

En los equipos tradicionales de seguridad y DevOps, no es raro escuchar comentarios como «La herramienta SAST está tardando demasiado» o «¿Integración continua? ¡Más bien, espera continua a que termine la herramienta SAST!». Se había vuelto normal que las herramientas SAST tardaran horas o incluso días en la fase de compilación o de integración continua (CI), mientras analizaban los repositorios de código fuente.

Se han hecho algunos ajustes para responder a la necesidad de obtener resultados más rápido, como trabajar con diferencias en el código fuente o programar el trabajo de CI de SAST para que se ejecute de noche o el fin de semana. Sin embargo, estas son soluciones temporales que indican que una herramienta es inadecuada y no puede adaptarse a los procesos y las expectativas del desarrollo moderno.

Por lo general, la seguridad no se integra en el lugar adecuado del SDLC

Para solucionar el ciclo de retroalimentación tardía que mencionamos, las herramientas SAST se habían implementado como un proceso de CI independiente, para no bloquear a los desarrolladores con análisis de larga duración. Pero este error de integrar herramientas SAST en un proceso de CI va totalmente en contra de la intención original, ya que las herramientas SAST deberían poder enfocarse en el código fuente. Eso significa que las herramientas SAST deberían usarse durante el desarrollo del software, en lugar de ser una medida posterior que solo se revisa en CI.

Integrar herramientas de seguridad en los procesos de compilación e integración continua es una excelente manera de incorporar la seguridad. Sin embargo, para no afectar la productividad de los desarrolladores, estas herramientas deben ser rápidas y ofrecer comentarios prácticos.

Los falsos positivos llevan al abandono de las herramientas SAST

Otro problema importante para quienes adoptan SAST es la precisión o, más específicamente, la falta de ella. Las herramientas SAST tradicionales suelen generar demasiadas alertas falsas, lo que provoca demasiadas notificaciones innecesarias. Las alertas de seguridad requieren toda la atención de los desarrolladores y, cuando muchas de estas notificaciones son falsas, el desarrollo real se ralentiza.

Los falsos positivos generan frustración y antagonizan al equipo de seguridad de las aplicaciones. En última instancia, esto lleva a los desarrolladores a ignorar todas las alertas de seguridad y abandonar por completo la herramienta.

Las herramientas SAST tradicionales pueden encontrar problemas, pero no corregirlos

Por último, cuando los hallazgos de una herramienta SAST son precisos, aun así no te dicen cómo resolver el problema. La causa está en cómo se diseñaron las herramientas SAST desde el principio. Originalmente, se crearon pensando en el equipo de seguridad, AppSec y perfiles similares. Esto significaba que los hallazgos podían carecer de contexto sobre el flujo de ejecución o simplemente informar el problema con un código CWE (Common Weakness Enumeration, una descripción de una posible vulnerabilidad). Pero si no eras especialista en seguridad, una herramienta SAST no te ayudaría a corregir el problema ni a solucionar la vulnerabilidad.

Quienes podían resolver los problemas de seguridad eran especialistas expertos en seguridad de aplicaciones y su comunidad, lo que creó otro cuello de botella para abordar la seguridad. También generó más frustración para los desarrolladores, que recibían los resultados del análisis de una herramienta SAST, pero no podían actuar para resolver los problemas.

Las herramientas SAST modernas que priorizan a los desarrolladores deben aumentar su productividad

En esencia, una herramienta SAST se enfoca en la seguridad del código. Las herramientas SAST encuentran problemas como la exposición de datos sensibles, la inyección SQL, la inyección de código y otros tipos de vulnerabilidades. ¿Quién introdujo estos problemas de seguridad? Desarrolladores como tú y yo. Entonces, ¿quién debería corregirlos? Así es: también deberían hacerlo los desarrolladores.

Priorizar a los desarrolladores es el ingrediente secreto de las mejores herramientas SAST, y así es como Snyk está revolucionando el campo de la seguridad de las aplicaciones. Snyk tiene sus raíces en una mentalidad que prioriza a los desarrolladores.

Veamos qué se necesita para que una herramienta SAST ofrezca una experiencia de seguridad productiva para los desarrolladores.

Seguridad del código integrada en los flujos de trabajo de los desarrolladores

Si los desarrolladores son esenciales para corregir las vulnerabilidades de seguridad, una característica clave de una herramienta SAST es que se integre de la manera más sencilla posible para ellos.

¿Dónde pasan la mayor parte del tiempo los desarrolladores (además de Google y StackOverflow)?

1. En su IDE, como IntelliJ o Visual Studio Code

2. En la interfaz de línea de comandos (CLI), donde pueden interactuar con sus repositorios Git, ejecutar comandos, depurar y administrar el código fuente y las rutinas de sus proyectos

3. En las revisiones de código

Para que se adopten, las herramientas SAST deben ayudar a los desarrolladores a encontrar y resolver problemas de seguridad directamente en las herramientas que ya usan. Además, los resultados deben ofrecer un contexto completo para que los desarrolladores puedan encontrar y corregir las vulnerabilidades de seguridad en su código.

Para quienes pasan el día en un IDE, aquí tienes un ejemplo de la herramienta SAST Snyk Code en acción, que muestra cómo luce una integración fluida de las herramientas de seguridad:

A la izquierda aparece una lista de posibles vulnerabilidades derivadas de prácticas de codificación segura deficientes. A la derecha del panel inferior, se muestra el contexto a nivel de línea que explica cómo se manifiesta un flujo de datos vulnerable y cómo se puede explotar.

Si eres desarrollador y te gusta pasar la mayor parte del tiempo en interfaces de terminal, una interfaz de línea de comandos podría ser más adecuada para ti. En este caso, puedes usar la CLI de Snyk Code para estos fines.

De hecho, si te gustan los hooks de Git, como ejecutar un linter, una suite de pruebas u otras automatizaciones antes de que los desarrolladores confirmen o suban su código, también puedes usar la CLI de Snyk para estos fines.

A continuación, se muestra el resultado de ejecutar una prueba de seguridad del código con la CLI de Snyk en el mismo proyecto:

❯ snyk code test

Testing /Users/lirantal/projects/repos/goof ...

 ✗ [Medium] Cleartext Transmission of Sensitive Information
     Path: Users/lirantal/projects/repos/goof/app.js, line 12
     Info: http (used in require) is an insecure protocol and should not be used in new code.

 ✗ [Medium] Information Exposure
     Path: Users/lirantal/projects/repos/goof/app.js, line 27
     Info: Disable X-Powered-By header for your Express app (consider using Helmet middleware), because it exposes information about the used framework to potential attackers.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 77
     Info: This endpoint handler performs a system command execution and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 166
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 223
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [High] SQL Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 39
     Info: Unsanitized input from the HTTP request body flows into find, where it is used in an SQL query. This may result in an SQL Injection vulnerability.

 ✗ [High] Command Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 86
     Info: Unsanitized input from the HTTP request body flows into child_process.exec, where it is used to build a shell command. This may result in a Command Injection vulnerability.

 ✗ [High] Cross-site Scripting (XSS)
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 109
     Info: Unsanitized input from the HTTP request body flows into send, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS).

✔ Test completed

Test type:         Static code analysis
Project path:      /Users/lirantal/projects/repos/goof

8 Code issues found
3 [High]  5 [Medium]

Resultados de análisis de seguridad en tiempo real

Para que una herramienta SAST sea compatible con cualquiera de los flujos de trabajo de desarrollo mencionados, debe ser lo suficientemente rápida para ofrecer resultados de análisis de seguridad en tiempo real. La velocidad permite practicar la codificación segura desde el inicio. Esto significa que los desarrolladores pueden encontrar y corregir problemas de seguridad mientras escriben código, en lugar de esperar a que el equipo de seguridad o una integración de DevSecOps los detecte después de subir el código. Esto último podría generar más frustración, ya que habría que refactorizar el código, lo que provocaría cambios innecesarios y ralentizaría el proceso de lanzamiento.

Nuestro enfoque sin fricciones para la codificación segura hace que Snyk Code sea único y le permite destacarse como herramienta de análisis estático de código para la seguridad. ¿Qué tan rápido es Snyk Code? Pruébalo y compruébalo por tu cuenta.

Alta precisión y pocos falsos positivos

Los flujos de trabajo integrados y los ciclos de retroalimentación rápidos son importantes, pero un factor que suele pasarse por alto para ofrecer una buena experiencia a los desarrolladores son los datos en sí.

Los desarrolladores deben confiar en sus herramientas para adoptarlas por completo e integrarlas en sus flujos de trabajo. La calidad de los datos de seguridad que reporta una herramienta SAST determinará si los desarrolladores la integran con confianza o la abandonan debido a la gran cantidad de falsos positivos.

Para alcanzar una precisión líder en la industria, Snyk Code cuenta con aprendizaje automático entrenado con problemas reales de seguridad del código de todos los proyectos de código abierto en GitHub. Así, puede aplicar esos conocimientos para identificar patrones en tu propio código. Para seguir entrenando estos modelos de aprendizaje automático, el motor de IA de Snyk Code se basa en la base de datos de vulnerabilidades propia de Snyk, seleccionada cuidadosamente de forma manual, y en commits de referencia como conjunto de entrenamiento. Todo esto ayuda a reducir significativamente los falsos positivos.

Ayudar a los desarrolladores a corregir problemas de seguridad del código

Un hilo de StackOverflow es el mejor amigo de un desarrollador, ¿verdad? Es broma, pero no del todo: los desarrolladores valoran los ejemplos útiles en los que otras personas muestran cómo resolver problemas de código. Entonces, ¿por qué debería ser diferente con los problemas de seguridad?

Veamos un ejemplo en el que una herramienta SAST detecta una posible vulnerabilidad de inyección de comandos, a menudo identificada como CWE-78: neutralización incorrecta de elementos especiales utilizados en un comando del sistema operativo («inyección de comandos del sistema operativo»). Es un término complicado, ¿verdad? Por lo general, los desarrolladores no tienen los conocimientos de seguridad necesarios para entender los CVE y CWE, su impacto o incluso cómo corregirlos siguiendo prácticas de codificación segura. Ese es el problema que Snyk se propuso resolver.

Es muy posible que, como desarrollador, no tengas conocimientos de seguridad para corregir este problema de inyección de comandos en la línea 86, que usa una API insegura de Node.js: exec(). Entonces, ¿qué harías si recibieras un informe de seguridad que te lo señalara?

Esta es otra área en la que Snyk Code supera a las herramientas SAST tradicionales: te ayuda a resolver los problemas de seguridad del código que detecta. En la esquina inferior derecha de la siguiente captura de pantalla del IDE IntelliJ, puedes ver que, para este proyecto de Node.js, Snyk Code muestra diferencias entre commits de varios proyectos de código abierto que resuelven el problema de inyección de código detectado aquí.

Con esta información, los desarrolladores pueden ver cómo otras personas han corregido problemas de seguridad similares. Este contexto más amplio sobre la solución sugerida les permite tomar una decisión más informada.

Resumen

En conclusión, los desarrolladores necesitan una herramienta SAST que encuentre problemas de seguridad tanto en su código como en las dependencias de código abierto que usan. Además, su herramienta SAST debe poder recomendar correcciones prácticas para las vulnerabilidades que detecte. Para que se adopte, también debe ser rápida y precisa, e integrarse con las herramientas y los flujos de trabajo de los desarrolladores. Puede parecer mucho pedir, pero una herramienta SAST que priorice a los desarrolladores necesita contar con todas estas capacidades para ser eficaz; y precisamente por eso Snyk Code ofrece todas estas funciones. Consulta nuestra guía de compra de SAST para elegir la herramienta SAST adecuada para tu organización.

¿Llegaste hasta aquí y te interesa saber cómo se relacionan las pruebas SAST y DAST?

¿Qué son las pruebas SAST y DAST?

SAST es el análisis estático de seguridad de aplicaciones. Para realizar un análisis de origen a destino y detectar posibles vulnerabilidades de seguridad o debilidades en función del flujo de datos, una herramienta solo necesita el código fuente de la aplicación. DAST, al ser un procedimiento dinámico de análisis de seguridad de aplicaciones, requiere que la aplicación esté activa y en ejecución en un entorno adecuado. Así, la herramienta puede observar el tráfico, rastrear la página web y, en general, automatizar la interacción con la aplicación para determinar si es vulnerable a problemas de seguridad. Obtén más información sobre SAST vs. DAST: cuál es la diferencia y cómo combinar ambos.