En el ecosistema de la ciberseguridad, tendemos a focalizar nuestros esfuerzos en la seguridad del desarrollo. Invertimos recursos ingentes en auditar el código propietario, buscando fallos de programación, configuraciones erróneas o vulnerabilidades técnicas en nuestros propios sistemas. Sin embargo, la realidad de las amenazas actuales nos demuestra que los incidentes más críticos no siempre ocurren por un error en el código, sino por algo mucho más difícil de parchear: el compromiso de la cadena de suministro y la confianza en terceros.
Recientemente, el compromiso de la infraestructura de actualizaciones de Notepad++ ha vuelto a poner de manifiesto la fragilidad de este modelo de confianza implícita. Proteger el perímetro ya no es suficiente cuando invitamos a actores externos a entrar en nuestra red a través de actualizaciones automáticas y dependencias de software.
A continuación, analizamos cómo este tipo de ataques redefinen la seguridad corporativa y por qué los estándares internacionales y la normativa europea más reciente ya exigen poner el foco en los proveedores.
El caso Notepad++: Anatomía de un compromiso de confianza
Para entender el alcance real de un ataque a la cadena de suministro, es clave analizar el reciente incidente que afectó a Notepad++.
Los atacantes no explotaron una vulnerabilidad en el editor de texto en sí. El código fuente de Notepad++ no fue modificado ni se identificaron fallos de programación en la aplicación principal. En su lugar, el ataque se centró en el mecanismo de distribución, concretamente en el componente WinGUp, encargado de gestionar las actualizaciones automáticas del software.
Qué ocurrió exactamente
Entre mediados y finales de 2025, actores avanzados comprometieron parte de la infraestructura que servía las actualizaciones oficiales del proyecto. A partir de ese momento, se produjo un ataque de tipo supply chain altamente selectivo y sigiloso:
- El usuario solicitaba una actualización legítima desde Notepad++.
- El componente de actualización contactaba con un servidor que aparentaba ser oficial.
- Para determinados objetivos concretos, el servidor entregaba un binario modificado con malware, firmado y empaquetado de forma creíble.
- El software actualizado seguía funcionando correctamente, evitando levantar sospechas inmediatas.
- El malware desplegado permitía capacidades de ciberespionaje, persistencia y comunicación con infraestructuras de mando y control externas.
El ataque no fue masivo. Precisamente su peligrosidad residía en su carácter dirigido: solo determinados perfiles fueron atacados, lo que permitió a los adversarios mantener un perfil bajo durante meses y retrasar la detección.
La lección clave
Este incidente ilustra uno de los riesgos más críticos de la seguridad moderna:
el software puede ser funcional, legítimo y aparentemente seguro, pero su procedencia puede estar envenenada.
La confianza implícita en los canales de actualización —especialmente en herramientas ampliamente utilizadas y consideradas “seguras”— se ha convertido en un vector de ataque de alto valor estratégico.
¿Por qué la cadena de suministro es el nuevo campo de batalla?
Los ataques a la cadena de suministro explotan un principio básico: las organizaciones confían en sus proveedores. Si descargamos una herramienta desde un sitio oficial o incorporamos una librería ampliamente utilizada, asumimos que el riesgo es mínimo.
Esta suposición ya no es válida.
Los riesgos actuales se pueden agrupar en tres grandes vectores que deben ser monitorizados de forma activa:
Compromiso de la infraestructura de distribución
Como en el caso de Notepad++, donde el canal de actualización es secuestrado y utilizado como puerta de entrada.
Contaminación de dependencias (Dependency Confusion)
Inyección de código malicioso en librerías de código abierto (npm, PyPI, Maven, etc.) que los desarrolladores integran de forma automática en el software corporativo.
Compromiso del entorno de compilación (CI/CD)
Infiltración en los sistemas de construcción del proveedor, inyectando malware antes incluso de que el software sea firmado digitalmente, como ocurrió en el conocido caso de SolarWinds.
En todos estos escenarios, el atacante se beneficia de una ventaja clave: hereda la confianza del proveedor legítimo.
El marco normativo: la seguridad de terceros ya no es opcional
La gravedad y recurrencia de estos incidentes no ha pasado desapercibida para los reguladores. En Europa, el enfoque ha cambiado radicalmente: la gestión del riesgo de terceros ya no es una recomendación, es un requisito legal y auditable.
ISO/IEC 27001:2022
La versión más reciente del estándar refuerza significativamente los controles sobre proveedores. En su Anexo A (controles 5.19 a 5.22) se exige:
- Gestión formal de la seguridad en la cadena de suministro.
- Evaluación de riesgos de proveedores.
- Monitorización continua del cumplimiento de requisitos de seguridad.
Directiva NIS2
La nueva directiva europea marca un antes y un después. El Artículo 21.2.d establece explícitamente que las entidades esenciales e importantes deben gestionar los riesgos derivados de la cadena de suministro, considerando las vulnerabilidades específicas de cada proveedor y prestador de servicios.
Esquema Nacional de Seguridad (ENS)
En su versión actualizada, el ENS refuerza la obligación de establecer condiciones de seguridad en la adquisición de productos y servicios TIC, exigiendo garantías proporcionales al riesgo del servicio prestado.
Paquete Omnibus y transparencia digital
El paquete regulatorio Omnibus, aunque enfocado principalmente en la protección de consumidores y servicios digitales, refuerza un principio clave:
la obligación de transparencia, integridad y control en los procesos de actualización y distribución de software.
Esto afecta directamente a los mecanismos de actualización automática y a la responsabilidad de los proveedores sobre su cadena de suministro.
Cyber Resilience Act (CRA)
El Cyber Resilience Act introduce por primera vez obligaciones horizontales de ciberseguridad para productos con componentes digitales, incluyendo software.
Entre sus exigencias destacan:
- Seguridad by design & by default.
- Gestión de riesgos de la cadena de suministro digital.
- Mecanismos seguros y verificables de actualización.
- Obligación de corregir vulnerabilidades durante todo el ciclo de vida del producto.
Con el CRA, la seguridad de la cadena de suministro deja de ser una “buena práctica técnica” para convertirse en una responsabilidad legal directa del fabricante y del proveedor.
Estrategia de defensa: del “Trust” al “Verify”
En Inprosec sabemos que prohibir el uso de software de terceros no es viable. La clave está en abandonar la confianza ciega y adoptar un modelo de verificación continua, alineado con los marcos normativos actuales.
Proponemos una estrategia basada en tres pilares:
Inventario y visibilidad (SBOM)
No se puede proteger lo que no se conoce.
- Qué es: una Lista de Materiales de Software (SBOM) que detalla todos los componentes y dependencias de una aplicación.
- Para qué sirve: permite identificar rápidamente la exposición ante un compromiso de un proveedor o librería concreta, y facilita el cumplimiento de NIS2, ISO 27001 y CRA.
Endurecimiento del proceso de actualización
Las actualizaciones son necesarias, pero también uno de los vectores más críticos.
- Verificación de hashes: comprobar la integridad de los binarios (SHA-256) desde canales independientes y confiables.
- Entornos de sandbox: probar las actualizaciones de software crítico en entornos aislados antes de su despliegue masivo, analizando comportamientos anómalos.
Principios de Zero Trust en la red
Asumir que el compromiso es posible implica limitar el impacto.
- Segmentación: estaciones y servidores no deben tener acceso sin restricciones a Internet.
- Whitelisting: permitir únicamente las comunicaciones estrictamente necesarias hacia dominios de actualización conocidos, bloqueando conexiones hacia infraestructuras de C2 desconocidas.
Conclusión: la procedencia es tan crítica como el código
El incidente de Notepad++ no es una anomalía: es un síntoma de un ecosistema digital profundamente interconectado.
La seguridad de la información ya no termina en nuestro firewall. Se extiende a nuestros proveedores, a sus procesos de desarrollo, a sus infraestructuras de distribución y a sus mecanismos de actualización.
Con la llegada de NIS2, ENS, Omnibus y el Cyber Resilience Act, esta realidad queda formalizada: la gestión de la cadena de suministro digital es una obligación legal, técnica y estratégica.
Adoptar una postura proactiva, exigir transparencia a los proveedores y aplicar controles compensatorios internos es la única vía para proteger los datos y garantizar la resiliencia operativa en un entorno donde la confianza debe ser verificada, nunca asumida.
¿Tu organización cumple con los requisitos de gestión de proveedores de la ISO 27001, NIS2 y el CRA? En Inprosec podemos ayudarte a auditar y fortificar tu cadena de suministro digital.