Vulnérabilités, contrôle export, soutenabilité : Hermine au-delà de la conformité Open Source

Entrées en application le 11 septembre 2026, les obligations de signalement du Cyber Resilience Act (CRA) imposent au fabricant qui a connaissance d’une vulnérabilité activement exploitée dans l’un de ses produits une alerte précoce sous 24 heures, une notification complète sous 72 heures, puis un rapport final dans les 14 jours qui suivent la mise à disposition d’un correctif. Le reste des obligations du règlement (dont les exigences essentielles de cybersécurité qui pèsent sur la conception même des produits) s’appliquera le 11 décembre 2027.

Ces délais ne laissent pas le temps d’enquêter (ils supposent que l’inventaire du produit soit déjà constitué et tenu à jour). Ils imposent d’avoir répondu bien en amont à une question d’apparence banale : de quoi ce produit est-il fait, d’où viennent ses composants, dans quelles conditions sont-ils utilisés, qui les maintient, et quels autres produits la même vulnérabilité affecte-t-elle ?

Porté par Enedis, inno³, Lectra, OVHcloud et RTE, le projet libre Hermine outille cette question depuis cinq ans, à partir des SBOM (software bills of materials, les inventaires de composants logiciels) et de l’analyse de conformité aux licences Open Source. L’objectif de ce billet n’est pas d’en présenter le fonctionnement dans le détail. Il s’agit plutôt de rendre compte de son extension en cours vers trois volets complémentaires : les vulnérabilités, le contrôle export et la soutenabilité des composants.

Un commun pour des infrastructures numériques maîtrisées

Pendant des années, l’analyse de conformité Open Source s’est faite à la main : tableurs de croisement entre licences et obligations, notes d’interprétation reconstruites projet après projet, arbitrages repris de zéro à chaque audit et dans chaque organisation. Ce travail était sérieux, et il n’était réutilisable par personne (chaque analyse restant prisonnière du format et du contexte dans lesquels elle avait été produite).

Hermine est l’illustration de ce que deviennent ces savoir-faire quand plusieurs organisations décident de les porter ensemble. Un SBOM y est importé, chaque composant rapproché d’un référentiel partagé, les obligations déclenchées selon le contexte réel de distribution ou d’exploitation, et un parcours de validation garde la trace de chaque arbitrage et de chaque curation. La synthèse produite en sortie réunit ainsi les seules obligations qui correspondent à l’exploitation réelle du produit et au rôle de chacune de ses dépendances, ce qui en fait un point de rencontre entre juristes, responsables conformité et responsables produit (qu’ils opèrent depuis la chaîne d’intégration continue de leur organisation ou depuis l’interface web commune).

Lancé en 2022 avec le soutien de Bpifrance, le projet bénéficie depuis 2026 d’un appui du TOSIT (The Open Source I Trust) et s’organise autour d’un comité de pilotage, d’un comité juridique qui se réunit chaque semaine et d’un comité technique. Le référentiel publié compte, en septembre 2026, 215 licences et 1 085 obligations, synchronisées automatiquement entre les instances (chaque organisation bénéficiant ainsi des curations versées par les autres). Le code est sous AGPL-3.0 et la base de connaissance sous licence ouverte : la feuille de route est arbitrée collectivement, les communs (logiciels et données) sont maintenus collectivement, et chaque organisation instancie ensuite Hermine dans son propre environnement, avec ses propres règles métier.

Quels nouveaux axes ouvrir au sein d’Hermine ?

Pensé dès l’origine pour ne pas rester cantonné aux licences, le modèle de données d’Hermine identifie, trace et qualifie chaque composant dans son contexte d’usage, et cette description forme un socle sur lequel d’autres analyses viennent se brancher.

Plusieurs capacités complémentaires sont ainsi en cours d’exploration, afin d’apporter à chaque organisation la vue la plus pertinente de son patrimoine numérique. Dans l’esprit modulaire qui caractérise les projets Open Source, chacun de ces axes est activable indépendamment, à l’échelle d’une instance, d’un produit ou d’une seule release :

• Vulnérabilités : rattachement des CVE et des identifiants EUVD (European Union Vulnerability Database) aux composants du SBOM, suivi par release, et qualification du caractère réellement applicable de chaque vulnérabilité au contexte d’usage.

• Contrôle export : qualification des composants au regard des régimes américains et européens, avec une attention particulière aux dépendances cryptographiques et aux modèles d’IA, et vérification de ce qui conditionne l’exemption Open Source, à savoir la disponibilité effective du code source et des éléments de gouvernance amont. L’identifiant d’archivage Software Heritage est intégré au parcours, ce qui permet de référencer dans un rapport la version exacte qui a été validée.

• Soutenabilité : vitalité du projet amont, financements, gouvernance, nombre de mainteneuses et de mainteneurs, éventuel archivage. Il s’agit d’éviter qu’une dépendance critique maintenue par une seule personne bénévole ne déclenche aucune alerte de sécurité et n’apparaisse sur aucun tableau de bord de conformité.

Ces premiers développements sont encourageants et confirment l’intérêt d’une approche associant un socle Open Source, des données partagées et une instanciation propre à chaque organisation, paramétrée en fonction de son environnement, de ses catégories de produits et de ses règles de conformité. La feuille de route dédiée reste néanmoins en arbitrage, et la mise en œuvre dépendra des organisations et des contributions réunies (chacun de ces volets reposant sur des sources de données et sur des expertises distinctes).

Que finance-t-on, et qu’est-ce qui est réellement maintenu ?

Une même question revient chez toutes celles et tous ceux qui financent des briques libres ou qui en dépendent, des grands comptes aux programmes publics : que finance-t-on exactement, qu’est-ce que cela expose, et qu’est-ce qui est réellement maintenu ? Un SBOM curé, des obligations qualifiées, des vulnérabilités rattachées et des indicateurs de soutenabilité permettent d’y répondre à l’échelle d’un projet comme à celle d’un portefeuille entier (à la condition que ces quatre analyses reposent sur un même inventaire, tenu à jour et partagé).

Les initiatives qui se construisent aujourd’hui autour de la résilience numérique et du financement des communs, de l’aDRI (A Digital Resilience Initiative) à EuroCommons, ont besoin de cette couche de connaissance en amont de leurs propres exigences, devenue un maillon clef de leur outillage. Hermine peut y contribuer, mais l’enjeu n’est pas qu’un outil particulier s’impose : il est que cette couche existe, soit partagée et n’ait pas à être reconstruite par chacune d’elles.

La conformité réglementaire, comme la résilience numérique, gagnerait ainsi à être traitée comme un coût partagé plutôt que comme un « avantage concurrentiel ». Chaque organisation qui refait dans son coin l’analyse de l’Apache-2.0 ou la qualification d’une dépendance cryptographique dépense de l’argent pour arriver (dans le meilleur des cas) à la conclusion de sa voisine, et le CRA s’apprête à multiplier cette dépense par le nombre d’entreprises concernées en Europe.

De là, les deux choix fondateurs du projet :

• un code sous AGPL-3.0, que chacune et chacun installe chez soi, sur son infrastructure, avec ses données, sans dépendre de personne ;
• un référentiel publié sous licence ouverte, réutilisable y compris par celles et ceux qui n’emploieront jamais l’outil, et pensé pour s’articuler aux standards existants, de SPDX à Software Heritage.

L’outillage n’est en effet qu’un moyen et non une finalité. Ce qui est visé, c’est la mutualisation d’un travail d’analyse dont la répétition ne profite à personne et dont les résultats ont vocation à circuler dans l’ensemble de l’écosystème.

Des chantiers ouverts aux contributions

Ces trois nouveaux chantiers viennent s’ajouter au socle licences (historiquement le premier volet du projet), et ils sont ouverts. Couvrir la mise en conformité globale d’une organisation suppose en effet d’articuler des dimensions techniques, juridiques, organisationnelles et économiques, et d’associer à cette construction davantage de structures, tant dans la conception que dans le développement de l’outil.

Le dépôt est hébergé sur GitLab, la documentation est publique et le référentiel est téléchargeable. Quatre façons d’y prendre part :

• utiliser : installer Hermine et le faire tourner en interne ;
• contribuer : enrichir les analyses de licences, les règles de contrôle export ou les règles de cybersécurité ;
• adhérer : rejoindre les organisations qui financent le développement et orientent la feuille de route ;
• soutenir : les financeurs de logiciels libres et les programmes qui construisent la résilience numérique européenne trouveront ici une brique déjà en production, gouvernée collectivement, et dont les résultats profitent à l’ensemble de la filière.

Quinze ans de pratique, d’analyse et d’automatisation sont déjà versés dans Hermine, quand le calendrier réglementaire, lui, ne se négocie pas. Les prochains mois serviront à arbitrer la feuille de route de ces trois axes (la priorisation dépendant directement des organisations qui s’y engageront) : toutes celles et tous ceux qui souhaitent y prendre part peuvent se manifester sur le dépôt ou venir en discuter avec l’équipe.

Hermine est un projet libre porté par Enedis, inno³, Lectra, OVHcloud et RTE, avec le soutien du TOSIT et de Bpifrance. Code sous AGPL-3.0, base de connaissance sous licence ouverte. hermine-foss.org