Reglamento de Ciberresiliencia: integre las obligaciones en el desarrollo de producto

El Reglamento de Ciberresiliencia (Cyber Resilience Act, CRA) incorpora obligaciones de ciberseguridad al ciclo de vida de los productos con elementos digitales incluidos en su ámbito de aplicación. Para un CTO, la tarea práctica consiste en vincular lo que ingeniería construye, distribuye y mantiene con las evidencias necesarias para demostrar el cumplimiento de esas obligaciones.

Esa vinculación debe funcionar a nivel de producto y de versión. Una política de seguridad corporativa no explica si una versión concreta tiene una configuración segura por defecto, qué dependencias contiene ni cómo recibirán los clientes una actualización de seguridad. Un ticket de vulnerabilidad marcado como «corregido» no establece qué versiones con asistencia siguen expuestas.

Por tanto, el punto de partida útil es un modelo del ciclo de vida del producto: ámbito, requisitos de seguridad, evidencias de cada versión, gestión de vulnerabilidades, compromisos de asistencia y decisiones con responsables claros. Integre ese modelo en el desarrollo en lugar de montarlo por separado antes de una evaluación.

Defina los límites del producto antes de asignar controles

El CRA se refiere a los productos con elementos digitales incluidos en su ámbito de aplicación, incluidos el hardware y el software cubiertos. No es una norma universal para todos los servicios SaaS. Un servicio alojado y un software distribuido a los clientes pueden requerir análisis distintos, y también debe examinarse el tratamiento de datos a distancia que forme parte integrante de un producto.

Utilice la guía de la Comisión Europea sobre el CRA como referencia de partida y resuelva después las cuestiones jurídicas específicas de cada producto. Registre la conclusión en lugar de depender de una suposición informal del equipo.

Para cada producto candidato, determine:

• Qué reciben los clientes: hardware, software instalado, componentes descargables o una combinación.
• Qué funciones de tratamiento de datos a distancia son necesarias para que el producto desempeñe sus funciones.
• Cómo se introduce el producto en el mercado de la UE y qué entidad lo suministra.
• Su rol como operador económico: fabricante, importador, distribuidor u otro rol pertinente.
• Las exclusiones aplicables, la legislación específica del producto y las consideraciones sobre código abierto.
• La categoría del producto y los requisitos de evaluación de la conformidad que se derivan de ella.

El código abierto requiere especial atención. El tratamiento del software suministrado fuera de una actividad comercial no significa que un fabricante comercial pueda ignorar los componentes de código abierto integrados en su producto. Distinga la posición del colaborador aguas arriba de su responsabilidad sobre el producto que usted suministra.

El entregable de ingeniería debe ser un breve registro del ámbito con un diagrama de arquitectura, los identificadores del producto, las entidades comerciales pertinentes, los supuestos y una conclusión aprobada. Designe a la persona responsable de reabrir esa conclusión cuando cambien la funcionalidad o la distribución.

Por ejemplo, una aplicación de gestión descargable y su servicio de analítica alojado no deberían recibir automáticamente una única decisión de ámbito indiferenciada. Identifique qué funciones operan localmente, cuáles dependen del servicio y si ese tratamiento a distancia forma parte de los límites del producto. Esa distinción afecta a la evaluación de riesgos, a los registros de dependencias y a la responsabilidad sobre los incidentes.

Trabaje con las fechas de aplicación vigentes

La Comisión fija el 11 de septiembre de 2026 para las obligaciones de notificación y el 11 de diciembre de 2027 para los requisitos principales del CRA. A 7 de octubre de 2026, la fecha de notificación ya ha pasado. Trate la preparación para la notificación como un requisito operativo actual, no como una tarea aplazada hasta la preparación de la conformidad.

Mantenga visibles dos líneas de trabajo:

Los productos introducidos en el mercado antes de la fecha principal de aplicación requieren atención a las disposiciones transitorias y a las modificaciones sustanciales. No dé por hecho que un producto antiguo es irrelevante a efectos de notificación solo porque su versión original sea anterior a diciembre de 2027.

Mantenga un registro fechado de requisitos legales. En cuanto a los umbrales de los eventos, los plazos escalonados de notificación, los destinatarios y los procedimientos de envío, consulte el texto jurídico vigente y la guía oficial de aplicación. No sustituya el proceso específico del CRA por una plantilla genérica de respuesta a incidentes.

Convierta los requisitos de seguridad en criterios de diseño y de publicación

Los requisitos esenciales del CRA abarcan las propiedades de seguridad del producto y la gestión de vulnerabilidades. Su implementación debe basarse en la evaluación de riesgos de ciberseguridad del producto, no en una lista de comprobación universal aplicada sin contexto arquitectónico.

Empiece por cómo puede causar daño el producto. Describa los usuarios, los entornos de despliegue, las interfaces expuestas, las operaciones privilegiadas, los datos sensibles y el uso indebido previsible. Incluya los supuestos operativos del cliente: un dispositivo desplegado en una red industrial tiene una exposición y unas limitaciones de recuperación distintas de las de una utilidad de escritorio.

Un ejercicio práctico de modelado de amenazas puede apoyar este trabajo; la guía de modelado de amenazas de OWASP ofrece un enfoque consolidado. El resultado debe vincular las amenazas con requisitos, decisiones de implementación y pruebas concretos.

Vea cómo los requisitos habituales se vuelven verificables:

Son ejemplos prácticos de implementación, no un sustituto de los requisitos aplicables. Determine su pertinencia y su suficiencia mediante la evaluación de riesgos.

Añada criterios de aceptación de seguridad al trabajo sobre funcionalidades. Una nueva API administrativa debe llegar con decisiones sobre autenticación, autorización, tratamiento de entradas y registro, no con la promesa de que seguridad la revisará más tarde. Revise el modelo de amenazas cuando añada una interfaz remota, un componente privilegiado o un nuevo límite de confianza.

La aprobación de una versión debe identificar las vulnerabilidades sin resolver, su explotabilidad, las configuraciones afectadas y su tratamiento. Aplique el requisito del CRA de comercializar los productos sin vulnerabilidades explotables conocidas, teniendo en cuenta la evaluación de riesgos y los requisitos esenciales aplicables; registrar o aceptar un riesgo no satisface por sí solo ese requisito. El resultado de un escáner no puede tomar esa decisión por sí solo: importan la accesibilidad, las condiciones previas y el comportamiento del producto. A la inversa, una puntuación numérica de gravedad baja no es motivo suficiente para ignorar una vulnerabilidad que tiene consecuencias en su modelo de despliegue.

El registro de la versión debe vincular la revisión del código fuente aprobada, el artefacto de compilación, el inventario de dependencias, los resultados de las pruebas y la decisión de seguridad. Así, la evaluación es reproducible cuando un cliente o una autoridad pregunten más adelante por una versión concreta.

Integre la diligencia debida sobre componentes en el proceso de compilación

Los componentes de terceros generan obligaciones que no se cumplen reenviando un aviso de seguridad del proveedor aguas arriba. Necesita saber qué distribuyó, si está afectado y cómo puede subsanarlo.

El CRA incluye entre sus requisitos de gestión de vulnerabilidades la obligación de elaborar una lista de materiales de software: en un formato de uso común y legible por máquina, que abarque al menos las dependencias de primer nivel. Como recomendación práctica, recoja información más profunda sobre las dependencias siempre que sus herramientas de compilación puedan producir resultados fiables. Las dependencias transitivas suelen determinar la exposición.

Una SBOM solo es útil cuando se corresponde con un artefacto real del producto. Asóciela al identificador de la versión y a la compilación, y distinga los componentes distribuidos de las herramientas que solo se usan en desarrollo. Incluya, cuando proceda, el firmware, los paquetes del sistema operativo, las bibliotecas integradas y los componentes comerciales; una exportación del gestor de paquetes puede pasar por alto varios de ellos.

Articule la revisión de componentes en torno a preguntas que cambien las decisiones de ingeniería:

• ¿Se mantiene el componente y es su vida útil con asistencia compatible con la nuestra?
• ¿Podemos obtener información sobre vulnerabilidades y actualizaciones de seguridad con rapidez?
• ¿Tenemos acceso al código fuente, una vía de parches del proveedor o una estrategia de sustitución?
• ¿Introduce el componente ejecución privilegiada o una nueva conexión externa?
• ¿Se podría seguir manteniendo el producto si el proveedor dejara de dar soporte al componente?

En el caso de los componentes comerciales, el área de compras debe establecer contactos de seguridad, mecanismos de notificación y acceso a las correcciones. Los plazos del proveedor deben dejar margen para su propia evaluación y sus obligaciones de notificación. El fabricante del producto sigue necesitando una vía de escalado interna cuando la respuesta de un proveedor sea incompleta.

En el caso de las dependencias de código abierto, conserve su procedencia y un plan de mantenimiento realista. Que un repositorio sea de acceso público no demuestra que alguien vaya a producir un parche compatible durante su periodo de asistencia.

Diseñe conjuntamente el periodo de asistencia y el mecanismo de actualización

La asistencia es un compromiso de ingeniería con consecuencias comerciales. Por lo general, el CRA exige un periodo de asistencia de al menos cinco años, salvo que el periodo de uso previsto del producto sea más corto. Determine el periodo aplicable con arreglo a los criterios del Reglamento, en lugar de elegir una fecha arbitraria que encaje con la hoja de ruta.

Registre la justificación, comunique a los clientes la información de asistencia exigida y vincúlela con las versiones del producto que se mantienen. El compromiso de asistencia debe tener en cuenta la capacidad de proporcionar actualizaciones de seguridad, no limitarse a mantener una dirección de soporte.

Antes de aprobar el plan de asistencia de un producto, pregúntese si puede:

• Volver a compilar las ramas antiguas con asistencia mediante cadenas de herramientas mantenidas.
• Producir, autenticar y distribuir actualizaciones de seguridad de forma segura.
• Probar las correcciones en el hardware y las configuraciones de despliegue con asistencia.
• Mantener las claves de firma y recuperarse de forma segura de su compromiso.
• Mantener disponible la información de actualización y de seguridad destinada a los clientes.
• Gestionar las dependencias cuyo soporte aguas arriba termine antes que el suyo.

Por lo general, las actualizaciones de seguridad deben proporcionarse gratuitamente durante el periodo de asistencia, con arreglo a lo dispuesto en el Reglamento. Cada actualización de seguridad publicada durante ese periodo debe seguir disponible durante al menos diez años desde su publicación o durante el resto del periodo de asistencia, si este fuera más largo. Planifique las correcciones de seguridad por separado del desarrollo de funcionalidades para que los clientes no se vean obligados innecesariamente a aceptar cambios funcionales no relacionados.

Pruebe algo más que el camino feliz. Una instalación interrumpida, la falta de almacenamiento, unas credenciales caducadas o una verificación fallida pueden convertir un parche válido en un problema de disponibilidad. Decida qué mecanismos de recuperación necesita el perfil de riesgo del producto.

Al finalizar la asistencia, la comunicación a los clientes y los registros internos deben coincidir. No deje una página de descargas que dé a entender que el mantenimiento de seguridad continúa cuando el registro de productos indica que el compromiso ha terminado.

Elabore un runbook de notificación que resista la incertidumbre

Un hallazgo de vulnerabilidad ordinario, una vulnerabilidad explotada activamente y un incidente grave no son intercambiables. El proceso de notificación del CRA necesita una evaluación documentada del desencadenante pertinente, no la notificación automática de cada alerta de un escáner ni el descarte automático de cualquier cosa que no cuente con una investigación forense completa.

El runbook debe empezar por la recepción. Los investigadores, el servicio de atención al cliente, los proveedores y los equipos de ingeniería necesitan una vía conocida para llegar a la función de seguridad de producto. Conserve el informe original y registre cuándo se tuvo conocimiento de la información pertinente; no reinicie las marcas de tiempo de conocimiento cuando un ticket cambie de equipo.

Para los eventos potencialmente notificables, recopile:

• Los identificadores del producto y las versiones con asistencia afectadas.
• Las evidencias de explotación o del impacto del incidente, con su grado de confianza y sus incertidumbres.
• Las condiciones de ataque conocidas, las funciones afectadas y los supuestos de despliegue.
• Las mitigaciones disponibles y el estado de las medidas correctoras.
• La evaluación del desencadenante, el responsable de la notificación y el cálculo de los plazos aplicables.
• Los avisos enviados, los acuses de recibo, las actualizaciones posteriores y las comunicaciones a los clientes.

Contraste con fuentes oficiales los plazos escalonados de notificación, los requisitos del informe final, los destinatarios y el procedimiento de notificación vigente. Las vulnerabilidades explotadas activamente y los incidentes graves tienen requisitos de notificación diferentes; un único campo de plazo copiado no basta.

Asigne un responsable principal de la notificación y un suplente con autoridad para coordinar ingeniería, el área jurídica y la comunicación con los clientes. Organice de antemano el acceso al mecanismo de notificación aplicable. La revisión jurídica debe estar disponible dentro del plazo de notificación, en lugar de convertirse en una cola de aprobación sin límite.

Ensaye el proceso con información incompleta. Un ensayo útil empieza con un informe de explotación creíble, una lista incierta de versiones afectadas y un proveedor de componentes que no está disponible. El equipo debe poder tomar a tiempo una decisión de notificación documentada mientras continúa la investigación.

La notificación del CRA no sustituye a otras obligaciones aplicables. Un evento relacionado con un producto también podría requerir una evaluación conforme a la normativa de protección de datos o a un contrato con un cliente. Coordine esas evaluaciones, pero mantenga separados sus desencadenantes, destinatarios y registros de decisión.

Confirme la clasificación antes de elegir el plan de evaluación

La clasificación del producto determina la vía de evaluación de la conformidad disponible. No suponga que todos los productos conectados necesitan la misma evaluación externa ni que todos los fabricantes pueden recurrir a una evaluación interna.

Determine la categoría aplicable a partir de las funciones del producto y de las definiciones y los anexos del Reglamento. Después, confirme la vía permitida, incluidas las condiciones relativas a normas armonizadas, especificaciones reconocidas, esquemas de certificación o evaluación por terceros.

La planificación de normas necesita un registro explícito de dependencias: qué referencias son aplicables, cuál es su estado actual y qué cambia si una vía prevista no está disponible. Evite que el plan de publicación dependa de una suposición no confirmada sobre las normas o sobre la capacidad de evaluación.

Revise la clasificación cuando cambie la funcionalidad. Añadir capacidades de gestión de la seguridad o de control de red puede afectar al análisis, pero el nombre de una funcionalidad no determina por sí solo una categoría. Evalúe la función real y documente la conclusión.

Mantenga la clasificación, la vía elegida y los entregables de conformidad vinculados a la documentación técnica. El marcado CE y la declaración UE de conformidad deben seguir el proceso aplicable; no sustituyen a la implementación de los requisitos subyacentes.

Mantenga un paquete de evidencias capaz de explicar una versión

La documentación técnica debe describir tanto el producto como el razonamiento que sustenta sus decisiones de seguridad. Conserve las evaluaciones de riesgos y la documentación a medida que cambia el producto, y aplique a los registros pertinentes los plazos legales de conservación.

Un paquete de evidencias del producto útil incluye la decisión de ámbito, la arquitectura, la evaluación de riesgos, los requisitos de seguridad, la información sobre componentes, los resultados de la verificación, los procedimientos de gestión de vulnerabilidades, la justificación de la asistencia y los registros de conformidad. Cada elemento necesita un responsable y una versión identificable.

Utilice identificadores estables para vincular estos registros. Un registro de vulnerabilidad debe explicar las versiones afectadas, la exposición, el tratamiento, la versión correctora y la comunicación necesaria. «Corregido» sin contexto de versión deja incompletas las evidencias del producto.

Los procesos existentes del SGSI pueden aportar evidencias útiles sobre gobierno, proveedores y desarrollo seguro. Sin embargo, ISO 27001 se refiere a un sistema de gestión de seguridad de la información con un alcance definido; la certificación no acredita la conformidad de un producto concreto con el CRA. Reutilice las evidencias pertinentes sin tratar las correspondencias entre marcos como equivalencias jurídicas.

Ejemplo práctico: un fallo en una dependencia de un dispositivo con asistencia

Considere un fabricante ilustrativo que suministra en la UE un dispositivo conectado a la red. Supongamos que se han revisado su ámbito y su clasificación, que dos ramas de versiones siguen teniendo asistencia y que se informa de que una biblioteca integrada está siendo explotada activamente en otros entornos.

La primera tarea no es cerrar el aviso del proveedor aguas arriba. Ingeniería identifica qué compilaciones del dispositivo contienen la biblioteca vulnerable y si la función afectada es accesible. La SBOM sugiere que ambas ramas la contienen, pero el análisis de la configuración muestra una exposición diferente. Esa distinción se registra con las evidencias que la respaldan.

A continuación, el responsable de seguridad de producto evalúa si los hechos disponibles cumplen el desencadenante de notificación aplicable del CRA. La incertidumbre sobre una configuración de despliegue se registra; no justifica dejar sin designar al responsable de la decisión. El runbook de notificación aporta las fases y el procedimiento de notificación vigentes.

Ingeniería desarrolla una mitigación temporal y una compilación parcheada para cada rama afectada. Las pruebas cubren la vía vulnerable, el funcionamiento normal y la instalación autenticada de la actualización. Si una rama no puede utilizar el parche del proveedor aguas arriba, el equipo registra su tratamiento alternativo y el riesgo residual en lugar de marcar todo el producto como corregido.

La comunicación a los clientes identifica las versiones afectadas, las medidas de protección inmediatas y la forma de obtener la actualización. El momento de la divulgación se coordina con los requisitos aplicables de gestión de vulnerabilidades y con cualquier consideración de seguridad justificada.

El registro completo vincula el aviso, el análisis de las compilaciones afectadas, la decisión de notificación, los envíos cuando sean obligatorios, los commits del parche, los resultados de las pruebas, los artefactos publicados y las comunicaciones. Un revisor puede ahora reconstruir tanto la respuesta de ingeniería como la decisión de cumplimiento.

Empiece con un producto y una cadena de evidencias completa

Elija un producto representativo con asistencia y siga una versión reciente y una vulnerabilidad a lo largo del ciclo de vida. Los vínculos de versión que falten, los compromisos de asistencia poco claros y los procedimientos de notificación inaccesibles saldrán a la luz rápidamente. Convierta cada carencia en una tarea con responsable y extienda después el modelo a toda la cartera.

Secani puede dar soporte a este flujo de evidencias vinculando requisitos, evidencias, responsables, tareas y decisiones de revisión. Las herramientas de ingeniería siguen siendo las fuentes operativas de las compilaciones, las versiones y las vulnerabilidades; el espacio de trabajo de cumplimiento relaciona esos registros con la obligación aplicable. Mantenga explícita la aprobación humana de las correspondencias y las conclusiones, y conserve la trazabilidad de las fuentes cuando utilice borradores asistidos por IA.

El siguiente paso inmediato es probar el runbook de notificación. En paralelo, exija que la próxima versión del producto incluya una decisión de ámbito vinculada, una evaluación de riesgos actualizada, un inventario de componentes y una aprobación de seguridad. Así se crea una práctica de ingeniería repetible mientras avanza la preparación de la conformidad.