Mejorar la experiencia de desarrollo con herramientas de seguridad en Pinterest

El uso seguro de bibliotecas de código abierto es una prioridad constante en las grandes organizaciones. Uno de los principales desafíos es integrar herramientas de seguridad en el flujo de trabajo de los desarrolladores y configurar un sistema que priorice la corrección de vulnerabilidades sin abrumarlos. Pero ¿cómo es un enfoque exitoso?

Nuestro Simon Maple (director de tecnología de campo, Snyk) conversó con Kalpesh Dharwadkar (ingeniero de seguridad de productos, Pinterest) para conocer cómo Pinterest usa Snyk para crear prácticas de seguridad diseñadas para desarrolladores.

Tres prioridades principales: visibilidad, análisis y clasificación

Pinterest usa mucho software de código abierto en su stack de desarrollo, por lo que una biblioteca de código abierto vulnerable puede afectar considerablemente su perfil ejecutivo. Antes de que Kalpesh se incorporara a la empresa, usaban un sistema improvisado para crear vistas de sus bibliotecas de código abierto con NPM audit. Al incorporarse, Kalpesh quiso configurar un sistema centralizado que ofreciera visibilidad de todas las bibliotecas de código abierto en uso. Su equipo evaluó numerosas soluciones y eligió Snyk por dos motivos principales: sus funciones diseñadas para desarrolladores y la compatibilidad con repositorios específicos de cada lenguaje, como Bazel (la herramienta de compilación que eligieron). Kalpesh describió sus principales prioridades de seguridad al comienzo de la conversación:

En Pinterest, nos enfocamos en tres aspectos principales para proteger el código abierto: obtener visibilidad de las bibliotecas vulnerables, contar con herramientas en todo el stack, además de analizar para encontrar correcciones, y, por último, clasificar las vulnerabilidades.

Kalpesh explicó que usan Jenkins para las compilaciones. Analizan el sistema de compilación con Snyk CLI y luego cargan los resultados en la interfaz web de Snyk. Su primer objetivo es obtener visibilidad de todas las dependencias en sus repositorios de código y priorizar la corrección de las vulnerabilidades. Por eso, analizaron el Sistema común de puntuación de vulnerabilidades (CVSS), que ofrece visibilidad de las vulnerabilidades. Si existe un exploit, usan la información de Snyk para determinar si la corrección tiene alta prioridad.

Agregar pruebas de seguridad en todo el pipeline

Luego, Simon preguntó sobre las pruebas en todo el pipeline de desarrollo y los desafíos que surgen al enseñar a los desarrolladores a usar Snyk. Kalpesh tiene una solución sencilla para este paso. Cuando comenzó a integrar Snyk en el pipeline de desarrollo, en lugar de darles acceso a la consola de Snyk, hizo que el análisis se ejecutara como un paso de la compilación de Jenkins. Después, empezó a encargarse de algunos de los “problemas fáciles de resolver” y pidió a los líderes técnicos o responsables de los proyectos que revisaran su trabajo. Esto despertó su interés en aplicar correcciones con las herramientas de Snyk y ayudó a conseguir una aceptación más amplia.

Clasificar vulnerabilidades de forma eficiente, priorizar correcciones y lidiar con Log4Shell

La conversación pasó a la clasificación de vulnerabilidades. Simon preguntó: “¿Qué señales o alertas buscas en tu lista de pendientes para poder decirles a los desarrolladores ‘estas son las cinco vulnerabilidades principales’ que deberían revisar?”. La solución de Kalpesh consiste en considerar la gravedad de la vulnerabilidad, si hay un exploit activo y si la vulnerabilidad se encuentra en un servicio expuesto a internet. Usa estos parámetros para priorizar las correcciones. Luego, se crea un ticket para que un desarrollador o responsable del servicio corrija la vulnerabilidad. El seguimiento de la información en el ticket ayuda a su equipo a entender si su evaluación de la vulnerabilidad coincide con lo que los desarrolladores consideran importante.

Se asigna el ticket al desarrollador. Es posible que nos responda: “Oye, no usamos esta función en particular que es vulnerable debido a la dependencia”. En ese caso, intentamos reducir la prioridad de la función.

Al hablar de Log4Shell, Simon le preguntó a Kalpesh cómo gestiona Pinterest una vulnerabilidad de día cero de gran alcance. Kalpesh recordó que, la mañana siguiente al anuncio de Log4Shell, su equipo declaró un incidente para investigar cuántos servicios estaban afectados. Había una opción disponible (una marca de JVM o una solución alternativa), que aplicaron a sus servicios Java, pero dependían de los responsables de los servicios para implementar todos los servicios, y eso lleva tiempo. La implementación de la solución alternativa ocupó a su equipo durante el fin de semana, porque querían asegurarse de que todos los servicios se hubieran implementado con la marca de JVM. Establecieron dos líneas de trabajo: una para detectar todos los servicios Java en Pinterest y otra para detectar los servicios que no estarían cubiertos por la solución alternativa de la marca de JVM. Para los servicios en los que la marca de JVM no era suficiente, una actualización era la única forma de mitigar la amenaza. Kalpesh agregó que una lección importante de Log4Shell fue tener un único dashboard que mostrara todo lo que se ejecuta en producción.

Automatizar análisis para que el desarrollo siga avanzando

Al volver a hablar sobre cómo Pinterest usa Snyk, Simon preguntó cuánto había reducido Snyk el trabajo manual de Pinterest al permitir que los desarrolladores se atendieran por su cuenta y cuánta visibilidad tenían de los pipelines de desarrollo.

En Pinterest, usamos monorepos específicos para cada lenguaje. Una vez que agregas un monorepo a Snyk, cualquier proyecto nuevo que se cree en ese repositorio se agrega automáticamente. Así que no hay que hacer ningún trabajo adicional cuando se crea un proyecto nuevo en ese repositorio. Una vez que el código se combina con el repositorio y se ejecuta el análisis de Snyk, podemos saber qué dependencias se incorporaron. [Cuando un desarrollador crea un proyecto en su monorepo, el análisis es] transparente para el desarrollador. Ni siquiera necesita saber que Snyk está en ejecución.

Con esta configuración, cada vez que un desarrollador crea un proyecto, este se analiza automáticamente y se envía a la interfaz de usuario de Snyk. Así, el equipo de Kalpesh puede verlo todo de forma integral.

Simon señala que, por lo general, los desarrolladores prefieren seguir trabajando en su propio flujo de trabajo en lugar de usar otras herramientas. Le preguntó a Kalpesh: “¿Cómo configuran todo para que los desarrolladores puedan seguir trabajando en sus pipelines?”

Kalpesh coincidió en que a los desarrolladores les gusta “seguir trabajando en sus tickets” y, al mismo tiempo, tener toda la información que necesitan. Mencionó el centro de aprendizaje de Snyk, que contiene recursos educativos para desarrolladores. Kalpesh dijo que tener acceso a este plan de estudios lo llevó a considerar la posibilidad de darles a los desarrolladores más acceso a la consola web de Snyk o agregar un enlace a información relevante de Snyk Learn en el ticket de JIRA, para ofrecerles más contexto sobre vulnerabilidades como XSS o la inyección de SQL. Es una forma útil de animar a los desarrolladores a ampliar sus conocimientos de seguridad.

Permitir que los desarrolladores trabajen donde prefieren

En general, Kalpesh y su equipo en Pinterest valoran un flujo de trabajo diseñado para desarrolladores, con énfasis en la clasificación para evitar abrumarlos. Señala que, cuando integraron Snyk por primera vez, detectaron una gran cantidad de vulnerabilidades en sus dependencias, por lo que era importante mostrar solo las que tenían alta prioridad para el negocio. La posibilidad de automatizar análisis y ver los resultados con Snyk, mientras los desarrolladores siguen usando las herramientas que prefieren, ayuda a Pinterest a mantener el desarrollo en marcha sin contratiempos.

Los desarrolladores quieren saber cuál es el problema, cómo solucionarlo y qué prioridad tiene. Si puedes especificar esas cosas en el ticket del desarrollador, ya está.