Gestionar la responsabilidad de seguridad a escala: la perspectiva de Twilio

A medida que las organizaciones siguen adoptando prácticas de DevSecOps para entregar software seguro, la responsabilidad de seguridad es un aspecto cada vez más importante. Snyk organizó recientemente una mesa redonda con Twilio para hablar sobre la responsabilidad de seguridad en 2021.

En esta publicación, resumiremos la conversación entre Guy Podjarny, presidente y cofundador de Snyk, y Yashvier Kosaraju, gerente sénior de seguridad de productos en Twilio. Los equipos de seguridad de productos de Twilio aprovechan Snyk Open Source para garantizar que el código sea seguro en todas las etapas del diseño y la implementación.

Cómo decidir quién (desarrollo o seguridad) es responsable de cada cosa

Cuando las empresas adoptan un enfoque de DevSecOps, una pregunta fundamental que deben responder es: desde el punto de vista de las prácticas y los procesos, ¿de qué deberían ser responsables mis desarrolladores y mis equipos de seguridad?

Los equipos de seguridad deberían encargarse de todas las funciones de seguridad, como los análisis, los modelos de amenazas y las pruebas de penetración, además de los procesos relacionados con el ciclo de vida de desarrollo de software seguro (SSDLC) y la seguridad corporativa. Por otro lado, los equipos de desarrollo deberían hacerse cargo del riesgo y garantizar que las vulnerabilidades se corrijan oportunamente.

Dicho esto, Kosaraju considera que el equipo de seguridad debería proporcionar herramientas fáciles de usar para que sea más sencillo obtener resultados.

“Al contratar desarrolladores, buscas cosas como si saben programar, diseñar y si conocen los algoritmos”, dice Kosaraju. “No es algo negativo, pero la experiencia en seguridad rara vez es una prioridad durante el proceso de contratación. Por eso es fundamental contar con un equipo central enfocado en la seguridad que tome esas decisiones para la empresa.”

En última instancia, los equipos directivos deben tomar la decisión final sobre quién se encarga de cada cosa. Pero el equipo de seguridad tiene la responsabilidad de ser un “centro de excelencia” para los desarrolladores, ya que las prácticas y los controles deberán integrarse directamente en las aplicaciones.

También es esencial asignar procesos específicos a una estructura organizacional. De lo contrario, las empresas tendrán un tablero de riesgos que informe sobre una gran cantidad de vulnerabilidades sin que ninguna unidad de negocio esté al tanto para corregirlas. Definir claramente la responsabilidad de seguridad desde el principio permite tomar medidas concretas.

Dejar atrás la mentalidad de “somos desarrolladores, no expertos en seguridad”

Lograr que los desarrolladores adopten la seguridad puede ser difícil para las organizaciones. A menudo, hay dos obstáculos principales para empezar: la visibilidad y la facilidad de uso.

Para empezar, la seguridad no tiene un ciclo de retroalimentación natural. Esto significa que las vulnerabilidades suelen acumularse sin resolverse hasta que son tantas que empiezan a afectar al negocio. Las empresas deben ser muy explícitas y hacer que los requisitos de seguridad sean visibles para todos los desarrolladores.

La realidad es que la seguridad es demasiado complicada. Para que los desarrolladores la adopten, hay que simplificarla. Un error común de las empresas es intentar abarcar demasiado y demasiado pronto. Al comenzar, busca un logro inicial, como implementar seguridad de código abierto y análisis de composición de software (SCA).

“Creo que es importante mostrar lo que tienes hoy y hacia dónde necesitas avanzar como parte de un proceso de mejora continua; por eso, la visibilidad es importante”, dice Kosaraju. “También creo que es importante establecer límites. Por ejemplo, cuando dices que el equipo de seguridad protegerá a la empresa, ¿significa que encontrará problemas de seguridad para que se corrijan o que los corregirá? Es fundamental establecer una división clara de responsabilidades y definir quién hace qué.”

A nivel de código, Twilio creó un modelo de responsabilidad al pedirles a todos los desarrolladores que agregaran un archivo YAML a cada repositorio de código. Cada archivo contiene la información necesaria para identificar a los responsables de esos repositorios. Así, el equipo de seguridad puede crear tickets en la cola correcta y contactar al responsable cuando se produce un incidente o se detecta una vulnerabilidad. Esto ayudó a la empresa a dejar de buscar responsables manualmente y poder encontrar al equipo correcto de inmediato y automatizar la gestión de vulnerabilidades.

Medir la seguridad desarrollador por desarrollador

Comenzar con un programa de recompensas por errores es una excelente manera de entender el retorno de la inversión de las herramientas de seguridad. Una vez que el programa está en marcha, es posible incorporar herramientas en distintas partes del SDLC y reducir la cantidad de reportes recibidos mediante el programa. Una disminución en los reportes permite que los equipos empiecen a enfocarse en las prácticas de seguridad desde el inicio del desarrollo.

“Es importante tener en cuenta que, cuando se introduce una herramienta nueva, la cantidad de errores siempre aumenta”, dice Kosaraju. “Una distinción clave es señalar las deficiencias de las herramientas y capacidades de seguridad. Los equipos de seguridad no son perfectos, pero reconocer esta realidad transmite el mensaje de que todos trabajan en conjunto para hacer que la empresa sea más segura y adoptar una mentalidad centrada en la seguridad.”

La mejor manera de que los desarrolladores pongan en contexto las vulnerabilidades respecto de la visibilidad general es observar cuánto tiempo permanecen abiertas las vulnerabilidades críticas en una cola. Esta es una métrica ideal para evaluar la capacidad de respuesta de los equipos al corregir vulnerabilidades. Por ejemplo, si el equipo de seguridad implementa la Herramienta X, que marca 30 vulnerabilidades como críticas, y un equipo de ingeniería corrige 29 en dos semanas, es una excelente métrica para monitorear a lo largo del tiempo.

Como la responsabilidad de seguridad sigue evolucionando año tras año, Snyk organiza seminarios web con regularidad para conocer distintos puntos de vista de profesionales de seguridad del sector. Estas mesas redondas son una oportunidad para que Snyk entienda las necesidades de los equipos de seguridad de aplicaciones y los desarrolladores, de modo que las empresas puedan seguir adaptando sus productos a las necesidades de seguridad de organizaciones como Twilio.