SurveyMonkey conversa con Snyk sobre seguridad para desarrolladores durante un crecimiento acelerado

Muchas empresas recurren a los CISO o a los equipos de cumplimiento para gestionar la seguridad durante todo el desarrollo de software. Sin embargo, esta práctica suele mantener las consideraciones de seguridad separadas de los desarrolladores. Los CISO pueden asignarles tareas de seguridad, pero si los desarrolladores no piensan en la seguridad con regularidad, es posible que las pasen por alto. Una forma de cerrar esta brecha es incorporar a un líder de ingeniería de seguridad (similar a un promotor de seguridad): alguien que defienda la seguridad como parte del proceso general de ingeniería.

Durante una reciente mesa redonda, Simon Maple, CTO de campo en Snyk, conversó 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 ofrecen visibilidad y la creación de un enfoque de camino pavimentado para motivar a los desarrolladores a enfocarse en la seguridad en organizaciones con un crecimiento acelerado. SurveyMonkey usa Snyk Open Source, Snyk Container y Snyk Code para integrar la seguridad en todo su proceso de desarrollo. Este es un resumen de la conversación.

Crear coherencia y visibilidad

Cuando Craik se incorporó a SurveyMonkey, la empresa usaba una arquitectura de microservicios. Cada equipo era responsable de sus propios servicios, desde el diseño y la creación hasta la implementación y el soporte. Esto llevó a que cada equipo hiciera lo que quería: todos agregaban complementos a sus propias canalizaciones y usaban sus herramientas preferidas. Esto dificultaba la trazabilidad. No había una forma clara de saber de dónde obtenían los desarrolladores los contenedores ni cuántas dependencias tenían. En ese entorno, la mayor preocupación de Craik era la gestión del código abierto. Preguntó si había alguna forma de hacer seguimiento del uso de licencias o generar una declaración de atribución confiable. Pero, como todo se gestionaba manualmente, la respuesta solía ser no.

[Los desarrolladores decían]: «Tengo 80.000 dependencias en mis proyectos. ¿Cómo sé qué estoy incorporando? ¿Y tengo que buscar todas estas licencias?». Ahí empezamos: necesitábamos ayudar a los desarrolladores a responder esas preguntas, no obligarlos a hacer cosas solo por motivos de seguridad.

Gracias a su experiencia, Craik sabía que ese era el primer desafío que debía abordar: establecer visibilidad y agregar gobernanza. Antes había trabajado en una empresa que lanzaba productos rápidamente, pero la posibilidad de comprender las versiones de los paquetes y los riesgos del código abierto no se abordó hasta que un cliente lo pidió. Por eso, en SurveyMonkey, antes de pensar en la visibilidad, se enfocó en la coherencia. Necesitaba establecer una cultura de DevOps en la que los desarrolladores pudieran delegar la creación de una canalización a un grupo designado que se encargaría de gestionarla. Una vez que logró que la gente adoptara esa idea, fue fácil crear una sola canalización de compilación. Llegar a ese artefacto de compilación fue el primer paso. Pronto pasó a buscar herramientas que ofrecieran visibilidad más allá de la canalización y permitieran ver lo que los desarrolladores hacían en sus equipos.

Ofrecer mejores herramientas y datos

A los desarrolladores les gusta encontrar soluciones por su cuenta: incorporan lo que necesitan para resolver un problema en su equipo o en su IDE. Craik quería definir y dejar claro qué incorporaban los desarrolladores durante la fase de creación de prototipos. Quería que tuvieran herramientas que reflejaran lo que ocurría en la canalización de compilación y dentro de su IDE o línea de comandos.

¿Cómo les damos [a los desarrolladores] buenas herramientas que funcionen igual en sus equipos y en la canalización de compilación? Identificarlo e implementarlo… fue fácil de adoptar para los desarrolladores una vez que supieron que reflejaba la canalización. La coherencia es clave.

También quería ofrecerles buenos datos a los desarrolladores. Por ejemplo, facilitarles la tarea de determinar si un paquete es viable para un proyecto o si deberían buscar otro. La mejor manera de hacerlo es con datos. Cuando los desarrolladores saben que tienen a su disposición algo como Snyk Advisor y pueden encontrar rápidamente métricas —qué tan popular es un paquete o cuál fue su problema más reciente—, comprenden la complejidad. Craik dice que este fue uno de los factores decisivos para asumir su cargo actual: poner datos confiables en manos de los desarrolladores y luego confiar en que tomarán las decisiones correctas.

Crear un camino pavimentado

Luego, Craik empezó a trabajar en una infraestructura de compilación común. Usó un repositorio de artefactos compartido (en su caso, Artifactory, aunque hay muchas opciones que funcionan). El objetivo principal era que los desarrolladores siempre descargaran los artefactos del registro. Este es un paso vital en una organización con un crecimiento acelerado, donde un equipo de desarrolladores cada vez más grande podría implicar una infraestructura también más grande (y sin regular). Pero Craik no quería que el equipo de seguridad fuera un obstáculo. Les decían a los desarrolladores: «Dirige tu archivo de configuración favorito a este sistema de artefactos y, si lo que necesitas no está ahí, el sistema lo descargará por ti. Te ayudará». Al principio, tuvieron que promover la idea para lograr que los desarrolladores hicieran el cambio. Pero, una vez que todos descargaban sus artefactos a través de ese único clúster, obtuvieron visibilidad para saber qué iba a dónde y cuándo, y qué versiones estaban en uso.

El equipo de Craik sí permitía que los desarrolladores trabajaran fuera de su canalización, pero en cuanto intentaban enviar un PR, este fallaba. La canalización de compilación que ejecuta las pruebas desde GitHub no podía descargar contenido directamente de Internet; solo lo hacía desde su repositorio de artefactos. Así que, si los desarrolladores adoptaban de antemano el comportamiento esperado y usaban el almacén de artefactos, no había ningún problema.

¿Cómo lograron que los desarrolladores no vieran la seguridad como un obstáculo? Lo hicimos con un enfoque cordial. Siempre usamos incentivos positivos. Les dijimos: «Cuando usas el repositorio único de artefactos, no tienes que preocuparte por los paquetes maliciosos ni por las licencias inadecuadas, porque podemos analizar todo a medida que ingresa. Podemos asegurarnos de que no hagas algo incorrecto». Así, los desarrolladores cambiaron su percepción de la seguridad: dejaron de verla como algo adversarial y empezaron a ver al equipo como personas que responden preguntas. Estamos aquí para ayudar, no para obstaculizar.

Promotores de seguridad: una iniciativa desde las bases

Mientras el equipo de Craik mantenía el camino pavimentado, algunos desarrolladores de SurveyMonkey se convirtieron gradualmente en promotores de seguridad. Los desarrolladores con más experiencia enseñaban a los integrantes nuevos del equipo sobre el repositorio de artefactos, cómo identificar señales en los PR y a quién acudir para hacer preguntas. Craik lo describe como «la idea general de trasladar el soporte de primer nivel a los equipos de desarrollo». No formalizó un programa de promotores de seguridad, porque, a medida que la gente se incorporaba al equipo, enfocarse en la seguridad simplemente se convertía en un hábito aprendido.

Cuando los desarrolladores auditan la seguridad de su propio código, el equipo de seguridad puede facilitarles el trabajo y apoyarlos cuando necesitan ayuda. Craik señala que, con un buen camino pavimentado y un conjunto de herramientas —incluidas las herramientas de Snyk, que facilitan detectar y corregir vulnerabilidades—, el equipo de seguridad puede iniciar nuevas compilaciones de los artefactos si hace falta, sin tener que molestar a los desarrolladores.

Los datos que obtenemos de nuestras herramientas y de nuestra canalización realmente permiten que los desarrolladores tomen decisiones fundamentadas.

Compartir responsabilidades y objetivos

En una cultura exitosa de shift left, los desarrolladores quieren encargarse de los requisitos de seguridad desde el principio. La validación les permite avanzar más rápido para completar el trabajo que genera ingresos. El equipo de seguridad no se acerca a los desarrolladores para decirles: «Tienen que seguir estos pasos por seguridad». En cambio, los desarrolladores acuden al equipo de seguridad y dicen: «Veo un problema en este paquete. ¿Está bien si sigo adelante?». El equipo también busca compartir la responsabilidad: en lugar de culpar a alguien por una vulnerabilidad que pudo haberse filtrado, corrigen el problema lo antes posible y luego conversan sobre lo que aprendieron.

Apoyar a los desarrolladores también implica permitir que se apoyen entre sí. Cuando el equipo de Craik implementó Snyk para detectar vulnerabilidades, no lo convirtió en un bloqueo en GitHub. En cambio, permitió que los desarrolladores con más experiencia asesoraran a los más nuevos durante las revisiones de código y de PR. Un desarrollador sénior podría decir: «Esta X roja significa que tienes un problema. Sí, técnicamente todavía puedes fusionar el código, pero esto es lo que está pasando ahora». No impusieron reglas estrictas desde el primer día; en cambio, construyeron una cultura colaborativa. La mejor estrategia fue ampliar el uso de las herramientas de Snyk al ritmo adecuado para los equipos de SurveyMonkey.

Mira la charla completa para descubrir más ideas valiosas sobre seguridad para desarrolladores.