Ataque a la cadena de suministro: cómo responder a clientes

Envíe un comunicado inicial (holding statement) en pocas horas, una respuesta confirmada en cuanto pueda demostrarla y un seguimiento cada vez que algo cambie. Diga lo que sabe, lo que todavía está comprobando y cuándo dará novedades. Base cada «no afectado» en lo que sus builds instalaron realmente durante la ventana del ataque, no en el lockfile de hoy.

Este artículo trata de qué decir, cuándo y con qué respaldo. Para la investigación en sí, es decir, cómo averiguar si un componente vulnerable está en sus productos y desde cuándo, consulte ¿estamos afectados por una CVE?.

Por qué los clientes le preguntan a usted y no al registro de paquetes

La semana siguiente a un ataque muy mediático, nos contó un pequeño proveedor de software, sus clientes le enviaban mensajes de texto: ¿lo vuestro es seguro? ¿Lo mío es seguro? Sus clientes manejan datos sensibles, su equipo no tiene ningún especialista en seguridad y la pregunta necesitaba respuesta ese mismo día.

Los clientes no preguntan si un paquete se vio comprometido. El registro y los investigadores ya lo han dicho. Preguntan si lo que usted les ha entregado lo contiene, porque su producto es su exposición. Ellos tienen sus propios clientes, auditores o reguladores que les hacen la misma pregunta. En cadenas de suministro reguladas, como las de semiconductores, equipos industriales y salud, la pregunta es contractual, no fruto de la curiosidad.

Además, volverán a preguntar si su respuesta no se puede comprobar. «No estamos afectados» sin nada detrás es una promesa; «hemos comprobado todos los builds de release del 24 al 31 de marzo y ninguno instaló las versiones afectadas» es una afirmación en la que pueden confiar.

Cuatro ataques recientes y la pregunta que planteó cada uno

La respuesta correcta depende de cómo funcionó el ataque, así que una plantilla por sí sola no basta. En cada uno de estos casos, un dato decide qué significa «afectado» para un proveedor.

Puerta trasera de xz Utils (CVE-2024-3094), revelada el 29 de marzo de 2024. Andres Freund encontró una puerta trasera en las versiones 5.6.0 y 5.6.1 de xz. Los tarballs de la versión contenían código que no estaba en el repositorio Git y que inyectaba la puerta trasera durante el build. Tanto la NVD como Red Hat le asignan un 10.0 en CVSS 3.1. Llegó sobre todo a distribuciones rolling y de pruebas: Debian testing, unstable y experimental, Fedora Rawhide y 41, openSUSE Tumbleweed y Kali, mientras que las versiones estables no se vieron afectadas. La pregunta que planteó: ¿alguna imagen o dispositivo que hayamos distribuido incluye xz 5.6.0 o 5.6.1, y qué imagen base usó cada build?

Gusano de npm Shai-Hulud, en oleadas desde septiembre de 2025. Los paquetes infectados ejecutan un script en el momento de la instalación que roba credenciales de npm, GitHub y la nube, y las usa para publicar versiones infectadas de más paquetes. La pregunta que planteó: ¿algún job de CI instaló una versión infectada, y quedaron expuestos nuestros tokens de publicación, lo que nos convertiría en propagadores? Nuestra entrada sobre Shai-Hulud enumera todas las oleadas y cómo comprobarlo.

LiteLLM en PyPI, 24 de marzo de 2026. Las versiones 1.82.7 y 1.82.8 se subieron directamente a PyPI con código para robar credenciales que nunca estuvo en el repositorio de GitHub del proyecto. En la 1.82.8, un archivo .pth ejecutaba la carga maliciosa cada vez que se iniciaba cualquier intérprete de Python, no solo al importar LiteLLM; recopilaba variables de entorno, claves SSH, credenciales de la nube y secretos de Kubernetes. HiddenLayer vincula el ataque a TeamPCP, que ese mismo mes atacó también herramientas de Trivy y Checkmarx. El propio aviso de LiteLLM da dos explicaciones del acceso inicial: atribuye el compromiso a la dependencia de Trivy en su workflow de escaneo de seguridad de CI y dice que la cuenta de PyPI de un mantenedor pudo verse comprometida. Incluso la ventana de exposición difiere dentro de ese mismo aviso: unos 40 minutos en un lugar y de 10:39 a 16:00 UTC en otro. La pregunta que planteó: ¿algún build o contenedor distribuido incluía esas versiones, y qué secretos había en ese entorno?

axios en npm, 31 de marzo de 2026. Un atacante se hizo con la cuenta de npm de un mantenedor y publicó axios 1.14.1 y 0.30.4, que añadían una dependencia, [email protected], cuyo script de instalación descargaba un troyano de acceso remoto para macOS, Windows y Linux. Datadog sitúa la ventana entre las 00:21 y las 03:25 UTC; según Snyk, las versiones se retiraron a las 03:29 UTC. La pregunta que planteó: ¿algún build resolvió esas versiones durante la ventana? Un lockfile confirmado antes de la ventana responde «no» para los builds que lo usaron, y no dice nada de los builds que ejecutaron npm install sin él.

Ataque	Ecosistema	Versiones afectadas	Ventana	Qué significa «afectado» para un proveedor
xz Utils	Distribuciones de Linux	5.6.0, 5.6.1	Semanas, hasta su revelación el 29 de marzo de 2024	Lo distribuyó, en una imagen o un dispositivo construido sobre una distribución afectada
Shai-Hulud	npm	Cientos de paquetes, por oleada	De horas a días por oleada	Construyó con él, y sus tokens pueden haberlo propagado; puede que también lo distribuyera
LiteLLM	PyPI	1.82.7, 1.82.8	24 de marzo de 2026, desde las 10:39 UTC (las fuentes difieren sobre el final)	Construyó con él o lo distribuyó, y los secretos de ese entorno pueden haber sido robados
axios	npm	1.14.1, 0.30.4	31 de marzo de 2026, aproximadamente de 00:21 a 03:25 UTC	Construyó con él durante la ventana; el troyano se ejecutó en la máquina de build

Las mismas preguntas surgen ante una vulnerabilidad crítica que no es un ataque a la cadena de suministro. Cuando PHP2Shell se explotó en octubre de 2026, los clientes de todos los productos que incluyen PHP preguntaron cuáles de sus versiones llevan un PHP afectado. Los pasos siguientes se aplican sin cambios.

La respuesta tiene tres fases

Fase	Cuándo	Qué envía
Comunicado inicial	En las horas siguientes a la noticia	Lo que sabe, lo que está comprobando, cuándo dará novedades
Respuesta confirmada	En cuanto pueda demostrarla, normalmente el primer día	«No afectado» para versiones concretas, o «afectado» con qué hacer
Seguimiento	Cuando se publique la corrección, cuando sepa algo nuevo, cuando cierre el caso	El mismo aviso, revisado

La primera hora: el comunicado inicial

El comunicado inicial es la primera declaración pública que hace antes de tener los hechos. Diga algo cierto, y rápido. El silencio se llena de suposiciones, y un cliente que no sabe nada de usted da por hecho que no se ha enterado.

Quién y dónde. Un remitente con nombre, en el canal que usó el cliente, y además su página de seguridad. Un texto común es mejor que respuestas improvisadas: se mantiene coherente y el departamento jurídico lo revisa una sola vez.
Qué contiene. Que está al tanto del ataque, que está comprobando sus productos y sistemas de build, lo que sabe hasta ahora, cuándo llegará la siguiente actualización y a quién dirigirse.
Qué no debe contener. «No estamos afectados» antes de haberlo comprobado, especulaciones sobre el atacante ni culpas.

Plantilla 1: comunicado inicial

Asunto: [Nombre del ataque]: nuestro comunicado inicial

Estamos al tanto del compromiso notificado de [paquete o proyecto] ([versiones afectadas], publicadas el [fecha]). Nuestro equipo de seguridad está comprobando todas las versiones de [producto] y nuestros sistemas de build en busca de las versiones afectadas. Hasta el momento [no hemos encontrado versiones afectadas en los productos comprobados / no hemos terminado la comprobación]. Les enviaremos una actualización antes del [fecha y hora, zona horaria]. Si entretanto tienen alguna pregunta, pueden dirigirse a [nombre, dirección de contacto de seguridad]. No haremos conjeturas sobre el impacto hasta haber completado la comprobación.

Para un mensaje de texto o un chat, bastan dos frases:

Estamos al tanto del compromiso de [nombre del ataque] y ya estamos comprobando todas las versiones de [producto] y nuestros builds. Le daremos una respuesta confirmada antes de las [hora].

Haga que su asesoría jurídica apruebe las tres plantillas antes de necesitarlas.

El primer día: confirme, con pruebas

Hay dos resultados posibles, y cada uno necesita sus propias pruebas. Para una respuesta «no afectado», reúna:

el paquete y las versiones afectadas, según el aviso de seguridad o el análisis de los investigadores
sus productos y las versiones que ejecutan realmente los clientes
para cada una de esas versiones, el build que la produjo y el registro de lo que instaló ese build, no el lockfile actual
todos los builds que se ejecutaron durante la ventana del ataque, incluidos los jobs de CI que nunca produjeron una versión
en el caso de gusanos que roban tokens, si había secretos de CI presentes en jobs que podrían haber ejecutado el código malicioso

¿Estamos afectados por una CVE? explica cómo establecer cada uno de estos puntos.

Cada afirmación que haga tiene que estar respaldada por algo que pueda mostrar:

Afirmación	Qué debe poder mostrar	Qué no basta
«La versión Y del producto X no contiene el paquete Z»	La SBOM registrada en el build de release de la versión Y	Un escaneo del repositorio actual
«Ninguno de nuestros builds instaló las versiones comprometidas»	Los registros de instalación de todos los builds de la ventana	Un lockfile que algunos jobs se saltan
«Nuestro proceso de publicación no se vio comprometido»	Los registros de red y de uso de secretos de la ventana	La ausencia de alertas
«Los clientes con la versión Y están seguros tras actualizar»	El registro del build corregido y las credenciales que ha rotado	Una entrada en el registro de cambios

Plantilla 2: no afectado

Asunto: [Nombre del ataque]: [producto] no está afectado

Hemos completado nuestra comprobación sobre el compromiso de [paquete] ([versiones afectadas]). Las siguientes versiones de [producto] no están afectadas: [lista de productos y versiones comprobados]. Hemos comprobado todos los builds de release y de CI que se ejecutaron entre el [fecha de inicio] y el [fecha de fin]. Esta declaración se basa en el registro de los componentes instalados por cada build de release, no en un escaneo de nuestro código fuente actual. Ninguno de estos builds instaló las versiones afectadas. Si necesitan las pruebas, podemos enviarles la SBOM de las versiones que utilizan o una declaración VEX. Si conocemos algo que modifique esta evaluación, se lo comunicaremos. Contacto: [nombre, dirección de contacto de seguridad].

Diga «no afectado» para versiones concretas. No escriba nunca «100 % seguro». Si después el cliente pide la SBOM completa, consulte cómo responder a las solicitudes de SBOM de los clientes.

Plantilla 3: afectado, con mitigación

Asunto: [Nombre del ataque]: acción necesaria para las versiones [x a y] de [producto]

Nuestra comprobación sobre el compromiso de [paquete] ha determinado que las versiones [x a y] de [producto] están afectadas. El primer build afectado se produjo el [fecha]; la versión [z], publicada el [fecha], ya no contiene [versión del paquete].

Qué significa: [riesgo en lenguaje claro, por ejemplo «un componente instalado en estas versiones puede enviar credenciales del sistema en el que se ejecuta a un servidor externo»].

Qué deben hacer ahora: actualizar a [producto] [z]. Si no pueden actualizar de inmediato, [mitigación, por ejemplo bloquear las conexiones salientes a los hosts indicados]. Si han utilizado las versiones [x a y] de [producto] en [entorno], roten las [credenciales o claves] a las que tuviera acceso.

Qué hemos hecho: hemos eliminado las versiones afectadas de nuestros builds, hemos reconstruido [producto] a partir de dependencias limpias, hemos rotado las credenciales que usan nuestros sistemas de build y [otras medidas]. [Hemos informado a las autoridades competentes cuando era obligatorio.]

Les enviaremos la próxima actualización antes del [fecha], o antes si cambia algo. Contacto: [nombre, dirección de contacto de seguridad].

Un aviso de «afectado» también puede ser una obligación legal; consulte la sección sobre notificación más abajo.

Dónde encajan VEX y CSAF. Una declaración «no afectado» o «corregido» puede publicarse como VEX, para que los escáneres de los clientes dejen de señalar el paquete. Los clientes más grandes pueden esperar además un aviso de seguridad legible por máquina; CSAF es el formato que piden la mayoría.

Seguimiento: ciérrelo como es debido

Envíe un seguimiento cuando se publique la corrección, cuando su investigación descubra algo nuevo, y una nota final cuando se cierre el caso. Mantenga un único aviso de seguridad por incidente y revíselo en lugar de enviar uno nuevo cada vez (actualice, no sustituya). Registre qué ha dicho a quién y cuándo: la próxima auditoría o el próximo cuestionario de seguridad de un cliente lo preguntará.

Qué decir cuando todavía no lo sabe

«Todavía no lo sabemos» genera más confianza que un «no afectado» que luego tiene que retirar. Frases honestas que no alarman a nadie:

«No hemos encontrado [paquete] en [productos comprobados hasta ahora]. Seguimos comprobando [productos o sistemas de build restantes] y le daremos novedades antes de las [hora].»
«Las versiones que utiliza se construyeron antes de la ventana del ataque. Estamos confirmando que ningún build posterior las sustituyó.»
«Estamos comprobando si alguno de nuestros sistemas de build ejecutó las versiones afectadas. El producto que tiene instalado es una cuestión aparte, y responderemos a ambas.»

Frases que conviene evitar:

«Ningún impacto en absoluto»
«Totalmente seguro»
«No afectado por ningún ataque a la cadena de suministro»
«Nuestro escáner no ha encontrado nada»

Cuando el ataque se convierte en una obligación de notificación

Si vende productos con elementos digitales en la UE, el Cyber Resilience Act aplica sus obligaciones de notificación desde el 11 de septiembre de 2026, el día en que ENISA puso en marcha la plataforma única de notificación. Una vulnerabilidad explotada activamente en su producto, o un incidente grave que afecte a su seguridad, desencadena una alerta temprana en un plazo de 24 horas desde que tiene conocimiento de ello, una notificación en un plazo de 72 horas y un informe final, presentados a través de la plataforma a su CSIRT coordinador y a ENISA. La guía del CRA recorre los pasos.

Si una dependencia comprometida que usted distribuyó, o un compromiso de su propio proceso de build, se ajusta a esas definiciones es algo que deben valorar usted y su asesoría jurídica, no este artículo. El reglamento define los términos:

Una «vulnerabilidad explotada activamente» es «una vulnerabilidad respecto de la cual existen pruebas fiables de que un agente malicioso la ha explotado en un sistema sin el permiso del propietario del sistema» (artículo 3, punto 42).
Un incidente es grave cuando «afecta negativamente o puede afectar negativamente a la capacidad de un producto con elementos digitales para proteger la disponibilidad, la autenticidad, la integridad o la confidencialidad de datos o funciones sensibles o importantes», o cuando «ha dado lugar o puede dar lugar a la introducción o ejecución de código malicioso» en el producto o en los sistemas de un usuario (artículo 14, apartado 5).

El artículo 14, apartado 8, añade una obligación respecto de los usuarios: informar a los usuarios afectados y, cuando proceda, a todos los usuarios, de la vulnerabilidad o el incidente y de cualquier medida de mitigación que puedan aplicar, «cuando proceda, en un formato estructurado, legible por máquina y fácilmente tratable de forma automática». La plantilla 3 puede formar parte del cumplimiento de esa obligación.

También se aplican otros regímenes. Con NIS2, las entidades esenciales e importantes notifican los incidentes significativos a su CSIRT o a la autoridad competente, y muchos contratos con clientes incluyen sus propias cláusulas de notificación con sus propios plazos.

Esté preparado antes del próximo

Un registro de lo que instaló cada build de release, conservado durante el periodo de soporte del producto (SBOM en tiempo de build).
Una lista de qué clientes ejecutan qué versiones.
Las tres plantillas anteriores, aprobadas por el departamento jurídico.
Un remitente con nombre y un canal para cada tipo de cliente.
Una página de seguridad y un archivo security.txt donde se publiquen las actualizaciones (divulgación coordinada de vulnerabilidades).
Control del tráfico saliente en el CI, para que un paquete comprometido no pueda enviar secretos a un host que el build no necesita (política de tráfico saliente en GitHub Actions).

Para incidentes que llegan a cientos en lugar de uno a uno, consulte cómo escalar un PSIRT.

Cómo encaja CRACI

La tabla de pruebas anterior pide una y otra vez lo mismo: un registro de lo que instaló cada build de release. Eso es lo que conserva CRACI. CRACI ejecuta sus builds de GitHub Actions en sus propios runners y registra todos los paquetes que cada job descargó realmente, incluidos los paquetes obtenidos por scripts de instalación y los restaurados desde cachés. Se conserva la SBOM de cada build anterior, de modo que «¿algún build instaló axios 1.14.1 durante la ventana?» se responde a partir del historial de builds, con el periodo en que estuvo afectado, hasta donde llegue su retención.

Las versiones maliciosas conocidas que tienen una CVE publicada, como la puerta trasera de xz, se señalan como cualquier otra vulnerabilidad, y un control de política puede bloquear los builds que las contengan. CRACI no detecta un paquete malicioso nuevo por su comportamiento ni por su reputación.

La política de tráfico saliente de CRACI bloquea las conexiones a hosts que un build no necesita, lo que limita lo que un script de instalación malicioso puede enviar fuera, incluso en un ataque que nadie ha visto antes. Cuando un cliente pide las pruebas, puede exportar la SBOM de las versiones que ejecuta en formato CycloneDX o SPDX y enviársela. CRACI es compatible con VEX.

Responda a «¿estuvimos afectados?» a partir de su historial de builds, o lea más sobre cómo funcionan los ataques a la cadena de suministro.

Cuándo CRACI no es la respuesta

Necesita ayuda con la comunicación en sí. El asesoramiento en comunicación y el jurídico son otro trabajo.
El software afectado no se construyó en CRACI. CRACI registra los builds de GitHub Actions que se ejecutan en sus runners; otros sistemas de CI están en la hoja de ruta.
La pregunta se refiere al producto de un proveedor que usted no ha construido. Se pueden añadir SBOM de proveedores a CRACI, pero la respuesta solo es tan buena como la SBOM del proveedor.
Necesita detectar un paquete malicioso totalmente nuevo antes de que exista ningún aviso. CRACI señala las versiones maliciosas conocidas una vez que se publica un aviso con una CVE; no detecta malware por su comportamiento ni por su reputación (cómo responder a vulnerabilidades de día cero).

Preguntas frecuentes

¿Qué digo a los clientes cuando un ataque a la cadena de suministro sale en las noticias?

Envíe un comunicado inicial en pocas horas: que está al tanto del ataque, que está comprobando sus productos y builds, lo que sabe hasta ahora y cuándo dará novedades. Después, envíe una respuesta confirmada para versiones concretas del producto en cuanto pueda respaldarla con registros de build, y un seguimiento cuando algo cambie.

¿Qué debe decir un comunicado inicial?

Qué ha pasado, en una frase; que está comprobando sus productos y sistemas de build; lo que ha encontrado hasta ahora; la hora de la siguiente actualización y un contacto. No debe decir «no afectado» antes de haberlo comprobado, ni especular sobre el atacante ni culpar a nadie.

¿Cómo digo «no estamos afectados» sin prometer de más?

Nombre los productos y versiones que ha comprobado, el intervalo de fechas de los builds comprobados y las pruebas que ha utilizado, como el registro de los componentes que instaló cada build de release. Diga «no afectado» para esas versiones, ofrezca la SBOM o una declaración VEX y comprométase a informar si algo cambia. Evite «100 % seguro» o «totalmente seguro».

¿Qué debe contener un aviso a los clientes de que «estuvimos afectados»?

Qué productos y versiones están afectados, desde cuándo y hasta qué versión corregida, el riesgo en lenguaje claro, qué debe hacer ahora el cliente (actualizar, rotar credenciales, bloquear hosts), qué ha hecho usted ya, cuándo llegará la siguiente actualización y a quién dirigirse.

¿Qué pruebas deben respaldar una declaración «no afectado»?

Para cada versión que ejecutan los clientes, el registro de lo que instaló el build que la produjo, no el lockfile de hoy. Añada los registros de todos los builds que se ejecutaron durante la ventana del ataque y, en los ataques que roban credenciales, si había secretos presentes en jobs que podrían haber ejecutado el código malicioso.

¿Tengo que notificar un ataque a la cadena de suministro según el Cyber Resilience Act?

Es posible. Desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales vendidos en la UE deben notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto: una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final. Si un ataque concreto cumple los requisitos es algo que deben valorar usted y su asesoría jurídica.

¿Con qué rapidez debemos responder a los clientes?

En pocas horas, con un comunicado inicial, aunque solo diga que lo está comprobando y cuándo dará novedades. La respuesta confirmada llega en cuanto pueda demostrarla. Un «lo estamos comprobando» rápido y honesto hace más por la confianza que un «no afectado» tardío.

¿Es seguro lo que nos vende? Cómo responder a los clientes tras un ataque a la cadena de suministro