Ataques a la cadena de suministro de software: lo que las organizaciones deben saber ahora
Por Orenda Security
Resumen ejecutivo: El compromiso de la cadena de suministro de software es ahora el segundo vector de brecha más común y el segundo más costoso según IBM: 4,91 millones de dólares por incidente y 267 días para contenerlo, el más largo de cualquier categoría. Sonatype identificó más de 454.600 nuevos paquetes de código abierto maliciosos en 2025, un aumento del 75 % interanual. Incidentes recientes —el gusano npm Shai-Hulud y el compromiso de chalk/debug— muestran que el riesgo de dependencias ha superado la gobernanza de la mayoría de las organizaciones. El desarrollo asistido por IA agrava el problema: los LLM alucinan paquetes inexistentes a tasas significativas, y casi la mitad del código generado por IA introduce vulnerabilidades conocidas. Este artículo aborda el panorama de amenazas, el contexto regulatorio y los cambios de gobernanza y del ciclo de vida de desarrollo de software (SDLC) que vale la pena evaluar ahora.
Un problema de gobernanza, no solo técnico
Las aplicaciones modernas se ensamblan a partir de componentes de código abierto a una escala que ha superado la visibilidad que la mayoría de las organizaciones tiene sobre su propio riesgo. El informe OSSRA 2025 de Black Duck encontró que el 97 % de las bases de código comerciales contienen componentes de código abierto, con un promedio de 911 por aplicación, el 64 % de ellos transitivos —introducidos indirectamente, sin una decisión de revisión deliberada. Esa es la razón estructural por la que los ataques a la cadena de suministro se han convertido en el patrón de intrusión dominante de 2025-2026: la superficie de ataque ha superado la gobernanza creada para controlarla.
El informe de IBM de 2025 sobre el costo de una brecha de datos sitúa el compromiso promedio de la cadena de suministro en 4,91 millones de dólares y 267 días para identificarlo y contenerlo, ambos por encima de los promedios generales de brechas. Una encuesta de BlackBerry de 2024 encontró que más del 76 % de las organizaciones habían sufrido un ataque a la cadena de suministro en el año anterior, el 74 % de ellos a través de un miembro que no monitoreaban activamente. Checkmarx encontró que el 63 % había sufrido uno en los últimos dos años, mientras que solo el 50 % solicitaba activamente SBOM a sus proveedores, y menos de la mitad sabía cómo actuar sobre ellos.
Dónde reside realmente la exposición
Cuatro patrones de ataque explican la mayoría de los incidentes actuales:
Compromiso de cuentas de mantenedores. Los atacantes obtienen mediante phishing las credenciales de un mantenedor de confianza y luego publican una actualización maliciosa de un paquete ya confiado aguas abajo, eludiendo por completo la revisión de código, ya que el código llega a través de un canal legítimo y previamente verificado.
Confusión de dependencias y typosquatting. Los atacantes registran paquetes públicos que imitan nombres privados internos, o nombres lo suficientemente parecidos a paquetes populares como para ser incorporados por herramientas automatizadas o por error del desarrollador.
Ejecución maliciosa durante la instalación. Tanto npm como Python permiten la ejecución de código arbitrario durante la instalación mediante hooks de ciclo de vida: la exposición ocurre antes de que un desarrollador llegue a usar la dependencia.
Compromiso del pipeline de CI/CD. Los sistemas de compilación (build) contienen credenciales de despliegue, claves de firma y tokens de API, lo que los convierte en objetivos de alto valor independientemente de la calidad del código. La brecha de tj-actions/changed-files expuso secretos en más de 23.000 repositorios a partir de un único token comprometido.
Incidentes reales, consecuencias reales
SolarWinds (2020) sigue siendo el caso de referencia de compromiso del proceso de compilación a gran escala: un actor estatal insertó una puerta trasera en una actualización de Orion firmada legítimamente, alcanzando aproximadamente 18.000 organizaciones, incluidas agencias federales de EE. UU., y dio forma a la respuesta regulatoria que se describe más abajo.
El compromiso de chalk/debug en npm (septiembre de 2025) ilustra el riesgo de concentración: una sola cuenta de mantenedor comprometida mediante phishing se utilizó para publicar versiones maliciosas de paquetes fundamentales de JavaScript con más de 2.000 millones de descargas semanales combinadas; un análisis estimó un radio de impacto de aproximadamente el 34 % de npm.
El gusano npm Shai-Hulud (2025) marcó un cambio en las tácticas empleadas: el primer gusano autopropagante de npm recolectó credenciales y las usó para republicar automáticamente versiones maliciosas de los propios paquetes de la víctima, propagándose sin ninguna infraestructura de mando y control. Una segunda ola en noviembre comprometió cientos de paquetes adicionales y generó decenas de miles de repositorios maliciosos.
Desarrollo asistido por IA: una nueva variable
Las herramientas de codificación con IA introducen dos riesgos distintos y medibles. Alucinación de paquetes («slopsquatting»): una investigación de USENIX Security 2025 analizó 576.000 muestras de código en 16 LLM y encontró una tasa promedio de alucinación de paquetes del 19,7 %, lo suficientemente repetible entre sesiones como para que los atacantes puedan registrar de antemano los nombres falsos más comunes. Un investigador lo demostró en la práctica: un paquete alucinado registrado como prueba obtuvo más de 15.000 descargas orgánicas en tres meses, incluida su adopción en el repositorio público de una gran empresa tecnológica. Una réplica de 2026 con modelos más recientes encontró tasas reducidas al 4,6 %-6,1 %: una mejora, pero no una eliminación.
Introducción de vulnerabilidades a nivel de código: el informe GenAI Code Security 2025 de Veracode, que evaluó más de 100 LLM en 80 tareas, encontró que el 45 % de las muestras de código generado por IA introducían vulnerabilidades del Top 10 de OWASP, una tasa que se mantuvo estable en el seguimiento de primavera de 2026 de Veracode. Apiiro encontró que el código generado por IA estaba asociado con un 322 % más de rutas de escalada de privilegios en bases de código de empresas Fortune 50.
El código asistido por IA y las dependencias sugeridas por IA merecen el mismo rigor de revisión que el código proveniente de un colaborador externo no verificado.
Fortalecer la resiliencia: qué deben hacer las empresas ahora
Gobernanza y postura de riesgo:
- Convertir la generación de SBOM en un estándar y desarrollar la capacidad de actuar sobre los SBOM proporcionados por los proveedores, no solo de recopilarlos.
- Alinear los controles con el NIST SSDF (SP 800-218) y confirmar la preparación para la EO 14028 y el CRA de la UE cuando corresponda; las obligaciones de notificación del CRA comienzan en septiembre de 2026.
- Registrar el riesgo de dependencias y del pipeline de compilación como una categoría distinta en los informes de riesgo a nivel de junta directiva.
Controles de SDLC y del pipeline:
- Exigir autenticación multifactor resistente al phishing para cualquier persona con acceso de publicación o mantenimiento sobre código del que se depende.
- Fijar las versiones de las dependencias en archivos de bloqueo (lockfiles) revisados y las acciones de CI/CD a SHA de commit específicos, no a etiquetas mutables.
- Adoptar un análisis de comportamiento de dependencias, capaz de detectar paquetes maliciosos recién publicados que las bases de datos de vulnerabilidades no pueden identificar.
- Avanzar hacia una procedencia de compilación verificada (SLSA) y la firma de artefactos (Sigstore/Cosign).
En resumen
El riesgo de la cadena de suministro ha pasado de ser una preocupación especializada a convertirse en un vector de brecha primario, con un costo medible, exposición regulatoria y visibilidad a nivel de junta directiva. Las organizaciones que lo gestionan eficazmente lo tratan como una responsabilidad compartida entre seguridad e ingeniería, integrada en los controles del SDLC en lugar de abordarla mediante auditorías periódicas.
Las pruebas de penetración y las evaluaciones de SDLC de Orenda Security están diseñadas para identificar este tipo de exposición antes de que llegue a producción, incluidas las tácticas detrás de los incidentes descritos anteriormente.
Solicita un presupuesto para obtener más información
