🛁 🏞️ 💆🏾 (S) SDLC, o Cómo hacer que el desarrollo sea más seguro. Parte 1 👩🏽‍🏫 👞 🤜🏼

Cada año crece la cultura de desarrollo, aparecen nuevas herramientas para garantizar la calidad del código y nuevas ideas sobre cómo usar estas herramientas. Ya escribimos sobre el dispositivo de análisis estático , sobre los aspectos de los analizadores a los que debe prestar atención y, finalmente, sobre cómo, desde el punto de vista de la organización, puede construir un proceso basado en el análisis estático .

En base a los problemas que a menudo encontramos, describimos todo el proceso de introducción de un escáner de código en un proceso de desarrollo seguro. Hoy hablaremos sobre cómo elegir el analizador que más le convenga.

De una forma u otra, todos los desarrolladores se enfrentan al análisis estático (análisis de código sin ejecución). Por ejemplo, cuando el compilador genera algunos errores o advertencias en función de los resultados del ensamblaje, estos son los resultados del análisis estático. A menudo usamos linters; este también es un análisis estático, aunque a menudo es muy simple. Hay ejemplos más interesantes: spotbugs (anteriormente findbugs), que le permite encontrar vulnerabilidades bastante interesantes en Java bytecode, o el conocido SonarQube, una plataforma para monitorear la calidad del código.

Sin embargo, las herramientas SAST completas todavía rara vez se encuentran. En primer lugar, estamos hablando de herramientas que pueden encontrar vulnerabilidades complejas. Como resulta en la práctica, las herramientas abiertas bien conocidas no pueden hacer frente a esta tarea, al menos porque se centran en otra área (errores y vulnerabilidades simples). Una buena herramienta SAST implementa el análisis de flujo de datos interprocedimiento. El análisis no debe tener lugar en el texto del programa, sino en la presentación interna: CFG, AST, etc. Lea más sobre esto en el artículo anterior .

SAST

Aquí hay un ejemplo: la conocida inyección SQL. En este ejemplo, los datos del usuario caen en la función completa de la consulta, pasan a la función injectableQuery y ya están en la consulta SQL, lo que hace que la aplicación sea vulnerable a la inyección SQL.

Para encontrar dicha vulnerabilidad, uno debe comprender de dónde pueden venir los datos "malos", cómo se pueden validar dichos datos, dónde no se pueden usar. Y lo más importante: necesita monitorear la transferencia de datos en toda la aplicación, este es el análisis de flujo de datos. El ejemplo es muy simple, en una aplicación real, los datos pueden pasar por muchas funciones y módulos, asignaciones y sinónimos.

Está claro que la búsqueda de texto no encontrará tal vulnerabilidad. El análisis intraprocesal tampoco se encontrará, y en algunas herramientas abiertas solo se implementa. Para encontrar tales vulnerabilidades (y esta suele ser la vulnerabilidad más crítica, es decir, el objetivo principal de la herramienta SAST), necesitamos algoritmos bien desarrollados para el análisis entre procedimientos del flujo de datos con grandes bases de reglas.

Es sobre la base de la complejidad algorítmica que surgen una serie de problemas técnicos que distinguen la implementación de la herramienta SAST de otros analizadores estáticos, por ejemplo, SonarQube. Discutiremos estos temas en una serie de artículos. Spoiler: consumo de recursos, duración del análisis, falsos positivos.

Cabe señalar que, además de los algoritmos, una buena herramienta envuelve todas las matemáticas en una interfaz de interfaz conveniente, lo que le permite usar SAST sin una preparación seria. Dichas herramientas también están integradas en el CI / CD utilizando complementos y API, automatizando así la búsqueda de vulnerabilidades y permitiéndole construir procesos de desarrollo seguros.

En el primer artículo, tratamos de clasificar los principales problemas que surgen durante el estudio de SAST, así como después de la decisión de implementar la herramienta. Hablaremos sobre algunos problemas aquí, algunos irán a los siguientes artículos.

Empecemos

¿Por qué SAST si ya tiene analizadores estáticos gratuitos?

Abordamos parcialmente esta pregunta en la parte anterior. Por supuesto, de ninguna manera disminuimos los méritos de las herramientas abiertas. Todo el mundo sabe que SonarQube es una gran herramienta para automatizar la evaluación de la calidad del código, con una gran cantidad de idiomas, integraciones y complementos compatibles. SonarQube es bueno para integrarse en el proceso de desarrollo, pero está destinado más a contar varias métricas de código y buscar errores o vulnerabilidades bastante simples. No implementa el análisis interprocedural del flujo de datos; en consecuencia, no puede usarse para buscar vulnerabilidades complejas. Por lo general, recomendamos usar SonarQube y una buena herramienta SAST (puede ser útil aquí si la herramienta SAST puede integrarse con SonarQube).

Hay otros buenos analizadores estáticos abiertos. Puede llamar a spotbugs (findbugs) para el código de bytes JVM con el complemento find-sec-bugs, que implementa el análisis en proceso del flujo de datos con un pequeño conjunto de reglas. Existe un conocido analizador de bandidos para Python. Uno no puede dejar de mencionar el analizador estático integrado en clang, que tiene un buen motor de análisis y una buena base de reglas.

Los problemas de tales herramientas son que, por lo general, son bastante poco especializados (por ejemplo, adecuados para un idioma), implementan algoritmos simples (es decir, no permiten encontrar vulnerabilidades complejas) y tienen bases de reglas mucho más pequeñas que las herramientas comerciales. Además, tienen un conjunto más pequeño de funcionalidades, tanto de interfaz como de integración. Bueno, podemos mencionar la falta de apoyo.

Por otro lado, las buenas herramientas comerciales SAST (y también hay malas) implementan algoritmos específicos complejos y tienen amplias bases de reglas que pueden incluir miles de registros. Por lo general, admiten muchos lenguajes de programación, tienen una interfaz rica y capacidades de integración (complementos, API). A continuación les doy un ejemplo de qué tipo de integraciones estamos hablando.

E incluso más abajo, mire un ejemplo de un esquema de integración que se puede construir sobre la base de una herramienta SAST. En general, el esquema no difiere de la introducción de otros medios de control de calidad del código. Los desarrolladores escriben código y pueden ejecutar inmediatamente una verificación SAST. El código ingresa al repositorio y a partir de ahí, varios disparadores que usan CI / CD ingresan a SAST. Los resultados del escaneo se pueden ver en la interfaz SAST, o pueden terminar en herramientas que apoyan el proceso de desarrollo (rastreador de errores, correo, etc.).

¿Qué herramienta SAST elegir?

Me detendré un poco en la etapa de elegir una herramienta. Hay muchas herramientas SAST, generalmente se presentan varias piezas en el mercado (3-4). Surge la pregunta, ¿cómo elegir la herramienta adecuada, qué buscar? Aquí no me sorprenderé, me centraré en tres puntos: comparación funcional, comparación de calidad y licencias. Es importante llevar la herramienta de prueba (piloto) en su circuito local y verificar su código en su infraestructura.

Sería bueno probar todas las funciones de la interfaz, para comprender cómo son aplicables a su caso y qué tan convenientes son de usar. Me refiero a uno de los artículos anteriores . Aquí hay algunas características útiles:

el lanzamiento más automatizado del escaneo (idealmente, sin configuraciones innecesarias en dos botones, puede ejecutar un escaneo);
— , , ;
;
;
;
(, );
;
, “”;
“ , ”;
;
.

Las capacidades de integración son muy importantes: con CI / CD, bugtrackers, repositorios, Active Directory. Sería bueno tratar de automatizar una acción simple utilizando la API, si corresponde.

Para verificar la calidad necesita escanear su código. Es bueno elegir varios ejemplos diferentes en diferentes idiomas para que la muestra sea representativa. Desde el punto de vista de la calidad, debe observar los falsos positivos (donde claramente no hay vulnerabilidad, pero la herramienta muestra) y las omisiones (idealmente, necesita saber dónde están las vulnerabilidades, o comparar las vulnerabilidades encontradas en diferentes herramientas). Prestaría un poco menos de atención a los falsos positivos, ya que generalmente es suficiente revisar los resultados del escaneo una vez, marcar los falsos y luego no lo molestarán.

Me centraré en dos puntos importantes. En primer lugar, es muy importante tener en cuenta todo esto en aplicación a su situación. Verifique exactamente su código (SAST puede funcionar de manera diferente en diferentes tipos de aplicaciones). Busque las características que necesita para integrar la herramienta en el proceso de desarrollo. Verifique la integración con los sistemas que tiene.

En segundo lugar, es muy importante durante el piloto comunicarse con el proveedor. SAST no es lo más fácil y, a menudo, es suficiente obtener el asesoramiento habitual del proveedor para apreciar completamente el poder de la herramienta.

¿En qué punto comienzas a escanear?

Cuanto antes se encuentre una vulnerabilidad, más barata será. Hay horarios tristes que vagan de presentación en presentación, ni siquiera los agregaré aquí. Pero la afirmación es bastante obvia. Una cosa es corregir la vulnerabilidad el día después de que se realice, otra cosa es hacer un cambio en el servidor de combate cuando ya ha sido pirateado. En consecuencia, es necesario transferir el uso de SAST a las primeras etapas de desarrollo. Aquí se puede argumentar que la introducción de SAST en el desarrollo es en sí mismo un evento costoso y puede que no valga la pena. Aquí argumentaré: por lo general, encontrar varias vulnerabilidades críticas cubre toda la implementación (incluso puede realizar una evaluación dentro del piloto).

Con este enfoque, también obtenemos una bonificación: cuando los desarrolladores ven los resultados de SAST "todos los días", avanzan en el conocimiento de la programación segura, por lo tanto, en general, se mejora la cultura del desarrollo seguro y el código mejora.

Por supuesto, al implementar SAST en el proceso de desarrollo, es necesario implementarlo en CI / CD, creando DevSecOps. La tendencia de transferir SAST de las comprobaciones de control antes del lanzamiento al proceso de desarrollo ha sido visible durante mucho tiempo, y en los últimos 2-3 años se ha puesto al día con nuestro mercado. Ahora ningún piloto pasa sin probar las capacidades de integración.

Al mismo tiempo, dejaría verificaciones de control antes del lanzamiento, idealmente, para ensamblajes binarios (esto también es posible). Por lo tanto, puede asegurarse de que no se agregaron nuevas vulnerabilidades durante el ensamblaje y la transferencia de la aplicación al producto.

Problemas técnicos

Y luego te daré 4 preguntas de inmediato.

Conecta SAST como SonarQube, ¿cuál es la dificultad?
SAST funciona durante mucho tiempo, ¿cómo configurar DevSecOps?
SAST da falsos positivos, ¿cómo configurar Quality Gate?
Y sin falsos positivos en el informe, varios miles de vulnerabilidades, ¿qué hacer con ellos?

Estos son los principales problemas técnicos que surgen al implementar SAST. Surgen por las siguientes razones.

Debido a la naturaleza exponencial de los algoritmos, SAST puede ejecutarse durante mucho tiempo y consumir muchos recursos, mucho más que un linter o SonarQube.
Por la misma razón, SAST puede dar muchos falsos positivos: es poco probable que los desarrolladores quieran analizar un montón de caídas todos los días después del próximo escaneo.
Por lo general, SAST se inicia en la base de código por primera vez, y la primera ejecución puede mostrar muchas operaciones, especialmente si hay mucho código y la base de datos no es muy nueva.

Todos los problemas tienen solución. En el próximo artículo de la serie, examinaremos, utilizando un ejemplo concreto de nuestra experiencia, cómo implementar SAST de tal manera que nivele todas sus características técnicas y haga felices a todos.

Asuntos de organización

No me olvidaría de los problemas de organización. En las grandes empresas, muchas de ellas surgen, desde el proceso de implementación en sí, la asignación de recursos hasta la creación de regulaciones y la replicación de procesos.

Los problemas de organización se generan por las mismas características técnicas que discutimos en el párrafo anterior. Bueno, además de esto, la división históricamente establecida y la confrontación entre desarrollo y seguridad aún no han desaparecido. También me refiero a nuestro artículo anterior.

Continuará

Implemente SAST: es necesario, generalmente está justificado. Pero, comenzando a implementar, sería bueno familiarizarse con todos los escollos que surgen en su camino. En este artículo, comenzamos a desmontarlos, continuaremos con los aspectos técnicos a continuación.

(S) SDLC, o Cómo hacer que el desarrollo sea más seguro. Parte 1