Lo que revela la campaña Miasma sobre el nuevo modelo de amenaza de la cadena de suministro y el mercado clandestino de credenciales de desarrollador.

Una cookie de sesión robada estuvo en mercados clandestinos durante siete semanas antes de que los atacantes la usaran para envenenar 32 paquetes de Red Hat en el registro de software npm, un ejemplo del enfoque industrial detrás de los ataques modernos a la cadena de suministro. Puntos clave Miasma es un gusano npm autorreplicante derivado de Mini Shai-Hulud que TeamPCP lanzó como código abierto el 12 de mayo. La publicación pública de la herramienta completa armada significa que cualquier operador puede ahora replicar campañas estructuralmente idénticas a las de la cadena de suministro. La campaña Miasma comprometió más de 89 paquetes npm en tres oleadas (del 1 al 5 de junio), afectando los repositorios de Red Hat, Vapi.ai y Microsoft Azure. El gusano generó paquetes maliciosos con atestados de procedencia de SLSA Build Level 3 válidos, derrotando el nivel más alto de verificación de integridad de la cadena de suministro. La causa raíz fue una credencial de desarrollador robada que permaneció en registros de infostealers durante siete semanas antes de ser armada. Este pipeline de infostealer a cadena de suministro es el patrón definitorio de la Economía de Credenciales de Desarrolladores. La tercer oleada de la campaña Miasma (5 de junio) introdujo una escalada significativa: archivos de persistencia que apuntan a asistentes de codificación de IA (Claude Code, Cursor, Gemini CLI, VS Code), expandiendo la superficie de ataque desde los registros de paquetes hasta el entorno local del desarrollador. Confiar en la detección a nivel de ejecución, como EDR, es insuficiente contra las amenazas de la cadena de suministro porque las herramientas EDR carecen de visibilidad en los entornos CI/CD efímeros donde ocurren el robo de credenciales y la armamento. Las organizaciones deben tratar las credenciales de desarrollador como infraestructura de plano de control y adoptar un enfoque escalonado de Gestión Continua de la Exposición a Amenazas (CTEM): endurecer la capa de generación, neutralizar secretos cosechados en tiempo real y hacer cumplir controles de publicación con intervención humana. Antecedentes sobre el gusano Miasma y el ataque a la cadena de suministro npm El 1 de junio, el gusano autorreplicante Miasma comprometió 32 paquetes npm oficiales bajo el espacio de nombres @redhat-cloud-services, entregando una carga útil de recolección de credenciales a un estimado de 80,000 a 117,000 descargas semanales. En cinco días, la campaña se escaló a través de tres distintas oleadas de ataque y forzó a GitHub a desactivar 73 repositorios en cuatro organizaciones de Microsoft. Los detalles técnicos del ataque a la cadena de suministro de Miasma son alarmantes: atestados de procedencia válidos de Niveles de Cadena de Suministro para Artefactos de Software (SLSA) en paquetes maliciosos; una nueva técnica de ejecución que elude la monitorización de scripts de instalación; y un nuevo mecanismo de persistencia que apunta a asistentes de codificación de IA. Pero el detalle más importante es una marca de tiempo. La firma de monitoreo de la red oscura Whiteintel detectó la credencial de GitHub y la cookie de sesión de un empleado de Red Hat en registros de infostealers el 13 de abril. Una segunda aparición se produjo el 15 de mayo. La credencial estuvo en mercados clandestinos durante aproximadamente siete semanas antes de que los atacantes la armaran el 1 de junio. Ese lapso de siete semanas es la firma de un modelo de amenaza emergente que el equipo de Operaciones Especiales de Investigación de Tenable (RSO) llama la Economía de Credenciales de Desarrolladores, y ha estado rastreando desde marzo de 2026. La Economía de Credenciales de Desarrolladores es un mercado negro estructurado para credenciales de desarrollador altamente privilegiadas donde los compromisos de la cadena de suministro de código abierto funcionan como infraestructura de generación de credenciales, los mercados clandestinos sirven como capa de distribución, y múltiples actores de amenazas con motivaciones distintas arman el acceso cosechado aguas abajo. La campaña Miasma es el ejemplo más claro de este modelo hasta la fecha y valida un patrón que ha estado acelerándose a través de los ecosistemas de npm, PyPI y GitHub a lo largo de 2026. La economía de tres capas, explicada a través de Miasma Cuando Tenable RSO evaluó por primera vez este patrón en marzo, construyó el análisis en torno a la campaña en cascada de TeamPCP (Trivy, KICS, LiteLLM, Telnyx y más de 66 paquetes npm) y el compromiso de Sapphire Sleet/UNC1069 Axios. La tesis identificó una estructura de tres capas: generación de credenciales, distribución y armamento. Tres meses después, la campaña Miasma valida cada capa con sorprendente claridad. CapaActor / grupoEnfoque operacionalObjetivos primariosValidación Miasma GeneraciónTeamPCPHarvest de credenciales a gran escala a través de la explotación de herramientasTrivy, KICS, TanStack, Red Hat en npmMiasma genera tokens de GitHub, credenciales de nube, secretos de CI/CD, claves SSH y archivos .env de cada entorno infectado. DistribuciónMercados clandestinos, agregadores de infostealersCorretaje de credenciales y proliferación de herramientasCredenciales de desarrollador robadas; código de gusano de código abiertoLa credencial de un empleado de Red Hat estuvo en registros de infostealers durante siete semanas antes de ser armada; código fuente de Shai-Hulud publicado el 12 de mayo. ArmamentoSapphire Sleet (nexo DPRK), LAPSUS$, operador de Miasma, actores imitadoresExfiltración patrocinada por el estado, robo de datos, compromiso en cascada de la cadena de suministroAxios (npm), Mercor AI, @vapi-ai/server-sdk, Azure/durabletaskCada ola de Miasma genera un nuevo conjunto de credenciales, alimentando la siguiente ola y habilitando a los actores aguas abajo. Capa 1: Generación de credenciales La primera capa de la Economía de Credenciales de Desarrolladores es la extracción. Los actores de amenazas comprometen herramientas de desarrollador e infraestructura de código abierto no principalmente para distribuir malware a los usuarios finales, sino para cosechar las credenciales que esos entornos contienen, como tokens de GitHub, tokens de publicación de npm, credenciales de proveedores de nube, secretos de CI/CD, claves SSH y claves API. TeamPCP fue pionero en esto a gran escala comenzando en septiembre de 2025 con el gusano original Shai-Hulud. Su innovación definitoria fue la extracción en cascada de credenciales: comprometer una herramienta confiable, cosechar las credenciales que contiene y usar esas credenciales para comprometer la siguiente herramienta en la cadena de dependencias. El compromiso del escáner de vulnerabilidades Trivy obtuvo secretos de ejecutores de CI/CD. Esos secretos habilitaron el compromiso de KICS. KICS produjo credenciales de nube adicionales. Cada eslabón en la cadena generó un conjunto más amplio de acceso privilegiado. Para mayo, TeamPCP había refinado esto en la variante Mini Shai-Hulud, la cual introdujo dos capacidades que hicieron que la capa de generación fuera dramáticamente más eficiente: Propagación a través de gusanos: El malware consulta el registro npm para cada paquete que la identidad comprometida puede publicar y se republica a través de todos ellos automáticamente. Secuestro de pipeline de CI/CD mediante la extracción de tokens de OpenID Connect (OIDC): en lugar de robar credenciales estáticas, Mini Shai-Hulud solicita tokens OIDC de corta duración a través de GitHub Actions, lo que permite publicar paquetes con procedencia criptográfica válida. En la campaña de la cadena de suministro Miasma, esta capa de generación operó a través de la cuenta de GitHub comprometida de un empleado de Red Hat. La carga útil del gusano barrió el entorno infectado en busca de: tokens de GitHub y tokens de acceso personal, tokens de publicación de npm, credenciales de nube de AWS, GCP y Azure, tokens de Vault de HashiCorp, tokens de cuenta de servicio de Kubernetes, claves privadas SSH, credenciales de registro de Docker, claves GPG, archivos .env. La variante de junio añadió coleccionistas dedicados para identidades de nube de GCP y Azure, yendo más allá de la extracción de secretos para enumerar todo el acceso a la nube que tiene la máquina infectada. Cada máquina que ejecutó npm install contra una versión comprometida de un paquete @redhat-cloud-services se convirtió en un nodo de generación de credenciales. Capa 2: Distribución La segunda capa es el mercado. Las credenciales robadas fluyen desde la capa de generación hacia mercados clandestinos, agregadores de registros de infostealers y servicios de corretaje de acceso, donde se vuelven disponibles para cualquier comprador. La línea de tiempo del ataque a la cadena de suministro de Miasma hace visible esta capa de una manera que campañas anteriores no hicieron. Whiteintel detectó la credencial de GitHub de un empleado de Red Hat y la cookie de sesión en registros de infostealers el 13 de abril. Esa credencial no fue generada por un ataque directo a la cadena de suministro contra Red Hat; un infostealer de uso común la cosechó, uno de los 13.2 millones de infecciones de infostealers que el Informe de Exposición de Identidad de SpyCloud de 2025 documentó como generando un promedio de 50 credenciales por infección. La credencial ingresó a la capa de distribución como un punto de datos entre miles de millones: SpyCloud recuperó 5.3 mil millones de pares de credenciales, 18.1 millones de claves y tokens API expuestos, y 8.6 mil millones de cookies de sesión robadas de la monitorización de criminales en el submundo solo en 2025. Durante siete semanas, la credencial estuvo en la capa de distribución antes de que alguien actuara sobre ella. Ese tiempo de espera es la brecha sistémica que explota la Economía de Credenciales de Desarrolladores. Las organizaciones que no monitorean los mercados clandestinos para credenciales de desarrollador expuestas están operando bajo la suposición de que el pipeline de generación a armamento no existe, o que opera demasiado lentamente para importar. Miasma demuestra que incluso una ventana de siete semanas, que es larga según los estándares del mercado clandestino, es más que suficiente para el armamento. La capa de distribución se amplificó aún más el 12 de mayo, cuando TeamPCP publicó el código fuente completo de Mini Shai-Hulud en GitHub bajo una Licencia MIT con el mensaje "Shai-Hulud: Abriendo El Carnage". La publicación incluía scripts de envenenamiento de caché de CI, el extractor de tokens OIDC y el ladrón de credenciales con su lógica de propagación. Este es el equivalente en la cadena de suministro de publicar un marco de explotación operativo: la herramienta misma se convirtió en un canal de distribución, reduciendo la barrera de entrada para cualquier operador que desee ejecutar una campaña estructuralmente idéntica. Capa 3: Armamento La tercera capa es el uso operacional. Los actores con motivaciones distintas adquieren credenciales de la capa de distribución y las arman contra objetivos específicos. En marzo, el equipo RSO documentó al menos tres actores distintos operando desde el mismo conjunto de credenciales: TeamPCP cosechó a gran escala: Sapphire Sleet/UNC1069 (nexo DPRK) operacionalizó tokens npm robados con fines financieros a través del compromiso de Axios y LAPSUS$ explotó credenciales comprometidas de VPN Tailscale provenientes de la violación de LiteLLM para el robo de datos de Mercor AI. El mismo ecosistema de credenciales alimentó a los tres. La capa de armamento de Miasma sigue evolucionando, pero la trayectoria a través de sus tres oleadas demuestra el patrón: Ola 1 (1 de junio) utilizó las credenciales robadas de Red Hat para comprometer 32 paquetes de @redhat-cloud-services, generando una nueva ronda de credenciales desde cada entorno de desarrollo que instaló una versión comprometida. Ola 2 (3 de junio) pivotó a 57 paquetes adicionales utilizando una técnica novedosa que los investigadores llaman "Phantom Gyp", que abusa de un archivo binding.gyp de 157 bytes para activar la ejecución de código durante npm install, eludiendo la monitorización de scripts de preinstalación que los defensores habían implementado tras las oleadas anteriores. Ola 3 (5 de junio) usó una cuenta de colaborador previamente comprometida, la misma que se usó en el ataque de PyPI del 19 de mayo, para enviar commits maliciosos al repositorio Azure/durabletask de Microsoft, forzando a GitHub a desactivar 73 repositorios en un barrido automatizado de 105 segundos. Cada ola alimentó a la siguiente: las credenciales robadas en la Ola 1 posibilitaron el acceso a los objetivos de la Ola 2, y las mismas cuentas comprometidas persistieron en la Ola 3. El comportamiento autorreplicante del gusano asegura que el conjunto de credenciales crezca con cada infección exitosa, creando un ciclo acumulativo donde generación y armamento se superponen. La escalada que debería preocupar a cada equipo de seguridad Tres aspectos de la campaña Miasma representan escaladas genuinas más allá de lo que la comunidad de seguridad había observado en ataques anteriores a la cadena de suministro. 1. La atestación de procedencia ya no es suficiente Los paquetes de la Ola 1 de Miasma llevaban atestaciones de procedencia de SLSA Build Level 3 válidas, el nivel más alto de verificación de integridad de la cadena de suministro de software. El pipeline CI/CD legítimo de Red Hat construyó los paquetes, utilizando la identidad de OpenID Connect (OIDC) confiable de Red Hat, a través de flujos de trabajo de GitHub Actions que el atacante inyectó en el pipeline. El certificado criptográfico era preciso. El paquete realmente fue construido por ese pipeline. El pipeline simplemente contenía malware en ese momento. Esto no es una elusión de la verificación de procedencia. Es una demostración de que la verificación de procedencia responde a una pregunta diferente de la que los defensores asumen. Una atestación firmada prueba que un pipeline específico construyó un paquete. No prueba que el pipeline estaba limpio. Las organizaciones que dependen de la verificación de procedencia como su control primario de cadena de suministro deberían tratar a Miasma como una limitación estructural, no como un fracaso aislado. 2. Los agentes de codificación de IA ahora son una superficie de ataque La ola Phantom Gyp (3 de junio) y la ola de Azure (5 de junio) introdujeron un mecanismo de persistencia que no se había documentado anteriormente en campañas de cadena de suministro: el malware deja archivos de configuración en directorios de proyectos para asistentes de codificación de IA, incluyendo .claude/settings.json para Claude Code, .cursor/rules para Cursor y archivos de configuración para Gemini CLI y VS Code. Estas no son extensiones trojanizadas o plugins comprometidos. Son sobrescrituras a nivel de instrucciones que alteran silenciosamente el comportamiento del asistente de IA la próxima vez que un desarrollador abra el proyecto. Si un desarrollador abre un proyecto infectado en un IDE asistido por IA, la puerta trasera se ejecuta. Las instrucciones ocultas del atacante pueden influir entonces en el código generado por IA, potencialmente introduciendo vulnerabilidades sutiles que son difíciles de distinguir de sugerencias legítimas. Esto representa una expansión significativa de la superficie de ataque desde los registros de paquetes y pipelines de CI/CD hasta el entorno local del desarrollador y el flujo de trabajo asistido por IA. El ataque no requiere npm install; se activa cuando un desarrollador abre un repositorio. Esta es la primera campaña de cadena de suministro observada que apunta sistemáticamente al flujo de trabajo de desarrollo asistido por IA como una superficie de persistencia y propagación. A medida que los asistentes de codificación de IA se convierten en herramientas estándar en entornos de desarrollo empresarial, es probable que este vector de ataque sea replicado y refinado. 3. La herramienta de código abierto ha creado un ecosistema de imitadores Mini Shai-Hulud ya no está limitado a TeamPCP. La publicación pública de la herramienta completa armada el 12 de mayo significa que cualquier operador puede replicar campañas estructuralmente idénticas contra nuevos ecosistemas objetivo. La carga útil de Miasma se deriva del código de código abierto, con modificaciones estéticas reemplazando referencias al universo de Dune con temas de mitología griega ("Miasma", "espartano", "hidra nemea"). No está claro si esto es TeamPCP operando bajo una nueva marca o un actor separado que estudió el código publicado y lo mejoró. Lo que está claro es la implicación. La barrera para llevar a cabo ataques a la cadena de suministro npm ha sido significativamente y permanentemente rebajada. Las pruebas sugieren que esta proliferación ya está ocurriendo. La Unidad 42 de Palo Alto Networks documentó que la actividad de imitadores que utiliza el código de herramientas Shai-Hulud ha complicado la atribución futura, y la evolución de la ola Phantom Gyp (ejecución de binding.gyp, enfoque en agentes de IA, canales de exfiltración modificados) es consistente con la operación continua de TeamPCP o un operador capaz que se basa en la infraestructura disponible públicamente. Por qué EDR y la detección reactiva no pueden resolver este problema La narrativa en torno a la defensa de la cadena de suministro ha dependido en gran medida de la detección a nivel de ejecución: la idea de que las herramientas de detección y respuesta de endpoint (EDR) capturarán la carga útil cuando se active, por lo que las organizaciones están protegidas. La campaña Miasma expone por qué esta suposición es estructuralmente defectuosa. EDR monitorea la ejecución, no la exposición. Confiar en EDR para detener un ataque a la cadena de suministro es como confiar en un detector de humo mientras almacenas canisters abiertos de gasolina en tu cocina. EDR no puede ver la Acción de GitHub mal configurada, el token npm sobreprivilegiado o la credencial robada de siete semanas que está en un mercado clandestino. Para cuando un agente EDR se activa ante una carga útil maliciosa, el robo de credenciales que habilita la siguiente ola ya ha ocurrido. La brecha de cobertura es donde ocurre el robo. EDR no tiene visibilidad sobre los ejecutores CI/CD efímeros y los entornos de construcción donde realmente se lleva a cabo la recolección de credenciales de Miasma. Estos entornos se activan, ejecutan el npm install comprometido, exfiltran secretos y se desactivan, todo antes de que un analista humano pudiera clasificar una alerta. En la Economía de Credenciales de Desarrolladores, el robo ocurre donde los agentes no están. La evasión de detección supera a la detección. Después del compromiso de TanStack en mayo, los defensores implementaron monitorización de scripts de preinstalación como control de detección. La ola Phantom Gyp, llegando solo tres semanas después, eludió ese control por completo al cambiar la ejecución a binding.gyp, un archivo que la mayoría de las herramientas de seguridad no monitorizan. La ola de Azure luego abandonó por completo la instalación de paquetes, trasladándose a archivos de configuración a nivel de repositorio que se activan al abrir IDE/editor. Cada respuesta defensiva crea un nuevo objetivo de evasión, y el ciclo de iteración se mide en días, no meses. La evasión de EDR es una capacidad activa e industrializada, y los atacantes de la cadena de suministro están demostrando el mismo comportamiento adaptativo. Si bien EDR tiene un papel, aborda el síntoma (la carga útil de malware en ejecución) en lugar de la enfermedad (la exposición no gestionada de credenciales de desarrollador e infraestructura de CI/CD). Neutralizar el riesgo sistémico creado por la Economía de Credenciales de Desarrolladores requiere un enfoque fundamentalmente diferente: identificar y eliminar las condiciones de exposición antes de que un atacante pueda explotarlas. El ecosistema responde, pero la brecha estructural permanece El ecosistema de npm no ha sido pasivo. npm ejecutó una invalidación de tokens a nivel de plataforma el 19 de mayo, obligando a cada mantenedor a re-autenticar. La versión 11.15.0 de npm CLI introdujo la publicación escalonada con puertas de aprobación humana de 2FA, requiriendo un paso de confirmación humano deliberado antes de que cualquier versión de paquete se haga pública. GitHub divulgo que aproximadamente 3,800 repositorios internos habían sido exfiltrados durante las campañas de Shai-Hulud. Isaac Schlueter, fundador de npm, pidió la desactivación obligatoria de la publicación sin MFA. Si bien son significativos, estas respuestas son estructuralmente reactivas: cada una aborda la técnica observada en la oleada anterior mientras el atacante ya se ha movido a la siguiente. La publicación escalonada aborda el abuso de tokens OIDC de la Ola 1. No aborda la ejecución de binding.gyp de la Ola 2. Ninguna aborda la persistencia del agente de codificación de IA de la Ola 3. El camino a seguir requiere pasar de la detección reactiva a la gestión de exposición preventiva: identificar y cerrar los puntos de generación de credenciales antes de que los atacantes puedan armarlos. Un enfoque escalonado para interrumpir la economía de credenciales La Economía de Credenciales de Desarrolladores opera sobre un principio simple: las credenciales que los defensores no conocen que están expuestas no pueden ser rotadas, y por lo tanto, permanecen vulnerables. Un enfoque CTEM escalonado interrumpe la cadena de ataque en cada capa. Fase 1: Endurecer la capa de generación La primera prioridad es eliminar las condiciones que permiten que ocurra el robo de credenciales. Las organizaciones deben auditar los archivos de bloqueo y eliminar los ganchos del ciclo de vida (--ignore-scripts) de inmediato para eliminar los vectores de preinstalación y postinstalación. Pero la ola Phantom Gyp de Miasma demuestra que los ganchos del ciclo de vida ya no son la única superficie de ejecución: agrega monitorización de binding.gyp a los controles de ingreso de paquetes y audita todos los repositorios clonados en busca de archivos de persistencia del agente de codificación de IA (.claude/settings.json, .cursor/rules, .gemini/ archivos de configuración). Las herramientas de seguridad mismas deben considerarse infraestructura crítica. Los eventos de 2026 han demostrado esto repetidamente: Trivy, Checkmarx KICS y la extensión de VS Code Nx Console funcionaron como puntos de entrada de alto valor precisamente porque los desarrolladores confían en ellas. Sujeta las herramientas de seguridad a los mismos controles de verificación de integridad e aislamiento que se aplican a los sistemas de producción. Fase 2: Neutralizar secretos cosechados en tiempo real El tiempo de permanencia de siete semanas de las credenciales en la línea de tiempo del ataque de Miasma es la ventana de explotación de la que depende la Economía de Credenciales de Desarrolladores. Cerrar esa ventana requiere ir más allá de la rotación periódica hacia una visibilidad continua sobre dónde están expuestas las credenciales, incluyendo en mercados clandestinos, ejecutores de CI/CD y etapas de construcción efímeras donde EDR no tiene huella. Implementar monitorización continua de credenciales en la dark web para cuentas de desarrollador (GitHub, npm, PyPI, Docker Hub) con rotación automática al detectar. Hacer cumplir MFA obligatoria con vidas útiles reducidas de tokens de acceso personal. El Informe de Riesgo de Seguridad en la Nube y AI de Tenable 2026 encontró que el 65% de los entornos en la nube contienen "credenciales fantasmas", cuentas de servicio inactivas y claves no rotadas que proporcionan puntos de pivote listos para los atacantes. Cada credencial fantasma es un pase gratis para un actor que opera en la capa de distribución. Usa Tenable One para mapear la superficie completa de ataque, incluyendo los pipelines de CI/CD y las etapas de construcción nativas en la nube que la detección a nivel de ejecución no puede alcanzar. Fase 3: Hacer cumplir la publicación con intervención humana y romper la cadena de automatización El autorreplicante del gusano depende de la publicación automáticamente: roba un token, enumera los paquetes publicables, republica con malware, repite. Insertar un paso obligatorio de confirmación humana rompe esa cadena de automatización. La función de publicación escalonada de npm (npm CLI 11.15.0) representa una implementación concreta de esta puerta, requiriendo una aprobación humana de 2FA antes de que cualquier versión de paquete se haga pública. Las organizaciones deberían: Adoptar publicación escalonada o flujos de trabajo equivalentes de intervención humana de inmediato. Revisar el alcance del token OIDC de GitHub Actions para asegurar que id-token: Write esté limitado a flujos de trabajo de lanzamiento en ramas protegidas únicamente. Implementar controles de mínimaEdadDePublicación para poner en cuarentena nuevas versiones de paquetes antes de su consumo. Establecer reglas de detección para indicadores de Miasma: repositorios de GitHub con la descripción "Miasma: El Blight que se Propaga"; la cadena de agente de usuario de GCP google-api-nodejs-client/7.0.0; y la cuenta de GitHub dead-drop liuende501. Monitorear eventos npm public anomalosos y creación no autorizada de repositorios de GitHub en cuentas organizativas. Estas no son medidas de endurecimiento opcionales. Son respuestas directas a capacidades que se han demostrado en la práctica y que ahora están disponibles como herramientas de código abierto para que cualquier operador implemente. Hacia dónde va esto a partir de aquí La Economía de Credenciales de Desarrolladores representa una maduración significativa del cibercrimen, yendo más allá de ataques oportunistas para establecer un mercado sofisticado, escalable y altamente especializado. Los eventos de marzo a junio han validado esta evaluación con sorprendente claridad: la apertura de TeamPCP del gusano Shai-Hulud; la proliferación de variantes imitadoras como Miasma; la difusión trans-ecosistema de npm a PyPI a GitHub Actions a extensiones de VS Code; y la introducción del enfoque en agentes de codificación de IA como una nueva superficie de persistencia. Esta evolución convierte nuestras propias herramientas de desarrollo en nuestra contra para cosechar el acceso necesario para compromisos a gran escala. El camino a seguir es un cambio fundamental hacia la inteligencia de exposición que identifica y cierra los puntos de generación de credenciales antes de que los atacantes puedan armarlos. Las organizaciones que soportarán este cambio son aquellas que traten los entornos de desarrollo como infraestructura de plano de control, no como estaciones de trabajo, y los gestionen con la visibilidad continua y el endurecimiento proactivo que proporciona un marco CTEM. La estela de credenciales de siete semanas de Miasma no es un peor caso. Es una línea base, y la siguiente ola ya se está ensamblando a partir de la misma herramienta de código abierto. Aprenda más Mini Shai-Hulud: Preguntas frecuentes sobre la campaña de cadena de suministro de TeamPCP La economía de credenciales de desarrolladores: por qué los datos de exposición son la nueva línea de frente en la guerra de la cadena de suministro Aplastar la amenaza de la cadena de suministro de Axios con Tenable Hexa AI: casos de uso para AI agente Preguntas frecuentes sobre el ataque a la cadena de suministro de Axios npm por el actor de amenaza UNC1069 relacionado con Corea del Norte Descarga de bombeo: nueva técnica de engaño de npm para ataques a la cadena de suministro Únase al equipo de Operaciones Especiales de Investigación de Tenable (RSO) en Tenable Connect para más discusiones sobre las últimas amenazas cibernéticas. Aprenda más sobre Tenable One, la plataforma de gestión de la exposición para la superficie de ataque moderna.