Estado a 13 de septiembre de 2026. El Reglamento (UE) 2024/2847 (Ley de Resiliencia Cibernética de la UE) establece requisitos de ciberseguridad para productos con elementos digitales comercializados en la Unión. La guía práctica de la Comisión se publicó el 27 de julio de 2026. Las obligaciones relacionadas con la notificación de vulnerabilidades e incidentes ya se aplican desde el 11 de septiembre de 2026; el conjunto principal de obligaciones de producto se aplicará a partir del 11 de diciembre de 2027. Esta guía está dirigida a ingenieros de software de productos que podrían estar en el ámbito de aplicación, no a abogados de evaluación de conformidad.
Honestidad sobre el ámbito: la CRA no sustituye a SOC 2, ISO 27001 o el GDPR. No es "otra casilla de verificación de un bot de cumplimiento". Muchas obligaciones de la CRA son procesos de fabricante, documentación y poscomercialización. Solo una parte puede detectarse en una pull request normal: actualización de inventario de dependencias y SBOM, rutas de divulgación de vulnerabilidades y controles de seguridad eliminados como código muerto. Si tu equipo legal o de producto no ha confirmado que la CRA aplica a lo que envías, detente aquí y pregúntales.
Qué entra en vigor y cuándo (calendario para desarrolladores)
Ya desde el 11 de septiembre de 2026, se aplican las obligaciones de notificación asociadas al régimen de notificación de vulnerabilidades e incidentes del Reglamento, según el calendario establecido por la normativa y la guía de la Comisión para los fabricantes. A partir del 11 de diciembre de 2027, los principales requisitos de ciberseguridad de producto (incluyendo expectativas de diseño seguro, procesos de gestión de vulnerabilidades y transparencia relacionada con SBOM para productos con elementos digitales) se aplican de manera más amplia. La clasificación exacta de tu producto (por defecto, importante, crítico) es una cuestión legal y de producto, no algo que decida una revisión de código.
Trata esas fechas como puntos de referencia para la planificación. Si las correcciones del Diario Oficial o guías posteriores las modifican, valida de nuevo esta página (consulta el registro de actualización de fechas).
Qué puede detectarse realmente en una pull request
Actualización de dependencias y SBOM: un cambio fija un componente obsoleto, elimina la generación del SBOM del CI o deja de publicar el inventario de componentes en el que se basa tu proceso de vulnerabilidades. Ruta de gestión de vulnerabilidades: un cambio elimina o codifica de forma fija el cierre de un contacto de seguridad, un feed de asesorías o un webhook de triaje interno de vulnerabilidades que tu proceso alineado con la CRA asume que existe. Erosión del diseño seguro: una PR de "limpieza" elimina la autenticación en un puerto de administración, desactiva las comprobaciones de actualización o deshabilita la verificación de integridad en los paquetes de actualización porque generaban ruido.
Estas son formas de ingeniería. No constituyen un archivo completo de conformidad con la CRA, una historia de marcado CE ni una evaluación de organismo notificado.
Ejemplo práctico: el CI deja de generar el inventario de componentes
Un equipo de plataforma acorta el CI en dos minutos eliminando un trabajo que ejecutaba syft (o equivalente) y subía un artefacto SBOM en cada etiqueta de versión. El Dockerfile y la aplicación siguen compilándose. Las pruebas siguen en verde. Los comentarios de revisión tratan sobre el coste del pipeline. Semanas después, el equipo de seguridad no puede responder "qué versiones se enviaron en la 1.8.3" sin reconstruir a partir de las capas.
Si tu producto está en el ámbito de la CRA y tu proceso depende de ese inventario para la gestión de vulnerabilidades y la transparencia, la eliminación del trabajo no es una higiene neutral. Una revisión consciente del cumplimiento marca la pérdida del paso de inventario en la PR, para que el equipo de producto y seguridad pueda aceptar el riesgo formalmente o restaurar el trabajo. Que heygrc cite un control de marco aquí es una señal, no una determinación de que el producto no es conforme.
Objetivos explícitamente no cubiertos
Esta guía no cubre módulos de evaluación de conformidad, marcado CE, registro de fabricante, redacción de la declaración de conformidad de la UE ni si tu producto se clasifica como "importante" o "crítico" según el Reglamento. No afirma que heygrc haga que un producto sea conforme con la CRA. No sustituye a tu PSIRT, revisión legal ni plan de respuesta de vigilancia del mercado.
Si solo necesitabas SOC 2 o ISO 27001 para clientes, la CRA puede seguir siendo irrelevante. No la fuerces.
Dónde encaja heygrc y el límite de la honestidad
heygrc está diseñado para mostrar cambios en pull requests relevantes para los controles, según los marcos que actives. Para la higiene de ingeniería relacionada con la CRA, la superposición útil es la misma clase de hallazgos que el desarrollo seguro y la gestión de vulnerabilidades en otros marcos (por ejemplo, requisitos de software del NIS 2 Art. 21, controles de desarrollo seguro de ISO 27001): comprobaciones de integridad de actualización eliminadas, autenticación debilitada, trabajos de inventario suprimidos. Mapea con cuidado; no inventes números de artículo de la CRA en los hallazgos a menos que tu base de conocimientos activada los incluya.
Mantén SAST, escáneres de dependencias y tu revisor de código. La ley de producto CRA está mayormente fuera del diff. El diff solo detecta la parte que elimina silenciosamente lo que esos programas asumen que sigue funcionando.