Como parte de la cultura Devsecops, mantener el entorno de desarrollo/producción actualizado a nivel de sistema y de aplicación de forma regular, aporta muchas ventajas a los desarrolladores y a los clientes. Aplicar este enfoque a las dependencias del proyecto, puede aportar más seguridad. Las actualizaciones suelen incluir medidas de seguridad corregidas y, es menos probable que contengan vulnerabilidades.
Dejando a un lado la seguridad, la actualización de las dependencias trae un cierto número de errores corregidos que en su mayoría tienen un impacto positivo en la aplicación de nuestros proyectos.
También, puede ser mejor, actualizar de forma iterativa en pequeños incrementos que hacer actualizaciones a lo grande, de forma automatizada. Esto hace que el entorno esté sujeto a menos fallos y a menos riesgos de regresión.
Durante el desarrollo, no siempre es fácil seguir la evolución de las numerosas bibliotecas de las que dependen nuestros proyectos. Esto contribuye a la entropía de los proyectos y la consecuencia es, en el mejor de los casos, una deuda técnica latente que se acumula poco a poco, y en el peor de los casos, la inclusión de defectos de seguridad.
Dependabot es una poderosa herramienta para facilitar las actualizaciones. Veamos por qué…
¿Cómo funciona la herramienta ?
Version update
Dependabot es una herramienta ya totalmente integrada con github, que podemos utilizar para automatizar el análisis y las actualizaciones de dependencias de nuestros proyectos desarrollados en ruby JavaScript,python , php ,python .NET, Rust et Elixir.
Funciona analizando los archivos de dependencia de nuestros proyectos, verificando que no haya una versión más reciente en los repositorios oficiales, o de los proyectos (Github). Después del análisis, crea automaticamente pull request (o merge request para Gitlab) para las dependecias que no están al día. Normalmente, leerá el archivo correspondiente, en función del idioma que se especifique, package.json como ejemplo para el js.
Veamos como se traduce en Gitlab una vez el proyecto dependabot-script se ha clonado :
Después del proyecto dependabot-script sobre Gitlab, hay que crear un cron que ejecutará la pipelina.
=> menu CI / CD > Schedules :
- Fijamos la periodicidad : (1 vez por semana, 2 veces por semana…)
- La target branch : master, develop
- Añadimos las variables de entrada :
- PROJECT_PATH : el camino que apunta al proyecto que vamos a analizar (davidson/app_skills).
- PACKAGE_MANAGER_SET : la lista de gestores de dependencias a aplicar. (maven, npm, bundler, .).
- DIRECTORY_PATH : Si deseamos especificar el directorio que contiene el archivo manifiesto(package.json….).
- PULL_REQUEST_ASSIGNEE : un número entero que corresponde al ID de la persona cuya solicitud de fusión queremos asignar.
- GITLAB_HOSTNAME : git-twister.davidson-idf.fr
- GITLAB_ACCESS_TOKEN : Dependabot va a necesitar acceso a la api de Gitlab para crear una merge request. Se necesita, por lo tanto, un token para autentificarse con los derechos necesarios.
Un cron sobre el proyecto Dependabot-script solo puede manejar un proyecto a la vez. Esto implica que si queremos analizar más proyectos, necesitaremos crear un nouveau cron.
Una vez lanzadas las construcciones, obtendremos la MR de la siguiente manera :
Durante una solicitud de fusión que se realiza automaticamente, se generan las notas de publicación, el registro de modificaciones de la bilioteca, así como los comités de comentarios del MR para adelantarse al trabajo de revisión del impacto (si esta información está disponible, obviamente).
La frecuencia de actualización es programada y personalizada. Si se identifica una nueva versión de la dependencia, se, lanzará un MR proporcionando estas notas de la publicación.
Security update
Atención : Estas funcionalidades están pendientes de confirmar o no se encuentran en Gitlab.
Funcionalidad en Github
La herramienta tiene la flexibilidad práctica de discernir facilmente el tipo de MR generado. Por tanto, cada MR mostrará una etiqueta específica en función de las ganancias aportadas por la actualización de la dependencia en cuestión.
A continuación, podemos ver una MR de seguridad.
Cuando no son seguras o se descubre una nueva vulnerabilidad en una dependencia que ya tenemos, la herramienta nos informa con alertas de seguridad de las dependencias vulnerables.
Si puede sugerir un parche, envíar también una MR para poner al día nuestro manifiesto de dependecia, con la versión no vulnerable más próxima.
Dependabot identifica las vulnerabilidades de seguridad basándose en:
Da también una puntuación de compatibilidad de la dependencia que se quiere actualizar.
Atención : Es posible ignorar la configuración de una dependencia especificando a dependabot que no queremos que nos propongan una actualización sobre ella.
Mantenimiento :
Siendo un proyecto que ha sido asumido por GitHub, sus posibilidades de ser apoyado a largo plazo se ven aumentadas.
Integración del proyecto según nuestras necesidades :
Una de sus características más interesantes es el hecho de poder configurar la herramienta de forma que se adapte al proyecto en el que se está trabajando.
De hecho, es posible configurar el llamado « GITLAB_AUTO_MERGE » para fusionar automáticamente la MR cuando pase nuestras pruebas.
Requisitos previos para su utilización : Si lo vamos a usar solamente de manera preventiva y si queremos explotar su capacidad para hacer MR y hacer la fusión automáticamente sin la intervención del ser humano, necesitamos tener pruebas fiables de nuestro código. Todo este proceso de gestión automatizada de dependencias ,solo funciona si tenemos un conjunto de pruebas sólido.
En una frase :
Tener una cobertura de pruebas completa, hasta el punto que si se pasan las pruebas, estamos seguros de realizar la fusion de la rama principal.
