Las estaciones de trabajo de los desarrolladores se han convertido en el objetivo con mayor ROI en los ataques a la cadena de suministro de software, y el problema se está acelerando.
“Hay una métrica clave que me preocupa: en los últimos tres meses tuvimos siete veces más vulnerabilidades en nuestra cadena de suministro en comparación con los tres meses anteriores”, afirma Gavin Williams, Gerente de Ingeniería en Omnea, proveedor de plataformas de adquisición de IA.
“Simplemente estamos viendo más problemas e incidencias en los registros a medida que pasa el tiempo, con más ataques a la cadena de suministro, pero también más problemas detectados por las herramientas de IA. Es muy fácil para los desarrolladores instalar un paquete vulnerable o algo que ha sido comprometido”.
La industria ha pasado años desplazando la seguridad hacia la izquierda en el pipeline. Pero la superficie de ataque se ha desplazado aún más a la izquierda que el pipeline, directamente a las propias máquinas.
Solo en el último año, los atacantes han entrado por diferentes puertas: la reciente brecha de GitHub a través de una extensión maliciosa de VS Code, Trivy a través de una herramienta de seguridad, TanStack (mini Shai-Hulud) a través de un gestor de paquetes, ataques de TeamPCP a través de paquetes maliciosos, pero todos comparten un factor clave. Están apuntando al dispositivo del desarrollador. Y está funcionando.
¿Pero por qué?
Me gusta pensarlo de esta manera: la mayoría de los edificios comerciales tienen su puerta principal asegurada con cerraduras, cámaras y elementos similares. Pero también hay una entrada de personal por la parte trasera con una puerta cortafuegos abierta, ya que la gente entra y sale todo el día con entregas. Esa entrada de personal conduce directamente a la oficina con las llaves de todas las salas, que es, en esencia, la estación de trabajo del desarrollador.
Hasta ahora, las organizaciones y sus equipos de seguridad no han considerado esto como un riesgo de seguridad porque “es solo para ellos”. Es una especie de creencia ciega de que nadie se molestará porque no es para ellos.
Pero si eres un atacante, literalmente no importa para quién sea la puerta (o, en este caso, el dispositivo); tiene sentido ir donde la fricción es menor.
La brecha entre lo que ve EDR y lo que realmente instalan los desarrolladores
Una de las razones clave de los ataques a la cadena de suministro, según James Berthoty, fundador y analista de Latio, es que los endpoints de los desarrolladores permanecen en gran medida sin monitorizar, ya que las herramientas tradicionales de detección y gestión no funcionan bien para sus casos de uso.
“Las herramientas EDR no son granulares; se centran principalmente en las aplicaciones o programas instalados, en lugar de en los paquetes internos de esa aplicación permitida”, afirma Walid Mahmoud, responsable de DevSecOps en el sector público del Reino Unido.
EDR monitoriza la actividad maliciosa a nivel de aplicación. Pero las organizaciones no pueden ver lo que ocurre dentro de las herramientas que los desarrolladores utilizan a diario, como los paquetes npm, las extensiones de IDE, los plugins de Chrome o las habilidades de Cursor.
Esto es importante, porque el problema comienza antes de que se escriba una sola línea de código.
“No se trata de que la gente despliegue código inseguro en producción. Se trata de que, incluso en la instalación, se exponen credenciales de GitHub”, afirma Gavin de Omnea.
Por ejemplo, un paquete malicioso puede ejecutar un script post-instalación y exfiltrar credenciales en el momento en que un desarrollador lo instala.
Y, por supuesto, sería un error no mencionar lo trivialmente fácil que resulta crear malware gracias a los LLM. Steeven George, jefe de seguridad de producto en Raisin, afirma que esta era un área que estaba creando un “punto ciego” para su organización, y no es el único.
Walid, del sector público del Reino Unido, explica lo que está haciendo la introducción de la IA: “Mucha gente vive ahora en el terminal y está instalando muchos archivos markdown y otras cosas. Sin embargo, naturalmente, sin ningún proceso verificado, nada les impide descargar cosas que han visto en Reddit o X. Esto podría formar parte de una campaña de malware para que la gente lo descargue. Y entonces, el resto es historia”.
Parte del problema es que ningún equipo es responsable de la intersección donde se encuentran las máquinas de los desarrolladores, donde AppSec, la seguridad de endpoints, la identidad y el riesgo de la cadena de suministro se unen. Y por eso ha sido más fácil utilizar herramientas como EDR y MDM para llenar el vacío sin proteger realmente a las organizaciones de estas crecientes amenazas. Pero está quedando claro que ya no es viable. La desventaja es ser el objetivo de un ataque significativo a la cadena de suministro (Eso es una desventaja considerable).
Cómo los equipos están protegiendo las máquinas de los desarrolladores contra ataques a la cadena de suministro
Chris Holman, líder del equipo de ingenieros de DevSecOps en la firma de ciberseguridad Glasswall, ha implementado Aikido Safe Chain en toda la infraestructura de la empresa.
"Cualquier pipeline de producción que toque paquetes compatibles se escanea ahora con Safe Chain para asegurarnos de que no estamos instalando nada comprometido".
Walid ha hecho lo mismo en el departamento del sector público del Reino Unido.
“Ha añadido una puerta de etapa que normalmente tenemos en nuestro ciclo de vida de desarrollo de software, pero esa puerta de etapa ahora es local. Así tenemos un poco más de confianza en que los desarrolladores tienen algún tipo de barrera de seguridad en su máquina local que les hará cuestionarse antes de instalar algo”.
Pero los paquetes son solo un punto de entrada; el equipo de Gavin ya estaba utilizando Safe Chain cuando se dieron cuenta de que necesitaban una visibilidad más amplia en todo el dispositivo del desarrollador.
“Hemos estado utilizando Safe Chain hasta ahora, pero tener una forma más completa de gestionar todos los dispositivos y verificar realmente que las cosas no se están instalando de forma insegura va a ser un verdadero cambio de juego”, dijo Gavin.
Eso es lo que llevó a varios de estos equipos hacia Aikido’s Device Protection, que extiende el mismo principio más allá de los registros de paquetes a las extensiones de IDE, los plugins de navegador y las herramientas de IA.
Walid lo describe como una “versión mejorada de Safe Chain”. Él dice: “Nos proporciona la telemetría para saber qué están utilizando los desarrolladores o qué han intentado instalar, dándonos más contexto sobre quién es susceptible a un ataque”.
El equipo de Kristina en Cognism planea implementarlo por razones similares. “Actualmente, ninguna otra herramienta ofrece ese tipo de cobertura. Las herramientas EDR no muestran los paquetes instalados en las máquinas de los desarrolladores, y las vulnerabilidades en las extensiones de Chrome no están cubiertas por otros proveedores. Sin duda, cerraremos esa brecha”.
Steeven ya lo ha probado. “Estoy muy contento de ver el panorama completo de las extensiones de navegador, las extensiones de Cursor y todos los registros de paquetes. Nos proporciona un modelo de amenaza general para todas nuestras máquinas de desarrolladores”.
Todos los equipos con los que hablamos encontraron la misma brecha
El patrón en estas conversaciones era consistente, entre líderes de seguridad e ingeniería de diferentes empresas y en distintas industrias, todos identificando de forma independiente la misma brecha. Las máquinas de los desarrolladores se encuentran entre las grietas de las herramientas existentes, y los atacantes lo han descubierto.
Los equipos que ya lo están abordando comenzaron con controles a nivel de paquete y ahora se están expandiendo a una visibilidad completa del dispositivo. Los que aún no han empezado probablemente estén utilizando la misma configuración de EDR y MDM que pasó por alto cada ataque mencionado en este artículo.
Descubra cómo funciona Device Protection aquí o pruébelo aquí.
