Los atacantes de la cadena de suministro no sólo intentan introducir código malicioso en software confiable. Están intentando robar el acceso que hace posible el software confiable. Recientemente, tres campañas separadas llegaron a npm, PyPI y Docker Hub en un período de 48 horas, y las tres apuntaron a secretos de entornos de desarrollador y canalizaciones de CI/CD, incluidas claves API, credenciales de nube, claves SSH y tokens. Esta es una preocupación constante y se propaga a sí misma, como se ve en ataques como las campañas del «mini Shai Hulud».
Ese patrón debería cambiar la forma en que los equipos de seguridad piensan sobre la cadena de suministro de software.
Tradicionalmente, la seguridad se centraba en sistemas compartidos como repositorios de código fuente, plataformas CI/CD, registros de artefactos, administradores de paquetes y entornos de nube. El objetivo era proteger las cargas de trabajo y los datos de producción. Es absolutamente necesario que nos centremos en estos ámbitos, pero el panorama es incompleto.
La entrega de software moderno comienza antes de que el código llegue a Git. Comienza en la estación de trabajo del desarrollador, donde se escribe el código, se instalan las dependencias, se prueban las credenciales, se solicita a los asistentes de IA, se crean contenedores y comienzan las acciones confiables.
Las estaciones de trabajo de los desarrolladores son una parte real de la cadena de suministro de software. Tratarlos como «simples» puntos finales comunes deja brechas entre la seguridad de los puntos finales, la seguridad de la identidad, la seguridad de las aplicaciones y la gobernanza de la cadena de suministro.
Los ataques a la cadena de suministro se han convertido en operaciones de recolección de credenciales
Los incidentes recientes siguen apuntando a la misma verdad operativa. Los atacantes pueden utilizar paquetes envenenados, imágenes comprometidas, bots de dependencia, flujos de trabajo maliciosos o herramientas de desarrollo vulnerables, pero el objetivo recurrente es el acceso.
Eventos como las campañas TeamPCP y Shai-Hulud muestran cómo los ataques a la cadena de suministro convergen cada vez más en torno al robo de credenciales. En la campaña TeamPCP, los atacantes utilizaron paquetes comprometidos y herramientas de desarrollo para recolectar tokens, credenciales de nube, claves SSH, archivos de configuración npm y variables de entorno.
Shai-Hulud impulsó el mismo patrón aún más, convirtiendo los entornos de desarrolladores infectados en puntos de recopilación de credenciales que expusieron miles de secretos en GitHub, servicios en la nube, registros de paquetes y sistemas internos.
Esto no es sólo una manipulación del software. Se trata de una recopilación de credenciales en puntos en los que los desarrolladores y la automatización ya tienen confianza.
La cadena de suministro queda expuesta cuando los atacantes obtienen acceso a credenciales y contexto que les permiten alterar, publicar, construir, implementar o hacerse pasar por sistemas de software confiables. Los paquetes modificados y publicados en un ataque moderno a la cadena de suministro permanecen activos durante horas, mientras que las herramientas de automatización combinan actualizaciones maliciosas en minutos.
El hilo conductor de muchos de los ataques recientes han sido los secretos, ya sea como vector de acceso inicial o como objetivo de recopilación.
La ruta del atacante ahora pasa por el contexto del lado del desarrollador
La estación de trabajo del desarrollador es valiosa porque concentra el contexto. A menudo contiene repositorios locales, archivos .env, historial de shell, claves SSH, credenciales y configuraciones del administrador de paquetes, scripts de compilación, registros de depuración y sesiones del navegador. Esas piezas se vuelven mucho más peligrosas cuando se ven juntas.
Un token de acceso único puede parecer limitado de forma aislada. Un token que se encuentra junto a un control remoto de Git, un script de implementación, un archivo README, un perfil de nube y una configuración de CI le indica al atacante dónde encaja el token y qué podría desbloquear. En la campaña Shai-Hulud 2.0, por ejemplo, las credenciales de GitHub dominaron las credenciales expuestas y exfiltradas, cada una con potencial acceso de administrador a repositorios y flujos de trabajo de CI.
El compromiso local no es sólo un problema de dispositivo. Puede servir como mapa para el control de fuentes, cuentas en la nube, flujos de trabajo de publicación de paquetes, sistemas CI/CD, API internas e infraestructura adyacente a la producción.
Autoridad de entrega de software de Developer Machines Concentrate
Una computadora portátil estándar para empleados puede exponer datos corporativos. Una estación de trabajo de desarrollador puede exponer la capacidad de cambiar el software. Esa distinción es fundamental al considerar la seguridad de los terminales.
Los desarrolladores suelen necesitar un acceso amplio para realizar su trabajo. Clonan repositorios privados, se autentican en servicios en la nube, publican paquetes, acceden a entornos de prueba e interactúan con múltiples herramientas internas. Sus máquinas se convierten en una intersección funcional de código fuente, credenciales, automatización y autoridad de entrega.
Si bien no todos los desarrolladores tienen acceso a la producción, muchos sí tienen acceso suficiente para influir en los sistemas que eventualmente producirán resultados de producción. Un token de registro puede afectar a los paquetes. Un token de GitHub puede afectar repositorios o flujos de trabajo. Un perfil de nube puede exponer la infraestructura. Una credencial CI/CD puede afectar el comportamiento de la compilación.
A la junta y a los auditores no les importa si un desarrollador almacenó un secreto localmente. En realidad, el riesgo empresarial es que una exposición local proporcione a los atacantes un camino hacia los sistemas que crean, modifican, publican u operan software.
Ese cambio cambia las preguntas que los equipos de seguridad deberían plantearse:
- ¿Puede identificar qué credenciales se pueden utilizar desde las estaciones de trabajo de los desarrolladores?
- ¿Puede limitar el valor y la vida útil de esas credenciales?
- ¿Puede detectar material confidencial antes de que ingrese al historial de Git, registros de CI, tickets, artefactos o chat?
- ¿Puede revocar y rotar el acceso rápidamente cuando sospecha que la estación de trabajo está comprometida?
- ¿Puedes notar la diferencia entre exposición local de bajo impacto y credenciales con privilegios similares a los de administrador?
Esas preguntas se sitúan entre AppSec, endpoints, identidad, plataforma y seguridad en la nube. Independientemente de cómo decida coordinar su organización, debe comprender cómo se conecta el comportamiento de los desarrolladores con los sistemas de entrega.
La automatización y la inteligencia artificial hacen que la superficie de exposición sea más delgada y rápida
La automatización ha comprimido el tiempo entre el compromiso y el impacto. Los robots de actualización de dependencias pueden abrir y fusionar cambios rápidamente. Los sistemas CI/CD pueden ejecutar flujos de trabajo confiables automáticamente. Los administradores de paquetes pueden ejecutar scripts de instalación. Los agentes de IA y los asistentes de codificación pueden leer archivos, llamar a herramientas, generar comandos, inspeccionar resultados y mover el contexto entre sistemas.
La automatización no es intrínsecamente insegura, pero normalmente cualquier automatización hereda la confianza, especialmente si se presenta en forma de agencia. Si una actualización de dependencia maliciosa parece rutinaria, un flujo de trabajo automatizado puede hacerla avanzar más rápido de lo que un revisor humano puede entender lo que sucedió.
IA en el circuito
El desarrollo asistido por IA añade otro conjunto de puntos de transferencia. Los datos confidenciales pueden aparecer en mensajes, salidas de terminales, llamadas a herramientas, código generado, memoria del agente, registros y configuración local copiados en una sesión de depuración. La cuestión es más amplia que si un proveedor de modelos almacena indicaciones. El problema más importante es que el contexto de desarrollo local ahora fluye a través de sistemas más semiautomatizados.
Los equipos de seguridad deben evaluar el riesgo de la codificación de IA a través de la misma lente que utilizan para el riesgo de la cadena de suministro. Los equipos deben responder: ¿qué fuentes y datos puede leer la herramienta? ¿Qué puede ejecutar? ¿A dónde va la producción? ¿Qué credenciales hay cerca? Y, quizás lo más importante, ¿qué confianza hereda el flujo de trabajo?
Los controles posteriores siguen siendo importantes, pero ya es demasiado tarde por sí solos
El escaneo de repositorios, la protección de sucursales, la política de CI/CD, la firma de artefactos, el análisis de dependencias y los controles de tiempo de ejecución siguen siendo esenciales. Crean puntos de cumplimiento compartidos y ayudan a los equipos a controlar el software a escala.
El problema ahora es el momento oportuno, gracias a la velocidad de los ataques modernos. Los atacantes ahora aprovechan las herramientas impulsadas por IA para explotar todos y cada uno de los secretos a los pocos segundos de ser descubiertos.
Las barandillas reducen la exposición potencial y el radio de explosión. La captura de material confidencial mientras un desarrollador edita un archivo, prepara una confirmación, ejecuta un comando local, instala una dependencia o interactúa con un asistente de inteligencia artificial mantiene el impacto al mínimo.
Los programas maduros distinguen entre acciones que deberían bloquearse, acciones que deberían dar advertencias y acciones que simplemente deberían generar telemetría para una investigación más profunda. El objetivo no es sepultar a los desarrolladores en fricciones.
Trate la estación de trabajo como un límite de la cadena de suministro local
La cadena de suministro de software moderna no comienza cuando se envía código. Comienza donde el código, las credenciales, la automatización y la confianza se unen por primera vez.
Es hora de tratar la estación de trabajo del desarrollador como un límite de la cadena de suministro local. Ese límite incluye el IDE, la terminal, el cliente Git, el administrador de paquetes, las herramientas de contenedor, la CLI en la nube, el sistema de compilación local, las prácticas de manejo de secretos, los asistentes de IA y los agentes de automatización. Es el lugar donde la acción de los desarrolladores individuales se convierte en un riesgo de entrega de software organizacional.
¿Encontró interesante este artículo?
Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en
noticias de google,
Gorjeo y
LinkedIn para leer más contenido exclusivo que publicamos.
