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 13, apartado 5, de la Ley de Resiliencia Cibernética (CRA) exige que se aplique la diligencia debida a los componentes de terceros, incluidos los de código abierto.
- El incumplimiento del artículo 13 conlleva multas de hasta 15 millones de euros o el 2,5 % de la facturación anual mundial, lo que sea mayor.
- El considerando 34, de carácter no vinculante, vincula la diligencia debida al riesgo asociado a cada componente y enumera cuatro posibles medidas, pero el método lo debes elegir y documentar tú mismo.
- Según las directrices de la Comisión Europea, al integrar un componente de código abierto no asumes la responsabilidad del cumplimiento de la CRA de dicho componente. El cumplimiento de tu producto sigue abarcando dicho componente, incluida la gestión de sus vulnerabilidades durante tu periodo de soporte, incluso después de que el desarrollador original deje de corregirlo.
- Las acciones del considerando 34 no tienen en cuenta si un paquete se ha compilado a partir de su código fuente publicado o si contiene código inyectado, por lo que tu propia evaluación de riesgos determinará hasta qué punto se deben comprobar ambos aspectos.
Si tu producto incluye componentes de código abierto, la Ley de Resiliencia Cibernética (CRA) te obliga a actuar con la debida diligencia respecto a ellos a partir del 11 de diciembre de 2027. Las directrices no vinculantes de la Comisión Europea añaden que los responsables del mantenimiento que no comercialicen sus componentes de código abierto no tienen ninguna obligación contigo en virtud de la CRA. El artículo 13, apartado 5, amplía tu obligación de actuar con la debida diligencia incluso a esos componentes, por lo que una biblioteca que su responsable no monetice sigue estando incluida.
¿Qué grado de diligencia debida es suficiente? La CRA deja esta cuestión abierta, y el considerando 34 adapta el nivel al riesgo del componente y enumera ejemplos de medidas sin exigir que se aplique ninguna de ellas en concreto. Ninguna de esas medidas pregunta si el paquete en el que se ejecuta tu producto se ha compilado a partir de su código fuente publicado o si contiene código que no debería estar ahí. La decisión es tuya, y no cumplir con los requisitos puede acarrear multas administrativas (artículo 64, apartado 2).
Lo que establece la Ley de Resiliencia Cibernética sobre los componentes que no has escrito tú
La Ley de Ciberresiliencia de la UE, el Reglamento (UE) 2024/2847, impone a los fabricantes la obligación de diligencia debida. Se entiende por producto con elementos digitales cualquier producto de software o hardware, incluidos los componentes de software o hardware comercializados por separado (artículo 3, apartado 1). El artículo 3, apartado 13, define al fabricante como toda persona física o jurídica que desarrolle o fabrique dichos productos, o que encargue su diseño, desarrollo o fabricación, y los comercialice bajo su nombre o marca comercial. La definición se aplica independientemente de que el producto se venda, se monetice o se regale.
Un componente es cualquier elemento de software o hardware destinado a integrarse en un sistema de información electrónico (artículo 3, apartado 6), por lo que, por lo general, una biblioteca de código abierto en la que se base tu producto cumplirá los requisitos. De conformidad con el artículo 2, apartado 1, la CRA se aplica a los productos comercializados cuyo destino previsto o uso razonablemente previsible incluya una conexión de datos a un dispositivo o a una red.
El artículo 3, apartado 22, define «poner a disposición en el mercado» como el suministro para su distribución o uso en el mercado de la UE en el marco de una actividad comercial, ya sea a título oneroso o gratuito. El suministro gratuito de algo puede seguir siendo comercial. En el caso del código abierto, lo que importa es si el editor lo monetiza, por ejemplo, cobrando por él, condicionando el acceso a las versiones o actualizaciones al pago, o utilizándolo para vender otros servicios (considerando 18; orientaciones de la Comisión, apartado 3.2). Una biblioteca que su mantenedor suministra al margen de una actividad comercial no se considera un producto, pero sigue siendo un componente del tuyo.
El artículo 13, apartado 5, exige a los fabricantes que actúen con la debida diligencia al integrar componentes procedentes de terceros, de modo que dichos componentes no pongan en peligro la ciberseguridad del producto. Incluye expresamente los componentes de código libre y de código abierto que no se hayan comercializado en el marco de una actividad comercial. El artículo 13 será de aplicación a partir del 11 de diciembre de 2027 (artículo 71, apartado 2).
El incumplimiento del artículo 13 puede acarrear multas administrativas de hasta 15 000 000 EUR o, en el caso de una empresa (término utilizado en la UE para referirse a una sociedad mercantil), hasta el 2,5 % de su volumen de negocios anual total a nivel mundial correspondiente al ejercicio financiero anterior, el que sea mayor (artículo 64, apartado 2).
La indemnización por daños causados por productos defectuosos se rige por un régimen independiente, la Directiva (UE) 2024/2853, la Directiva sobre responsabilidad por productos defectuosos. El considerando 31 la califica de complementaria a la CRA y señala que la falta de actualizaciones de seguridad que provoque daños podría dar lugar a la responsabilidad del fabricante en virtud de la misma.
Lo que la diligencia debida determina y lo que no determina
La Ley de Resiliencia Cibernética exige a los fabricantes que actúen con la debida diligencia, y es en el considerando 34 —de carácter no vinculante— donde el texto se concreta más. En él se establece que el nivel adecuado depende de la naturaleza y el grado del riesgo de ciberseguridad asociado a un componente, y que la debida diligencia debe tener en cuenta una o varias de las cuatro medidas enumeradas (Tabla 1). Las preguntas frecuentes de la Comisión sobre la CRA, un documento de preguntas y respuestas independiente de sus directrices, aportan ejemplos adicionales.
Tabla 1. Medidas que las fuentes mencionan para la diligencia debida en relación con un componente
| Acción | Fuente | Fundamentos |
|---|---|---|
| Cuando proceda, comprueba que el fabricante del componente haya demostrado la conformidad con la CRA, por ejemplo, mediante el marcado CE. | Considerando 34 | Recital (interpretativo) |
| Comprueba que el componente reciba actualizaciones de seguridad periódicas; por ejemplo, a través de su historial de actualizaciones. | Considerando 34 | Recital (interpretativo) |
| Comprueba que el componente no presente ninguna vulnerabilidad registrada en la base de datos europea de vulnerabilidades ni en otras bases de datos públicas de vulnerabilidades. | Considerando 34 | Recital (interpretativo) |
| Realizar pruebas de seguridad adicionales | Considerando 34 | Recital (interpretativo) |
| Realizar un análisis de la composición del software, aislar los componentes de alta criticidad, revisar la lista de materiales de software (SBOM) del componente cuando esté disponible, comprobar su periodo de soporte, verificar que su finalidad prevista se ajuste al uso previsto por el fabricante o evaluar el nivel de seguridad de su fabricante. | Preguntas frecuentes de la Comisión, respuesta 4.4.2 (versión 1.4, 4 de septiembre de 2026) | Preguntas frecuentes sobre la Comisión (sin carácter oficial) |
Nota: En la sección de preguntas frecuentes de la Comisión se indica que sus respuestas no establecen ningún requisito adicional y que sus opiniones no tienen carácter vinculante.
El considerando 34 dice «una o más», por lo que no considera que ninguna acción concreta sea obligatoria. Ni este considerando ni el artículo 13, apartado 5, establecen un método, una profundidad ni un formato de registro.
El anexo VII enumera los elementos que debe contener la documentación técnica. En él se incluyen la evaluación de riesgos, la descripción de cómo los componentes de software se integran en el sistema global y los informes de ensayo, pero no contiene ningún apartado específico dedicado a la diligencia debida de los componentes. Esto no significa que la diligencia debida no quede documentada. El artículo 13, apartado 7, sigue exigiendo a los fabricantes que documenten de forma sistemática los aspectos relevantes del producto en materia de ciberseguridad, de forma proporcional a su naturaleza y a los riesgos de ciberseguridad que presente.
Una vez establecido el nivel en función del riesgo y sin especificar el método, es su propio razonamiento el que determina el grado de diligencia debida que se aplica a cada componente. Las orientaciones de la Comisión (puntos 170 y 171) dividen esta obligación en dos pasos: utilice la evaluación de riesgos de su producto para identificar qué requiere el producto de cada componente y, a continuación, verifique que el componente lo proporciona. Una nota de dicha verificación, redactada en el momento de la incorporación del componente, es más fiable que una reconstruida años más tarde, ya que el artículo 13, apartado 5, vincula la obligación a la integración.
Lo que se te queda grabado y lo que no
Las orientaciones de la Comisión, de 27 de julio de 2026, establecen que los fabricantes que integran componentes de código abierto no son responsables del cumplimiento individual de la CRA por parte de dichos componentes, incluso cuando aportan código fuente para su mantenimiento (punto 86). Siguen teniendo sus propias obligaciones con respecto al producto, incluida la diligencia debida prevista en el artículo 13, apartado 5, así como la notificación de vulnerabilidades y el intercambio de soluciones, según lo dispuesto en el artículo 13, apartado 6 (punto 88).
Los administradores y responsables del mantenimiento en las fases iniciales tienen obligaciones en materia de CRA mucho menos exigentes que los fabricantes. El artículo 3, apartado 14, define al administrador de software de código abierto como una persona jurídica, distinta de un fabricante, cuyo objetivo es apoyar de forma sistemática y continuada el desarrollo de productos específicos libres y de código abierto destinados a actividades comerciales, y que garantiza su viabilidad. El artículo 24 establece un régimen menos estricto para los administradores: una política de ciberseguridad documentada, la cooperación con las autoridades de vigilancia del mercado y, en casos limitados, parte de las obligaciones de notificación previstas en el artículo 14 relativas a vulnerabilidades explotadas e incidentes (artículo 24, apartado 3). La guía añade que los responsables del mantenimiento de componentes que no se hayan comercializado no tienen ninguna obligación frente a los fabricantes que los integren (punto 87).
Sus obligaciones no se limitan a la integración. El artículo 13, apartado 6, le obliga a notificar cualquier vulnerabilidad que detecte en un componente al fabricante o al responsable de su mantenimiento, con el fin de que se subsane, y a compartir el código o la documentación pertinentes si ha desarrollado una solución. El artículo 13, apartado 8, exige que las vulnerabilidades del producto, incluidos sus componentes, se gestionen de forma eficaz durante todo el período de soporte que usted establezca. Dicho período debe ser de al menos 5 años, salvo que se prevea que el producto esté en uso durante menos de 5 años. En virtud de la CRA, ni los administradores (artículo 24) ni los responsables del mantenimiento de componentes que no se hayan comercializado (punto 87) están obligados a ofrecerte un período de soporte, por lo que una versión de un componente puede dejar de recibir correcciones de la fuente original aunque al período de soporte de tu producto aún le queden años por delante.
Las acciones enumeradas no preguntan cómo se ha compilado un paquete
Tres de las cuatro medidas del considerando 34 se centran en el historial publicado de un componente. Se pregunta si su fabricante ha demostrado su conformidad, si recibe actualizaciones de seguridad periódicas y qué indican las bases de datos de vulnerabilidades al respecto. La cuarta, las pruebas de seguridad adicionales, es la única en la que debes probar el componente tú mismo.
El historial de un componente describe cómo se comporta un proyecto, pero no indica si el paquete que finalmente se ejecuta en tu producto se ha compilado a partir del código fuente que publica el proyecto, ni si contiene código que no debería estar ahí. La procedencia de la compilación y el código inyectado no aparecen en ninguna de las acciones mencionadas en el considerando 34 ni en los ejemplos de las preguntas frecuentes de la Comisión. Sin embargo, ambos factores influyen directamente en si un componente pone en peligro la ciberseguridad del producto, el resultado que el artículo 13, apartado 5, pretende evitar.
El apartado 5 del artículo 13 no especifica el método, por lo que la forma de comprobar la procedencia y detectar código inyectado depende de ti. Dos opciones son verificar un paquete comparándolo con su código fuente y analizarlo en busca de código malicioso antes de que entre en tu entorno. Una SBOM enumera lo que contiene un producto, pero el hecho de incluir un paquete en la lista no verifica cómo se ha compilado ni qué código contiene. Tu evaluación de riesgos debería indicarte en qué medida cada componente necesita esto.
Comprobación de los paquetes antes de que lleguen a tu entorno
SecureChain, de TuxCare, analiza el código fuente de los paquetes de código abierto que cubre en busca de malware conocido, patrones de código sospechosos y otros riesgos de la cadena de suministro; a continuación, recompila los paquetes a partir de ese código fuente analizado en entornos de compilación aislados y reforzados. Los paquetes que no superan el análisis se bloquean antes de que lleguen a tu entorno. Cada paquete incluye una SBOM, un documento VEX y una procedencia SLSA de nivel 3, es decir, un registro del código fuente y de la compilación que lo generó.
En el caso de los componentes que aún reciben mantenimiento activo, SecureChain distribuye correcciones en paquetes recompilados, en el marco de un acuerdo de nivel de servicio, a medida que surgen nuevas vulnerabilidades. Una vez que finaliza el mantenimiento del desarrollador original, el servicio «Endless Lifecycle Support» de TuxCare sigue solucionando vulnerabilidades de todos los niveles de gravedad, desde las críticas hasta las de menor gravedad, en las versiones específicas que utilices.
¿No puedes confirmar qué contienen los paquetes que envías? Descubre cómo SecureChain los verifica antes de que se incorporen a tus compilaciones.
PREGUNTAS FRECUENTES
¿A quién afecta la Ley de Resiliencia Cibernética?
La Ley de Resiliencia Cibernética (CRA), el reglamento de la UE sobre ciberseguridad de los productos, se aplica a los productos con elementos digitales que se comercializan en el mercado de la UE en el marco de una actividad comercial y cuyo destino previsto o uso razonablemente previsible incluya una conexión de datos a un dispositivo o una red (artículos 2, apartado 1, y 3, apartado 22). Las obligaciones recaen principalmente en los fabricantes. Los importadores, los distribuidores y los gestores de software de código abierto tienen obligaciones específicas (artículos 19, 20 y 24).
¿Cuándo se aplican las disposiciones de la Ley de Resiliencia Cibernética?
La Ley de Resiliencia Cibernética (CRA) entró en vigor el 10 de diciembre de 2024. El capítulo IV, relativo a la notificación de los organismos de evaluación de la conformidad, es de aplicación desde el 11 de junio de 2026, y el artículo 14, relativo a la presentación de informes por parte de los fabricantes, desde el 11 de septiembre de 2026. El resto de disposiciones se aplicará a partir del 11 de diciembre de 2027 (artículo 71, apartado 2).
¿Sustituye la CRA a las normas sobre responsabilidad por productos defectuosos?
No. El considerando 31 de la Ley de Resiliencia Cibernética (CRA) califica a la Directiva (UE) 2024/2853, la Directiva sobre responsabilidad por productos defectuosos, de complementaria. Dicha Directiva regula la indemnización por los daños causados por productos defectuosos, mientras que la CRA establece las obligaciones de los fabricantes, respaldadas por multas administrativas (artículo 64). El artículo 65 aplica las normas de la UE sobre acciones representativas a las infracciones que perjudiquen o puedan perjudicar los intereses colectivos de los consumidores.
¿Pueden los fabricantes utilizar software de código abierto de mantenedores a los que la CRA no está sujeta?
Sí, siempre y cuando el fabricante actúe con la debida diligencia para que dichos componentes no pongan en peligro la ciberseguridad del producto. El artículo 13, apartado 5, de la Ley de Ciberresiliencia (CRA) se refiere expresamente a los componentes de código abierto que no se han comercializado en el mercado, y el considerando 34 establece que el nivel depende del riesgo que presente el componente.
¿Están obligados los fabricantes a notificar las vulnerabilidades de los componentes al responsable del mantenimiento?
Sí, una vez que la identifiquen. A partir del 11 de diciembre de 2027, el artículo 13, apartado 6, de la Ley de Resiliencia Cibernética (CRA) exige que el fabricante notifique cualquier vulnerabilidad en un componente integrado —incluidos los de código abierto— a quien lo fabrique o mantenga, y que la subsane. Si el fabricante desarrolla una solución, deberá compartir el código o la documentación pertinentes. Esto es independiente de la obligación de notificación a las autoridades prevista en el artículo 14, que se aplica desde el 11 de septiembre de 2026.
