La cadena de suministro de software ha tenido una racha brutal.
En los últimos meses hemos visto ataques contra Axios, Trivy, LiteLLM, SAP, Vercel y una nueva campaña Mini Shai-Hulud que afectó a una larga lista de paquetes, incluidos TanStack, UiPath y Mistral AI.
Luego, GitHub confirmó que los atacantes accedieron a alrededor de 3.800 repositorios internos cuando una extensión tóxica de VS Code aterrizó en la computadora portátil de un solo empleado.
La extensión era Nx Console, una herramienta legítima con 2,2 millones de instalaciones y una insignia de editor verificada, comprometida mediante tokens robados de un ataque a la cadena de suministro independiente.
La versión maliciosa estuvo disponible en el mercado solo durante dieciocho minutos, pero la actualización automática ya se envió a los editores durante ese período.
Cofundador y director ejecutivo de Aikido Security.
Estos ataques llegaron por diferentes puertas.
Una extensión del navegador, un gusano en el registro de paquetes, un complemento IDE tóxico. Pero todos terminaron en lo mismo: la máquina de un desarrollador. GitHub no es una empresa descuidada.
Si esto puede suceder en la plataforma que alberga la mayor parte del código fuente del mundo, le puede pasar a cualquiera.
Los desarrolladores son ahora el objetivo principal
Los desarrolladores se han convertido en los objetivos más valiosos en la cadena de suministro de software porque tienen acceso directo a credenciales de nube, claves SSH, tokens de publicación npm, configuraciones de Kubernetes y código fuente. Un único certificado comprometido puede ser suficiente para exponer paquetes maliciosos o desencadenar compromisos posteriores en miles de organizaciones.
El auge del desarrollo impulsado por la IA también está contribuyendo al desafío de dos maneras. En primer lugar, los agentes de codificación que trabajan en las computadoras portátiles de los desarrolladores extraen paquetes y agregan habilidades sin supervisión humana sobre lo que está instalado, lo que por supuesto aumenta la superficie de ataque en los dispositivos de los desarrolladores.
En segundo lugar, ha reducido drásticamente la barrera de entrada para lanzar un ataque a la cadena de suministro porque lo que antes requería habilidades prácticas y conocimientos técnicos profundos ahora solo requiere una suscripción a un LLM. Los atacantes más capacitados están utilizando la IA para llevar a cabo ataques cada vez más sofisticados que pueden moverse más rápido de lo que pueden responder los equipos de seguridad.
Durante años, la seguridad de la cadena de suministro ha significado proteger la infraestructura de paso de códigos, como registros y tuberías de construcción y sistemas CI/CD. Estas capas siguen siendo importantes, pero la vulnerabilidad comienza ahora, en el dispositivo del desarrollador, antes de que el código ingrese a la infraestructura compartida.
La protección tradicional de endpoints es insuficiente
A pesar del contenido confidencial en las máquinas de los desarrolladores y los riesgos crecientes que enfrentan, la mayoría de las empresas todavía los protegen de la misma manera que protegen una computadora portátil estándar para empleados corporativos: con protección de punto final (EDR) tradicional para detectar amenazas al sistema operativo y administración de dispositivos móviles (MDM) para administrar lo que está instalado.
El problema es que la mayor parte de lo que los desarrolladores hacen todos los días ocurre sobre el sistema operativo, a través de administradores de paquetes, mercados IDE, extensiones de navegador y herramientas de inteligencia artificial. Estos son en su mayoría invisibles para los EDR y MDM. Un paquete npm malicioso no se registra cuando se ejecuta un script posterior a la instalación
Una extensión de VS Code comprometida no registra la extracción silenciosa de credenciales. Un navegador AI con acceso OAuth sobrepermitido no registra el complemento. Estas herramientas no fueron diseñadas para cómo funciona el desarrollo de software hoy en día.
Las empresas están estancadas eligiendo entre malas opciones
Como resultado, la mayoría de las organizaciones intentan proteger el punto final del desarrollador con métodos que tal vez no quieran utilizar.
Algunos bloquean todo, trazando una línea dura entre los desarrolladores y la Internet abierta. Esto puede funcionar en entornos altamente regulados como los servicios financieros, pero acaba con el ritmo de desarrollo en cualquier otro lugar. Este enfoque es tan limitante que los desarrolladores en estos entornos a menudo encuentran soluciones como segundas computadoras portátiles y VPN deshabilitadas, lo que empeora la situación de seguridad si no se hace nada.
Muchas empresas van por el otro lado y permiten a los desarrolladores instalar todo lo que necesitan y esperan que nada salga mal. Dadas las cuestiones que acabo de enumerar, este enfoque es extremadamente arriesgado (y casi imposible).
Otros prueban una tercera ruta, aprobando manualmente las solicitudes de instalación caso por caso. Si bien esta precisión es útil desde la perspectiva de la seguridad y del desarrollador, es imposible escalarla.
La industria está resolviendo el problema equivocado
Gran parte del debate sobre seguridad de la cadena de suministro en este momento gira en torno a la detección. ¿Qué tan rápido se puede detectar un paquete malicioso? ¿Qué tan rápido puedes marcar una extensión comprometida? Estas son preguntas razonables, pero pasan por alto algo importante.
Mire la infracción de GitHub. La extensión maliciosa de la consola Nx fue identificada y eliminada en dieciocho minutos. Eso es realmente rápido. Pero no importó, porque las actualizaciones automáticas distribuyeron la versión comprometida a los editores que se ejecutaban durante esa ventana. La detección te dice que hay algo malo. Eso no impidió que llegara a las máquinas de desarrollo.
Una pregunta más útil es: ¿Cómo puedo evitar que algo llegue al dispositivo en primer lugar? Un período de recuperación, cuando se lanza una nueva versión y un retraso cuando se permite su instalación, habrían evitado por completo la infracción de GitHub.
Si su política dice “no instalar automáticamente nada publicado hace menos de 48 horas”, entonces la versión maliciosa de la consola Nx nunca llega a un dispositivo. Esta es una regla de tiempo básica que ayuda al ecosistema a detectar los problemas antes de que lleguen a la ventana.
El mismo pensamiento se aplica más ampliamente. Sepa qué está instalado en cada máquina de desarrollador. Establezca políticas sobre qué paquetes, extensiones y complementos están permitidos. Cuando un desarrollador necesita algo fuera de la política, bríndele una manera de solicitarlo para que no tenga que evitarlo.
Nada de esto pretende esterilizar el entorno de desarrollo. El desarrollo de software moderno se basa en código abierto, herramientas de terceros y, cada vez más, agentes de inteligencia artificial. Los desarrolladores necesitan libertad para trabajar. Pero esa libertad debería ser visible y gobernada, no invisible.
el primer dominó
El dispositivo del desarrollador es la primera pieza de dominó en la cadena de suministro de software. Cada brecha importante que describo en este artículo comenzó allí. Ni en proceso ni en producción.
Las correcciones no son complicadas. Vale la pena ignorarlos. La industria pasó años haciendo la transición de las salvaguardias que quedaron en trámite. Es hora de transferir completamente al dispositivo.
Hemos revisado y clasificado los mejores monitores empresariales..
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
