¿Cómo implementar un analizador estático en el desarrollo para que todos estén contentos?

En el proceso, a menudo se nos hace la pregunta: cómo implementar un analizador estático en desarrollo para que todo esté bien. Ya hablamos sobre por qué se necesita un analizador estático para un desarrollo seguro. Este artículo será útil si está eligiendo un analizador estático o si ya planea implementarlo. ¿Cómo configurar el proceso para que las vulnerabilidades descubiertas en el código finalmente se arreglen? En este artículo intentaremos ayudarlo a resolver este problema.

Lo que está por venir?

Implementar el analizador de tal manera que las vulnerabilidades se arreglen de manera estable no es una cuestión rápida. Por experiencia, podemos decir que lleva de un par de semanas a varios meses. Si está implementando el analizador en una gran empresa, prepárese para una serie de aprobaciones. Después de todo, estos son cientos de bases de código que deben analizarse, y docenas de equipos con sus propias órdenes de desarrollo.

Para agregar una nueva etapa de desarrollo: análisis estático, tendrá que estudiar cómo funciona el proceso de cada equipo y proponer una solución que sea conveniente para todos. En pequeñas empresas, el orden de desarrollo establecido puede no existir en absoluto. La implementación del analizador puede ser una excusa para construir un proceso. Para que la integración sea más suave, le recomendamos que averigüe qué analizador tiene las capacidades para esto.

¿Cuáles son las opciones de integración?

El analizador generalmente asume una interfaz no gráfica (CLI, REST) ​​para la integración en cualquier proceso. Hay analizadores con integraciones listas para usar: con herramientas de compilación y entornos de desarrollo, con sistemas de control de versiones (Git, SVN), servidores CI / CD (Jenkins, TeamCity, TFS), sistemas de gestión de proyectos (Jira) y gestión de usuarios (Active Directory). Cuanto más útil sea para su empresa, más fácil será configurar todo.

¿Cómo puedes construir un proceso?

Considere la situación estándar: los departamentos involucrados son seguridad de la información, gestión de lanzamientos y desarrollo. Como regla, el cliente de la implementación del analizador es la seguridad de la información (IS). La tarea es acordar quién, cuándo y qué hará. Distinguimos los siguientes pasos: iniciar el análisis, procesar los resultados del análisis, crear una solicitud para corregir la vulnerabilidad, corregir la vulnerabilidad, verificar la corrección . Considere cada paso con más detalle.

Paso 1. Ejecute el análisis

Puede ejecutar el análisis de forma manual o automática. Los enfoques tienen sus pros y sus contras.

Manualmente

Él mismo recordaba el analizador, descargó el código él mismo, fue y miró los resultados.



Si hay alrededor de una docena de proyectos en la empresa y un oficial de seguridad se encarga de monitorear la seguridad, tal escenario es posible. Si hay alrededor de un centenar de proyectos, debe configurar la automatización.

Automatizado

Decida con qué frecuencia y en qué punto necesita analizar el código. Por ejemplo, antes de ingresar a un entorno productivo, de acuerdo con un horario determinado (una vez por semana) o después de cada cambio.

Si la aplicación rara vez se actualiza, pero también necesita controlar su seguridad, configure el análisis si hay algún cambio.

Si mucha gente trabaja en el código, se crean muchas ramas, a menudo se producen cambios; es mejor analizar a menudo, pero no interfieren con el desarrollo. Por ejemplo, al momento de crear una solicitud de fusión con la rama principal o cuando el estado de la tarea en esta rama cambia. La integración con un sistema de control de versiones o con un sistema de gestión de proyectos lo ayudará con esto. La integración con CI / CD hará que el análisis sea uno de los pasos de compilación.

Establezca el cronograma para que tenga tiempo de procesar los resultados.

Paso 2. Procesar los resultados del análisis.

No indique a los desarrolladores que corrijan de inmediato todas las vulnerabilidades encontradas. Deje que el oficial de seguridad los verifique primero. Los resultados del primer análisis pueden parecer deplorables: docenas de vulnerabilidades críticas, cientos de vulnerabilidades menos críticas y miles de falsos positivos. Que hacer aqui Recomendamos corregir las vulnerabilidades gradualmente. El objetivo final es lograr la ausencia de vulnerabilidades tanto en el código antiguo como en el nuevo. En la etapa inicial, verifique las vulnerabilidades críticas (aún inseguras con ellas) y nuevas (el nuevo código es más fácil de solucionar).

Usa filtros. Ordene las vulnerabilidades por gravedad, por idioma, archivo y directorio. Las herramientas más avanzadas le mostrarán vulnerabilidades solo en el nuevo código, ocultarán vulnerabilidades en bibliotecas de terceros. Se han aplicado filtros, pero ¿todavía hay muchas vulnerabilidades?

Ver las vulnerabilidades más probables. Hay analizadores que evalúan la probabilidad de un falso positivo. Si hay muchas vulnerabilidades y el nivel de criticidad es casi el mismo para todos, filtre los resultados con esta métrica. Por lo tanto, procesa rápidamente las vulnerabilidades más probables (vea la captura de pantalla a continuación).



Usar estados de verificación. Para capturar los resultados de la verificación, generalmente los analizadores ofrecen trabajar con los estados de la vulnerabilidad: confirmar o rechazar como falso positivo. Como regla general, el trabajo realizado debe conservarse durante el reescaneo.

Paso 3. Crear una solicitud de reparación de vulnerabilidad

Si el desarrollador comienza el análisis de su código e inmediatamente corrige las vulnerabilidades, entonces, por supuesto, no necesita crear solicitudes innecesarias.

Si el oficial de seguridad revisa y verifica los resultados, entonces para la corrección adicional de las vulnerabilidades confirmadas, generalmente se necesita establecer una tarea. Nos hemos enfrentado repetidamente al hecho de que fue en este paso cuando surgieron las dificultades.

Formulario de solicitud

Hay empresas en las que se fijan grandes tareas para la etapa en el sistema de gestión de proyectos (por ejemplo, Jira). Y para subtareas y errores, por ejemplo, se utilizan problemas de GitLab, acceso al que solo el líder del equipo y su equipo tienen acceso. También sucede que el ensamblaje es imposible sin crear una tarea separada en el sistema de gestión de proyectos. El analizador puede tener integraciones con las que puede crear las consultas necesarias de inmediato en la interfaz.

A menudo dentro de la misma compañía con numerosos grupos de desarrollo, cada uno de ellos tiene su propio procedimiento para implementar tareas de trabajo. Y necesitas adaptarte a todos. Surgen preguntas:

• ¿Vale la pena asignar un proyecto separado para corregir vulnerabilidades o crear tareas en las existentes?
• ¿Es la vulnerabilidad un error familiar o una nueva entidad?
• ¿Crear una tarea separada para cada vulnerabilidad o agrupar tareas similares?
• ¿Qué debo dar como descripción del problema: un enlace a una vulnerabilidad en la interfaz del analizador o un lugar en el código y describir brevemente el problema?
• ¿Necesita el desarrollador acceso a los resultados? Simplemente envíe un informe en PDF con el texto "ver página 257 "y eso es suficiente?

Por supuesto, depende de cómo se ajuste el proceso en el equipo, qué sistemas de seguimiento de errores se utilizan.

Si el código está escrito por contratistas para quienes el acceso a los sistemas internos es mínimo, un esquema con un informe en PDF es adecuado. Por lo general, para un informe, puede seleccionar vulnerabilidades que le interesen e inmediatamente enviarlas a la dirección deseada desde la interfaz del analizador.

Si una empresa no puede hacer un solo paso sin crear un proyecto para un determinado tipo de tarea con una cierta cantidad de recursos, entonces debe buscar una herramienta con integración para su sistema. Las integraciones más flexibles generarán una descripción de la tarea para usted (ni siquiera se olvidarán del enlace al código fuente en el sistema de control de versiones) y le permitirán completar todos los campos requeridos. Elija el tipo de tarea, especifique el padre, los artistas e incluso la versión de lanzamiento.

Costos laborales y plazos

Si el equipo decidió hacer una evaluación de los costos laborales para cada tarea, entonces la tarea de corregir la vulnerabilidad debe hacerse de la misma manera. En el camino, los desarrolladores verifican las vulnerabilidades. A veces, en este paso, resulta que la vulnerabilidad es falsa o imposible de explotar.

Pero, por regla general, los recursos aún no son suficientes para corregir de inmediato todas las vulnerabilidades. Por lo tanto, también es necesario coordinar sus prioridades.

Las tareas fueron determinadas por los costos laborales y las prioridades; luego, los responsables de las fechas de lanzamiento (puede ser el gerente del proyecto o el mismo líder del equipo) deciden qué arreglar y cuándo. Al principio, al usar el analizador, le recomendamos que no posponga el lanzamiento, si no se corrigen todas las vulnerabilidades.

Paso 4. Repara las vulnerabilidades

Cómo asignar adecuadamente los recursos: conectar nuevas personas o confiar a quienes ya están comprometidos con el desarrollo es una cuestión presupuestaria. Una cosa es cierta: si la empresa asigna recursos para la instalación del analizador, debe prepararse para los costos de reparación de vulnerabilidades. Una forma posible es establecer el porcentaje de tiempo para reparar vulnerabilidades como un trabajo con deuda técnica.

Hay dos escenarios: corregir inmediatamente en el proceso de desarrollo o a solicitud de un oficial de seguridad. La reparación de vulnerabilidades durante el desarrollo es un escenario ideal. Inmediatamente encontrado - inmediatamente corregido. El desarrollador escanea su rama de características antes de solicitar una fusión con la rama principal. Esto también se puede automatizar mediante integraciones: con el entorno de desarrollo, con herramientas de compilación, sistema de control de versiones o con CI / CD.

Otro escenario es analizar la rama de desarrollo principal después de todos los cambios. Un oficial de seguridad o líder de equipo revisa los resultados y crea tareas para corregir vulnerabilidades. Este escenario lleva más tiempo. En la entrada del desarrollador se encuentra el código fuente, la tarea de corrección y los resultados del análisis. Para un desarrollador, la tarea de corregir una vulnerabilidad no es muy diferente de corregir un error.

Paso 5. Verifique la solución

Debe asegurarse de que la vulnerabilidad esté realmente corregida y que no haya aparecido una nueva en su lugar. Hay resultados del análisis del código corregido. ¿Qué buscar? ¿Archivo y número de línea de la vulnerabilidad? ¿O buscar por nombre de vulnerabilidad? Es posible y así. Pero si se cambia el código, la línea con la vulnerabilidad podría cambiar, y aún podría haber muchas ocurrencias de una vulnerabilidad. Algunos analizadores pueden mostrar vulnerabilidades "fijas". De acuerdo, para que pueda verificar la corrección de vulnerabilidad más rápido (ver captura de pantalla).

Ejemplos

Aquí hay dos escenarios posibles.

Escenario 1

El equipo usa Git para el control de versiones, Jira para la gestión de proyectos y tareas. Jenkins configura el horario de compilación. Por ejemplo, una vez al día si hay cambios en la sucursal. Como paso adicional, se indica el inicio del analizador.

El oficial de seguridad revisa los resultados del análisis de la rama principal (maestro o desarrollo), y los desarrolladores revisan sus ramas de características.

Los desarrolladores corrigen vulnerabilidades si es necesario. Si el analizador puede filtrar vulnerabilidades a pedido: muestre solo vulnerabilidades nuevas o no muestre vulnerabilidades en bibliotecas de terceros, muestre vulnerabilidades en un directorio o archivo específico; el desarrollador podrá ver rápidamente los resultados que le interesan. Entonces, la probabilidad de corrección es mayor.

El oficial de seguridad revisa los resultados del análisis de la rama principal. Mediante la integración con Jira, el oficial de seguridad crea tareas de gestión de vulnerabilidades desde la interfaz del analizador. Lo siguiente es la coordinación de plazos y prioridades.

Cuando se corrige la vulnerabilidad y el nuevo código pasa todas las etapas de desarrollo interno (revisión del líder del equipo, prueba de usuario y regresión), el oficial de seguridad debe asegurarse de que la vulnerabilidad ya no esté allí. El autor cierra la tarea completada.

Escenario 2

El código de la empresa está escrito por un grupo de contratistas. Timlid interactúa con los desarrolladores por correo electrónico y usa GitLab para el control de versiones. Los contratistas no tienen acceso a los sistemas internos de gestión de proyectos (Jira).

El oficial de seguridad o el líder del equipo revisa los resultados del análisis de la rama principal de desarrollo. Los contratistas no tienen acceso al analizador. Si hay vulnerabilidades que deben corregirse, el oficial de seguridad envía un informe en PDF con los resultados del análisis al líder del equipo o inmediatamente al desarrollador.

A partir del informe, el desarrollador descubre dónde se encuentra la vulnerabilidad, en qué consiste y cómo se puede solucionar. Es valioso si para vulnerabilidades asociadas con el flujo de datos inseguros (por ejemplo, inyección SQL), el esquema de distribución se descargará en el informe: desde la fuente de datos hasta su uso en la llamada a la función / método (ver captura de pantalla).



Después de corregir la vulnerabilidad, el líder del equipo informa al oficial de seguridad que es hora de verificar los resultados del nuevo escaneo.

¿Qué más es importante?

Establecer la interacción entre la seguridad de la información y el desarrollo. Es importante que ambas partes estén interesadas en corregir las vulnerabilidades. Bueno, si no solo serán solicitudes, sino también comunicación en vivo.

No descuides los roles de usuario. Un buen analizador debe tener la capacidad de diferenciar los derechos. Es poco probable que un contratista necesite derechos de administrador o los resultados de un análisis de los sistemas internos. Para editar los resultados, para cambiar la criticidad y el estado, es suficiente para permitir que el oficial de seguridad y el líder del equipo. El principio de privilegios mínimos no ha sido cancelado.

Si la empresa es grande y usa un sistema de administración de usuarios (por ejemplo, Active Directory), considere herramientas con integración lista para usar. Podrá reutilizar los roles y grupos aceptados en la empresa y otorgarles los derechos necesarios.

Conclusión

Después de elegir un analizador, prepárese para el hecho de que aún debe implementarse correctamente. No tenga miedo de las reuniones y la coordinación con los participantes: cuanto mejor comprenda en el proceso, más útil será el resultado. Es importante que el escenario de trabajo no solo se apruebe, sino que también se empiece a seguir.

Publicado por Elizaveta Kharlamova, analista principal, Solar AppScreener