Chaque appareil intelligent embarque un firmware construit à partir de paquets open source, de SDK de fournisseurs de puces et d'outils récupérés pendant le build. Il suffit d'un seul d'entre eux pour une attaque de la chaîne d'approvisionnement. CRACI exécute vos builds de firmware, enregistre chaque composant qui y entre et empêche le build d'atteindre ce dont il n'a pas besoin.
L'essentiel du code d'un appareil connecté a été écrit par d'autres : une distribution Linux embarqué, le board support package du fournisseur de puces, une pile réseau, quelques centaines de bibliothèques open source et les crates Rust sous-jacentes. Les mêmes composants sont livrés dans les produits de nombreuses marques, et les appareils restent des années dans les foyers, souvent bien après que quelqu'un a examiné pour la dernière fois ce qu'ils contiennent.
Un seul composant faible a donc une grande valeur pour un attaquant. Une faille dans une bibliothèque ou un SDK partagés expose tous les produits qui l'embarquent, et une release empoisonnée atteint tous les builds qui la récupèrent. Les incidents suivants illustrent ce schéma.
Dix-neuf vulnérabilités, jusqu'à CVSS 10.0, dans une petite bibliothèque TCP/IP que des fabricants d'appareils utilisaient sous licence depuis des années, souvent sous un autre nom. Elle se trouvait dans les produits de nombreux fournisseurs, et beaucoup ont d'abord dû déterminer s'ils la livraient.
Vous ne pouvez pas corriger un composant dont vous ignorez qu'il est livré.
Des failles dans le SDK d'un fournisseur de puces ont touché environ 200 modèles d'appareils de quelque 65 fabricants : routeurs, caméras IP, passerelles d'éclairage connecté, jouets connectés. Un botnet Mirai les recherchait deux jours après la publication des détails.
Le code du fournisseur de puces devient le vôtre dès qu'il est livré dans votre appareil.
Une porte dérobée a été introduite dans le projet xz en amont, dans les versions 5.6.0 et 5.6.1. Les images Linux embarqué intègrent systématiquement des bibliothèques de compression comme xz, généralement sans que personne ne les ait choisies.
Un logiciel open source de confiance peut devenir hostile en une seule release.
Des attaquants ont utilisé les propres certificats de signature d'ASUS pour signer une version piégée de son utilitaire de mise à jour et l'ont distribuée depuis les serveurs de mise à jour officiels. Kaspersky a estimé qu'elle avait pu atteindre plus d'un million d'utilisateurs.
Une signature valide prouve seulement qui a signé, pas ce qui a été inclus.
Le durcissement de l'appareil, comme le secure boot, l'absence de mots de passe par défaut et un port de débogage fermé, protège l'appareil que vous livrez. Les étapes ci-dessous protègent ce qui y entre.
CRACI couvre le volet build de cette liste : la SBOM de chaque build, les SBOM de fournisseurs, la surveillance continue, l'isolation du build, le contrôle du trafic sortant et les garde-fous de politique. La signature et le durcissement de l'appareil restent assurés par vos propres outils.
Exécutez vos builds Yocto et autres builds Linux embarqué sur les runners GitHub Actions de CRACI, jusqu'à 32 vCPU, en x86-64 ou en ARM64 natif. Pendant le build, CRACI enregistre chaque paquet et fichier récupéré, y compris les paquets de l'hôte, les sources Git, les GitHub Actions et les téléchargements qu'aucune recette ni aucun lockfile ne liste. Sur un build core-image-sato, la SBOM de CRACI contenait tous les composants de la SBOM de Yocto, plus 88 que celle-ci avait manqués, avec une package URL pour chacune des 653 versions de crates Rust : toutes peuvent donc être surveillées face aux vulnérabilités.
Chaque job s'exécute dans sa propre machine virtuelle isolée, sous une politique de trafic sortant validée avant le démarrage du job et qui bloque tout en cas d'échec. Avec une politique en refus par défaut, le build atteint vos sources de paquets et rien d'autre. Une dépendance compromise qui tente d'envoyer vos éléments de signature ou vos tokens vers l'hôte d'un attaquant est bloquée et déclenche une alerte, même si l'attaque est nouvelle et que personne n'a encore publié d'avis de sécurité à son sujet.
Ajoutez les SBOM de vos fournisseurs de puces et autres fournisseurs : les composants achetés sont surveillés en même temps que les logiciels que vous construisez. Quand la prochaine vulnérabilité de SDK surviendra, le code du fournisseur sera dans le même enregistrement que le vôtre.
CRACI continue de réévaluer les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées. L'historique des builds montre quels builds contenaient la dépendance vulnérable, directe ou transitive, et la vue d'inventaire montre quelles versions logicielles sont déployées sur quels produits. Les équipes de sécurité trient chaque résultat et l'acheminent vers l'équipe responsable de la correction, et un garde-fou de politique peut tenir une CVE précise à l'écart de tous les builds suivants.
Le marquage CE au titre du Cyber Resilience Act repose sur une documentation technique et une évaluation de la conformité. CRACI fournit les preuves sur la chaîne d'approvisionnement dont cette documentation a besoin : SBOM au build exportées en CycloneDX ou SPDX, enregistrements de vulnérabilités et historique des builds. CRACI soumet aussi les notifications de vulnérabilités CRA en votre nom. L'évaluation de la conformité, la déclaration UE de conformité et le marquage CE restent de votre responsabilité, en tant que fabricant.
CRACI ne signe ni le firmware, ni les SBOM, ni la provenance, et il ne détecte pas les nouveaux paquets malveillants par comportement ou réputation : il signale une release malveillante dès qu'un avis de sécurité avec une CVE existe, et s'appuie jusque-là sur la politique de trafic sortant. Il ne réalise pas votre évaluation de la conformité et ne rédige pas votre déclaration de conformité. Il exécute aujourd'hui des jobs GitHub Actions sur des runners Linux ; GitLab CI, Jenkins et les runners Windows et macOS figurent sur la roadmap.
Questions fréquentes sur la sécurisation des appareils connectés et de leur chaîne d'approvisionnement logicielle
C'est une attaque qui atteint un appareil par un élément sur lequel son fabricant s'appuie plutôt que par l'appareil lui-même : une bibliothèque open source vulnérable, le SDK d'un fournisseur de puces, une release de paquet empoisonnée, un outil de build compromis ou un canal de mise à jour détourné. Comme le même composant est livré dans de nombreux produits, une seule faiblesse peut atteindre à la fois des millions d'appareils de nombreuses marques.
Commencez par ce que vous livrez : conservez une SBOM pour chaque build de firmware, suivez les composants des fournisseurs et continuez à vérifier les versions livrées à mesure que de nouvelles vulnérabilités apparaissent. Verrouillez le build lui-même, tenez à l'écart les versions réputées dangereuses avec des garde-fous de politique, protégez vos clés de signature et mettez en place un processus de tri, de correction et de divulgation. Le durcissement de l'appareil, comme le secure boot et la désactivation des mots de passe par défaut, compte aussi, mais il n'aide pas si le firmware contient déjà un composant vulnérable.
Connaissez chaque composant qui entre dans l'image, y compris ce que le build récupère hors de vos recettes et lockfiles, et conservez cet enregistrement par release. Construisez dans un environnement isolé qui ne peut atteindre que les sources dont il a besoin : une dépendance malveillante ne pourra alors envoyer vos secrets nulle part. Surveillez les composants enregistrés et les SBOM de vos fournisseurs face aux nouvelles vulnérabilités aussi longtemps que les appareils sont pris en charge.
Oui. Les builds Yocto et BitBake s'exécutent sur les runners CRACI, et CRACI enregistre la SBOM du job pendant le build. La sortie SPDX de Yocto contient toujours des métadonnées de recette que CRACI n'enregistre pas, comme les correctifs appliqués et les CVE qu'une recette marque comme corrigées : gardez donc create-spdx activé si vous en dépendez.
Oui, si vous disposez d'une SBOM pour ces SDK. Vous pouvez ajouter des SBOM de fournisseurs à CRACI, et ces composants sont surveillés en même temps que les logiciels que vous construisez. Tout ce que votre build télécharge auprès d'un fournisseur pendant le build est également enregistré dans la SBOM du job.
Pas par comportement ni par réputation. Une release malveillante connue dotée d'une CVE publiée, comme la porte dérobée xz, est signalée comme toute autre vulnérabilité, et un garde-fou de politique peut bloquer les builds qui la contiennent. Contre les nouvelles attaques, la protection de CRACI est la politique de trafic sortant en refus par défaut, qui empêche le build d'atteindre des hôtes dont il n'a pas besoin.
Non. CRACI ne signe ni le firmware, ni les SBOM, ni la provenance. Continuez à utiliser votre propre processus de signature et un stockage matériel des clés pour les releases et les mises à jour.
Le Cyber Resilience Act couvre les produits comportant des éléments numériques mis sur le marché de l'UE, ce qui inclut la plupart des appareils grand public connectés. Les obligations de déclaration s'appliquent à partir du 11 septembre 2026 et le règlement s'applique intégralement à partir du 11 décembre 2027. CRACI automatise une part importante de la visibilité et des preuves sur la chaîne d'approvisionnement dont le processus CRA a besoin ; le respect du règlement relève du processus du fabricant.
CRACI exécute des jobs GitHub Actions sur des runners Linux, x86-64 et ARM64, de 1 à 32 vCPU. D'autres systèmes CI, comme GitLab CI et Jenkins, figurent sur la roadmap, tout comme les runners Windows et macOS.
Réservez une démo et nous vous montrerons chaque composant récupéré par les builds de vos appareils, et lesquels sont vulnérables
Réserver une démo