Cómo crear una cultura moderna de DevSecOps: lecciones de Jaguar Land Rover y Asda
Brian Piper
21 de febrero de 2024
0 minutos de lectura
Las personas, los procesos y las herramientas influyen en la capacidad de una organización para mantener un programa sólido de seguridad de aplicaciones. En un panel reciente de Black Hat Europe, Snyk conversó con dos clientes —Jaguar Land Rover (JLR) y Asda— sobre los desafíos particulares que enfrentan al gestionar equipos de desarrollo, incorporar nuevas herramientas de seguridad y crear un programa moderno de DevSecOps en toda la organización.
JLR comenzó a fabricar automóviles en 1935. Tras varias fusiones y adquisiciones —y casi un siglo de innovación tecnológica—, la empresa emplea hoy a 3,000 desarrolladores en todo el mundo que trabajan en diversos proyectos de software. Mike Welsh, arquitecto principal de seguridad empresarial de DevSecOps en JLR, tiene la tarea de mantener estrategias para toda la empresa que garanticen prácticas de desarrollo seguro y conecten equipos diversos mediante procesos unificados.
En cambio, Asda se encuentra en las primeras etapas de creación de su programa de DevSecOps. Aunque es una marca consolidada, la reciente separación de Walmart ha dejado a Asda operando como “la startup más grande de Europa”. Ruta Baltiejute, líder de DevSecOps en Asda, está creando desde cero la cultura de DevSecOps de la empresa, incorporando nuevas herramientas y trabajando de manera transversal con ingenieros y personal de seguridad para sentar las bases de su enfoque de desarrollo seguro de aplicaciones.
Aunque las dos empresas se encuentran en etapas de madurez muy distintas en lo que respecta a crear una cultura de DevSecOps, hay algunas lecciones en común que ambas han aprendido a lo largo del camino.
1. Involucra a los desarrolladores en la toma de decisiones
Durante el panel, Mike y Ruta coincidieron en que contar con el apoyo de los desarrolladores es fundamental para crear una cultura sólida de DevSecOps. Ambos recomendaron a otros profesionales de DevSecOps asegurarse de que los ingenieros participen en todas las decisiones, desde sugerir nuevas herramientas de desarrollo hasta ejecutar una prueba de concepto. Esta colaboración es esencial para evitar que los ingenieros se resistan a los requisitos de seguridad o ignoren las herramientas que se les imponen. Mike sugiere que “es muchísimo más fácil convencer a las personas de adoptar y seguir usando las herramientas que seleccionaste si participaron en el proceso de selección”.
Sin ese apoyo, la adopción de nuevos procesos o herramientas se verá afectada y supondrá un problema enorme para la integridad de tu programa. Para Mike y JLR, es una gran preocupación. La empresa emplea a miles de ingenieros en EMEA, APAC y América. Mike necesitaba encontrar herramientas que funcionaran para todos y que todos estuvieran dispuestos a usar, para que la empresa pudiera tener visibilidad del 100 % de su base de código y conocer las vulnerabilidades pertinentes. Como dijo Mike: “No tiene sentido ver solo el 10 % de tu base de código y tratar de determinar si es seguro o no”.
Snyk fue la opción ideal. Es una solución reconocida en el sector y los miembros de la comunidad de desarrolladores de JLR la recomendaban con frecuencia. Con Snyk Open Source, Snyk Container y Snyk Code, Mike pudo estandarizar las políticas y los procesos del equipo e integrarlos con Snyk. Ahora, todos los desarrolladores pueden usar Snyk para identificar vulnerabilidades. Gracias a una gran cantidad de automatizaciones que crearon con la API de Snyk, JLR puede analizar de manera eficaz la enorme cantidad de 14,000 proyectos de su sistema de gestión de código. Es una solución que permite a los desarrolladores trabajar con más eficiencia y producir código más seguro.
2. Enfoca los cambios en los procesos desde la perspectiva de los beneficios
Antes de incorporar cualquier novedad, es importante asegurarse de que los cambios en los procesos o las nuevas herramientas que planeas implementar aporten un beneficio práctico al equipo de ingeniería. Después de todo, para adoptar un proceso nuevo con entusiasmo, los ingenieros deben entender cómo los beneficiará.
Ruta recomienda investigar para entender los puntos de fricción de los desarrolladores y comunicarles los resultados para que también los comprendan. Dedica tiempo a observar cómo trabajan y comenta en voz alta lo que notas. Observa sus procesos y señala los distintos puntos de fricción que encuentran durante el día (por ejemplo, un proceso que consume mucho tiempo). A veces, se trata de un problema conocido que los desarrolladores estarán encantados de explicar con más detalle; otras veces, puede ser algo que ni siquiera habían notado o que no reconocían como una oportunidad de mejora.
Una vez que entiendas cómo beneficiará a los desarrolladores un requisito, debes comunicarles esos beneficios. Explícales cómo y por qué un nuevo proceso hará que su trabajo diario sea más fácil, seguro o eficiente.
En Asda, Ruta encontró cierta resistencia a las nuevas herramientas y los nuevos procesos, sobre todo por parte de empleados con más antigüedad y contratistas. Tras separarse de Walmart, la empresa quedó en una situación particular: en algunos aspectos operaba como una entidad nueva y, en otros, como una empresa antigua. Si a esto se suma un crecimiento acelerado (de hecho, el programa de ingeniería se triplicó), es natural que los ingenieros se resistan.
Ruta y su equipo aprovecharon la oportunidad única de hacer crecer al mismo tiempo los equipos de ingeniería y seguridad desde cero, y fomentaron la colaboración con los desarrolladores mientras evaluaban muchas soluciones del mercado. Al final, Snyk resultó ser la mejor opción para Asda, que adoptó toda la plataforma Snyk (Snyk Open Source, Snyk Code, Snyk IaC y Snyk Container). Así, los ingenieros obtuvieron beneficios prácticos en su trabajo diario y el equipo de seguridad pudo atender sus inquietudes y cumplir con sus requisitos.
¿Tienes un equipo particularmente resistente? Si nada más funciona, Mike sugiere recurrir a la gamificación. Los números lo demuestran, y a los ingenieros les encanta ver la diferencia concreta entre un enfoque y otro. Sé transparente con los resultados de los distintos equipos que aplican diversos procesos para comunicar eficazmente los beneficios de cada uno.
3. Simplifica el proceso de incorporación
Por más beneficioso que sea un proceso nuevo, los desarrolladores solo escucharán tu propuesta y lo adoptarán si les resulta fácil hacerlo.
Como les recordó Ruta a los asistentes: “Nunca lograrás que un desarrollador lea un documento de 50 páginas sobre cómo debe hacer algo en la empresa. Si le das las herramientas y una manera sencilla de hacerlo, seguirá esas políticas correctamente”.
4. Aprende de las experiencias pasadas, en equipo
En teoría, la colaboración es excelente. Pero, para asumir responsabilidades, lo mejor es formalizar un proceso de colaboración que garantice que se escuchen todas las voces. Es probable que tu equipo tenga muchos conocimientos y experiencias en común. ¿Qué mejor lugar para buscar nuevas ideas o comentarios sobre herramientas y procesos?
En JLR, Mike y su equipo crearon un DevSecOps Guild, integrado por representantes de distintas áreas de la empresa con diversas experiencias profesionales. Los representantes se reúnen para hablar sobre herramientas que han usado antes o que podría valer la pena evaluar. El conocimiento colectivo del grupo ayuda a JLR a formalizar sus iniciativas de colaboración y reducir sus prioridades entre la gran variedad de herramientas del sector.
En una cultura de DevSecOps, la colaboración es esencial
En esencia, cada lección aprendida destaca la importancia de la colaboración entre los equipos de seguridad y desarrollo. Sin importar en qué etapa de tu camino hacia DevSecOps te encuentres, la solidez y continuidad de tu programa dependen del apoyo de todas las personas involucradas. Consulta la sesión completa de Black Hat para profundizar en estas lecciones.
¿Buscas una herramienta que les encante a tus desarrolladores y a tus equipos de seguridad? Descubre la moderna plataforma de seguridad para desarrolladores de Snyk.
