La malware de código abierto ha cambiado de forma.
Lo que antes se concentraba en la minería ruidosa de cryptomonedas se ha movido hacia algo mucho más valioso: el acceso.
Nuestros datos recientes muestran que los atacantes apuntan cada vez más a credenciales y secretos incrustados en dependencias de software, con las organizaciones del Reino Unido en el foco.
Este cambio marca una transición de abuso oportunista a compromiso deliberado de la cadena de suministro. En lugar de agotar ciclos de cómputo, los atacantes se posicionan dentro de los pipelines de construcción y en los flujos de trabajo de los desarrolladores.
El objetivo es la persistencia, no la disrupción.
Para las organizaciones que confían en gran medida en software de código abierto, esto cambia fundamentalmente tanto el modelo de amenaza como el impacto potencial.
Esto es lo que “shift left” significa en 2026: controlar lo que entra en la compilación, no solo detectar lo que se ejecuta en producción.
Por qué el robo de credenciales ha superado a la criptominería
Más de la mitad de los paquetes maliciosos de código abierto se centran ya en robar credenciales y secretos, superando a la criptominería como tipo de amenaza dominante. La razón es simple. Las credenciales ofrecen valor duradero. Proporcionan acceso persistente, mayor alcance entre entornos y un menor riesgo de detección que el abuso de recursos. Un token o una clave API robados pueden abrir sistemas completos, no solo una máquina.
La criptominería, en cambio, es fácil de detectar y rápida de detener. Consuma recursos y activa alertas. El robo de credenciales se integra y puede ejecutarse en segundos. Aprovecha la confianza puesta en los flujos de trabajo de los desarrolladores para operar en un entorno seguro.
Para los atacantes que buscan maximizar el retorno minimizando la exposición, este enfoque maximiza ganancias sin el riesgo de ser descubierto.
La implicación es clara: proteger la infraestructura de runtime ya no basta. El límite de seguridad ahora empieza en la ingestión de dependencias y en el entorno del desarrollador.
El malware de múltiples etapas se convierte en la norma
El malware moderno de código abierto rara vez es de un solo propósito. Nuestro análisis muestra que el comportamiento de dropper y loader aumenta casi un 2.900 por ciento año tras año en el primer trimestre de 2025, señalando un cambio hacia ataques elaborados y de múltiples etapas.
Alrededor del 77 por ciento de los paquetes maliciosos distribuidos a través de ecosistemas de código abierto ahora combinan múltiples tipos de amenaza. Los droppers aparecen en casi todos los casos observados, mientras que las características de exfiltración de secretos se encuentran en casi dos tercios.
Estos paquetes están diseñados para evolucionar después de la instalación, introduciendo payloads adicionales o cambiando comportamiento con el tiempo. Esto refleja campañas industrializadas más que experimentación oportunista. Los atacantes están invirtiendo en resiliencia, sigilo y escala.
Para los defensores, esto significa que pensar en firmas ya no basta. Si el malware es modular y adaptable, los controles deben centrarse en la procedencia, el comportamiento y la prevención antes de la ejecución. De nuevo, esto es lo que “shift left” significa: asegurar el propio grafo de compilación, no solo las cargas de trabajo que produce.
Cadenas de suministro bajo presión directa
El uso generalizado de código abierto, especialmente dentro del ecosistema de JavaScript, crea exposición sistémica. Las aplicaciones modernas dependen de cientos de paquetes directos y transitivos de npm. Esa densidad de reutilización genera eficiencia, pero también amplifica el riesgo ascendente.
La actividad reciente vinculada al grupo Lazarus ilustra la amenaza. Se identificaron más de 200 paquetes maliciosos, casi todos concentrados en npm. Cuando un único ecosistema sostiene plataformas financieras, servicios gubernamentales y una infraestructura nacional crítica, el riesgo de concentración se convierte en un problema estratégico.
Una dependencia comprometida no permanece aislada. Se propaga a través de marcos compartidos, bibliotecas internas y pipelines de CI. En sectores basados en rapidez y reutilización, el compromiso ascendente se convierte rápidamente en impacto descendente. Por eso la gobernanza de dependencias ya no es solo un tema de higiene de desarrolladores; es una preocupación de la cadena de suministro a nivel de junta directiva.
La automatización convierte un paquete en miles de compromisos
Los malware de hoy apuntan cada vez más a pipelines de CI/CD y flujos de trabajo de desarrollo optimizados para la automatización. Cuando una dependencia comprometida entra en una compilación, puede extraer silenciosamente claves API, certificados y tokens de acceso sin activar alertas en tiempo de ejecución. La automatización hace el resto.
Lo que comienza como un único paquete envenenado puede diseminarse a través de cientos o miles de compilaciones. Los sistemas diseñados para acelerar la entrega aceleran también la compromiso.
La conclusión práctica es inquietante pero necesaria: si los sistemas de compilación están automatizados, los controles de seguridad deben estar automatizados al mismo nivel. La revisión manual no puede escalar frente a la distribución automatizada.
Asistentes de codificación impulsados por IA y el problema de las alucinaciones
La IA en el desarrollo añade una capa adicional de riesgo. Estudios y pruebas han mostrado que los modelos de lenguaje grandes pueden, en un porcentaje significativo, sugerir paquetes o funciones que no existen. Los desarrolladores ante la presión de tiempo pueden intentar instalar o depender de estas dependencias alucinadas, ampliando sin saberlo la superficie de ataque.
Los nombres de paquetes alucinados, ejemplos fabricados y sugerencias de dependencias inseguras pueden socavar silenciosamente la integridad de la cadena de suministro. Ya hay atacantes aprovechando convenciones de nombres y modelos de confianza para sembrar paquetes que parecen legítimos tanto para humanos como para máquinas.
Cada alucinación genera retrabajo, fricción y pérdida de productividad. Mucho de este desperdicio podría reducirse si los sistemas de IA estuvieran anclados a inteligencia de paquete autoritaria y en tiempo real, más que a la predicción de patrones.
Nuestra investigación reciente refuerza este punto. La empresa encontró que modelos de IA más pequeños con inteligencia de paquetes en vivo superan significativamente a modelos más grandes sin conexión cuando se manejan tareas de actualización de dependencias y selección de paquetes. Los hallazgos sugieren que el contexto real-time del ecosistema importa más que el tamaño del modelo cuando los desarrolladores toman decisiones de seguridad. También ayuda que los modelos más pequeños sean 70 veces más baratos que los modelos de vanguardia.
Esto tiene implicaciones directas para la defensa de la cadena de suministro de software. Si los asistentes de codificación de IA recomiendan dependencias sin verificar la procedencia de los paquetes, su estado de mantenimiento o señales de confianza del ecosistema, corren el riesgo de acelerar la propagación de paquetes maliciosos o alucinados en entornos de producción.
En la práctica, el desarrollo seguro asistido por IA dependerá menos de modelos cada vez más grandes y más de si esos modelos están conectados a una inteligencia de software autoritaria y actualizada de forma continua.
Aquí también la lección es control upstream. Las salvaguardas deben situarse en el punto de selección de dependencias, no después de que el código ya haya sido enviado.
Por qué los defensores se quedan atrás
Muchos controles de seguridad del Reino Unido siguen centrados en detectar amenazas después de que el código se despliega. Los atacantes se han movido upstream. Apuntan al proceso de compilación, al grafo de dependencias y a las relaciones de confianza de los desarrolladores.
Esta desalineación deja a las organizaciones bien preparadas para incidentes en runtime pero expuestas durante el desarrollo. Mientras los defensores asumen que el malware se detectará durante la ejecución, la compromisión de la cadena de suministro continuará pasando inadvertida.
“Shift left” a menudo se trata como un eslogan. En la práctica, significa hacer cumplir políticas antes de la instalación, validar la procedencia antes de la ejecución y bloquear paquetes maliciosos antes de que entren en el grafo.
Robo de llaves, no de ciclos
El malware de código abierto ha evolucionado de robar cómputo a robar acceso. Las credenciales desbloquean ecosistemas, no solo máquinas. Para las organizaciones del Reino Unido, esto convierte la seguridad de la cadena de suministro en una preocupación estratégica, no solo técnica.
Prevenir que código malicioso entre en la compilación es ahora más eficaz que responder después del despliegue. El cambio silencioso de las monedas a credenciales ya ha ocurrido. La pregunta es si las defensas se adaptarán lo suficientemente rápido para igualarlo.
Si no está automatizado, no escalas.
Qué deberían priorizar las organizaciones ahora
Para responder de manera efectiva, las organizaciones del Reino Unido deberían centrarse en un pequeño conjunto de controles estructurales:
● Controlar la ingestión de dependencias con aplicación de políticas automatizadas antes de que los paquetes entren en CI/CD.
● Monitorear de forma continua la exposición de secretos dentro de entornos de compilación y revocar credenciales comprometidas rápidamente.
● Aplicar la verificación de procedencia e integridad de componentes de código abierto, incluyendo dependencias transitivas.
● Anclar las herramientas de IA de codificación a inteligencia de paquetes autoritaria para prevenir sugerencias de dependencias alucinadas o maliciosas.
Ninguno de estos pasos elimina el riesgo. Pero, en conjunto, realinean las defensas con dónde operan realmente los atacantes: de forma upstream, automatizada y dentro de la cadena de suministro.
Hemos revisado el mejor software antivirus disponible.
Este artículo fue producido como parte de TechRadar Pro Perspectives, nuestro canal para presentar las mentes más brillantes de la industria tecnológica hoy.
Las opiniones expresadas aquí son propias del autor y no necesariamente las de TechRadarPro o Future plc. Si estás interesado en contribuir, descubre más aquí: https://www.techradar.com/pro/perspectives-how-to-submit
