¿Cómo elegir una herramienta SAST para asegurar su desarrollo?

Cuando se trata de un desarrollo seguro, ¿cómo se integra un escáner de código en el proceso, cuáles son las trampas y las trampas?

Todos los desarrolladores se enfrentan al análisis estático (pruebas de seguridad de aplicaciones estáticas o SAST, que significa análisis de código sin ejecución). Sin embargo, rara vez vemos soluciones SAST completas en uso capaces de detectar vulnerabilidades avanzadas. Las herramientas de código abierto conocidas a menudo no pueden hacer frente a esta tarea solo porque se centran en otra área (errores y vulnerabilidades simples). Una buena herramienta SAST proporciona análisis de flujo de datos entre procedimientos.

Usando una inyección SQL común como ejemplo, los datos proporcionados por el usuario van a terminado función de una consulta, luego se mueve a inyectableQuery función, y finalmente llega a una consulta SQL, lo que hace que una aplicación sea vulnerable a la inyección SQL.

Para encontrar tal vulnerabilidad, necesitamos entender de dónde pueden provenir los datos “malos”, cómo validarlos y dónde no deben usarse. También necesitamos monitorear el movimiento de datos en toda la aplicación o, en otras palabras, realizar análisis de flujo de datos. Si bien este ejemplo es muy simple, en una aplicación real, los datos pueden viajar a través de muchas funciones, módulos, asignaciones y sinónimos.

Obviamente, una búsqueda de texto no encontrará tal vulnerabilidad. Tampoco lo hará el análisis entre procedimientos, que es la única opción disponible en algunas herramientas de código abierto. Para encontrar las vulnerabilidades más críticas, necesitamos algoritmos bien desarrollados para el análisis del flujo de datos entre procedimientos con grandes bases de reglas.

Dado que la complejidad algorítmica plantea algunos problemas técnicos, la implementación de SAST difiere de la de otros analizadores estáticos, como SonarQube. Además de los algoritmos, una buena herramienta reúne todas las matemáticas subyacentes en un shell intuitivo y fácil de usar. Estas herramientas también pueden integrarse en CI / CD a través de complementos y API para automatizar la búsqueda de vulnerabilidades y crear procesos de desarrollo seguros.

A continuación se muestran las principales cuestiones que surgen al estudiar y optar por SAST.

Ya tenemos analizadores estáticos gratuitos, ¿por qué utilizar SAST?

De ninguna manera queremos disminuir los méritos de las herramientas de código abierto. SonarQube es una gran solución para automatizar la evaluación de la calidad del código, con una gran cantidad de lenguajes, integraciones y complementos compatibles. Aunque es fácil de integrar en el proceso de desarrollo, SonarQube cuenta principalmente varias métricas de código y busca vulnerabilidades bastante simples. La solución también carece de análisis de flujo de datos entre procedimientos y, por lo tanto, no puede encontrar vulnerabilidades avanzadas. Por lo general, recomendamos utilizar tanto SonarQube como una buena herramienta SAST capaz de integrarse con SonarQube.

Hay otros buenos analizadores estáticos de código abierto. Uno de ellos es spotbugs (findbugs) para el código de bytes de JVM, que tiene un complemento find-sec-bugs con análisis de flujo de datos entre procedimientos con un pequeño conjunto de reglas. Para Python, hay un popular bandido analizador. Un analizador estático integrado sonido metálico tiene un buen motor de análisis y una base de reglas.

Recuerde que estas herramientas tienen un enfoque limitado (por ejemplo, admiten un solo idioma) y utilizan algoritmos simples (es decir, no pueden encontrar vulnerabilidades avanzadas). En comparación con los productos comerciales, las herramientas de código abierto tienen bases de reglas mucho más pequeñas, interfaces y funcionalidad de integración más deficientes y no tienen soporte.

En cambio, las herramientas SAST comerciales de calidad (recuerde, no todas son buenas) utilizan algoritmos específicos complejos, tienen bases de reglas extensas que incluyen hasta miles de registros, admiten muchos lenguajes de programación y cuentan con una interfaz rica y capacidades de integración (complementos, API). A continuación se proporcionan ejemplos de integración.

Además, hay un ejemplo de un gráfico de integración basado en SAST. Los desarrolladores escriben un código y pueden ejecutar SAST de inmediato. El código va a un repositorio y luego, mediante CI / CD y varios activadores, a SAST. Los resultados del análisis pueden verse en una interfaz SAST o transmitirse a herramientas de soporte de desarrollo (rastreador de errores, correo electrónico, etc.).

¿Qué herramienta SAST elegir?

Céntrese en tres criterios: funcionalidad, calidad y licencia. Debe probar una herramienta en su entorno local y probarla en su código e infraestructura. Pruebe todas las funciones de la interfaz para comprender hasta qué punto se aplican a su situación y qué tan fáciles de usar son:

• Automatizado, idealmente, con dos clics de distancia, lanzamiento de escaneo
• Análisis de diferentes tipos de aplicaciones: código fuente, código binario y varios idiomas en un solo archivo
• Exclusión de directorio del análisis
• Analisis incremental
• Adición de reglas de búsqueda de vulnerabilidades personalizadas
• Comparación de escaneos (seguimiento de vulnerabilidades de un escaneo a otro)
• Se realiza un seguimiento de la edición de resultados de escaneo de escaneo a escaneo
• Descripciones claras de vulnerabilidades, preferiblemente con un seguimiento de análisis de flujo de datos para vulnerabilidades de tipo inyección
• Métrica que refleja «la confianza de la herramienta de que una detección no es un falso positivo»
• Administración flexible
• Funciones analíticas ricas y fáciles de usar

Las capacidades de integración de CI / CD, seguimiento de errores, repositorio y Active Directory son muy importantes. Automatizar una acción simple a través de una API (si está disponible) también es una buena idea.

Para comprobar el rendimiento de la herramienta SAST, escanee su código tomando varias muestras escritas en diferentes idiomas. En cuanto a la calidad, observe tanto los falsos positivos (es decir, la herramienta indica incorrectamente una vulnerabilidad) como los falsos negativos (necesita saber dónde están las vulnerabilidades o comparar las encontradas por diferentes herramientas).

También es importante recordar verificar su código, no el de otra persona; SAST puede funcionar de manera diferente en diferentes tipos de aplicaciones. Busque las características que necesita para integrar en su proceso de desarrollo y verifique la integración con los sistemas que ya están en su lugar. Comunicarse con el proveedor durante el programa piloto. SAST no es tan simple y la consulta con el proveedor puede ayudarlo a ver todos los beneficios.

¿Cuándo iniciar los escaneos?

Una cosa es arreglar una vulnerabilidad un día después de su introducción y otra muy distinta es reparar un servidor de producción ya pirateado. Es por eso que el uso de SAST debe trasladarse a las primeras etapas de desarrollo. Cuando los desarrolladores ven los resultados de SAST con regularidad, mejoran su conocimiento de programación segura, lo que contribuye a un desarrollo más seguro.

Sin embargo, usaría comprobaciones previas al lanzamiento de todos modos, idealmente después de cada compilación binaria (esto también es posible). De esta manera, puede asegurarse de que no se agreguen nuevas vulnerabilidades durante la compilación de la aplicación y la transferencia a producción.

En resumen, SAST es un producto imprescindible que suele dar sus frutos. Sin embargo, antes de continuar con la implementación, recomiendo encarecidamente revisar todos los posibles obstáculos.

Contribuido por Dan Chernov MSIS, CISSP, CISA, CTO, Aplicación solar