Las estaciones de trabajo de los desarrolladores se han convertido en el objetivo con mayor retorno de la inversión en ataques a la cadena de suministro de software ataques a la cadena de suministro, y el problema se está agravando.
«Hay un indicador clave que me preocupa: en los últimos tres meses hemos detectado siete veces más vulnerabilidades en nuestra cadena de suministro que en los tres meses anteriores», afirma Gavin Williams, director de ingeniería de Omnea, proveedor de una plataforma de contratación basada en IA.
«A medida que pasa el tiempo, vemos cada vez más problemas y dificultades en los distintos registros, con más ataques a la cadena de suministro también con más incidencias detectadas por las herramientas de inteligencia artificial. Para los desarrolladores es muy fácil instalar un paquete vulnerable o algo que haya sido comprometido».
El sector lleva años adelantando las medidas de seguridad en el proceso de desarrollo. Sin embargo, la superficie de ataque se ha adelantado aún más que el proceso de desarrollo y se ha trasladado a los propios equipos.
Solo en el último año, los atacantes han entrado por diferentes vías: la reciente brecha de seguridad en GitHub a través de una extensión maliciosa de VS Code, Trivy una herramienta de seguridad, TanStack (mini Shai-Hulud) a través de un gestor de paquetes y los ataques de TeamPCP mediante paquetes maliciosos, pero todos ellos comparten un factor clave. Su objetivo son los dispositivos de los desarrolladores. Y les está funcionando.
¿Pero por qué?
Me gusta verlo de esta manera: la mayoría de los edificios comerciales tienen la puerta principal bien protegida con cerraduras, cámaras y demás. Pero también hay una entrada para el personal en la parte trasera, cuya puerta cortafuegos está abierta porque hay gente entrando y saliendo todo el día con los envíos. Esa entrada para el personal conduce directamente a la oficina donde se guardan las llaves de todas las salas, que es, en la práctica, el puesto de trabajo del desarrollador.
Hasta ahora, las organizaciones y sus equipos de seguridad no han considerado esto como un riesgo para la seguridad porque «solo les afecta a ellos». Es una especie de creencia ciega de que nadie se molestará en hacerlo porque no les concierne.
Pero si eres un atacante, le da igual para quién sea la puerta (o, en este caso, el dispositivo); lo lógico es ir donde haya menos obstáculos.
La diferencia entre lo que detecta el EDR y lo que los desarrolladores instalan realmente
Según James Berthoty, fundador y analista de Latio, una de las principales causas de ataques a la cadena de suministro es que los terminales de los desarrolladores suelen carecer de supervisión, ya que las herramientas tradicionales de detección y gestión no se adaptan bien a sus casos de uso.
«Las herramientas de EDR no son tan detalladas; se centran principalmente en las aplicaciones o programas instalados, en lugar de en los paquetes internos de esa aplicación autorizada», afirma Walid Mahmoud, DevSecOps en el sector público del Reino Unido.
El EDR supervisa la actividad maliciosa a nivel de aplicación. Sin embargo, las organizaciones no pueden ver lo que ocurre dentro de las herramientas que utilizan a diario los desarrolladores, como los paquetes npm, las extensiones de los entornos de desarrollo integrado (IDE), los complementos de Chrome o las funciones de Cursor.
Esto es importante, porque el problema comienza incluso antes de escribir una sola línea de código.
«No se trata de que la gente implemente código inseguro en el entorno de producción. Se trata de que, incluso durante la instalación, sus credenciales de GitHub quedan expuestas», afirma Gavin, de Omnea.
Por ejemplo, un paquete malicioso puede ejecutar un script tras la instalación y sustraer credenciales en el momento en que un desarrollador lo instale.
Y, por supuesto, sería un error no mencionar lo increíblemente fácil que se está volviendo crear malware gracias a los modelos de lenguaje grande (LLM). Steeven George, responsable de seguridad de productos en Raisin, afirma que este era un ámbito que suponía un «punto ciego» para su organización, y no es el único.
Walid, que trabaja en el sector público del Reino Unido, explica las consecuencias de la introducción de la IA: «Ahora hay mucha gente que trabaja en la terminal y está instalando un montón de archivos Markdown y otras cosas. Sin embargo, como es lógico, al no existir procesos verificados, nada les impide descargar cosas que han visto en Reddit o en X. Estas podrían formar parte de una campaña de malware destinada a que la gente las descargue. Y luego... ya sabemos cómo acaba la historia».
Parte del problema radica en que ningún equipo se hace cargo del punto de intersección en el que se encuentran los equipos de los desarrolladores, donde confluyen AppSec, la seguridad de los puntos finales, la gestión de identidades y los riesgos de la cadena de suministro. Por eso ha resultado más fácil utilizar herramientas como EDR y MDM para llenar ese vacío sin proteger realmente a las organizaciones frente a estas amenazas crecientes. Pero cada vez está más claro que eso ya no es viable. La desventaja es ser el blanco de un ataque significativo a la cadena de suministro (yeso es una desventaja considerable).
Cómo protegen los equipos los equipos de los desarrolladores frente a ataques a la cadena de suministro
Chris Holman, jefe del equipo DevSecOps de la empresa de ciberseguridad Glasswall, ha implantado Aikido Safe Chain en todo el entorno de la empresa.
«Cualquier canal de producción que utilice paquetes compatibles se analiza ahora con Safe Chain para asegurarnos de que no estamos instalando nada malicioso».
Walid ha hecho lo mismo en todo el departamento del sector público del Reino Unido.
«Se ha añadido una fase de control que solemos tener en nuestro ciclo de vida de desarrollo de software, pero ahora esa fase es local. Así que nos da un poco más de tranquilidad saber que los desarrolladores cuentan con una especie de barrera de seguridad en su equipo local que les pedirá confirmación antes de instalar algo».
Pero los paquetes son solo un punto de partida; el equipo de Gavin ya utilizaba Safe Chain cuando, según él, se dieron cuenta de que necesitaban una visibilidad más amplia de todo el dispositivo de desarrollo.
«Hasta ahora hemos estado utilizando Safe Chain, pero disponer de una forma más completa de gestionar los dispositivos de todos y asegurarnos realmente de que no se instalen programas de forma insegura va a suponer un verdadero punto de inflexión», afirmó Gavin.
Eso es lo que llevó a varios de estos equipos a adoptar la «Protección de dispositivos» de Aikido, que amplía ese mismo principio más allá de los registros de paquetes para abarcar extensiones de IDE, complementos de navegador y herramientas de IA.
Walid lo describe como una «versión mejorada de Safe Chain». Afirma: «Nos proporciona los datos necesarios para saber qué están utilizando los desarrolladores o qué han intentado instalar, lo que nos da más información sobre quiénes son vulnerables a un ataque».
El equipo de Kristina en Cognism tiene previsto implementarlo por motivos similares. «Actualmente, ninguna otra herramienta ofrece ese nivel de cobertura. Las herramientas EDR no muestran los paquetes instalados en los equipos de los desarrolladores, y otros proveedores no cubren las vulnerabilidades de las extensiones de Chrome. Sin duda, vamos a subsanar esa carencia».
Steeven ya lo ha probado. «Me alegra mucho poder ver una visión general completa de las extensiones del navegador, las extensiones de Cursor y todos los registros de paquetes. Nos ofrece un modelo global de amenazas para todos nuestros equipos de desarrollo».
Todos los equipos con los que hablamos detectaron la misma carencia
El patrón que se observó en todas estas conversaciones fue el mismo: los responsables de seguridad e ingeniería de distintas empresas y sectores identificaron, de forma independiente, la misma carencia. Los equipos de los desarrolladores quedan al margen de las herramientas existentes, y los atacantes se han dado cuenta de ello.
Los equipos que ya se están ocupando de ello comenzaron con controles a nivel de paquete y ahora están ampliando su alcance para lograr una visibilidad completa de los dispositivos. Es probable que los que aún no han empezado sigan utilizando la misma configuración de EDR y MDM que no detectó ninguno de los ataques mencionados en este artículo.
Descubre cómo funciona Device Protection aquí o pruébalo aquí.
