Le Cyber Resilience Act pour les auteurs d'intégrations et d'add-ons Home Assistant

Vous publiez une intégration Home Assistant, un dépôt HACS ou un add-on. Depuis le 11 septembre 2026, le Cyber Resilience Act européen demande à certains d'entre vous de signaler les vulnérabilités activement exploitées sous 24 h. Voici comment savoir si vous êtes concerné, ce que la plateforme attend déjà, et ce qu'il faut mettre en place cette semaine.

Êtes-vous « fabricant » ?

Le règlement s'applique à tout produit comportant des éléments numériques mis à disposition sur le marché de l'Union dans le cadre d'une activité commerciale (règlement (UE) 2024/2847, article 2, paragraphe 1, et article 3, point 1). Une intégration est un logiciel. Un add-on aussi. La seule vraie question est l'activité commerciale.

Les considérants donnent le test. Un logiciel libre et open source qui n'est pas monétisé par son fabricant est hors du règlement (considérant 18). Monétisé veut dire, en pratique : vous demandez un prix, vous vendez une version payante ou du support payant, vous acceptez des dons qui dépassent vos coûts, ou vous traitez des données personnelles au-delà de ce que la sécurité exige (considérants 18 et 19).

• Intégration custom sur HACS, écrite par un particulier, sans revenu : hors du règlement. C'est le modèle dominant ; HACS n'a aucun mécanisme de paiement. Restez ainsi pour rester dehors.
• Intégration custom avec un lien GitHub Sponsors ou Buy Me a Coffee : cela dépend des faits. Des dons qui couvrent l'hébergement et les appareils de test ne sont pas une activité commerciale (considérant 18). Un revenu régulier qui finance votre temps commence à y ressembler.
• Intégration maintenue par le fabricant d'un appareil, core ou custom : l'appareil est le produit, l'intégration en fait partie, et l'entreprise en est le fabricant (article 13). Les partenaires « Works with Home Assistant » (500 CHF par an, intégration core de niveau gold, certification CE ou FCC) sont tous ici.
• Add-on payant, ou add-on qui donne accès à un service payant : fabricant. Idem pour un add-on gratuit qu'une entreprise maintient dans le cadre de son activité.
• Nabu Casa vend les abonnements Home Assistant Cloud et recrute un ingénieur pour se préparer au CRA : fabricant pour ce qu'elle vend. HACS appartient à l'Open Home Foundation depuis 2025, le profil que l'article 24 appelle gestionnaire de logiciels open source. Ni l'une ni l'autre n'a publié de position sur le CRA.

Un installateur qui configure des intégrations pour un client est un utilisateur, pas un distributeur. Une entreprise qui forke une intégration et la diffuse sous son propre nom en devient le fabricant (article 22).

Ce qui s'applique maintenant, ce qui s'applique en 2027

« Activement exploitée » veut dire que quelqu'un utilise la faille contre de vraies installations, pas qu'un scanner l'a trouvée. Quand un avis de sécurité écrit « exploitée dans la nature » pour votre code, vos 24 h ont commencé, ou avaient commencé plus tôt si vous le saviez avant.

Les cas récents viennent du core, de l'application compagnon et d'un add-on très répandu, pas d'une intégration HACS. Frigate NVR, CVE-2026-25643 : injection de commande via la configuration go2rtc, CVSS 9.1, 6 février 2026. Frigate, CVE-2026-54652 : un compte « viewer » pouvait lire des journaux contenant des mots de passe admin, CVSS 8.1, 8 juillet 2026. Intégration Downloader du core, CVE-2025-65713 : traversée de répertoire, corrigée en 2025.8.0, 23 décembre 2025. Application compagnon, CVE-2026-44698 : exfiltration du jeton OAuth, CVSS 8.3, 29 mai 2026. Aucune CVE n'a été trouvée pour une intégration custom en 2025 ou 2026 ; le précédent est l'avis du 22 janvier 2021 qui couvrait six intégrations custom d'un coup.

Ce que la plateforme demande déjà

• Intégrations core : revue par le projet et échelle de qualité, de bronze à platinum. Les signalements de sécurité passent par GitHub Security Advisories, réponse visée sous 7 jours, embargo de 90 jours, pas de bug bounty.
• Intégrations custom : ni examinées, ni auditées, ni maintenues par le projet. HACS vérifie un manifest, un hacs.json, un dépôt actif et une release GitHub. Personne ne lit le code.
• Add-ons : publiés via un repository.yaml où le champ mainteneur est facultatif. La politique de sécurité du projet ne couvre pas les intégrations custom, et HACS n'a aucun canal de signalement central. Personne ne dépose votre signalement au titre de l'article 14 à votre place.

Quelle classe pour votre produit ?

La plupart des intégrations sont des produits « par défaut » : auto-évaluation, pas d'organisme notifié. L'annexe III liste les produits « importants » pour lesquels une évaluation par un tiers peut être exigée, sauf application d'une norme harmonisée. Deux entrées comptent ici : les produits pour maison intelligente avec fonctions de sécurité (serrures, caméras, babyphones, alarmes) et les assistants virtuels généralistes pour maison intelligente. La classe s'attache au produit vendu : un vendeur de serrures ou de caméras la porte avec l'appareil. Une intégration seule est d'abord un composant logiciel. Si votre code est le seul moyen de piloter l'appareil, lisez l'annexe III, classe I, avant de supposer l'auto-évaluation.

Cette semaine, dans l'ordre

1. Décidez votre statut avec le test de champ d'application gratuit. Huit questions, un résultat écrit avec les références d'articles. Intégration gratuite sans activité commerciale : arrêtez-vous là, et notez cette décision par écrit.
2. Publiez un contact sécurité : un SECURITY.md dans le dépôt et une politique de divulgation coordonnée d'un paragraphe. L'annexe I, partie II, point 5 l'exigera en 2027 ; aujourd'hui, c'est ce qui amène un chercheur chez vous avant le forum.
3. Écrivez la procédure 24 h / 72 h sur une page : qui surveille les avis GitHub, qui tranche « exploitée ou pas », qui dépose sur la plateforme ENISA, où est le journal.
4. Générez votre SBOM. Pour une intégration, la liste requirements épinglée du manifest.json ; pour un add-on, les paquets de l'image de conteneur. Exportez-la en fichier requirements pour que le scanner gratuit signale ce qui figure sur la liste KEV de la CISA.
5. Réglez la question de la période de support. L'article 13, paragraphe 8, demande au moins cinq ans, sauf si le produit est destiné à être utilisé moins longtemps. Écrivez la date dans votre README et, pour un appareil, sur la page produit.

Le kit génère les treize documents derrière ces étapes à partir d'un seul formulaire, en français ou en anglais : politique CVD, security.txt, procédure de signalement avec les modèles de type ENISA, déclaration de support, analyse de risque de l'annexe I, squelette de l'annexe VII. Trois d'entre eux se lisent en entier avant de payer.

Où poser vos questions

Le forum officiel a une catégorie « Share your Projects! » avec une sous-catégorie « Custom Integrations ». Ses conditions d'utilisation interdisent le spam et le contenu commercial non sollicité qui renvoie vers des sites tiers ; aucune règle écrite sur l'auto-promotion des intégrations n'a été trouvée. Aucun fil sur le CRA n'y existe encore, ni sur GitHub. Les règles du Discord et de Reddit n'ont pas pu être vérifiées. Le groupe de travail ORC de la fondation Eclipse maintient une FAQ publique sur le CRA qui couvre les questions open source.

Sources : règlement (UE) 2024/2847 tel que publié au Journal officiel ; Home Assistant Developer Docs, documentation HACS, politique de sécurité et conditions d'utilisation de Home Assistant (15 septembre 2026) ; blog Home Assistant (22 janvier 2021, 21 août 2024, 16 avril 2025) ; Works with Home Assistant (15 septembre 2026) ; offre d'emploi Nabu Casa (26 août 2026) ; OSV sur CVE-2026-25643 (6 février 2026) ; SentinelOne sur CVE-2026-54652 (juillet 2026) ; GitHub Advisory Database sur CVE-2025-65713 (23 décembre 2025) ; ZeroPath sur CVE-2026-44698 (29 mai 2026). Ce n'est pas un conseil juridique.