Para empezar, en general sobre el proyecto. Hemos construido un proceso de desarrollo seguro en una gran empresa comercial en la que el departamento de TI tiene un personal enorme y está dividido en muchas áreas que están mínimamente correlacionadas entre sí. Convencionalmente, estas áreas se pueden dividir en 3 grupos principales. El primero, un grupo muy grande, es el software de caja registradora, que está escrito principalmente en Java (90% de los proyectos). El segundo grupo de sistemas más extenso en términos de cantidad de código son las aplicaciones SAP. Y finalmente, el tercer bloque fue una "mezcolanza" de portales y aplicaciones móviles: varios sitios externos para los clientes de la empresa, aplicaciones móviles para estos sitios, así como recursos internos: aplicaciones móviles y portales web para el personal del minorista.
El cliente del proyecto, el departamento de seguridad de la información, formuló la tarea general de una manera bastante estándar para los tres grupos: “queremos tener menos vulnerabilidades y un desarrollo seguro de todos los sistemas creados dentro de la empresa”. Pero en la práctica, en cada departamento específico, todo se veía muy diferente al de otros colegas, porque en cada paso de la implementación del desarrollo seguro, teníamos que hacer un millón de compromisos diferentes. Algunos matices ayudaron a construir el proceso, mientras que otros, por el contrario, interfirieron. Al final, logramos crear un enfoque más o menos general para la mayoría de los proyectos.
Formulamos este enfoque de la manera más simple posible: se escanea el código más relevante para todos los desarrolladores. Si hablamos en términos de Gitflow, y todos los grupos de proyectos, con la excepción de SAP, tenían ramas de desarrollo en Gitflow, la rama de desarrollo principal se escanea según un cronograma.
Pero, como siempre, hay excepciones a cualquier regla: el enfoque general no se podría aplicar en todas partes "tal cual" por varias razones. Primero, nuestra herramienta (analizador de código) tiene varias limitaciones debido al hecho de que queremos poder hacer el análisis más profundo de algunos lenguajes de programación, si es necesario. Entonces, en el caso de Java, el código de bytes de análisis es mucho más profundo que el del código fuente. En consecuencia, el escaneo de proyectos de Java requería un ensamblaje preliminar de código de bytes y solo luego enviarlo para su análisis. En el caso de las aplicaciones C ++, Objective C e iOS, el analizador se incorporó al proceso en la etapa de compilación. También tuvimos que tener en cuenta los diversos requisitos individuales de los desarrolladores de todos los proyectos. A continuación, describiremos cómo construimos el proceso para portales y aplicaciones móviles.
Portales y aplicaciones móviles
Parece que todas estas aplicaciones están combinadas en un grupo lógico, pero de hecho fueron un desastre terrible. Había más de 120 portales (!). La empresa es muy grande, con muchos departamentos comerciales, administrativos y técnicos, y de vez en cuando cada uno de ellos decide que necesita su propio portal y aplicación móvil. Este portal y la aplicación se crean, se utilizan durante algún tiempo y luego se abandonan de forma segura. Como resultado, en la etapa inicial, tuvimos que realizar un inventario para el cliente, ya que incluso los desarrolladores de estas aplicaciones no tenían una única lista de bases de código. Por ejemplo, para administrar los repositorios de este grupo, los desarrolladores utilizaron dos GitLabs con diferentes administradores. Además, entre los portales y las aplicaciones móviles, una parte importante de los proyectos se implementó mediante desarrollo externo.Por lo tanto, cuando se acercaba el tiempo de lanzamiento, los contratistas a menudo transferían los códigos fuente de la nueva versión a la empresa casi en una memoria USB. Como resultado, la compañía tenía un zoológico de varias aplicaciones y un completo desastre en su código. Tuvimos que hacer una lista de todos los proyectos, encontrar a todos los responsables de ellos - propietarios técnicos, líderes de equipo, y luego acordar con el cliente principal - el departamento de seguridad de la información, cuál de ellos analizaremos.
Como resultado, elegimos sistemas de producción y software compatible para el análisis, y no tocamos los sistemas de archivo en absoluto. Varias aplicaciones internas se consideraron no críticas, ya que no podían causar ningún daño financiero a la empresa y no se seleccionaron para el análisis. Por ejemplo, un sistema de gestión para empacadores dentro de un almacén o cargadores. No hay nada vulnerable a los clientes externos de la empresa en ellos, y su piratería por parte de uno de los empleados internos solo causará pequeños inconvenientes internos a varios departamentos.
El servicio de SI ha formulado la introducción del análisis de código para las vulnerabilidades como una tarea prioritaria para este grupo de software y los desarrolladores, para construir un proceso de verificación conveniente integrado en los ciclos de desarrollo.
Integración según el esquema estándar
Se utilizó GitLab de dos versiones diferentes como sistema de control de versiones en el grupo de portales y aplicaciones móviles.
Configuración de la integración con GitLab
No todas las aplicaciones usaban CI / CD, y donde no lo estaba, tuvimos que insistir en usarlo. Porque si realmente desea automatizar el proceso de verificación del código en busca de vulnerabilidades (y no solo cargar manualmente un enlace para su análisis) para que el propio sistema lo descargue en el repositorio y brinde los resultados a los especialistas necesarios, entonces no puede prescindir de instalar corredores. Los corredores en este caso son agentes que se comunican automáticamente con los sistemas de control de versiones, descargan el código fuente y lo envían a Solar appScreener para su análisis.
Los desarrolladores del portal y el grupo de aplicaciones móviles querían organizar el desarrollo seguro como un proceso semiautomático para que el código fuera escaneado en busca de vulnerabilidades sin ninguna participación de su parte. Para que el oficial de seguridad verifique los resultados del análisis de vulnerabilidades y asigne tareas a los desarrolladores en Jira si considera que las vulnerabilidades son críticas, o las envíe a los desarrolladores para que las aclaren. Los desarrolladores decidirían si necesitan reparar urgentemente la vulnerabilidad o no. Y si es necesario, planearían en qué versión pueden incluir las correcciones.
Jira se utilizó principalmente como rastreador de errores, en el que el analizador de código proporcionaba automáticamente información sobre las vulnerabilidades encontradas.
Configuración de la integración de Jira
En casos excepcionales, los líderes del equipo observaron los resultados del rastreo por sí mismos e iniciaron tareas en Jira manualmente.
Creación de una tarea en Jira
También registramos estos casos en las regulaciones como una característica separada. En algunos proyectos, en general, todas las correcciones se discutieron en Slack o Telegram, y las tareas se establecieron en tiempo real.
Como resultado, el proceso de desarrollo seguro después de la implementación de Solar appScreener comenzó a tener este aspecto: los portales se revisan diariamente para detectar cambios en el código de la rama de desarrollo principal. Si la rama principal y más relevante no se ha actualizado en 24 horas, no ocurre nada. Si se ha actualizado, esta rama se envía para su análisis al proyecto correspondiente para este repositorio. El repositorio en GitLab correspondía a un proyecto específico en el analizador de código, y fue en este proyecto donde se escaneó la rama principal. Después de eso, el oficial de seguridad revisó los resultados del análisis, los verificó y comenzó las tareas de corrección en Jira.
Resultados de análisis y tareas de corrección de vulnerabilidades creadas en Jira
Comenzamos a reparar las vulnerabilidades, por regla general, de las críticas, que debían eliminarse con urgencia. Cuando esas vulnerabilidades terminaron, el equipo procedió a corregir los nuevos errores encontrados en el código. Y ya en la tercera etapa, por ejemplo, en el marco del cierre de alguna deuda técnica, también se eliminaron las viejas vulnerabilidades restantes.
No estándar como estándar
Este, a primera vista, un proceso no tan complicado tenía dos serias limitaciones. Primero, para analizar las aplicaciones de Android (es decir, escritas en Java), necesitábamos un ensamblaje. Y en segundo lugar, iOS necesitaba máquinas macOS en las que nuestro agente estaría instalado y habría un entorno que nos permitiera crear aplicaciones. Nos ocupamos de las aplicaciones de Android de manera bastante simple: escribimos nuestras partes en los scripts que ya estaban disponibles para los desarrolladores, que también se lanzaron de acuerdo con el programa. Nuestras partes de los scripts empezaron a construir el proyecto en la configuración más amplia, que se envió a Solar appScreener para su análisis. Para verificar las aplicaciones de iOS, instalamos nuestro agente MacOS en una máquina Mac, que ensambló el código y también envió el código al analizador para escanearlo a través de GitLab CI. Además, como en el caso de otros tipos de software,el oficial de seguridad revisó los resultados del análisis, los verificó y envió los problemas de reparación a Jira.
También nos referimos a portales y aplicaciones móviles como cualquier proyecto escrito en Java; los recopilamos y analizamos de manera similar.
En aquellos proyectos en los que no había CI / CD, que era un requisito previo para nosotros, simplemente dijimos: “Chicos, si quieren analizar, recójalo manualmente y cárguelo en el escáner usted mismo. Si no tiene lenguajes Java o similares a JVM, Scala, Kotlin y otros, simplemente puede cargar el código en el repositorio desde el enlace y todo estará bien ".
Complejidad del proyecto
Como puede ver en lo anterior, en esta pila de aplicaciones, el principal problema fue la falta de CI / CD en muchos proyectos. Los desarrolladores a menudo construían a mano. Comenzamos a integrar nuestro analizador con los portales de Sharepoint en C #. Ahora C # ha cambiado más o menos a sistemas Linux, aunque no del todo en toda regla. Y cuando el proyecto estaba en pleno apogeo, este lenguaje todavía funcionaba en Windows, y tuvimos que instalar un agente en Windows para GitLab. Este fue un verdadero desafío ya que nuestros especialistas están acostumbrados a usar comandos de Linux. Se necesitaban soluciones especiales, por ejemplo, en algunos casos era necesario especificar la ruta completa al archivo exe, en otros no, algo tenía que ser revisado, etc. Y luego de la implementación de la integración con Sharepoint, el equipo del proyecto de aplicación móvil en PHP dijo,que tampoco tienen corredor y quieren usar C # -ovskiy. Tuve que repetir las operaciones por ellos.
Resumen
Como resultado, a pesar de un parque de tecnologías, equipos y procesos tan heterogéneo, logramos agrupar los casos principales de este caso en varios pipelines, automatizar su ejecución, en su caso, e implementarlos. En nuestro ejemplo, pudimos asegurarnos de que:
- La solución que estamos implementando es lo suficientemente antigua como para brindar la flexibilidad que necesita para crear procesos DevSecOps en entornos de implementación radicalmente diferentes. La flexibilidad se logra a través de un gran conjunto de integraciones incorporadas y personalizadas, sin las cuales los costos de mano de obra para la implementación aumentarían significativamente o lo harían imposible;
- . 3-4 ;
- DevSecOps DevOps , , . win-win - .
Recuerde: esta es la primera parte de una serie de artículos sobre la construcción de un proceso de desarrollo seguro en un gran minorista. En el próximo post, revelaremos los detalles de la implementación de este proyecto en la familia de aplicaciones SAP.
¿Ha tenido su propia experiencia en la implementación de proyectos similares? ¡Estaremos encantados de que comparta con nosotros sus casos de implementación de prácticas de desarrollo seguro en los comentarios!
Autor: Ivan Staroselsky, Jefe del Departamento de Operación y Automatización de Sistemas de Información