SAST y SCA: juntos son mejores con Snyk

A medida que las aplicaciones se vuelven más complejas, también lo hace la tarea de protegerlas.

Aunque el código fuente de las aplicaciones incluye código propietario, gran parte también es código abierto de terceros. Por eso, los equipos de desarrollo y seguridad que buscan lanzar código seguro sin dejar de mantener un ritmo de desarrollo ágil deben combinar las pruebas de seguridad de aplicaciones estáticas (SAST) y el análisis de composición de software (SCA) como parte de una estrategia integral de seguridad de software.

Pero es más fácil decirlo que hacerlo.

Como estrategia de pruebas más antigua y consolidada, SAST ha sido tradicionalmente el enfoque lógico para empezar en la seguridad de aplicaciones. Los profesionales pueden elegir entre una gran variedad de herramientas SAST, con metodologías y prácticas recomendadas bien documentadas. Sin embargo, las soluciones SAST tienen una mala reputación en cuanto a velocidad, precisión y facilidad de uso en general. Estos aspectos negativos pueden disuadir a un equipo de usar SAST o llevarlo a elegir SCA en su lugar.

Las soluciones tradicionales de SCA no son muy distintas: su historial incluye integraciones difíciles y una alta tasa de falsos positivos. Aunque las vulnerabilidades en paquetes de código abierto han puesto a SCA en el centro de atención, su adopción sigue siendo limitada: apenas el 38 % de las organizaciones confirma que usa controles de seguridad para código abierto. Además, aunque analizan tus dependencias (y las dependencias de estas), las herramientas de SCA no pueden detectar vulnerabilidades en el código que escribes.

Pero usar SAST y SCA de forma independiente va en contra de la creciente preferencia de las organizaciones por reducir la proliferación de herramientas y consolidar las herramientas de seguridad de aplicaciones. Por eso, el razonamiento suele ser SAST o SCA, en lugar de considerar SAST y SCA como parte de un enfoque combinado.

En esta publicación, veremos por qué SAST y SCA son el enfoque adecuado y cómo implementar ambos sin aumentar la cantidad de herramientas.

¿Cuál es la diferencia entre SAST y SCA?

Entender la diferencia entre SAST y SCA es clave para adoptar un enfoque combinado.

¿Para qué se usa SAST?

SAST es una metodología estructural de pruebas de seguridad de aplicaciones que analiza el código fuente o el código de bytes de una aplicación para detectar vulnerabilidades de seguridad, como las del Top 10 de OWASP y las CWEs. Además del código fuente o de bytes, puede evaluar otros recursos, como documentación y especificaciones. Las herramientas modernas de SAST transforman el código original en una representación intermedia y realizan varios tipos de pruebas mediante un conjunto de reglas que suele ejecutarse en un solucionador lógico.

La ventaja de SAST es que abarca todas las rutas y los estados posibles de una aplicación, e incluso detecta errores que los desarrolladores no buscaban inicialmente. Cuando se detectan, estos problemas deben señalarse con su ubicación precisa o la ruta que recorren en la aplicación, incluidos los nombres de archivo y los números de línea, además de información adicional sobre el problema.

Una desventaja de las herramientas SAST tradicionales es que sus proveedores deben encontrar un equilibrio entre mostrar los problemas reales, mostrar todos los problemas posibles y los recursos de cómputo que se utilizan. Por lo tanto, las herramientas representan un compromiso: sobreestiman el comportamiento de las aplicaciones y aceptan cierta cantidad de falsas alarmas y problemas no detectados a cambio de ahorrar tiempo de cómputo. Aun así, analizar proyectos grandes con herramientas SAST tradicionales puede tomar días o incluso semanas.

¿Para qué se usa SCA?

Las aplicaciones modernas dependen de decenas, si no cientos, de paquetes de código abierto, que suelen llamarse dependencias. De hecho, el 98 % de las aplicaciones contiene software de código abierto. A su vez, estas dependencias dependen de otros paquetes de código abierto, llamados dependencias transitivas. Los paquetes de código abierto cubren una gran variedad de tareas, desde las más sencillas, como dar formato al texto, hasta otras más complejas, que abarcan frameworks y entornos de ejecución.

Una práctica recomendada habitual es tratar los paquetes de código abierto como una unidad. Es válido corregir o modificar el código siempre que los cambios se aporten al paquete y se incorporen a este. Los cambios locales rompen el versionado del paquete y pueden sobrescribirse al descargar una nueva versión.

SCA es una metodología de seguridad de aplicaciones que se centra en analizar las dependencias de código abierto que usan las aplicaciones, ya sea de forma directa o indirecta, y correlacionar este análisis con datos de vulnerabilidades para rastrear cualquier vulnerabilidad de seguridad conocida que puedan incluir. Cuando se detectan, estas vulnerabilidades se marcan con información sobre ellas y, en algunos casos, también con la solución recomendada. Es importante destacar que SCA también ayuda a identificar los riesgos legales derivados del uso de código abierto, al detectar las licencias incluidas en los paquetes.

Por qué usar SAST y SCA en conjunto

Según las diferencias funcionales entre ambas metodologías de pruebas, queda claro que compararlas directamente no tiene sentido.

Aunque comparten algunos aspectos, como implementarse al inicio del proceso de desarrollo y analizar el código fuente, abarcan dos tipos distintos de código que conforman una aplicación: SAST ayuda a mitigar los riesgos del código escrito internamente, mientras que SCA ayuda a mitigar los riesgos del código escrito fuera de la organización.

Por lo tanto, un enfoque eficaz de seguridad de aplicaciones debe incluir herramientas de pruebas de seguridad capaces de gestionar y mitigar ambos tipos de riesgo. Este enfoque ofrece visibilidad integral del código propietario y los componentes de código abierto, permite identificar y corregir problemas antes y a lo largo del ciclo de vida del desarrollo y, en general, minimiza los riesgos.

Requisitos clave para un enfoque combinado

Optar por un enfoque combinado no es una decisión sencilla, y la implementación de SAST y SCA como parte de un programa de seguridad de aplicaciones puede presentar desafíos culturales y técnicos.

El modelo DevSecOps requiere que los desarrolladores asuman más responsabilidad por la seguridad, pero las experiencias pasadas y actuales con soluciones tradicionales dificultan que adopten una metodología de pruebas, y mucho más dos. Algunos equipos pueden mostrarse reacios a agregar otra herramienta de seguridad a las que ya usan.

Una solución sencilla podría ser integrar las herramientas SAST y SCA en el pipeline de CI/CD y enviar los hallazgos a los desarrolladores. Pero esto separa el proceso y obliga a esperar a que terminen los análisis y se apliquen las correcciones antes de realizar los despliegues. En el mundo ágil de DevOps, retrasar un lanzamiento durante semanas simplemente no es viable.

Por eso, para que un programa combinado de seguridad de aplicaciones tenga éxito, debe contar ante todo con soluciones fáciles de usar para los desarrolladores. Es más probable que usen herramientas SAST y SCA que se integren rápida y fácilmente en sus flujos de trabajo actuales desde las primeras etapas del desarrollo que herramientas lentas, difíciles de usar y que solo pueden implementarse en etapas posteriores.

Además, un flujo de trabajo consolidado en el que los análisis SAST y SCA se ejecuten al mismo tiempo o desde una misma herramienta reduce la complejidad para los desarrolladores y los costos generales para los equipos de seguridad.

El enfoque de Snyk: Snyk Code y Snyk Open Source

La plataforma de Snyk ofrece un enfoque combinado de seguridad de aplicaciones con SAST y SCA, que permite crear de forma segura y ágil todas las distintas partes que componen las aplicaciones actuales.

Al usarlos en conjunto, Snyk Code para SAST y Snyk Open Source para SCA ofrecen pruebas rápidas y precisas, fáciles de usar y con funciones de autoservicio. Así, los desarrolladores y los equipos de seguridad pueden encontrar, priorizar y corregir fácilmente tanto los problemas de seguridad en su propio código propietario como las vulnerabilidades conocidas en sus dependencias de código abierto, lo que reduce los riesgos y acelera el desarrollo seguro.

La aplicación se corrige antes de entrar al pipeline de CI/CD, lo que elimina las demoras de los análisis y la carga de clasificar y registrar informes de problemas, y permite que el equipo de seguridad de aplicaciones se enfoque en la postura de seguridad general de la organización.

Las pruebas consolidadas de Snyk se realizan desde las primeras etapas y a lo largo del ciclo de vida del desarrollo, por ejemplo, directamente en el IDE:

Una herramienta, dos metodologías de análisis: el complemento de Snyk para IDE de JetBrains en acción.

Los análisis son rápidos y los resultados aparecen en el entorno de trabajo del desarrollador, acompañados de explicaciones claras y fáciles de entender. Se superpone un flujo de datos de la aplicación al código original, con la posibilidad de navegar entre distintos archivos. También se ofrecen ejemplos de proyectos de código abierto para mostrar cómo otras personas abordaron el problema en un contexto similar. Y lo mejor de todo: como es rápido y no tiene límites, los desarrolladores pueden analizar cambios pequeños con frecuencia y corregir problemas antes de que lleguen al sistema de control de versiones del código fuente.

Snyk ejecuta automáticamente análisis consolidados en otras etapas posteriores del desarrollo. Por ejemplo, al importar un proyecto nuevo desde GitHub, Snyk analiza automáticamente el código fuente del repositorio con SAST (1) y SCA (2):

Un proyecto importado a Snyk. Resultados de análisis SAST y SCA en una vista consolidada.

Es importante destacar que la plataforma Snyk se basa en la Base de datos de vulnerabilidades Snyk Intel, que reúne varias fuentes públicas, comentarios de la amplia comunidad de desarrollo de Snyk y el trabajo de investigación de un equipo dedicado de Snyk para ofrecer los datos de vulnerabilidades más completos, oportunos y prácticos del mercado. Esto garantiza que los resultados de los análisis y las recomendaciones de corrección sean precisos.

La interfaz de usuario de Snyk permite que los equipos de desarrollo y seguridad revisen periódicamente su base de código para detectar vulnerabilidades descubiertas recientemente. Por ejemplo, ante la reciente vulnerabilidad Log4Shell, Snyk Open Source permitió a los usuarios de Snyk analizar rápida y fácilmente toda la base de código de sus aplicaciones, identificar los repositorios vulnerables y tomar las medidas necesarias. Además, estas pruebas se pueden automatizar y hacer obligatorias mediante comprobaciones de PR o integrando Snyk en un pipeline de CI/CD.

Snyk no cobra por análisis, línea de código ni proyecto. Los equipos de seguridad de aplicaciones no tienen que limitar sus análisis a proyectos esenciales ni a una frecuencia determinada por los costos de licencia: pueden analizar todo el código que quieran, con la frecuencia que necesiten.

Por último, la plataforma Snyk también analiza vulnerabilidades en contenedores y en infraestructura como código (como quizá hayas notado en una captura de pantalla anterior), lo que ofrece una visión integral de todas las distintas partes de código que conforman una aplicación.

La respuesta es… ambos

Combinar SAST y SCA es mejor: permite que las organizaciones tengan una visión completa de todo el software que utilizan.

La tarea de proteger las aplicaciones modernas debe ser tan ágil como los procesos que impulsan su desarrollo. Usar ambas herramientas ya es un estándar de facto en la seguridad de aplicaciones y cada vez es más necesario para cumplir con distintos tipos de requisitos regulatorios, como PCI DSS, y con diversas iniciativas gubernamentales de todo el mundo que abordan la seguridad de las aplicaciones y el aumento de los ataques a la cadena de suministro de software.

Las organizaciones que buscan entregar aplicaciones seguras no deberían tener que elegir una metodología sobre otra por experiencias anteriores, preferencias por un enfoque o incluso presupuestos limitados. SAST y SCA ofrecen una visibilidad integral e indispensable de TODO el código fuente que conforma una aplicación, por lo que deben ser elementos clave de cualquier programa de seguridad de aplicaciones.

¿No sabes cómo empezar con SAST y SCA? ¡Prueba Snyk gratis!