Herramientas de cumplimiento del CRA comparadas

Para quién es esta página

Fabrica un producto con elementos digitales y lo introduce en el mercado de la UE. El Cyber Resilience Act, Reglamento (UE) 2024/2847, se le aplica por fases: sus obligaciones de notificación desde el 11 de septiembre de 2026 y sus disposiciones principales desde el 11 de diciembre de 2027. Está eligiendo herramientas para la parte técnica de ese trabajo. Nosotros desarrollamos CRACI, así que téngalo en cuenta. Describimos cada herramienta a partir de su propia documentación e indicamos dónde encaja mejor otra herramienta.

Hay una regla que recorre toda esta página. El cumplimiento es un proceso que dirige el fabricante, con evaluación de riesgos, documentación y evaluación de la conformidad. Las herramientas generan evidencia y automatizan partes del trabajo. Ninguna de las herramientas siguientes hace que un producto cumpla por sí sola.

Qué pide el CRA

Para la cadena de suministro de software, cinco requisitos concentran la mayor parte del trabajo.

1. Una SBOM. Los fabricantes identifican y documentan los componentes del producto, «también mediante la elaboración de una nomenclatura de materiales de software en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior de los productos» (anexo I, parte II). El anexo VII la sitúa en la documentación técnica, que una autoridad de vigilancia del mercado puede solicitar.
2. Gestión de vulnerabilidades. Abordar y corregir las vulnerabilidades sin demora, también mediante actualizaciones de seguridad, realizar pruebas periódicas y aplicar una política de divulgación coordinada de vulnerabilidades (anexo I, parte II).
3. Notificación. Notificar las vulnerabilidades explotadas activamente y los incidentes graves a su CSIRT y a ENISA a través de la plataforma única de notificación del CRA: una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final a más tardar 14 días después de que haya una corrección o mitigación disponible para una vulnerabilidad, o en el plazo de un mes para un incidente grave (artículo 14).
4. Evidencia. Documentación técnica, una evaluación de la conformidad y una declaración UE de conformidad (artículos 28, 31 y 32, anexo VII), a disposición de las autoridades durante al menos 10 años después de la introducción del producto en el mercado o durante el periodo de soporte, si este es más largo (artículo 13).
5. Un periodo de soporte. Un periodo que refleje el tiempo durante el que se espera que se use el producto, de al menos cinco años salvo que el uso previsto sea más corto, durante el cual las vulnerabilidades se gestionan de forma eficaz (artículo 13).

Cómo elegir

• ¿Con qué mitad del trabajo necesita ayuda? Las herramientas técnicas generan la SBOM, los registros de vulnerabilidades y la evidencia del build. Las plataformas de gestión del cumplimiento asignan los requisitos a controles, redactan políticas y hacen el seguimiento del proceso. La mayoría de las herramientas destacan en una de las dos mitades, así que decida qué carencia es mayor.
• ¿Compila usted el software o lo integra? Si gran parte del producto le llega de fabricantes de chips y proveedores en forma de binarios, el análisis binario es la manera de ver su interior. Si lo compila usted, el build es la fuente de evidencia más directa.
• ¿De dónde sale su SBOM y cómo sabe que está completa? Los escáneres, las consultas a las herramientas de build y el registro del build pueden dar respuestas distintas para el mismo lanzamiento.
• ¿Puede encontrar los lanzamientos afectados en cuestión de horas? Una alerta temprana en 24 horas depende de un inventario por lanzamiento en el que pueda confiar.
• ¿Necesita un sistema de registro? Con muchos productos y proveedores, la gestión de SBOM con VEX y su intercambio se convierten en un trabajo en sí mismos.

De un vistazo

Dos tablas: primero las herramientas de SBOM, SCA y gestión de SBOM, y después las herramientas pensadas para firmware y dispositivos. Las filas siguen los requisitos anteriores. «No indicado» significa que las páginas del proveedor que citamos no lo dicen en ningún sentido.

SBOM, SCA y gestión de SBOM

Firmware y dispositivos

CRACI

CRACI es un runner de GitHub Actions. Para el software que usted compila, registra lo que descargó cada job, incluidos los paquetes restaurados desde cachés de CI, y genera una SBOM CycloneDX o SPDX con un estado de completitud por job y por caché. Sigue reevaluando las SBOM de lo que se ha distribuido, es compatible con VEX y envía en su nombre las notificaciones del CRA cuando hay que notificar una vulnerabilidad explotada activamente. Para Yocto, registra lo que la salida SPDX del propio Yocto deja fuera. Ayuda con: generación de SBOM, gestión de vulnerabilidades, notificaciones del CRA, evidencia. Tenga en cuenta: no analiza binarios que usted no haya compilado, no ofrece asignación de controles ni gestión de políticas y hoy es compatible con GitHub Actions (GitLab CI y Jenkins están en la hoja de ruta). Cumplimiento del CRA con CRACI

Gestión de SBOM

Cybeats

Cybeats SBOM Studio se define como «el sistema de registro de SBOM». Almacena las SBOM de sus productos y proveedores en SPDX 2.2 a 3.0.1 y CycloneDX 1.2 a 1.7, las valida con un Quality Score antes de importarlas, coteja cada componente con inteligencia de vulnerabilidades, emite VEX y comparte las SBOM con los clientes, también a través de la Transparency Exchange API. Su guía de normativas expone el calendario de 24 horas, 72 horas y 14 días del CRA. Ayuda con: gestión de SBOM, gestión de vulnerabilidades, evidencia. Tenga en cuenta: para la generación remite a proveedores de su Marketplace, así que la propia SBOM procede de otra herramienta. CRACI frente a Cybeats y alternativas a Cybeats

FOSSA

FOSSA empezó en el cumplimiento de licencias y hoy cubre el ciclo de vida de la SBOM. Genera SBOM SPDX y CycloneDX, opcionalmente con declaraciones VDR o VEX, importa SBOM de proveedores con políticas para los elementos mínimos de la NTIA y la FDA, las monitoriza en busca de vulnerabilidades y las comparte mediante un SBOM Portal en Enterprise. A septiembre de 2026 tiene un plan gratuito, y Business cuesta $20 por proyecto al mes con facturación anual. Ayuda con: SBOM, intercambio con las autoridades, licencias. Tenga en cuenta: la CLI de FOSSA analiza el proyecto a través de su herramienta de build o lo deduce del código fuente, en lugar de registrar el build. CRACI frente a FOSSA

Anchore

Anchore Enterprise se basa en los proyectos de código abierto Syft y Grype. Escanea imágenes de contenedor, sistemas de archivos y SBOM importadas, vuelve a escanear las SBOM almacenadas sin el artefacto original, aplica paquetes de políticas como FedRAMP y NIST, y se ejecuta de forma autoalojada, también en entornos aislados (air-gapped). Su material sobre el CRA abarca la gestión de SBOM, la monitorización frente a fuentes como CISA KEV, el apoyo para los plazos de 24 y 72 horas, las anotaciones VEX y los registros de auditoría. Ayuda con: SBOM, gestión de vulnerabilidades, evidencia. Tenga en cuenta: sus SBOM describen lo que un escáner encuentra en una imagen o un directorio, no lo que el build descargó y dejó atrás. CRACI frente a Anchore

Suites de SCA

Black Duck

Black Duck SCA combina el escaneo de gestores de paquetes, por firmas, de fragmentos y de binarios, de modo que encuentra código abierto que nadie declaró, y su KnowledgeBase hace el seguimiento de más de 2.750 licencias. Binary Analysis examina firmware sin código fuente, Coverity ofrece SAST con una opción de comprobaciones alineadas con el CRA anunciada en julio de 2026, y Defensics realiza pruebas de fuzzing. Black Duck sostiene que el CRA exige varias capas de pruebas, no solo SCA. Ayuda con: SBOM, gestión de vulnerabilidades de los componentes y de su propio código, pruebas. Tenga en cuenta: el precio se fija mediante presupuesto, y todas sus técnicas inspeccionan el código o el resultado en lugar del build. CRACI frente a Black Duck

Sonatype

Sonatype Lifecycle aplica políticas de código abierto con datos de alcanzabilidad y de actualización, y abre Golden Pull Requests. Repository Firewall pone en cuarentena los componentes que no cumplen la política antes de que entren en sus repositorios. SBOM Manager importa, monitoriza y comparte SBOM con un flujo de trabajo VEX, y Sonatype lo presenta como su producto para el CRA; su guía también propone Nexus Repository como sitio de distribución de las actualizaciones de seguridad. Ayuda con: gestión de vulnerabilidades, gestión de SBOM, mantener fuera los componentes dañinos. Tenga en cuenta: la oferta de productos está cambiando (los nuevos clientes compran Sonatype Guide), y Lifecycle analiza lo que produjo el build en lugar de lo que descargó. CRACI frente a Sonatype

Firmware y dispositivos

ONEKEY

ONEKEY analiza firmware compilado «sin necesidad de código fuente ni de acceso a la red». Genera una SBOM a partir del binario, importa SBOM de proveedores, busca posibles zero-days como credenciales codificadas de forma fija y vuelve a analizar el firmware cada día. Su Compliance Wizard guía a los equipos por el CRA, IEC 62443-4-2, ETSI EN 303 645 y la Directiva de equipos radioeléctricos. Ayuda con: SBOM del firmware que usted no ha compilado, gestión de vulnerabilidades, comprobaciones guiadas. Tenga en cuenta: trabaja sobre la imagen después del build, así que no registra lo que descargó el build. CRACI frente a ONEKEY y alternativas a ONEKEY

Finite State

Finite State analiza firmware, binarios, código fuente y SBOM de proveedores, con compatibilidad con más de 50 arquitecturas de conjuntos de instrucciones binarias, y los reúne en un único registro de producto. Clasifica los hallazgos por alcanzabilidad e inteligencia sobre exploits, registra las decisiones VEX, y su flujo de cumplimiento abarca la asignación de controles del CRA y los informes listos para auditoría con artefactos SBOM y VEX. Ayuda con: SBOM de todos los proveedores, triaje de vulnerabilidades, evidencia. Tenga en cuenta: parte de los artefactos, así que controlar a qué puede acceder su propio build queda fuera de su alcance. CRACI frente a Finite State y alternativas a Finite State

Exein

Exein trabaja en el dispositivo. Exein Runtime utiliza eBPF para monitorizar y bloquear comportamientos maliciosos en Linux embebido, y la capa de Yocto de código abierto meta-exein incorpora el agente Pulsar a su imagen. Exein Analyzer escanea el firmware antes del lanzamiento, o su SBOM cuando el binario no está disponible, prioriza con una puntuación de alcanzabilidad y asigna los hallazgos a los requisitos del CRA. Ayuda con: gestión de vulnerabilidades sobre el terreno, SBOM del firmware, asignación al CRA. Tenga en cuenta: la capa de Yocto cambia lo que se ejecuta en el dispositivo; no ejecuta ni registra su build. CRACI frente a Exein

Plataformas de gestión del cumplimiento

Estas herramientas no generan SBOM ni escanean código. Trabajan en la mitad de gobernanza: asignar los requisitos del CRA a controles, redactar políticas y hacer el seguimiento de plazos y aprobaciones. Necesitan evidencia técnica de otras fuentes.

Venvera

Venvera es una plataforma de cumplimiento desarrollada en la UE que cubre el CRA junto con NIS2, DORA, ISO 27001 y SOC 2. Para el CRA hace el seguimiento de los plazos de notificación de 24 y 72 horas, la gestión de vulnerabilidades, la SBOM como requisito que hay que mantener, la vía de evaluación de la conformidad por clase de producto, y la documentación técnica del anexo VII y la declaración UE de conformidad. Ayuda con: asignación de controles, plazos de notificación, seguimiento del proceso de conformidad. Tenga en cuenta: comprueba que existe una SBOM y que se mantiene; la propia SBOM procede de otra herramienta.

ZeroRisk

ZeroRisk es una plataforma de cumplimiento basada en agentes que cubre el RGPD, ISO 27001, SOC 2, NIS2, DORA y el CRA. Para el CRA, su agente asigna los requisitos a su organización, rellena de antemano una evaluación de preparación, redacta los controles y las políticas que faltan y monitoriza a los proveedores presentes en sus productos, con una nueva comprobación cada 24 horas y aprobación humana de cada conclusión. Ayuda con: preparación, políticas, garantías sobre los proveedores. Tenga en cuenta: su página sobre el CRA no menciona la generación de SBOM ni la monitorización de vulnerabilidades de sus propios builds.

Notificar dentro de los plazos

El artículo 14 atribuye la notificación al fabricante, y se aplica desde el 11 de septiembre de 2026, también a los productos que ya están en el mercado. Lo que pueden hacer las herramientas es acortar el tiempo entre «esta vulnerabilidad se está explotando» y «sabemos qué productos y lanzamientos la contienen». Eso depende de inventarios por lanzamiento en los que pueda confiar, de una monitorización continua y de un vínculo entre cada artefacto distribuido y sus componentes. Anchore y Cybeats describen los plazos de notificación en su material sobre el CRA, Venvera hace el seguimiento de los plazos, y el análisis binario de ONEKEY, Finite State o Exein cubre el código de proveedores que usted no puede recompilar. La API de CRACI devuelve SBOM, trazas de red y procedencia, y CRACI envía la alerta temprana, la notificación y el informe final en nombre del fabricante.

Cómo encaja CRACI

CRACI es un runner de GitHub Actions. Para el software que usted compila, registra lo que descargó cada job, incluidos los paquetes restaurados desde cachés de CI, y genera una SBOM CycloneDX o SPDX con un estado de completitud por job y por caché. Aplica una política de egress al build, sigue reevaluando las SBOM de lo que se ha distribuido, es compatible con VEX y exporta las SBOM en CycloneDX o SPDX, vulnerabilidades incluidas, como evidencia para el CRA. Cuando hay que notificar una vulnerabilidad explotada activamente, CRACI envía en su nombre las notificaciones del CRA. Para Yocto, ejecuta BitBake en runners de hasta 32 vCPU y 96 GB de RAM y registra lo que la salida SPDX del propio Yocto deja fuera, como los paquetes del host y las URL de paquete de los crates de Rust. La vista de inventario de CRACI muestra exactamente qué versiones de software están desplegadas en qué productos, a escala global. CRACI automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro de software que las empresas necesitan para su proceso más amplio de cumplimiento del CRA.

No basta por sí solo si la mayor parte de su producto le llega de proveedores en forma de binarios, o si necesita comprobaciones guiadas frente a normas, asignación de controles y gestión de políticas, protección en el dispositivo o, hoy, sistemas de CI distintos de GitHub Actions (GitLab CI y Jenkins están en la hoja de ruta). Para los builds que son suyos, CRACI cubre la SBOM, la monitorización y las notificaciones del CRA en un solo producto; para el firmware que no puede recompilar, el análisis binario ve lo que su build nunca vio. Consulte qué es el CRA, el cumplimiento del CRA y el IoT industrial.

Herramientas de cumplimiento del CRA: preguntas frecuentes

Qué hace el software de cumplimiento del CRA y qué sigue correspondiendo al fabricante

¿Qué es el software de cumplimiento del CRA?

Software que ayuda a un fabricante a cumplir el Cyber Resilience Act. Los hay de dos tipos: herramientas técnicas que generan la SBOM, los registros de vulnerabilidades y la evidencia del build, y plataformas de gestión del cumplimiento que asignan los requisitos a controles y hacen el seguimiento de los plazos de notificación, la evaluación de riesgos y la evaluación de la conformidad. Ninguna hace que un producto cumpla por sí sola.

¿Qué obligaciones del CRA puede automatizar una herramienta?

Sobre todo la parte de gestión de vulnerabilidades: generar la SBOM, monitorizarla en busca de nuevas vulnerabilidades, encontrar los lanzamientos afectados, registrar las decisiones de triaje y VEX, preparar y enviar las notificaciones del artículo 14 y exportar evidencia para la documentación técnica. La evaluación de riesgos, el diseño seguro, la evaluación de la conformidad y la declaración de conformidad siguen siendo decisiones del fabricante.

¿Necesito una herramienta o varias?

Normalmente más de una. Una herramienta técnica le da la SBOM y la evidencia de vulnerabilidades; una plataforma de gestión del cumplimiento o un consultor cubren los controles, las políticas y la vía de conformidad. Para el firmware que recibe de proveedores en forma de binarios, el análisis binario aporta lo que su propio build no puede ver.

¿Cuál es el plazo para las notificaciones del CRA?

El artículo 14 se aplica desde el 11 de septiembre de 2026: una alerta temprana en las 24 horas siguientes a tener conocimiento de una vulnerabilidad explotada activamente, una notificación en un plazo de 72 horas y un informe final a más tardar 14 días después de que haya una corrección o mitigación disponible. Abarca los productos que ya están en el mercado. El resto del CRA se aplica desde el 11 de diciembre de 2027.

¿Envía CRACI las notificaciones del CRA?

Sí. CRACI envía la alerta temprana, la notificación y el informe final en nombre del fabricante. La obligación de notificar sigue correspondiendo al fabricante.

¿Alguna herramienta realiza la evaluación de la conformidad del CRA?

Ninguna herramienta de software la sustituye. El fabricante realiza la evaluación, mediante control interno o, para los productos importantes y críticos, con un organismo notificado o un esquema de certificación cuando el CRA lo exige. Las herramientas aportan la evidencia que utiliza la evaluación.