[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:que-le-pide-el-cra-por-sus-dependencias-diligencia-debida-notificacion-aguas-arriba-y-vulnerabilidades-explotables-conocidas":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","que-le-pide-el-cra-por-sus-dependencias-diligencia-debida-notificacion-aguas-arriba-y-vulnerabilidades-explotables-conocidas","Qué le pide el CRA por sus dependencias: diligencia debida, notificación aguas arriba y vulnerabilidades explotables conocidas, según las orientaciones de la Comisión","Un producto de software es sobre todo código de otros. El CRA hace al fabricante responsable del producto en su conjunto y le impone tres deberes hacia los componentes que contiene: diligencia debida según el artículo 13(5), notificar vulnerabilidades aguas arriba y compartir correcciones según el artículo 13(6), e introducir el producto en el mercado sin vulnerabilidades explotables conocidas. Las orientaciones de la Comisión del 27 de julio de 2026, secciones 3.4, 7.3 y 9.2, dicen qué exige cada uno y qué no: ni notificaciones duplicadas, ni obligación de que acepten su corrección, y una definición de «conocida» que incluye la base de datos CVE y la prensa.","2026-09-11","\nLa mayor parte de un producto de software con elementos digitales es código que su fabricante no escribió: bibliotecas, frameworks, un sistema operativo, una base de datos, un servicio en la nube. El Cyber Resilience Act, Reglamento (UE) 2024\u002F2847, no hace al fabricante responsable del cumplimiento propio de esos componentes. Le hace responsable del producto en su conjunto, y vincula tres deberes a los componentes que contiene. Artículo 13(5): ejercer la diligencia debida al integrarlos. Artículo 13(6): notificar las vulnerabilidades que encuentre en ellos a su mantenedor, y compartir las correcciones que escriba. Anexo I, parte I, punto 2(a), leído con el artículo 13(1): introducir el producto en el mercado sin vulnerabilidades explotables conocidas. El Reglamento enuncia cada uno en una frase. Las orientaciones de la Comisión del 27 de julio de 2026, C(2026) 5252, secciones 3.4, 7.3 y 9.2, dicen qué exige cada uno, y este artículo son esas secciones, con las FAQ de la Comisión sobre la aplicación, versión 1.4, sección 5.4, donde añaden algo.\n\n## Quién es responsable de un componente: solo quien lo introduce en el mercado\n\nEl apartado 87 de las orientaciones zanja la pregunta que se hacen mantenedores e integradores: «Que el CRA se aplique a un componente FOSS determinado depende únicamente de si la persona física o jurídica que lo publica lo introduce en el mercado». Integrar un componente en un producto monetizado «no tiene ningún efecto sobre la condición de ese componente FOSS», y el apartado 86 añade que los fabricantes «no se hacen responsables del cumplimiento individual del CRA por esos componentes, ni siquiera cuando aportan código fuente a su mantenimiento». [Cuándo se introduce un proyecto en el mercado](\u002Farticles\u002Fis-your-open-source-project-commercial-under-the-cra-the-commissions-seven-tests) es una pregunta para quien lo publica. Lo que debe el integrador está en el apartado 88: el cumplimiento «de sus propios productos con elementos digitales», la diligencia debida del artículo 13(5) «respecto de los componentes FOSS que integran», y las notificaciones y correcciones del artículo 13(6).\n\n## Diligencia debida, artículo 13(5): decidir qué necesita del componente, y luego verificarlo\n\nLa sección 7.3 traza la línea entre la evaluación de riesgos y la diligencia debida. La evaluación de riesgos del artículo 13(2) cubre el producto y los riesgos que le llegan de fuera, «como las redes externas, los factores ambientales u otros aspectos externos», y para esos «el CRA no exige a los fabricantes controlar o gobernar el entorno externo», solo «identificar esos riesgos y mitigarlos mediante el diseño y el desarrollo del producto» (apartado 168). El ejemplo del apartado 169 es un back-end que no forma parte del producto pero podría usarse para enviarle órdenes maliciosas: la respuesta está a nivel de producto, «autenticación criptográfica de las órdenes remotas, verificación de la integridad de los cambios de configuración o generación de registros de seguridad», y el Reglamento «no impone obligaciones sobre cómo se organiza, dota de personal u opera la infraestructura back-end».\n\nLa diligencia debida es el otro deber, y «se refiere a elementos que forman parte del propio producto con elementos digitales, en particular componentes de software o hardware integrados suministrados por un tercero» (apartado 170). Su contenido cabe en una frase del mismo apartado: «solo puede lograrse determinando qué requiere el producto con elementos digitales de sus componentes para cumplir sus objetivos de ciberseguridad, y verificando, de manera basada en el riesgo, que esos componentes se ajustan a las necesidades del producto». El apartado 171 lo concreta: si el producto «se apoya en funciones criptográficas, mecanismos de actualización o comunicaciones seguras proporcionados por un componente, el fabricante debe, como parte de su diligencia debida, identificar esas necesidades y verificar que el componente las satisface». La prueba «puede consistir en documentación obtenida del fabricante del componente, como especificaciones técnicas, documentación de seguridad o documentación pertinente de conformidad o garantía», y «cuando proceda, el fabricante también puede realizar pruebas».\n\nDos consecuencias para una lista de dependencias. Primera, la diligencia debida es proporcionada y específica: pregunta qué hace cada componente por la seguridad del producto y comprueba eso, no todo sobre cada paquete. Una biblioteca de registro y una biblioteca TLS no tienen el mismo expediente. Segunda, la comprobación se hace «en el momento de la integración» (apartado 172), y los componentes se tratan «como componentes suministrados externamente cuyas propiedades se verifican mediante la diligencia debida», no se rediseñan. Apartado 173: «Cuando el fabricante desarrolla funcionalidades por sí mismo, debe aplicar directamente los requisitos esenciales. Cuando el fabricante integra componentes desarrollados por otros, debe garantizar mediante la diligencia debida que esos componentes pueden utilizarse de un modo que permita al producto con elementos digitales en su conjunto cumplir».\n\n## Notificar aguas arriba y compartir correcciones, artículo 13(6): cuatro límites que fijan las orientaciones\n\nEl artículo 13(6) exige que un fabricante que identifique una vulnerabilidad en un componente integrado la notifique «a la persona o entidad que fabrica o mantiene el componente», y que comparta cualquier corrección que desarrolle. La sección 9.2.1 acota el deber de cuatro maneras.\n\n**Solo la versión que integra, por el canal del mantenedor, y no dos veces.** Apartado 223: los fabricantes «solo están obligados a notificar aguas arriba respecto de la versión del componente que integran»; cuando el mantenedor tiene «políticas de seguridad, procesos de divulgación coordinada de vulnerabilidades o canales designados», la notificación va por ellos; y «los fabricantes no están obligados a notificar aguas arriba cuando pueden confirmar que la persona o entidad que fabrica o mantiene un componente conoce la existencia de una vulnerabilidad». Las orientaciones piden a los fabricantes consultar «bases de datos de vulnerabilidades de acceso público, avisos de seguridad propios del proyecto o gestores de incidencias establecidos antes de notificar aguas arriba», para ahorrar duplicados a los mantenedores.\n\n**Solo vulnerabilidades del componente, no de su integración.** Apartado 224: el deber cubre «las vulnerabilidades que existen en el propio componente integrado, y no las que existen como resultado de la integración entre el componente y otro código desarrollado por el fabricante». Cuando la integración revela un comportamiento del componente que no era evidente por separado, informar al mantenedor se recomienda, no se exige.\n\n**No cuando no hay mantenedor.** Apartado 225: no se debe ninguna notificación aguas arriba «cuando el componente ya no tiene mantenedor, o cuando el fabricante ya no depende del mantenedor original para nuevas versiones o correcciones de seguridad»; en su lugar se recomienda informar a los usuarios del componente mediante «los mecanismos comunitarios existentes (como listas de correo o tickets de incidencias) o mediante registros públicos de vulnerabilidades».\n\n**Compartir la corrección; no tener que conseguir que la fusionen.** Apartados 226 a 229: una corrección que desarrolle para la vulnerabilidad de un componente debe compartirse aguas arriba, «cuando proceda, en un formato legible por máquina» y, para un componente de código abierto, «de forma compatible con la licencia de ese componente». Pero los fabricantes «no están obligados por el CRA a garantizar que sus correcciones de seguridad sean necesariamente aceptadas» ni «integradas en el repositorio de código del componente», no están obligados a aceptar a cambio la corrección del mantenedor, y cuando mitigan la vulnerabilidad cambiando otra cosa en su propio sistema, «el CRA no exige al fabricante compartir aguas arriba la modificación de otra parte del sistema».\n\n## Cuándo la vulnerabilidad de un componente le toca a usted notificarla a las autoridades\n\nLa notificación obligatoria del artículo 14 es un deber distinto de la notificación aguas arriba, y ambos se confunden fácilmente. El apartado 218 de las orientaciones y la FAQ 5.4 trazan la línea: un fabricante notifica una vulnerabilidad explotada activamente «contenida en su producto»; cuando la vulnerabilidad de un componente de terceros «no puede explotarse en su producto con elementos digitales (por ejemplo, porque el código vulnerable no es alcanzable)» o «no ha sido explotada en su producto», «no está sujeta a notificación obligatoria para ese fabricante». Las FAQ añaden que el fabricante del componente también la notifica, «si ese componente se ha introducido en el mercado», y que el integrador «puede seguir notificando esa vulnerabilidad de forma voluntaria, con arreglo al artículo 15». Así que una CVE listada en una dependencia pone en marcha dos cosas: la evaluación de alcanzabilidad que decide [si el reloj de 24 horas ha empezado](\u002Farticles\u002Fwhen-does-the-cra-24-hour-clock-start-becoming-aware), y, si ha encontrado algo que el mantenedor no sabe, la notificación del artículo 13(6).\n\n## Vulnerabilidades explotables conocidas en el momento de publicar\n\nEl primer requisito esencial del anexo I, parte I, punto 2(a), es comercializar el producto «sin vulnerabilidades explotables conocidas», y la sección 9.2.2 responde a las dos palabras que el Reglamento deja abiertas. «Explotable» es el artículo 3(41): «una vulnerabilidad que tiene el potencial de ser utilizada eficazmente por un adversario en condiciones operativas prácticas», que el apartado 231 contrapone a las vulnerabilidades explotables «solo en condiciones teóricas (por ejemplo, en un laboratorio o una simulación)». «Conocida» son los apartados 233 y 234, y es amplio: una vulnerabilidad «debe considerarse conocida cuando figura en bases de datos de vulnerabilidades pertinentes y accesibles al público, como la base de datos europea de vulnerabilidades» u «otras bases de datos de vulnerabilidades destacadas»; cuando el fabricante «ha tenido conocimiento de ella a través de información no pública, por ejemplo mediante la divulgación coordinada de un investigador de seguridad o mediante sus propias pruebas y análisis internos, incluido, por ejemplo, el uso de servicios basados en IA»; y «cuando se ha informado de ella pública y destacadamente en medios fiables».\n\nEl apartado 235 lo mantiene proporcionado: un informe «no significa, en sí mismo, que sea explotable en la práctica o aplicable al producto concreto», el fabricante «tendrá que investigarla y confirmar la veracidad de esa información y su aplicabilidad», y «puede transcurrir un tiempo limitado entre el primer informe de la vulnerabilidad y su confirmación». Los apartados 236 y 237 abordan la versión que está a un día de salir cuando aparece una nueva CVE en una dependencia: la obligación «se aplica en el momento de la introducción en el mercado», es «una obligación basada en el riesgo», y el fabricante decide sobre la base de «la gravedad, la explotabilidad y el impacto potencial de la vulnerabilidad» si el producto puede introducirse en el mercado o la vulnerabilidad debe corregirse antes, y «también puede tener en cuenta los riesgos de posponer el lanzamiento del producto», por ejemplo cuando la versión corrige otras vulnerabilidades explotables. Una vez en el mercado, las obligaciones de gestión del anexo I, parte II, se aplican de todos modos.\n\n## Variantes y familias de productos\n\nUna sección corta que ahorra el mayor trabajo. Sección 7.4: cuando los productos «comparten la misma arquitectura, el mismo diseño relevante para la seguridad y la misma finalidad prevista, y están expuestos a los mismos riesgos de ciberseguridad», el fabricante «puede apoyarse en (i) una única evaluación de riesgos de ciberseguridad», «(ii) un único conjunto de documentación técnica; y (iii) un único procedimiento de evaluación de la conformidad», y emitir «una única declaración UE de conformidad» que «identifique claramente las variantes de producto a las que se aplica» (apartado 175). El apartado 176 da la prueba: las diferencias de «color, formato, tamaño de memoria u otras características sin relevancia para la seguridad» no dividen la familia; las diferencias en «interfaces de comunicación, pilas de software, mecanismos de actualización o conectividad remota» sí, y deben reflejarse en los documentos.\n\n## Qué conservar, por componente\n\nEl registro que satisface los tres deberes cabe en la SBOM que ya elabora para [el anexo I, parte II, punto 1](\u002Farticles\u002Fdoes-the-cra-require-an-sbom), una fila por componente:\n\n1. Nombre, versión integrada, y el contacto de seguridad o canal de divulgación del mantenedor.\n2. Qué necesita el producto de él para su seguridad, en el sentido del apartado 171: nada, o criptografía, actualizaciones, autenticación, transporte, etcétera.\n3. La prueba que posee de esa necesidad y cuándo la obtuvo: la documentación del mantenedor, un elemento de garantía, su propia prueba.\n4. La alcanzabilidad de las vulnerabilidades conocidas del componente en su producto, y la fecha de la última comprobación contra las bases de datos que nombra el apartado 233.\n5. Las notificaciones aguas arriba realizadas y las correcciones compartidas, con fechas, o la confirmación de que el mantenedor ya lo sabía.\n\nEsa tabla es el expediente de diligencia debida, la entrada de la evaluación de alcanzabilidad cuando aparece una CVE, y la parte de la [documentación técnica](\u002Farticles\u002Fwhat-goes-in-the-cra-technical-file-annex-vii-point-by-point) que una autoridad leerá primero cuando la pregunta sea «lo sabía».\n\n## Fuentes\n\n- Reglamento (UE) 2024\u002F2847, artículo 3(41), artículo 13(1), (2), (5) y (6), artículo 14(1), artículo 15, anexo I parte I punto 2(a) y parte II punto 1, considerando 34.\n- Comisión Europea, orientaciones de la Comisión sobre la aplicación del Reglamento (UE) 2024\u002F2847, C(2026) 5252 final de 27 de julio de 2026, anexo, sección 3.4 (apartados 85 a 88), secciones 7.3 y 7.4 (apartados 167 a 177), sección 9.1 apartado 218, secciones 9.2.1 y 9.2.2 (apartados 222 a 237).\n- Comisión Europea, FAQ sobre el Cyber Resilience Act, versión 1.4 de 4 de septiembre de 2026, sección 5.4.\n\nEsto no es asesoramiento jurídico. Las secciones 7.3 y 9.2 suman siete páginas entre las dos y responden a la pregunta de las dependencias con más precisión que la página de cualquier proveedor de herramientas; léalas con su lockfile abierto.\n",1789383978047]