Cómo Mulesoft impulsa una cultura que prioriza a los desarrolladores y desplaza la seguridad a la izquierda con Snyk
Gerald Crescione
30 de abril de 2024
0 minutos de lecturaAunque llevar la seguridad a la izquierda ha sido un tema popular durante aproximadamente una década, muchas organizaciones todavía tienen dificultades para hacerlo realidad. Existen muchos conceptos erróneos sobre lo que significa desplazar la seguridad a la izquierda y cómo pueden los equipos de desarrollo hacerse cargo de la seguridad sin alterar sus flujos de trabajo actuales. Por ejemplo, muchos equipos suelen pasar los problemas de seguridad a los desarrolladores en una etapa más temprana del ciclo de vida de desarrollo de software (SDLC), sin darles el contexto ni las herramientas adecuados para resolverlos de forma práctica.
El equipo de Mulesoft quería hacer algo distinto a simplemente lanzar alertas de seguridad a los desarrolladores. Creían que el verdadero éxito de DevSecOps depende de priorizar la experiencia del desarrollador. Pero para hacer realidad estos objetivos, Mulesoft necesitaba emprender un camino con las soluciones y los procesos adecuados.
En una charla informal reciente, Clinton Herget, Field CTO en Snyk, y Martin Adolfi, Sr. Engineering Manager en Mulesoft, conversaron sobre el recorrido de Mulesoft hacia DevSecOps. Profundizaron en la verdadera definición de seguridad para desarrolladores en las organizaciones aceleradas de hoy y hablaron sobre los desafíos y logros de Mulesoft al alcanzar sus objetivos de llevar la seguridad a la izquierda.
El desafío de Mulesoft para hacer realidad el enfoque de «desplazar la seguridad a la izquierda»
Cuando Adolfi y su equipo empezaron a profundizar en sus iniciativas de DevSecOps, tenían una visión clara de lo que significaba desplazar la seguridad a la izquierda y de lo que no significaba. El equipo notó una desconexión entre las expectativas de seguridad y la mentalidad habitual de los desarrolladores. Adolfi lo describió como «lanzar a la izquierda» en lugar de desplazar a la izquierda: enviar alertas e informes a los desarrolladores sin darles contexto ni orientación suficientes y luego esperar que resuelvan los problemas. Este enfoque termina costándoles tiempo y capacidad mental a los desarrolladores, porque los obliga a cambiar de contexto y a alejarse de un estado de concentración y productividad. Los aparta de lo que disfrutan hacer —programar e innovar—, lo que reduce su satisfacción laboral y genera tensiones entre los equipos de desarrollo y seguridad.
Para motivar a los desarrolladores a tener éxito en seguridad y, en última instancia, convertirse en referentes de seguridad, hay que ofrecerles el camino de menor resistencia. Según Adolfi, la clave está en empoderarlos para que resuelvan los problemas dentro de sus ciclos de retroalimentación actuales. Dijo: «Si el problema llega a convertirse en un ticket, ya es demasiado tarde… Hay que crear herramientas que estén dentro del ciclo de trabajo del desarrollador, en lugar de decir: “Tenemos un nuevo panel o un nuevo informe, y tienes que buscar la información que necesitas en esta herramienta”... [Como desarrollador], constantemente me interrumpen cuando estoy haciendo lo que quiero y lo que me resulta interesante. Tengo que consultar siete fuentes de datos distintas para hacer mi trabajo».
El equipo sabía que quería integrar los ciclos de retroalimentación de seguridad en los flujos de trabajo actuales de los desarrolladores, pero para lograrlo tenía que resolver algunos desafíos.
Primero, tenían que responder a los comentarios de los desarrolladores, quienes consideraban que había «demasiada burocracia» en el proceso de seguridad de las aplicaciones. Los equipos de desarrollo de Mulesoft sentían la presión de mantener los proyectos actuales mediante la aplicación periódica de parches, además de cumplir con los requisitos de cumplimiento y los SLA en las nuevas aplicaciones. Necesitaban un enfoque de seguridad que no agravara el problema de la burocracia.
Además, los pipelines de los equipos de desarrollo eran muy distintos entre sí, pero los desarrolladores valoraban ese nivel de libertad y no querían renunciar a él. Esta variedad de lenguajes, frameworks y microservicios dificultaba establecer un proceso de seguridad uniforme en toda la organización.
Los logros de Mulesoft en DevSecOps
Para responder a estos desafíos, Mulesoft necesitaba un socio de seguridad que priorizara a los desarrolladores. El equipo eligió la plataforma de Snyk porque se alineaba estrechamente con sus objetivos de DevSecOps.
Adolfi dijo: «Snyk sigue nuestra filosofía de desplazar la seguridad a la izquierda, ofrecer más valor e información, y explicarles a los desarrolladores cómo solucionar los problemas, con toda la información necesaria para comprender el impacto y la gravedad; todo eso».
Como Snyk se integra en los distintos entornos nativos de los desarrolladores y ofrece comentarios y sugerencias de corrección al instante, Adolfi y su equipo han simplificado con éxito el proceso para que los desarrolladores de Mulesoft encuentren y corrijan vulnerabilidades.
Adolfi dijo: «La principal razón por la que el equipo de experiencia del desarrollador se enfocó en Snyk y no en el resto de nuestra pila tecnológica es que Snyk está más cerca del desarrollador».
Snyk + Mulesoft: lo que viene
Mientras el equipo de Mulesoft sigue protegiendo el SDLC con una mentalidad DevSecOps, continuará guiándose por el principio de desplazar la seguridad a la izquierda al empoderar a los desarrolladores. Para empoderar a los equipos de desarrollo, hay que darles las herramientas y los procesos que necesitan para corregir vulnerabilidades con éxito en tiempo real y evitar, en la medida de lo posible, los cambios de contexto.
En la siguiente etapa de su recorrido de desarrollo, el equipo de Mulesoft planea incorporar más herramientas de IA en sus pipelines. Ven oportunidades de usar la IA tanto para escribir como para revisar código.
Para conocer más sobre el recorrido de Mulesoft en seguridad para desarrolladores y sus logros en DevSecOps, escucha la conversación completa de Adolfi y Herget.
