SurveyMonkey habla con Snyk sobre la seguridad de los desarrolladores durante el hipercrecimiento

Muchas empresas recurren a los directores de seguridad de la información o a los equipos de cumplimiento para gestionar la seguridad a lo largo del desarrollo del software. Pero esta práctica suele mantener las consideraciones de seguridad separadas de los desarrolladores. Los directores de seguridad de la información pueden asignar tareas de seguridad a los desarrolladores, pero si estos no piensan en la seguridad con regularidad, esas tareas pueden pasarse por alto. Una forma de salvar esta distancia es incorporar a un responsable de ingeniería de seguridad (similar a un defensor de la seguridad), alguien que defienda la seguridad como parte del proceso general de ingeniería.

Durante un debate reciente, Simon Maple, director de Tecnología de Campo en Snyk, habló con Craik Pyke, director sénior de Ingeniería de Seguridad, Nube y Almacenes de Datos en SurveyMonkey (ahora parte de Momentive). Hablaron sobre el uso de herramientas que proporcionan visibilidad —y sobre la creación de un enfoque más simple para animar a los desarrolladores a centrarse en la seguridad— en organizaciones de hipercrecimiento. SurveyMonkey utiliza Snyk Open Source, Snyk Container y Snyk Code para integrar la seguridad en todo su proceso de desarrollo. A continuación, hacemos un resumen de la conversación.

Crear coherencia y visibilidad

Cuando Craik se incorporó a SurveyMonkey, utilizaban una arquitectura de microservicios. Cada equipo era responsable de sus propios servicios, del diseño a la construcción, luego a la implementación y finalmente a la asistencia. Esto llevó a los equipos a hacer lo que querían: cada uno agregó complementos a sus propios pipelines y utilizó sus herramientas preferidas. Esto supuso un desafío para la trazabilidad. No había un seguimiento claro de dónde obtenían los desarrolladores los contenedores ni de cuántas dependencias tenían. En este entorno, la mayor preocupación de Craik era la gestión del código abierto. Se preguntaba si había alguna forma de rastrear el uso de licencias o de producir una declaración de atribución confiable. Pero como todo se gestionaba manualmente, la respuesta solía ser negativa.

\[Los desarrolladores decían]: “Tengo 80 000 dependencias en mis proyectos. ¿Cómo sé lo que estoy ingresando? ¿Y tengo que buscar todas esas licencias?”. Ahí fue donde empezamos: teníamos que ayudar a los desarrolladores a responder a sus preguntas, no obligarlos a hacer cosas porque fueran seguras.

Con su experiencia, Craik sabía que este era el primer desafío que había que abordar: establecer visibilidad y agregar gobernanza. Anteriormente trabajó en una empresa que enviaba productos con rapidez, pero la noción de poder comprender las versiones de los paquetes y los riesgos del código abierto implicados no se abordaba hasta que un cliente lo pedía. Así que, en SurveyMonkey, antes de pensar en la visibilidad, pensó en la coherencia. Necesitaba establecer una cultura DevOps, en la que los desarrolladores pudieran ceder el trabajo de construir un pipeline a un grupo designado que lo gestionara. Una vez que la gente se acostumbró a esa idea, fue fácil crear un único pipeline para la construcción. Llegar a ese artefacto de construcción fue el primer paso. Rápidamente pasó a buscar herramientas para la visibilidad más allá del pipeline, en lo que los desarrolladores estaban haciendo en sus máquinas.

Proporcionar mejores herramientas y datos

A los desarrolladores les gusta resolver las cosas: utilizan todo lo que necesitan para resolver un problema en su propia máquina o en su IDE. Craik quería articular y definir lo que los desarrolladores hacían durante la fase de creación de prototipos. Quería que tuvieran herramientas que reflejaran lo que ocurría en el pipeline de creación y en su IDE o línea de comandos.

¿Cómo conseguimos que \[los desarrolladores] dispongan de buenas herramientas que sean las mismas en sus máquinas que en el pipeline de creación? Identificar eso, y conseguir que se implementara... fue una tarea fácil para los desarrolladores una vez que supieron que reflejaba el pipeline. La coherencia es la clave.

También quería ofrecer a los desarrolladores buenos datos. Por ejemplo, facilitar a los desarrolladores la tarea de determinar si un paquete es viable para un proyecto o si deben buscar otro. La mejor forma de hacerlo es con datos. Cuando los desarrolladores saben que existe algo como Snyk Advisor, y pueden encontrar rápidamente métricas, como la popularidad de un paquete o su problema más reciente, entienden la complejidad. Craik afirma que este fue uno de los factores decisivos en su puesto actual: poner datos confiables en manos de los desarrolladores y confiar en que tomaran las decisiones correctas.

Construir un camino más simple

A continuación, Craik empezó a trabajar en una infraestructura de construcción común. Utilizó un repositorio común de artefactos (en su caso fue Artifactory, pero hay muchas variedades que sirven). El objetivo principal era que los desarrolladores siempre sacaran artefactos del registro. Este es un paso vital en una organización de hipercrecimiento, donde un equipo creciente de desarrolladores podría significar una infraestructura creciente (y no regulada). Pero Craik no quería que el equipo de seguridad actuara como un bloqueador. Les decían a los desarrolladores: “Apunta tu archivo de configuración favorito a este sistema de artefactos y, si lo que quieres no está ahí, el sistema lo buscará por ti. Te ayudará”. Tuvieron que hacer una campaña al principio para conseguir que los desarrolladores hicieran el cambio. Pero una vez que todos estaban tirando de sus artefactos a través de ese único clúster, obtuvieron visibilidad de lo que estaba ocurriendo, dónde y cuándo, y qué versiones se estaban ejecutando.

El equipo de Craik permitía a los desarrolladores trabajar fuera de su pipeline, pero en cuanto intentaban enviar una solicitud de cambio, fallaba. El pipeline de compilación que realiza sus pruebas desde GitHub no podía extraer información directamente de Internet, sino solo de su repositorio de artefactos. Así que, si los desarrolladores adoptaron el comportamiento esperado por adelantado y están utilizando el almacén de artefactos, no hay ningún problema.

¿Cómo lograron los desarrolladores que la seguridad no fuera un obstáculo? Lo hicimos con un enfoque amistoso. Utilizamos recompensas durante todo el proceso. Dijimos: “cuando vas al repositorio único de artefactos, no tienes que preocuparte por paquetes maliciosos o licencias incorrectas, porque podemos escanear las cosas a medida que llegan. Podemos asegurarnos de que no estás haciendo lo incorrecto”. Así que los desarrolladores cambiaron su visión de la seguridad, pasando de ser adversarios a ser simplemente personas que preguntan y responden. Estamos ahí para ayudar, no para entorpecer.

Defensores de la seguridad: una cuestión básica

Mientras el equipo de Craik mantenía un camino simple, algunos de los desarrolladores de SurveyMonkey se convirtieron gradualmente en defensores de la seguridad. Los desarrolladores más experimentados enseñaron a los miembros más nuevos del equipo el repositorio de artefactos, cómo encontrar señales en las solicitudes de cambios y a dónde dirigirse con sus preguntas. Craik llama a esto “una noción laxa de incorporar el soporte de primer nivel en los equipos de desarrolladores”. No formalizó un programa de defensores de la seguridad, porque a medida que la gente se unía al equipo, centrarse en la seguridad simplemente se convertía en un comportamiento aprendido.

Cuando los desarrolladores son auditores de seguridad de su propio código, los miembros del equipo de seguridad pueden actuar como facilitadores: personas que apoyan a los desarrolladores cuando necesitan ayuda. Craik señala que, con un camino más simple y un buen conjunto de herramientas, como las de Snyk, que facilitan la detección y corrección de vulnerabilidades, el equipo de seguridad puede iniciar la reconstrucción de los artefactos si es necesario, sin tener que molestar a los desarrolladores.

Los datos que obtenemos de nuestras herramientas y nuestro pipeline realmente permiten al desarrollador tomar una decisión inteligente.

Compartir responsabilidades y objetivos

En una cultura exitosa de cambio a la izquierda, los desarrolladores quieren gestionar los requisitos de seguridad por adelantado. La validación les permite avanzar con mayor rapidez para completar el trabajo orientado a los ingresos. El equipo de seguridad no se dirige a los desarrolladores para decirles “tienen que tomar estas medidas por motivos de seguridad”. Más bien, los desarrolladores acuden al equipo de seguridad y dicen: “Veo un problema en este paquete. ¿Puedo proceder?”. El equipo también se esfuerza por compartir la responsabilidad: en lugar de culpar a alguien por una vulnerabilidad que se haya podido escapar, remedian el problema lo antes posible y luego hablan de lo que aprendieron de él.

Apoyar a los desarrolladores también significa dejar que los desarrolladores se apoyen entre sí. Cuando el equipo de Craik lanzó Snyk para comprobar vulnerabilidades, no lo convirtieron en un bloqueador en GitHub. En su lugar, permitieron que los desarrolladores más veteranos asesoraran a los más jóvenes durante las revisiones de código y solicitudes de cambios. Un desarrollador sénior podría decir: “Esta X roja significa que tienes un problema. Sí, técnicamente todavía se puede fusionar el código mediante combinación, pero esta es la situación actual”. El primer día no se impusieron normas estrictas, sino que se creó una cultura de colaboración. El mejor enfoque consistió en adaptar las herramientas de Snyk al nivel adecuado para los equipos de SurveyMonkey.

Mira la charla completa para obtener más información sobre seguridad para desarrolladores.