Cómo mejoramos la experiencia de los desarrolladores en Pinterest con herramientas de seguridad

Usar bibliotecas de código abierto de forma segura es una prioridad constante en las grandes corporaciones. Uno de los principales desafíos que esto implica es la integración de herramientas de seguridad en el flujo de trabajo de los desarrolladores sin agobiarlos y configurar un sistema que priorice las correcciones de vulnerabilidades. En este punto, vale la pena preguntarse: “¿Cómo debería ser el enfoque correcto?”.

Simon Maple (director de tecnología de campo en Snyk) habló con Kalpesh Dharwadkar (ingeniero de seguridad de producto en Pinterest) para conocer cómo Pinterest usa Snyk para elaborar prácticas de seguridad fáciles de implementar para desarrolladores.

Las tres grandes prioridades: visibilidad, escaneo y clasificación

Pinterest emplea mucho software de código abierto en su pila de desarrollo, por lo que una biblioteca de código abierto vulnerable podría afectar al perfil ejecutivo. Antes de que Kalpesh se uniera a la empresa, usaban un sistema improvisado de desarrollo de vistas en sus bibliotecas de código abierto usando auditorías de NPM. Pero cuando Kalpesh se unió, quiso establecer un sistema centralizado para obtener visibilidad sobre todas las bibliotecas de código abierto en uso. Su equipo evaluó diversas soluciones y eligió a Snyk por dos razones principales: sus funcionalidades fáciles de implementar para desarrolladores y la asistencia para repositorios de lenguajes específicos, como Bazel (la herramienta que usan para desarrollar). Kalpesh mencionó cuáles eran sus principales prioridades para la seguridad al comienzo de la conversación:

Para proteger el código abierto en Pinterest, debemos enfocarnos en tres cuestiones: obtener visibilidad de las bibliotecas vulnerables, elegir, aprovisionar y configurar herramientas en la pila además de escanearla en busca de vulnerabilidades y, finalmente, clasificar las vulnerabilidades.

Kalpesh explicó que usan Jenkins para las compilaciones. Escanean el sistema de compilación con Snyk CLI y, luego, cargan los resultados en la interfaz de usuario web de Snyk. El primer objetivo es obtener visibilidad sobre todas las dependencias en los repositorios de código y priorizar la corrección de cualquier vulnerabilidad. Para ello, consideran el CVSS (sistema de puntuación de vulnerabilidades comunes), que ofrece visibilidad sobre las vulnerabilidades. Si una vulnerabilidad se explota, utilizan la información de Snyk para determinar si la corrección debe ser urgente.

Cómo sumar pruebas de seguridad en todo el pipeline

A continuación, Simon le preguntó sobre la implementación de pruebas en el pipeline de desarrollo y cuáles habían sido los desafíos al enseñarles a los desarrolladores a usar Snyk. Para este paso, Kalpesh había ideado una solución simple. Cuando introdujo Snyk en el pipeline de desarrollo, en lugar de mostrar la consola de Snyk a los desarrolladores, optó por ejecutar el escaneo como paso en la compilación de Jenkins. Luego, empezó a abordar las cuestiones más sencillas (es decir, las correcciones simples) por su cuenta y pidió a líderes en tecnología o quienes tenían los proyectos que revisaran su trabajo. De este modo, logró hacer que se interesaran en aplicar las correcciones con las herramientas de Snyk y la participación se expandió entre los equipos.

Clasificación eficiente, priorización de correcciones, y limpieza y transformación de Log4Shell

A continuación, la conversación viró a la clasificación de vulnerabilidades. Simon le preguntó a Kalpesh cuáles eran los indicios o las señales de alerta que se buscan en el trabajo pendiente para poder decirles a los desarrolladores cuáles son las cinco vulnerabilidades principales que deberían abordar. Su respuesta es considerar la gravedad de la vulnerabilidad, analizar si se está explotando de forma activa y si la vulnerabilidad aparece en un servicio expuesto a Internet. Estos son los parámetros que Kalpesh emplea para priorizar las correcciones. Luego, se crea un ticket para un desarrollador o el propietario del servicio de modo que pueda corregir la vulnerabilidad. Monitorear la información del ticket le permite al equipo comprender si la evaluación de la vulnerabilidad coincide con lo que los desarrolladores consideran importante.

El desarrollador recibe el ticket. Pero podría decirnos “en realidad no estamos usando esta funcionalidad que es vulnerable a la dependencia.” En ese caso, intentamos reducir la prioridad de la funcionalidad.

Luego, la conversación se centró en Log4Shell. Simon le preguntó a Kalpesh cómo lidia Pinterest con una vulnerabilidad importante de día cero. Kalpesh mencionó que la mañana posterior al anuncio del lanzamiento de Log4Shell, su equipo denunció un incidente para analizar cuántos servicios se habían afectado. Existía una solución o marca de JVM (máquina virtual Java), que aplicaron a los servicios de Java, pero dependía de que los propietarios de los servicios la implementaran en todos los servicios, lo que lleva tiempo. Implementar la solución le llevó al equipo toda la semana, ya que deseaban asegurarse de que todos los servicios implementados tuvieran la marca de JVM. Establecieron dos flujos de trabajo: uno detectaba todos los servicios de Java en Pinterest y el otro detectaba cualquier servicio que la solución o marca de JVM no pudiera abarcar. En el caso de los servicios donde la marca de JVM no era suficiente, la única forma de mitigar la amenaza era aplicar una actualización. Del caso de Log4Shell, Kalpesh se lleva una importante lección: tener un único panel que pueda mostrar todo lo que se ejecuta en producción.

Escaneos automáticos para que continúe el desarrollo

En la conversación sobre cómo Pinterest usa Snyk, Simon le preguntó a Kalpesh en qué medida Snyk pudo reducir los esfuerzos manuales de Pinterest en el autoservicio de los desarrolladores y cuánta visibilidad tienen sobre los pipelines de desarrollo.

En Pinterest, utilizamos monorrepositorios específicos según el lenguaje. Cuando se agrega un monorrepositorio en Snyk, cualquier proyecto nuevo que se cree en dicho repositorio se agrega automáticamente. Por esta razón, no hay ningún trabajo adicional que deba realizarse al crear un nuevo proyecto en el repositorio. Cuando el código se fusiona mediante combinación en el repositorio y se realiza el escaneo de Snyk, obtenemos visibilidad sobre qué dependencias se agregaron. \[Cuando un desarrollador crea un proyecto en el monorrepositorio, el escaneo] es transparente para el desarrollador. Ni siquiera necesita saber que Snyk se está ejecutando.

Con esta configuración, cada vez que un desarrollador crea un proyecto, este se escanea automáticamente y se envía a la interfaz de usuario de Snyk, lo que le permite al equipo de Kalpesh ver todo lo que sucede.

Simon menciona que, en general, los desarrolladores quieren quedarse en su flujo de trabajo, en lugar de desplazarse a otras herramientas. Considerando esto, le preguntó a Kalpesh: “¿Qué configuración tienen para que los desarrolladores permanezcan en sus pipelines?”.

Kalpesh opina igual: los desarrolladores desean quedarse en sus tickets, pero quieren tener toda la información necesaria. El centro de aprendizaje de Snyk contiene recursos educativos para los desarrolladores y, gracias a que pueden acceder a él, Kalpesh consideró mostrarles a los desarrolladores más de la consola web de Snyk o, quizá, agregar un vínculo a información relevante de Snyk Learn en un ticket de JIRA para que tengan más contexto sobre las vulnerabilidades, como inyección de SQL o XSS. Es una forma útil de alentar a los desarrolladores a que formen su conocimiento en seguridad.

Cómo mantener a los desarrolladores donde desean estar

En general, Kalpesh y su equipo en Pinterest valoran un flujo de trabajo fácil de implementar para desarrolladores y resaltan la capacidad de clasificación para evitar agobiarlos. Mencionó que, en cuanto integraron Snyk, vieron una gran cantidad de vulnerabilidades provenientes de sus dependencias, por lo que era crucial marcar solo aquellas que eran prioritarias para el negocio. Poder automatizar los escaneos y ver los resultados en Snyk mientras los desarrolladores permanecen en las herramientas que eligen hace que el flujo de desarrollo de Pinterest se produzca sin inconvenientes.

A los desarrolladores les interesa saber cuál es el problema, cómo se corrige y cuál es la prioridad. Si todo ello se puede especificar en el ticket de un desarrollador, ya puedes continuar.