Skip to main content

Resumen de SnykCon: automatizar para mayor cumplimiento y bucles de comentarios más rápidos

Escrito por:

13 de abril de 2022

10 minutos de lectura

En DevSecOps, la automatización es clave porque permite aumentar la eficiencia. Al automatizar tareas del ciclo de vida de desarrollo de software, podrás integrar muchas herramientas al flujo de trabajo. Además, esta automatización les permite a quienes se encargan del desarrollo, el mantenimiento y la seguridad dedicarse a buscar soluciones creativas para problemas complejos, en lugar de dedicar tiempo valioso a tareas manuales y repetitivas.

En SnykCon 2021, dos de las presentaciones estaban dedicadas a la automatización. Sam Hodgkinson y Ben Davies de Citrix contaron cómo utilizaron la automatización para optimizar el proceso de aprobación de licencias de código abierto. David Wiggs de Bain detalló cómo el empleo de la automatización puede habilitar el uso de pipelines como servicio y explicó cómo su equipo integró la seguridad en el pipeline CI/CD. En ambas sesiones, se resaltó cómo la automatización puede fortalecer un flujo de trabajo de desarrollo.

Automatización de aprobaciones de licencias de código abierto

Muchas personas saben del software de código abierto, pero no tantas conocen qué son las licencias de código abierto. El código abierto lo escriben desarrolladores y está disponible para uso público. Por otro lado, las licencias de código abierto distinguen cómo y cuándo puedes usar un paquete de código abierto. La automatización permite detectar y analizar las licencias de código abierto presentes en el código. De esta manera, recibirás alertas sobre las restricciones de licencia que se aplican a los paquetes de código abierto de modo que puedas compararlas con las políticas legales internas para garantizar que puedas utilizar el código.

Los desafíos que encontraron

En Citrix, el equipo de ingeniería buscaba la forma de encontrar todas las licencias de código abierto de un proyecto mientras se conservaba la compatibilidad con los muchos gestores de paquetes y lenguajes usados en toda la organización. También necesitaban controlar las compilaciones de CI/CD según el cumplimiento de las licencias y colaborar con el equipo de asuntos legales para crear políticas mejor definidas para todo el personal.

Para resolver esto, Sam y Ben analizaron la plataforma de Snyk. Su objetivo era crear un flujo de trabajo sin interrupciones y enfocado en las personas que no representara un problema para el equipo de ingeniería (o el de asuntos legales); las interacciones simplificadas para usuarios que podían desarrollar con las herramientas de Snyk cumplieron sus deseos.

A continuación, investigaron cómo sumar en una API automatizada todo el proceso de creación de políticas para un marco legal, poniendo atención en que la solución pudiera escalarse en el futuro.

Con los resultados de Snyk, Sam y Ben pudieron tomar decisiones normativas con la API de políticas y ofrecer comentarios fáciles de implementar para que los desarrolladores tomaran decisiones respecto de las políticas aceptadas o rechazadas.

La solución que desarrollaron

Crearon un pipeline CI/CD, a partir del código fuente que pasa directo por la CLI de Snyk. Snyk analiza el código fuente y muestra información de la licencia. Esta información pasa a través de una puerta de licenciamiento que decide si debe “anularse” algún fragmento de código según el uso de la licencia. El código que pasa por la puerta de licenciamiento se envía a la API de políticas, que lo aprueba o lo rechaza. (Las políticas provienen del equipo de asuntos legales de Citrix). En el 90 % de los casos, este proceso está completamente automatizado. En otros casos, podría generarse un ticket para que alguien del equipo de asuntos legales lo revise manualmente. De todos modos, esa revisión no queda perdida, sino que se inserta en la API de políticas para su aprobación y el desarrollador puede continuar con su trabajo.

“Al automatizar este proceso por completo, los procesos que demoraban dos semanas y la mayoría de las decisiones sobre políticas (el 90 %) ahora solo toman segundos. Es sencillamente genial”.

CitrixCitrix

Ben Davies

Software Engineer of Engineering Productivity, Citrix

Citrix creó un motor de políticas personalizadas según un complejo marco legal. Snyk ayudó a su equipo a superar barreras técnicas para automatizar todo el proceso, lo que permitió sumar seguridad al pipeline CI/CD. También se redujo el tiempo de resolución. En un proceso automatizado, la mayoría de las decisiones sobre políticas tardan segundos. Sam y Ben ahora utilizan las herramientas de Snyk como parte de la configuración de compilación, y la tecnología se encarga de sí misma.

Cómo cerrar el bucle de comentarios

Sumar seguridad a un pipeline de desarrollo de software no es algo nuevo. Sin embargo, las personas suelen enfocarse en los aspectos técnicos de un pipeline y no en cómo este se utiliza. David Wiggs de Bain se preguntaba: “¿Los desarrolladores usan el pipeline de desarrollo de software que se ofrece y realmente obtienen lo que necesitan?”. Piensa en las herramientas de seguridad y las herramientas de pruebas como los productos que los desarrolladores usan. Si el pipeline es un producto, ¿los usuarios (es decir, los desarrolladores) lo están aprovechando correctamente?

Los tres pilares de la automatización

El modelo de “pipeline como servicio” comienza con un repositorio operativo. Luego, se podría sumar un repositorio de “acciones personalizadas” que defina de dónde los pipelines obtienen los pasos. Entonces podrías tener un repositorio para herramientas: un envoltorio de API, una herramienta con repositorios o cualquier proceso de automatización específico de la herramienta.

Estos tres primeros pilares reducen al mínimo la cantidad de sitios donde ocurren y se rastrean cambios. Cuando los usuarios sugieren cómo mejorar el proceso, puedes aplicar esos cambios en un solo sitio en lugar de repetirlos en varias ubicaciones.

Cómo aplicar el flujo de trabajo

Con esta configuración, se siguen los siguientes pasos:

  1. Se activa el flujo de trabajo del pipeline (considéralo como un pipeline “en ejecución”) y se extrae el repositorio de acciones personalizadas.

  2. El archivo action.yml extrae el repositorio con herramientas específicas de seguridad.

  3. Se ejecutan las secuencias de comandos específicas de las herramientas. De este modo, las actualizaciones o solicitudes de funcionalidades se realizan en un solo lugar y, siempre que se consume una acción personalizada, se heredan los cambios.

Veamos la arquitectura de este pipeline de forma ascendente, a partir del repositorio con herramientas de seguridad. Este repositorio puede contener secuencias de comandos que definen varias funciones. Por ejemplo, podría llamarse a una secuencia de comandos de PowerShell que utiliza la API de Snyk para verificar si existe un determinado repositorio en la plataforma de Snyk; en caso contrario, se importa el repositorio. En este momento, se ejecutan algunas secuencias de comandos y el resto de la arquitectura permite heredarlas para un determinado repositorio operativo.

Ahora subamos un nivel. El repositorio de acciones personalizadas extrae el repositorio con las herramientas de seguridad y ejecuta una secuencia de comandos específica de seguridad. Con acciones compuestas, puedes dirigir muchos comandos en un único paso. Esto crea una capa de abstracción que simplifica la experiencia de usuario, pero también te permite llamar a varias secuencias de comandos y agregar dependencias.

Esto sucede dentro del archivo action.yml, que te permite establecer las versiones sin necesariamente tener que sumar cambios a muchos repositorios operativos.

En el nivel superior, el repositorio operativo puede ver la acción personalizada de GitHub. Cuando se inicia el flujo de trabajo del repositorio operativo, se extrae el repositorio de acciones personalizadas y se lleva el contenido al tiempo de ejecución. Deberás volver a hacer una extracción anidada, que te permite utilizar el archivo action.yml y las secuencias de comandos del repositorio con herramientas, todo durante el tiempo de ejecución del repositorio operativo.

“\[Sumar seguridad al pipeline] es una excelente forma de devolverles esa información a los desarrolladores sin que necesariamente deban abandonar sus herramientas”.

David Wiggs

Manager, Bain

Desde la perspectiva del usuario, se agregaron varias secuencias de comandos personalizadas, pero de forma “nativa”. Con las herramientas de Snyk, se agregó seguridad al pipeline mediante acciones en GitHub. Si las acciones de GitHub pueden agregar herramientas de seguridad a un pipeline, los desarrolladores no necesitarán salir del espacio de trabajo que conocen (es decir, GitHub) para obtener información de la seguridad del proceso de desarrollo. De este modo, se creó un bucle de comentarios más veloz de forma interna, sin pedirles a los desarrolladores que crearan cambios en varios espacios.

Cómo sumar la automatización para mejorar los flujos de trabajo

La automatización suma eficiencia a toda la organización. En estas presentaciones, se describen dos ejemplos de cómo aprovechar la automatización, pero existen muchos más. La plataforma de Snyk brinda varias herramientas para sumar la automatización a los flujos de trabajo e incorporar estándares de seguridad sin inconvenientes durante todo el proceso de desarrollo.

Snyk Top 10: Vulnerabilites you should know

Find out which types of vulnerabilities are most likely to appear in your projects based on Snyk scan results and security research.