Todo dispositivo inteligente lleva firmware construido a partir de paquetes de c贸digo abierto, SDK de proveedores de chips y herramientas descargadas durante el build. A un ataque a la cadena de suministro le basta con uno de ellos. CRACI ejecuta sus builds de firmware, registra cada componente que entra e impide que el build llegue a nada que no necesite.
La mayor parte del c贸digo de un dispositivo conectado la escribi贸 otra persona: una distribuci贸n de Linux embebido, el paquete de soporte de placa del proveedor de chips, una pila de red, unos cientos de bibliotecas de c贸digo abierto y los crates de Rust que hay debajo. Los mismos componentes se distribuyen en productos de muchas marcas, y los dispositivos permanecen en los hogares durante a帽os, a menudo mucho despu茅s de que alguien mirara por 煤ltima vez lo que contienen.
Eso hace que un solo componente d茅bil valga mucho para un atacante. Un fallo en una biblioteca o un SDK compartidos deja expuestos todos los productos que lo distribuyen, y una versi贸n envenenada llega a todos los builds que la descargan. Estos incidentes muestran el patr贸n.
Diecinueve vulnerabilidades, de hasta CVSS 10.0, en una peque帽a biblioteca TCP/IP que los fabricantes de dispositivos llevaban a帽os licenciando, a menudo bajo otro nombre. Estaba dentro de productos de muchos proveedores, y muchos de ellos tuvieron que averiguar primero si la distribu铆an.
No se puede parchear un componente que no se sabe que se distribuye.
Los fallos en el SDK de un proveedor de chips llegaron a unos 200 modelos de dispositivos de unos 65 fabricantes: routers, c谩maras IP, pasarelas de iluminaci贸n inteligente, juguetes conectados. Una botnet Mirai los estaba buscando dos d铆as despu茅s de que se publicaran los detalles.
El c贸digo del proveedor de chips es su c贸digo en cuanto se distribuye en su dispositivo.
Se introdujo una puerta trasera en el propio proyecto upstream xz, en las versiones 5.6.0 y 5.6.1. Las im谩genes de Linux embebido incorporan como algo habitual bibliotecas de compresi贸n como xz, normalmente sin que nadie las elija.
Un proyecto de c贸digo abierto de confianza puede volverse hostil en una sola versi贸n.
Los atacantes usaron los propios certificados de firma de ASUS para firmar una versi贸n con puerta trasera de su utilidad de actualizaci贸n y la distribuyeron desde los servidores oficiales de actualizaci贸n. Kaspersky estim贸 que pudo llegar a m谩s de un mill贸n de usuarios.
Una firma v谩lida solo demuestra qui茅n firm贸, no qu茅 entr贸.
El refuerzo de los dispositivos, como el arranque seguro, la ausencia de contrase帽as por defecto y un puerto de depuraci贸n cerrado, protege el dispositivo que usted distribuye. Los pasos siguientes protegen lo que entra en 茅l.
CRACI cubre la parte de build de esta lista: la SBOM de cada build, las SBOM de proveedores, la monitorizaci贸n continua, el aislamiento de los builds, el control de egress y los controles de pol铆tica. La firma y el refuerzo de los dispositivos siguen en manos de sus propias herramientas.
Ejecute sus builds de Yocto y de otros Linux embebidos en los runners de GitHub Actions de CRACI, de hasta 32 vCPU, en x86-64 o ARM64 nativo. Mientras se ejecuta el build, CRACI registra cada paquete y archivo que descarga, incluidos los paquetes del host, las fuentes de Git, las GitHub Actions y las descargas que ninguna receta o lockfile enumera. En un build de core-image-sato, la SBOM de CRACI inclu铆a todos los componentes de la propia SBOM de Yocto m谩s 88 que esta pasaba por alto, con una URL de paquete para cada una de las 653 versiones de crates de Rust, de modo que todas pueden monitorizarse en busca de vulnerabilidades.
Cada job se ejecuta en su propia m谩quina virtual aislada bajo una pol铆tica de egress que se valida antes de que empiece el job y que, si falla, bloquea. Con una pol铆tica de denegaci贸n por defecto, el build llega a sus fuentes de paquetes y a nada m谩s. Una dependencia comprometida que intente enviar su material de firma o sus tokens al host de un atacante queda bloqueada y activa una alerta, incluso cuando el ataque es nuevo y nadie ha publicado a煤n un aviso sobre 茅l.
A帽ada las SBOM de sus proveedores de chips y de otros proveedores, y los componentes adquiridos se monitorizar谩n junto con el software que usted construye. Cuando aparezca la pr贸xima vulnerabilidad de un SDK, el c贸digo del proveedor estar谩 en el mismo registro que el suyo.
CRACI sigue reevaluando las SBOM monitorizadas a medida que se publican nuevas vulnerabilidades. El historial de builds muestra qu茅 builds conten铆an la dependencia vulnerable, directa o transitiva, y la vista de inventario muestra qu茅 versiones de software est谩n desplegadas en qu茅 productos. Los equipos de seguridad hacen el triaje de cada hallazgo y lo env铆an al equipo responsable de la correcci贸n, y un control de pol铆tica puede mantener un CVE concreto fuera de todos los builds posteriores.
El marcado CE conforme al Cyber Resilience Act se basa en la documentaci贸n t茅cnica y en una evaluaci贸n de la conformidad. CRACI aporta las evidencias de la cadena de suministro que necesita esa documentaci贸n: SBOM del build exportadas en CycloneDX o SPDX, registros de vulnerabilidades e historial de builds. CRACI tambi茅n presenta en su nombre las notificaciones de vulnerabilidades del CRA. La evaluaci贸n de la conformidad, la declaraci贸n UE de conformidad y el marcado CE siguen siendo cosa suya, como fabricante.
CRACI no firma firmware, SBOM ni procedencia, y no detecta paquetes maliciosos nuevos por comportamiento o reputaci贸n: se帽ala una versi贸n maliciosa cuando existe un aviso con un CVE y, hasta entonces, se apoya en la pol铆tica de egress. No realiza su evaluaci贸n de la conformidad ni redacta su declaraci贸n de conformidad. Hoy ejecuta jobs de GitHub Actions en runners Linux; GitLab CI, Jenkins y los runners Windows y macOS est谩n en la hoja de ruta.
Preguntas habituales sobre c贸mo proteger los dispositivos conectados y su cadena de suministro de software
Es un ataque que llega a un dispositivo a trav茅s de algo de lo que depende su fabricante y no del propio dispositivo: una biblioteca de c贸digo abierto vulnerable, el SDK de un proveedor de chips, una versi贸n de paquete envenenada, una herramienta de build comprometida o un canal de actualizaci贸n secuestrado. Como el mismo componente se distribuye en muchos productos, un solo punto d茅bil puede llegar a la vez a millones de dispositivos de muchas marcas.
Empiece por lo que distribuye: mantenga una SBOM de cada build de firmware, haga seguimiento de los componentes de proveedores y siga comprobando las versiones distribuidas a medida que aparecen nuevas vulnerabilidades. Blinde el propio build, mantenga fuera las versiones problem谩ticas conocidas con controles de pol铆tica, proteja sus claves de firma y tenga un proceso de triaje, correcci贸n y divulgaci贸n. El refuerzo de los dispositivos, como el arranque seguro y la desactivaci贸n de las contrase帽as por defecto, tambi茅n importa, pero no ayuda si el firmware ya lleva un componente vulnerable.
Conozca cada componente que entra en la imagen, incluido lo que el build descarga fuera de sus recetas y lockfiles, y conserve ese registro por versi贸n. Compile en un entorno aislado que solo pueda llegar a las fuentes que necesita, para que una dependencia maliciosa no pueda enviar sus secretos a ning煤n sitio. Monitorice los componentes registrados y las SBOM de sus proveedores frente a nuevas vulnerabilidades mientras los dispositivos tengan soporte.
S铆. Los builds de Yocto y BitBake se ejecutan en runners de CRACI, y CRACI registra la SBOM del job mientras se ejecuta el build. La salida SPDX propia de Yocto sigue conteniendo metadatos de recetas que CRACI no registra, como los parches aplicados y los CVE que una receta marca como corregidos, as铆 que mantenga create-spdx activado si depende de ellos.
S铆, cuando tenga una SBOM de ellos. Puede a帽adir SBOM de proveedores a CRACI, y esos componentes se monitorizan junto con el software que usted construye. Todo lo que su build descargue de un proveedor durante el build queda registrado tambi茅n en la SBOM del job.
No por comportamiento ni por reputaci贸n. Una versi贸n maliciosa conocida que tiene un CVE publicado, como la puerta trasera de xz, se se帽ala como cualquier otra vulnerabilidad, y un control de pol铆tica puede bloquear los builds que la contengan. Frente a ataques nuevos, la protecci贸n de CRACI es la pol铆tica de egress de denegaci贸n por defecto, que impide que el build llegue a hosts que no necesita.
No. CRACI no firma firmware, SBOM ni procedencia. Siga usando su propio proceso de firma y su almacenamiento de claves respaldado por hardware para las versiones y las actualizaciones.
El Cyber Resilience Act cubre los productos con elementos digitales introducidos en el mercado de la UE, lo que incluye la mayor铆a de los dispositivos de consumo conectados. Las obligaciones de notificaci贸n se aplican a partir del 11 de septiembre de 2026 y el reglamento se aplica en su totalidad a partir del 11 de diciembre de 2027. CRACI automatiza una parte significativa de la visibilidad de la cadena de suministro y de las evidencias que necesita el proceso del CRA; cumplir el reglamento sigue siendo un proceso del fabricante.
CRACI ejecuta jobs de GitHub Actions en runners Linux, x86-64 y ARM64, de 1 a 32 vCPU. Otros sistemas de CI, como GitLab CI y Jenkins, est谩n en la hoja de ruta, al igual que los runners Windows y macOS.
Reserve una demo y le mostraremos cada componente que descargan los builds de sus dispositivos, y cu谩les de ellos son vulnerables
Reservar una demo