Resumen de SnykCon: automatización para mejorar el cumplimiento y agilizar los ciclos de retroalimentación
13 de abril de 2022
0 minutos de lecturaLa automatización es un componente clave de DevSecOps porque aumenta la eficiencia. Automatizar el trabajo durante el ciclo de vida del desarrollo de software te ayuda a integrar varias herramientas en tu flujo de trabajo. También permite que los desarrolladores, mantenedores y referentes de seguridad se concentren en crear soluciones innovadoras para problemas complejos, en lugar de dedicar tiempo a tareas manuales tediosas.
Dos de las presentaciones de SnykCon 2021 se centraron en la automatización. Sam Hodgkinson y Ben Davies de Citrix explicaron cómo usaron la automatización para agilizar el proceso de aprobación de licencias de código abierto. David Wiggs, de Bain, nos ofreció un análisis detallado de cómo usar la automatización para habilitar pipelines como servicio y explicó cómo su equipo integró la seguridad en su pipeline de CI/CD. Ambas sesiones destacaron el uso de la automatización para fortalecer los flujos de trabajo de desarrollo.
Automatización de la aprobación de licencias de código abierto
Muchas personas conocen el software de código abierto, pero no tantas conocen las licencias de código abierto. El código abierto lo escriben desarrolladores y está disponible gratuitamente para el público. Las _licencias de código abierto determinan cómo y cuándo puedes usar un paquete de código abierto. La automatización puede detectar y analizar las licencias de código abierto en tu código. Esto te alerta sobre las restricciones de licencia que se aplican a los paquetes de código abierto para que puedas compararlas con las políticas legales internas y confirmar que tu código esté listo para usarse.
El desafío que enfrentaron
Los ingenieros de Citrix querían encontrar una forma de descubrir todas las licencias de código abierto dentro de un proyecto y, al mismo tiempo, admitir los numerosos administradores de paquetes y lenguajes de programación que se usan en toda la organización. También querían bloquear las compilaciones de CI/CD según el cumplimiento de las licencias y colaborar con su equipo legal para crear políticas más claras para todos.
Sam y Ben comenzaron a explorar la plataforma de Snyk para encontrar una solución. Querían crear un flujo de trabajo fluido y centrado en las personas, que no generara dificultades para los ingenieros ni para su equipo legal. Además, les gustaron las interacciones simplificadas con los usuarios que pudieron crear con las herramientas de Snyk.
Después, investigaron cómo incorporar todo el proceso de políticas del marco legal en una API automatizada, con la idea de hacer que la solución fuera extensible para necesidades futuras.
Con los resultados de Snyk, Sam y Ben pudieron tomar decisiones sobre políticas mediante su API y ofrecer a los desarrolladores comentarios fáciles de entender para que pudieran decidir sobre las políticas aprobadas o rechazadas.
La solución que crearon
Crearon un pipeline de CI/CD que comienza con el código fuente y pasa directamente por la CLI de Snyk. Snyk analiza el código fuente y devuelve información sobre las licencias. Esa información pasa por un control de licencias, que decide si se debe «rechazar» una parte del código según el uso de las licencias. El código que supera el control se envía a una API de políticas, que responde sí o no. (Las políticas provienen del equipo legal de Citrix). Este proceso está totalmente automatizado en el 90 % de los casos. En otros casos, puede generarse un ticket para que alguien del equipo legal lo revise manualmente. Pero esa revisión no se pierde: se incorpora a la API de políticas para su aprobación y el desarrollador puede seguir trabajando.
«Al automatizar por completo este proceso... redujimos un proceso de dos semanas a unos segundos en la mayoría de las decisiones sobre políticas: el 90 %. Lo cual es excelente».

Ben Davies
Software Engineer of Engineering Productivity, Citrix
Citrix creó un motor de políticas personalizado basado en un marco legal complejo. Snyk ayudó al equipo a superar las barreras técnicas para automatizar por completo el proceso y habilitar la seguridad en todo el pipeline de CI/CD. También redujeron el tiempo de resolución. Con un proceso automatizado, la mayoría de las decisiones sobre políticas se toman en segundos. Sam y Ben ahora activan las herramientas de Snyk como parte de la configuración de compilación y la tecnología se encarga del resto.
Cerrar el ciclo de retroalimentación
Incorporar seguridad en un pipeline de desarrollo de software no es una idea nueva. Sin embargo, a menudo las personas se enfocan en los aspectos técnicos del pipeline, en lugar de cómo se usa. David Wiggs, de Bain, preguntó: ¿los desarrolladores usan el pipeline de desarrollo de software que les proporcionas? ¿Obtienen lo que necesitan? Piensa en las herramientas de seguridad y pruebas como _productos que usan los desarrolladores. Entonces, si tu pipeline es un producto, ¿tus usuarios (los desarrolladores) pueden usarlo con éxito?
Tres pilares de la automatización
El modelo de «pipeline como servicio» comienza con un repositorio de trabajo. Después, puedes incorporar un repositorio de «acciones personalizadas» que defina de dónde se obtienen los pasos de los pipelines. Luego puedes tener un repositorio de herramientas: un contenedor de API, una herramienta de repositorio o cualquier automatización específica de una herramienta.
Estos tres primeros pilares reducen la cantidad de lugares donde se realizan y registran los cambios. Cuando los usuarios sugieren formas de mejorar el proceso, puedes hacer esos cambios en un solo lugar en vez de repetirlos en varias ubicaciones.
Ejecutar el flujo de trabajo
Esta estructura te prepara para los siguientes pasos:
Se activa el flujo de trabajo del pipeline (piensa en esto como la «ejecución» de un pipeline). Se extrae el repositorio de acciones personalizadas.
El archivo
action.ymlextrae un repositorio específico de una herramienta de seguridad.Se ejecutan los scripts específicos de cada herramienta. Así, las solicitudes de funciones o las actualizaciones se realizan en un solo lugar central y todos los que usan una acción personalizada heredan el cambio.
Veamos esta misma arquitectura de pipeline desde abajo, empezando por el repositorio de herramientas de seguridad. Este repositorio puede contener scripts que definan varias funciones. Por ejemplo, podrías llamar a un script de PowerShell que use la API de Snyk para comprobar si un repositorio determinado está en la plataforma de Snyk; si no lo está, lo importa. En este punto, se ejecutan algunos scripts y el resto de la arquitectura permite que esos scripts se hereden en un repositorio de trabajo determinado.
Ahora subamos un nivel. El repositorio de acciones personalizadas extrae el repositorio de herramientas de seguridad y ejecuta un script específico de seguridad. Con las acciones compuestas, puedes coordinar varios comandos como un solo paso. Esto crea una capa de abstracción que simplifica la experiencia del usuario y también te permite llamar a varios scripts e introducir dependencias.
Esto ocurre dentro del archivo action.yml, que te permite establecer versiones sin tener que introducir cambios en varios repositorios de trabajo.
En la capa superior, permites que un repositorio de trabajo acceda a la acción personalizada de GitHub. Cuando se inicializa el flujo de trabajo en el repositorio, se extrae el repositorio de acciones personalizadas y se incorpora su contenido al entorno de ejecución. Se realiza otra extracción anidada, que te permite aprovechar el archivo action.yml y los scripts del repositorio de herramientas, todo dentro del entorno de ejecución del repositorio de trabajo.
«[Integrar la seguridad en el pipeline] es una excelente manera de devolverles esa información a los desarrolladores sin que tengan que salir necesariamente de su entorno principal».
David Wiggs
Manager, Bain
Desde la perspectiva del usuario, incorporaste varios scripts personalizados de una forma «nativa». Integraste la seguridad en el pipeline con las herramientas de Snyk y las acciones de GitHub. Si las acciones de GitHub pueden integrar herramientas de seguridad en un pipeline, los desarrolladores no tienen que salir de su entorno de trabajo habitual (GitHub) para consultar información de seguridad sobre su proceso de desarrollo. Creaste un ciclo de retroalimentación más rápido «entre bastidores», sin pedirles a los desarrolladores que hagan cambios en varios lugares.
Explorar la automatización para mejorar los flujos de trabajo
La automatización puede aumentar la eficiencia en toda tu organización. Estas presentaciones describen dos ejemplos de cómo aprovecharla, pero hay muchos más. La plataforma de Snyk ofrece numerosas herramientas para incorporar la automatización a tus flujos de trabajo e integrar estándares de seguridad de forma fluida en todo tu proceso de desarrollo.
