El viaje de la cadena de suministro de software ha atravesado momentos extremadamente duros. En los últimos meses, los ataques han afectado a Axios, Trivy, LiteLLM, SAP, Vercel, y una nueva campaña Mini Shai-Hulud que ha golpeado a una larga lista de paquetes, incluyendo TanStack, UiPath y Mistral AI.

Luego, GitHub confirmó que los atacantes habían accedido a casi 3,800 repositorios internos después de que una extensión maliciosa de VS Code llegara al portátil de un empleado.

La extensión era Nx Console, una herramienta legítima con 2.2 millones de instalaciones y un badge de editor verificado, comprometida mediante una token robado de un ataque previo a la cadena de suministro.

La versión maliciosa estuvo disponible en el marketplace durante solo dieciocho minutos, pero la actualización automática ya la había desplegado en editores activos dentro de ese intervalo.

Estos ataques llegaron por puertas distintas: una extensión de navegador, un gusano en el registro de paquetes, un complemento IDE adulterado. Pero todos aterrizaron en un mismo objetivo: la máquina del desarrollador. GitHub no es una empresa descuidada.

Si esto puede suceder en la plataforma que aloja la mayor parte del código fuente del mundo, puede ocurrir en cualquiera.

Los desarrolladores son ahora el objetivo principal

Los desarrolladores se han convertido en uno de los objetivos más valiosos de la cadena de suministro de software porque manejan credenciales en la nube, llaves SSH, tokens de publicación en npm, configuraciones de Kubernetes y acceso directo al código fuente. Una sola credencial comprometida puede ser suficiente para publicar paquetes maliciosos o desencadenar compromisos aguas abajo en miles de organizaciones.

El auge del desarrollo impulsado por IA también contribuye al desafío de dos maneras. Primero, los agentes de programación que trabajan en las laptops de los desarrolladores descargan paquetes y añaden habilidades con poca o ninguna supervisión humana sobre lo que se instala, lo que, por supuesto, aumenta la superficie de ataque en el dispositivo del desarrollador.

Segundo, ha reducido drásticamente la barrera de entrada para realizar ataques a la cadena de suministro, ya que lo que antes requería habilidad real y conocimiento técnico profundo ahora solo necesita una suscripción a un LLM. Atacantes más experimentados también están utilizando IA para realizar ataques cada vez más sofisticados que escalan más rápido de lo que pueden responder los equipos de seguridad.

Durante años, la seguridad de la cadena de suministro se centraba en asegurar la infraestructura por la que pasa el código, como registros, pipelines de construcción y sistemas CI/CD. Esos planos siguen importando, pero la vulnerabilidad ahora empieza más temprano, en el dispositivo del desarrollador, antes de que el código entre a la infraestructura compartida.

La protección tradicional del endpoint es insuficiente

A pesar de la información sensible en las máquinas de desarrollo y de los riesgos crecientes, la mayoría de las empresas aún protegen estos dispositivos de la misma forma que cualquier portátil corporativo: con protección de endpoint tradicional (EDR) para detectar amenazas en el sistema operativo y gestión de dispositivos móviles (MDM) para controlar lo que se instala.

El problema es que gran parte de lo que hacen los desarrolladores a diario ocurre por encima del sistema operativo, a través de gestores de paquetes, mercados de IDE, extensiones de navegador y herramientas de IA. Estas herramientas son mayormente invisibles para EDR y MDM. Un paquete malicioso de npm ejecutando un script post-instala no se registra.

Una extensión de VS Code comprometida que exfiltra credenciales de forma silenciosa no se registra. Un complemento de navegador con permisos excesivos de OAuth no se registra. Estas herramientas no estaban diseñadas para cómo funciona hoy el desarrollo de software.

Las empresas quedan entre dos opciones mediocres

Como resultado, la mayoría de las compañías se encuentra defendiendo el endpoint del desarrollador con enfoques que preferirían no usar.

Algunas bloquean todo, aplicando una línea rígida entre desarrolladores y la Internet abierta. Esto puede funcionar en entornos altamente regulados como servicios financieros, pero frena la velocidad de desarrollo en otros lugares. Esta aproximación es tan restrictiva que los desarrolladores, en esos entornos, a menudo buscan soluciones como usar segundas laptops o desactivar VPNs, lo que empeora la postura de seguridad.

Muchas empresas optan por la otra dirección y permiten a los desarrolladores instalar todo lo necesario y esperar que nada salga mal. Dadas las cuestiones anteriores, este enfoque es extremadamente riesgoso (y prácticamente indefendible).

Otros prueban un tercer camino, aprobando manualmente las solicitudes de instalación caso por caso. Si bien esta precisión es efectiva desde el punto de vista de seguridad y necesidades del desarrollador, es imposible de escalar.

La industria está resolviendo el problema equivocado

La mayor parte de la conversación de seguridad de la cadena de suministro se centra en la detección. ¿Qué tan rápido puedes identificar un paquete malicioso? ¿Qué tan rápido puedes señalar una extensión comprometida? Son preguntas razonables, pero no abarcan algo crucial.

Observe la brecha de GitHub. La extensión maliciosa de Nx Console fue identificada y retirada en dieciocho minutos. Eso es realmente rápido. Pero no importó, porque la actualización automática ya había distribuido la versión comprometida a editores en funcionamiento durante ese intervalo. La detección te dice que algo malo existía, pero no impide que llegue a las máquinas de desarrollo.

La pregunta más útil es: ¿cómo evitas que algo llegue a la planta de la dispositivo en primer lugar? Un periodo de enfriamiento, un retraso entre la publicación de una nueva versión y su instalación permitida, habría prevenido completamente la brecha de GitHub.

Si tu política dice “no instalar nada publicado hace menos de 48 horas,” la versión maliciosa de Nx Console nunca llega a un único dispositivo. Esa es una regla de temporización básica que da a la ecosistema el margen para detectar y corregir problemas antes de que lleguen.

Este mismo razonamiento se aplica de forma más amplia. Conoce lo que está instalado en cada máquina de desarrollo. Establece políticas sobre qué paquetes, extensiones y plugins están permitidos. Cuando un desarrollador necesite algo fuera de la política, dale una vía para solicitarlo que sea lo suficientemente rápida para que no busque atajos.

Ninguna de estas acciones implica hacer que los entornos de desarrollo sean estériles. El desarrollo de software moderno depende de código abierto, herramientas de terceros y cada vez más de agentes de IA. Los desarrolladores necesitan libertad para trabajar. Pero esa libertad debe ser visible y gobernada, no invisible.

El primer dominó

El dispositivo del desarrollador es el primer dominó en la cadena de suministro de software. Cada brecha mayor descrita en este artículo empezó allí, no en un pipeline ni en producción.

Las soluciones no son complicadas. El costo de ignorarlas es alto. La industria ha pasado años moviendo la seguridad hacia la izquierda en la pipeline. Es hora de trasladarla hasta el dispositivo.

Este análisis forma parte de nuestra visión sobre la seguridad en el desarrollo de software y pretende abrir un diálogo sobre prácticas que protejan a los equipos sin frenar la innovación.

from Latest from TechRadar https://ift.tt/0heaDid
via IFTTT IA