Un ciberataque a la cadena de suministro te afecta a través de un proveedor, una actualización de software, un paquete de código abierto, un subcontratista o un proveedor de servicios en el que ya confías. La evaluación de proveedores debe comprobar ahora cómo estos desarrollan, firman, supervisan y revocan su software, y no solo si cumplen los requisitos de un cuestionario de seguridad. Empieza por el alcance del acceso, la evidencia de la SBOM, el historial de incidentes, los derechos contractuales y la supervisión continua.
Por qué un ciberataque a la cadena de suministro es ahora un riesgo que afecta al consejo de administración
IBM X-Force informó en 2026 de que los incidentes graves relacionados con la cadena de suministro o con terceros se habían multiplicado casi por cuatro desde 2020. El mismo índice de 2026 señaló un aumento del 49% en el número de grupos activos de ransomware en 2025 con respecto a 2024, lo cual es relevante porque los atacantes utilizan cada vez más a los proveedores como vía rápida para acceder a numerosas víctimas a la vez.
Un ciberataque a la cadena de suministro resulta atractivo porque vuelve la confianza en tu contra. En lugar de irrumpir por la puerta principal, un intruso contamina un paquete, se aprovecha de un proveedor de servicios gestionados, compromete un sistema de compilación o aprovecha una vulnerabilidad en un producto de transferencia de archivos que tu equipo ya utiliza.
La intención de búsqueda en este caso es práctica e informativa: quieres saber en qué consiste este tipo de ataque, por qué está aumentando y cómo evaluar a los proveedores externos antes de que se conviertan en un problema para ti. La respuesta no es «comprar una herramienta». Las herramientas ayudan, pero tu proceso debe poner de manifiesto en qué casos se concede confianza sin pruebas.
Para las empresas más pequeñas, lo complicado es la medición. En 2026 siguen siendo escasos los datos públicos primarios fiables sobre la incidencia de ataques a la cadena de suministro específicos de las pymes; muchas de las cifras que aparecen en los titulares proceden de encuestas a proveedores o de informes secundarios. Así que no bases tu programa en estadísticas que infunden miedo. Básalo en el análisis de las dependencias: ¿qué proveedores pueden acceder a tus datos, código, sistemas de identidad, red de producción o clientes?
¿Qué es un ataque a la cadena de suministro, en palabras sencillas?
Un ataque a la cadena de suministro es una intrusión que llega al objetivo real a través de un tercero. Este tercero puede ser un proveedor de SaaS, una biblioteca de software, un integrador de servicios en la nube, un proveedor de nóminas, un MSP, una herramienta de CI/CD, un SDK para móviles o incluso el ordenador portátil de un subcontratista.
SolarWinds sigue siendo el ejemplo clásico en el ámbito empresarial. El 13 de diciembre de 2020, la CISA informó de que las versiones de la plataforma Orion de SolarWinds, desde la 2019.4 HF 5 hasta la 2020.2.1 HF 1 —lanzadas entre marzo y junio de 2020—, estaban siendo objeto de ataques activos. El 14 de diciembre de 2020, SolarWinds comunicó a la SEC que la vulneración de Orion probablemente se debía a un ataque dirigido a la cadena de suministro y que el código malicioso afectaba a las actualizaciones lanzadas durante ese mismo periodo comprendido entre marzo y junio de 2020.
MOVEit mostró otro patrón. Un aviso de junio de 2023 emitido por la CISA, el FBI y el MS-ISAC indicaba que el grupo de ransomware CL0P había aprovechado vulnerabilidades de MOVEit Transfer a partir de mayo de 2023. Muchas víctimas no fueron atacadas porque tuvieran contraseñas débiles, sino que quedaron expuestas porque un producto de transferencia de uso generalizado formaba parte de un flujo de trabajo sensible.
Las dependencias de software aportan un toque diferente. El 29 de marzo de 2024, la CISA asignó el CVE-2024-3094 a un código malicioso incrustado en las versiones 5.6.0 y 5.6.1 de XZ Utils. Ese incidente sirvió para recordar que la confianza en el código abierto es social, técnica y, en ocasiones, frágil.
Los incidentes recientes demuestran que el problema de los proveedores se está agravando cada vez más rápido
El incidente de TanStack de 2026 es el tipo de caso que los equipos de compras deberían analizar. El 11 de mayo de 2026, TanStack informó de que un atacante había publicado 84 versiones maliciosas en 42 paquetes npm de @tanstack/* entre las 19:20 y las 19:26 UTC. Seis minutos. Eso es menos tiempo del que duran las reuniones de pie de muchas empresas.
OpenAI declaró el 11 de mayo de 2026 que la vulnerabilidad de TanStack en npm formaba parte de un ataque más amplio a la cadena de suministro de software conocido como «Mini Shai-Hulud». El 12 de junio de 2026, OpenAI anunció que revocaría por completo un antiguo certificado de firma de aplicaciones para macOS después de que los dispositivos de dos empleados se vieran afectados por el incidente relacionado con TanStack. OpenAI también afirmó que no se vieron afectados los datos de los usuarios, según informaron en 2026 BleepingComputer y TechRadar.
Otros informes de 2026 ampliaron el panorama. SecurityWeek informó el 12 de mayo de 2026 de que TanStack, Mistral AI y UiPath se vieron afectados por un nuevo ataque a la cadena de suministro. Axios informó el 31 de marzo de 2026 de que investigadores de Google habían relacionado un ataque a la cadena de suministro de npm, en el que se vio implicado el paquete Axios, con un grupo presuntamente norcoreano identificado como UNC1069.
Los grupos de ransomware están atentos. ITPro informó el 3 de julio de 2026 de que Vect y TeamPCP colaboraban en una campaña que incluía ataques a la cadena de suministro y extorsión. Si se analiza la velocidad de los ataques asistidos por IA, el patrón coincide con lo que los equipos de seguridad ya están observando en campañas cada vez más rápidas, como Operaciones de ransomware basadas en la inteligencia artificial.
Criterios de selección de proveedores que realmente reducen el riesgo
Un cuestionario adecuado está bien. Un cuestionario por sí solo es puro teatro. Para un proveedor con acceso significativo, se necesitan pruebas, derechos y una forma de reaccionar cuando el riesgo del proveedor cambie tras la firma del contrato.
La norma NIST SP 800-161 Rev. 1, publicada en 2022, ofrece el marco adecuado: la gestión de riesgos de la cadena de suministro cibernética debe integrarse en las evaluaciones de proveedores, las políticas, los planes y la gestión de riesgos empresarial en general. En pocas palabras, no hay que dejar que la seguridad de los proveedores quede relegada al papeleo de las compras.
- Primero, el acceso al mapa: Enumera los sistemas, las clases de datos, los derechos de administrador, los tokens, los repositorios y los flujos de trabajo de los clientes a los que el proveedor tiene acceso.
- Pregunta por la compatibilidad con SBOM: Las directrices de la CISA para la adquisición de software en 2024 incluyen preguntas a los proveedores sobre las listas de componentes de software (SBOM) validadas en formatos legibles por máquina aprobados por la NTIA o la CISA.
- Validar los controles de compilación: Pregunte cómo valida el proveedor las bibliotecas, los sistemas de compilación, los pasos de empaquetado y las herramientas de CI/CD, otro aspecto mencionado en las directrices de adquisición de la CISA para 2024.
- Comprobar el riesgo relacionado con el personal: Se exigen respuestas claras sobre los empleados y contratistas sometidos a proceso de selección, especialmente en el caso del personal de apoyo con acceso privilegiado.
- Contrato sobre derechos en caso de incidentes: Las notificaciones, el registro de accesos, los derechos de auditoría, las obligaciones en materia de revocación de certificados, la divulgación de información sobre subcontratistas y los derechos de rescisión deben constar por escrito.
- Supervisar de forma continua: integrar la detección de vulnerabilidades con los repositorios de SBOM para que las alertas puedan vincularse a los productos que realmente utilizas, tal y como recomienda la guía del NIST sobre SBOM de 2024.
Este es el escollo que muchos equipos pasan por alto: el proveedor que presenta mayor riesgo no siempre es el más grande. Un complemento especializado con derechos de actualización automática, un pequeño proveedor de servicios gestionados (MSP) con privilegios de administrador de dominio o una herramienta de integración continua (CI) con secretos del repositorio pueden tener un alcance de impacto mayor que un gran proveedor con acceso limitado a los datos.
Si tu empresa aún está desarrollando su programa de control, combina la evaluación de proveedores con un plan de cumplimiento más amplio. El coste de pasar por alto los principios básicos de gobernanza queda bien reflejado en esta guía sobre el cumplimiento de las normas de ciberseguridad en 2026.
Un método basado en cifras para clasificar a los proveedores externos
La mayoría de las puntuaciones de riesgo de los proveedores son demasiado vagas. «Alto, medio, bajo» suena claro, pero oculta la conversación que hay que mantener. Prefiero una sencilla puntuación de exposición de 100 puntos, porque obliga a los equipos a comparar a los proveedores en función del acceso real.
Asigna a cada proveedor un máximo de 25 puntos por la sensibilidad de los datos, 25 por el nivel de privilegios, 20 por la dependencia operativa, 15 por la capacidad de actualizar el software o ejecutar código, y 15 por la sustituibilidad. Una plataforma de nóminas con datos fiscales de los empleados, integración de inicio de sesión único y sin una alternativa fácil podría obtener una puntuación de 80. Una herramienta de boletines informativos con solo contactos de marketing públicos podría obtener una puntuación de 25.
Ahora hay que ponerle empeño. Si tienes 60 proveedores y solo 10 horas al mes para revisiones de seguridad, no repartas ese tiempo de forma equitativa. Dedica el 70% de ese tiempo a los 10 proveedores con mayor riesgo, el 20% a los proveedores de riesgo medio y el 10% a la incorporación de nuevos proveedores. Suena contundente porque lo es. Además, funciona mejor que fingir que todos los proveedores merecen la misma revisión.
| Incidente u orientación | Año | ¿Qué pasó? | Lección sobre la selección de proveedores |
|---|---|---|---|
| SolarWinds Orion | 2020 | La CISA afirmó que las versiones afectadas de Orion lanzadas entre marzo y junio de 2020 estaban siendo objeto de ataques activos. | Revisar las actualizaciones firmadas, la integridad de las compilaciones y las obligaciones relativas a la notificación de incidentes de los proveedores. |
| MOVEit Transfer | 2023 | La CISA, el FBI y el MS-ISAC afirmaron que CL0P aprovechó las vulnerabilidades de MOVEit a partir de mayo de 2023. | Clasifica las herramientas de transferencia de archivos como de alto riesgo cuando gestionan flujos de datos confidenciales. |
| XZ Utils CVE-2024-3094 | 2024 | La CISA ha asignado un CVE al código malicioso presente en las versiones 5.6.0 y 5.6.1 de XZ Utils. | La gestión de las dependencias de código abierto requiere un equipo de mantenimiento y un seguimiento de las versiones. |
| Vulnerabilidad de TanStack en npm | 2026 | TanStack afirmó que en seis minutos se publicaron 84 versiones maliciosas repartidas en 42 paquetes. | Los controles automatizados de paquetes son más eficaces que la revisión manual cuando los ataques se producen a esta velocidad. |
Un ciberataque a la cadena de suministro también puede propagarse a través de los flujos de trabajo de programación basados en IA, donde confluyen repositorios, agentes, gestores de paquetes y datos confidenciales. Si tus desarrolladores están adoptando herramientas de programación más inteligentes, infórmate sobre información sobre repositorios y riesgos relacionados con la programación basada en IA antes de permitir un acceso generalizado a las nuevas herramientas.
Cláusulas contractuales y controles operativos en los que debes insistir
El lenguaje utilizado en materia de seguridad debe ser lo suficientemente específico como para poder evaluarse. La afirmación «El proveedor sigue las mejores prácticas del sector» es insuficiente. Solicita que se especifiquen las prácticas que se ajusten al riesgo: entrega de la lista de materiales de seguridad (SBOM), notificación de vulnerabilidades, controles sobre los subcontratistas, registro del acceso privilegiado, aislamiento de las copias de seguridad, prueba de la eliminación de datos y procedimientos de revocación de certificados.
Para los proveedores de software, las directrices de la CISA sobre el uso de las SBOM para 2024 indican que estas pueden servir de apoyo a los flujos de trabajo de adquisición, la gestión de proveedores, la gestión de riesgos de terceros, la elaboración de informes de cumplimiento y la gestión de vulnerabilidades. Eso no significa que todas las SBOM sean útiles. Un inventario en PDF obsoleto carece prácticamente de valor en comparación con una SBOM legible por máquina que tus herramientas de gestión de vulnerabilidades puedan procesar.
Los controles de identidad merecen una atención especial. Los proveedores deben utilizar la autenticación multifactorial (MFA) resistente al phishing para el acceso privilegiado siempre que sea posible, cuentas de servicio con ámbito limitado, tokens de corta duración y cuentas con nombre específico en lugar de credenciales compartidas. Si Microsoft 365 u otra plataforma de identidad forma parte de la cadena, hay que replantearse por qué la MFA por sí sola puede fallar ante determinadas vías de ataque en esta advertencia de autenticación multifactorial (MFA) de Microsoft 365.
El término «cero confianza» se utiliza en exceso como eslogan, pero el principio se aplica perfectamente al acceso de los proveedores: nunca se debe conceder a un proveedor más acceso del que requiera la tarea. Para obtener una visión más detallada de las políticas, especialmente en entornos regulados, Seguridad de «confianza cero» para organismos federales también ofrece lecciones útiles fuera del ámbito gubernamental.
Hay un contraargumento válido: las exigencias agresivas de los proveedores pueden ralentizar el proceso de contratación y molestar a los pequeños proveedores. Mi opinión es sencilla: hay que adaptar la exigencia al alcance del impacto. Un contratista de diseño no necesita un anexo de seguridad de 40 páginas si nunca tiene acceso a datos de producción; un proveedor de la cadena de montaje, en cambio, sí lo necesita sin lugar a dudas.
Cómo actuar cuando un proveedor se ve afectado por un incidente de seguridad
Cuando un proveedor sufre un ciberataque en la cadena de suministro, la rapidez es más importante que elaborar informes minuciosos. Suspende las integraciones de riesgo, renueva las claves de acceso, identifica las versiones afectadas, extrae los registros y decide si conviene suspender las actualizaciones automáticas. Tu plan de gestión de incidentes ya debería indicar quién es el responsable de cada proveedor crítico.
Plantea preguntas directas: ¿qué productos, versiones, certificados de firma, repositorios, dispositivos de los empleados, subcontratistas y entornos de los clientes se vieron afectados? La revocación del certificado de OpenAI en 2026 tras el incidente relacionado con TanStack es un ejemplo útil, ya que abordó la cuestión de la confianza en el software firmado, y no solo en los equipos infectados.
La comunicación debe ser concisa pero sincera. Explica a los clientes lo que sabes, lo que no sabes, qué funciones has desactivado y cuándo les informarás. Si recurres a proveedores de servicios gestionados (MSP), integradores de la nube o proveedores de seguridad, aquí es también donde tus prioridades anuales en materia de ciberseguridad Deben convertirse en hábitos de trabajo, en lugar de quedarse en meras presentaciones.
El caso extremo menos evidente: puede que un proveedor esté limpio, pero quizá su paquete de origen no lo esté. Por eso son importantes los repositorios de SBOM, la supervisión de dependencias y la trazabilidad de la compilación. No solo estás evaluando a un proveedor, sino también la cadena que hay detrás de él.
Preguntas frecuentes
¿Qué es un ciberataque a la cadena de suministro?
Un ciberataque a la cadena de suministro pone en peligro a una organización a través de un tercero de confianza, como un proveedor de software, un paquete de código abierto, un contratista, un proveedor de servicios gestionados (MSP) o una plataforma SaaS. El atacante se aprovecha de la confianza existente en lugar de atacar directamente al objetivo final.
¿Cuáles son algunos ejemplos famosos de ataques a la cadena de suministro?
SolarWinds Orion en 2020, el ataque a MOVEit Transfer en 2023, el CVE-2024-3094 de XZ Utils en 2024 y la vulneración de TanStack npm en 2026 son ejemplos muy conocidos. Aunque difieren técnicamente, cada uno de ellos muestra cómo un componente de confianza puede suponer un riesgo para los eslabones posteriores de la cadena.
¿Cómo se puede prevenir un ciberataque a la cadena de suministro?
No es posible evitar todos los casos de compromiso de la seguridad de los proveedores, pero sí se puede reducir su impacto. Limita el acceso de los proveedores, exige listas de componentes de software (SBOM), supervisa las vulnerabilidades de forma continua, utiliza credenciales con alcance limitado, revisa la seguridad de las compilaciones e incluye en los contratos las obligaciones relativas a la notificación de incidentes.
¿Necesitan las pequeñas empresas una gestión de riesgos de proveedores?
Sí, pero debe ser proporcional. Empieza por clasificar a los proveedores que tienen acceso a fondos, datos de clientes, sistemas de identidad, herramientas de producción o copias de seguridad, y luego revisa primero a los proveedores con mayor riesgo.
ES 
EN 
FR