Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- El artículo 21 de la NIS2 establece que la seguridad de la cadena de suministro es una medida mínima y obliga a las entidades a evaluar las vulnerabilidades de cada proveedor directo.
- La ENISA, la agencia de ciberseguridad de la UE, señala en sus directrices no vinculantes sobre contratación pública en el ámbito hospitalario que los responsables del mantenimiento de software de código abierto podrían no considerarse proveedores directos.
- Es posible que el código abierto añadido por los desarrolladores no tenga un proveedor al que preguntar, por lo que la responsabilidad de revisarlo recae en tu equipo.
- Los órganos de gestión aprueban las medidas del artículo 21 y pueden ser considerados responsables, por lo que conviene comprobar que dichas medidas abarquen el código abierto añadido por los desarrolladores.
Un registro de proveedores elaborado a partir de los contratos puede parecer completo y, sin embargo, pasar por alto el código abierto que contiene tu software. La medida de seguridad de la cadena de suministro recogida en la segunda Directiva sobre seguridad de las redes y la información (NIS2) se centra en tus proveedores directos. Sin embargo, es posible que el código abierto que añaden tus propios desarrolladores no tenga un proveedor al que enviar un cuestionario.
Entonces, ¿a quién se considera tu proveedor cuando el código es de código abierto? La respuesta determina qué preguntas puedes plantear a un proveedor y qué comprobaciones deben realizar los miembros de tu equipo.
Sea cual sea la respuesta, el hecho de comprar a un proveedor no implica que tus obligaciones en virtud de la NIS 2 recaigan en dicho proveedor. La Directiva exige a las organizaciones afectadas que gestionen el riesgo de los proveedores mediante sus propias medidas, y la Agencia de Ciberseguridad de la Unión Europea (ENISA) afirma en su Guía Técnica de Aplicación, de carácter no vinculante, que externalizar un riesgo no exime de la responsabilidad sobre el mismo.
Qué se espera de ti en el marco de la medida de seguridad de la cadena de suministro de la NIS2
La medida se aplica a las entidades esenciales e importantes, las dos categorías que define la Directiva NIS2, en función de la importancia crítica de un sector o servicio y del tamaño de la organización. En la práctica, esto suele referirse a organizaciones medianas y grandes de los sectores que enumera, además de algunas más pequeñas, por lo que no todas las empresas quedan incluidas.
El artículo 21, apartado 2, enumera diez medidas que una entidad debe adoptar como mínimo. La medida contemplada en la letra d) es la seguridad de la cadena de suministro. Incluye el aspecto de seguridad de las relaciones de cada entidad con sus proveedores directos o prestadores de servicios. A continuación, el artículo 21, apartado 3, detalla los aspectos que deben tenerse en cuenta para dicha medida: las vulnerabilidades específicas de cada proveedor directo y prestador de servicios; la calidad general de los productos y las prácticas de ciberseguridad de los proveedores, incluidos sus procedimientos de desarrollo seguro; y los resultados de cualquier evaluación de riesgos coordinada a escala de la Unión sobre las cadenas de suministro críticas.
Esos son los requisitos de seguridad de la cadena de suministro establecidos en la Directiva. Una directiva es vinculante para los Estados miembros, no para las empresas, por lo que estas normas se aplican a las entidades a través de la legislación nacional de cada país. El artículo 21, apartado 1, también exige que las medidas sean adecuadas y proporcionadas a los riesgos, lo que deja parte del diseño en vuestras manos.
En un considerando de la Directiva NIS2 y en otros textos de la UE también se hace referencia a los proveedores. El único texto vinculante es un reglamento adoptado por la Comisión Europea porque así lo exigía la Directiva NIS2: el Reglamento de Ejecución (UE) 2024/2690. En él se establecen normas detalladas relativas al artículo 21, incluida una política sobre proveedores, para determinados proveedores de servicios digitales, como los proveedores de servicios en la nube y de servicios gestionados.
| Documento | Lo que se indica sobre los proveedores | A quiénes se dirige | ¿Es vinculante? | Fundamentos |
|---|---|---|---|---|
| NIS2 (Directiva (UE) 2022/2555), artículo 21, apartado 2, letra d), y apartado 3 | Seguridad de la cadena de suministro, incluidas las relaciones con los proveedores directos; las vulnerabilidades de los proveedores directos; la calidad de los productos de los proveedores, sus prácticas de ciberseguridad y sus procedimientos de desarrollo seguro | Entidades esenciales e importantes | Sí, a través de la legislación nacional | Directiva de la UE |
| NIS2, considerando 85 | Se mencionan los editores de software; se recomienda establecer condiciones contractuales con los proveedores directos; podrían tenerse en cuenta otros niveles de proveedores | Entidades esenciales e importantes | No | Considerando: una ayuda para la interpretación |
| Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de 17 de octubre de 2024 | Política de seguridad de la cadena de suministro para proveedores directos, con criterios de selección | Tipos de entidades digitales que cotizan en bolsa, como los proveedores de servicios en la nube y de servicios gestionados | Sí, para ese tipo de personas | Acto de ejecución |
| Guía técnica de aplicación de la ENISA, versión 1.0, junio de 2025 | Consejos prácticos y ejemplos ilustrativos sobre el Reglamento de aplicación | Tipos de entidades digitales enumerados; pueden servir de referencia para otros | No | Orientaciones de la ENISA |
| Guía de herramientas para la seguridad de la cadena de suministro de las TIC de la UE, febrero de 2026 | Enfoque común para evaluar y mitigar los riesgos de la cadena de suministro de las TIC | Los Estados miembros y los agentes públicos y privados | No, voluntario | Orientaciones del Grupo de Cooperación del NIS |
Es posible que los responsables del mantenimiento del software de código abierto no se consideren proveedores directos
El considerando 85 de la Directiva NIS2 incluye a los editores de software entre los proveedores cuyos riesgos son relevantes, y considera que las entidades podrían plantearse ir más allá de los proveedores directos. Sin embargo, los considerandos no generan obligaciones por sí mismos, y las relaciones con los proveedores a las que se refiere el artículo 21 son las que se mantienen con los proveedores directos.
Las directrices de contratación pública de la ENISA de julio de 2026 relativas a la ciberseguridad de los hospitales y los proveedores de asistencia sanitaria abordan la cuestión de si un responsable del mantenimiento de software de código abierto es un proveedor directo, al menos en el sector sanitario.
Según la ENISA: «En el caso del software libre y de código abierto (OSS), es posible que las entidades que mantienen y distribuyen el software de forma abierta no se consideren proveedores directos de servicios».
Esto es así, añaden las directrices, cuando no existe una relación contractual con el proyecto más allá de una licencia de derechos de autor estándar, o cuando el contrato se celebra con un gestor de software de código abierto. Este término se define en otra ley, la Ley de Resiliencia Cibernética, y se refiere a una persona jurídica, distinta de un fabricante, que apoya de forma continuada el desarrollo de determinados productos de código abierto.
Las directrices no son vinculantes y se han redactado para la contratación pública en el sector sanitario, por lo que no determinan cómo interpretará una autoridad nacional el artículo 21. Son coherentes con el texto de la Directiva, que en ningún momento exige expresamente que una entidad someta a un proceso de verificación a los responsables del mantenimiento de un proyecto de código abierto. El riesgo que conlleva el propio código sigue estando contemplado en las medidas previstas en el artículo 21, aunque no necesariamente en el marco de las medidas de seguridad de la cadena de suministro.
Un proveedor puede incluir código abierto en un producto, un prestador de servicios puede ofrecerlo como parte de un servicio, o tus propios desarrolladores pueden añadirlo al software que creáis. El proveedor o prestador suele ser tu proveedor directo, por lo que se le aplican los criterios del artículo 21, apartado 3, incluido el desarrollo seguro. Cuando tus propios desarrolladores añaden código abierto, es posible que no exista un proveedor en el sentido contractual. El artículo 21, apartado 2, letra e), relativo a la seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas de redes y de información, incluida la gestión de vulnerabilidades, se ajusta mejor a ese caso que la medida de seguridad de la cadena de suministro.
Si vendes software, es posible que seas el proveedor directo al que tus clientes se refieren. La NIS2 abarca a las organizaciones por sector y tamaño, por lo que el mero hecho de ser proveedor de alguien no te incluye, por sí solo, en su ámbito de aplicación. Tendrás obligaciones propias si tu empresa es, a su vez, una entidad esencial o importante. Sea cual sea tu situación, las propias medidas de los clientes pueden llevarles a preguntarte cómo desarrollas y mantienes lo que les suministras.
Donde terminan los cuestionarios y empiezan tus propias comprobaciones
La NIS2 no establece controles específicos para los paquetes de código abierto. Los controles que se indican a continuación son medidas prácticas que se ajustan a lo dispuesto en el artículo 21, apartado 2, letra e), y a su gestión de vulnerabilidades.
La evaluación de un proveedor funciona porque puedes solicitarla. Envías un cuestionario, tienes un contrato y el proveedor tiene un motivo para responder. Cuando tus propios desarrolladores incorporan código abierto, poco de eso se aplica al mantenedor, que ha publicado el código bajo una licencia y puede que nunca haya oído hablar de ti. Un cuestionario por sí solo no puede verificar que el paquete que ejecutas coincida con el código que publicaron sus mantenedores y, al no haber un proveedor al que enviarlo, normalmente no hay nadie responsable de revisarlo antes de que llegue a tus manos. Es posible que un mantenedor que haya dejado de publicar correcciones tampoco responda a una pregunta de seguridad.
Eso nos lleva a las comprobaciones del propio paquete. ¿Coincide con el código fuente publicado? ¿Podría contener algún elemento malicioso? ¿Sigue alguien actualizando la versión que utilizas? Tu equipo debe asegurarse de que se realicen estas comprobaciones, ya sea llevándolas a cabo él mismo o recurriendo a un servicio que se encargue de ello.
También te interesará disponer de un registro de lo que contiene tu software y de la procedencia de cada uno de sus componentes, ya que no podrás responder a preguntas propias de un proveedor sobre componentes que no puedas enumerar. Los registros habituales son una lista de materiales de software (SBOM) y datos de procedencia que indican de dónde procede un artefacto y cómo se ha creado. Una declaración del Vulnerability Exploitability eXchange (VEX) añade el estado de las vulnerabilidades conocidas en un producto. La fiabilidad de cada uno de ellos depende de quien lo haya elaborado, así que comprueba quién está detrás y cuándo se actualizó por última vez.
Los órganos de administración aprueban las medidas previstas en el artículo 21 y pueden ser considerados responsables
En virtud del artículo 20, apartado 1, los Estados miembros deben garantizar que los órganos de dirección de las entidades esenciales e importantes aprueben las medidas previstas en el artículo 21, supervisen su aplicación y puedan ser considerados responsables de las infracciones del artículo 21 cometidas por la entidad. La disposición no especifica si los miembros a título individual son personalmente responsables. La norma explícita para las personas físicas figura en el artículo 32, apartado 6. Los Estados miembros deben garantizar que se pueda exigir responsabilidad a las personas con autoridad para representar, tomar decisiones en nombre de o controlar una entidad esencial cuando incumplan su obligación de garantizar el cumplimiento de la normativa, y el artículo 33, apartado 5, amplía esta disposición a las entidades importantes.
La formación también es importante: según el artículo 20, apartado 2, los miembros de los órganos de administración deben recibir formación para identificar los riesgos y evaluar las prácticas de gestión de riesgos de ciberseguridad, así como su impacto en los servicios de la entidad.
Un órgano de gestión que aprueba medidas redactadas exclusivamente para proveedores contratados ha aprobado precisamente ese ámbito de aplicación. La Directiva sigue cubriendo el riesgo derivado del código abierto que añaden tus desarrolladores. El problema es que, al redactar las medidas, este riesgo puede acabar sin asignarse ni a las medidas de seguridad de la cadena de suministro ni a las medidas de desarrollo contempladas en la letra e), y es posible que un órgano de gestión que consulte el registro de proveedores nunca lo detecte. Pregunta a quien redacte las medidas cuál de ellas cubre las comprobaciones de ese código y quién las lleva a cabo.
Cómo reducir la brecha entre las revisiones de los proveedores y tus proyectos de construcción
En el caso del código abierto que no viene acompañado de un contrato con el proveedor, SecureChain de TuxCare se encarga de realizar esas tres comprobaciones directamente en el propio paquete. Analiza el código abierto en busca de malware oculto, recompila los paquetes de código abierto a partir de ese código analizado en entornos aislados y reforzados, y bloquea cualquier elemento que no supere las comprobaciones antes de que llegue a tu entorno. Los paquetes activos se actualizan mediante un acuerdo de nivel de servicio (SLA) y, una vez finalizado el mantenimiento del desarrollador original, el servicio Endless Lifecycle Support (ELS) garantiza que se sigan proporcionando las correcciones. La cobertura abarca JavaScript, Python, Java, Go y PHP, y las compilaciones incluyen procedencia de nivel 3 según el estándar SLSA (Supply-chain Levels for Software Artifacts), SBOM y registros VEX.
Si no sabes qué se ha incluido en una compilación, o si hay vulnerabilidades sin resolver en paquetes que ya nadie mantiene, comprueba cómo SecureChain registra cada compilación y aplica parches a esos paquetes.
PREGUNTAS FRECUENTES
¿Cómo aborda la NIS2 la seguridad de la cadena de suministro?
La NIS2, la directiva de la UE sobre ciberseguridad, incluye la seguridad de la cadena de suministro como una de las diez medidas mínimas en su artículo 21. Dicha medida abarca los aspectos de seguridad de las relaciones de una entidad con sus proveedores directos o prestadores de servicios. El apartado 3 del artículo 21 exige a las entidades que evalúen las vulnerabilidades de cada proveedor directo, así como la calidad de sus productos y la seguridad de sus procedimientos de desarrollo.
¿Quién debe cumplir las medidas de la NIS2 relativas a la cadena de suministro?
Entidades esenciales e importantes. La NIS2, la directiva de la UE sobre ciberseguridad, clasifica a las organizaciones en dos categorías en función de la importancia crítica de su sector o servicio y del tamaño de la organización. Por lo general, abarca a las organizaciones medianas y grandes de los sectores que enumera, así como a algunas más pequeñas que cumplen criterios específicos.
¿Impone la NIS2 obligaciones a los proveedores?
No directamente. En sus directrices de contratación pública para hospitales de julio de 2026, la ENISA, la agencia de ciberseguridad de la UE, señala que la Directiva NIS2 no impone requisitos directamente a los proveedores de tecnologías de la información y la comunicación (TIC). No obstante, los clientes sujetos a la Directiva NIS2 pueden seguir solicitando garantías a los proveedores como parte de sus propias medidas.
¿Son vinculantes las directrices de la ENISA sobre la seguridad de la cadena de suministro en el marco de la Directiva NIS 2?
No. La ENISA, la agencia de ciberseguridad de la UE, califica su Guía Técnica de Aplicación de junio de 2025 como no vinculante. Dicha guía respalda el Reglamento de Ejecución (UE) 2024/2690 de la Comisión, que abarca los tipos de entidades digitales enumerados, como los proveedores de servicios en la nube y de servicios gestionados. Las directrices de la ENISA de julio de 2026 sobre la contratación pública en el ámbito hospitalario son, asimismo, recomendaciones.
¿A cuánto pueden ascender las multas del NIS2 por incumplir las medidas del artículo 21?
En virtud del artículo 34 de la NIS2, la Directiva de la UE sobre ciberseguridad, los Estados miembros deben fijar multas máximas de al menos 10 millones de euros o el 2 % de la cifra de negocios anual total a nivel mundial para las entidades esenciales, y de al menos 7 millones de euros o el 1,4 % para las entidades importantes, el importe que sea mayor. Por «volumen de negocios» se entiende la cifra del ejercicio financiero anterior correspondiente a la totalidad de la empresa a la que pertenece la entidad. Las multas se aplican a las infracciones del artículo 21 o de las normas de notificación de incidentes del artículo 23, y las leyes nacionales establecen las cifras concretas.
¿Se aplica la NIS2 de la misma manera en todos los países de la UE?
No. Las obligaciones se aplican a las entidades a través de la legislación nacional de cada Estado miembro, por lo que los detalles varían. Muchos Estados miembros cuentan ya con leyes en vigor, aunque la mayoría no cumplió el plazo de octubre de 2024 para su adopción. En julio de 2026, la Comisión Europea llevó ante el Tribunal de Justicia de la Unión Europea a Irlanda, España, Francia y los Países Bajos por no haber notificado la transposición completa. Consulta la legislación de cada país en el que operes.
