Le Cyber Resilience Act - de la contrainte réglementaire à l'opportunité stratégique pour l'Open Source?

Le 6 novembre dernier, à l'occasion du Redhat Summit, j'ai eu le plaisir de présenter, aux côtés de mon confrère Benjamin Jean du cabinet inno³, une session intitulée « CRA & Open Source : de l’obligation de conformité à l’opportunité stratégique ». Notre objectif était simple : décortiquer ce nouveau règlement majeur pour montrer qu'au-delà de la contrainte - certes réelle et disruptive pour certains membres de notre écosystème, le Cyber Resilience Act (CRA) pourrait devenir un catalyseur pour la maturation de notre écosystème Open Source.

Pourquoi une nouvelle réglementation ?

Pour commencer, nous avons rappelé le contexte (diapositive 7) : le CRA s'inscrit dans une démarche réglementaire plus large de l'Union européenne visant à sécuriser son marché intérieur numérique, dans la lignée de textes comme NIS, Cybersecurity Act ou NIS 2. L'objectif est clair : renforcer la sécurité des produits numériques, matériels comme logiciels, pour protéger consommateurs et entreprises.

Publié le 20 novembre 2024, ce texte nous accorde une période d'adaptation de 36 mois, portant son application complète au 11 décembre 2027. Sa grande nouveauté, et la raison de notre intervention, est qu'il s'agit du premier règlement européen à adresser directement et spécifiquement le cas des logiciels Open Source.

L'Open Source et la complexité de la "Supply Chain" logicielle

Pour comprendre l'impact du CRA, il est indispensable de saisir la nature de la chaîne d'approvisionnement logicielle. C'est un point que nous avons illustré à l'aide des diapositives 9 à 14. Un logiciel moderne n'est pas un bloc monolithique, mais un assemblage de multiples composants :

• Des bibliothèques et frameworks qui forment le socle technique.
• Des briques d'infrastructure qui assurent des fonctions essentielles.
• Le code applicatif propre à l'éditeur, qui n'est souvent que la partie visible de l'iceberg.

Cette complexité est souvent invisible pour le client final et, il faut l'avouer, parfois même pour l'éditeur, qui n'a pas toujours une vision exhaustive des dépendances "transitives" (les dépendances de ses dépendances).

Cette situation a déjà mené à des incidents de sécurité que nous connaissons tous (Heartbleed, Log4Shell, faille XZ), où des composants massivement utilisés mais faiblement soutenus sont devenus des vecteurs d'attaque. Nous avons insisté sur un point qui nous semble crucial, parfaitement résumé par la citation du mainteneur Thomas Depierre : « I am not your supplier ». Contrairement à une chaîne logistique classique, il n'existe pas de relation contractuelle entre les mainteneurs de projets Open Source et leurs utilisateurs. Les failles de sécurité sont donc moins des "attaques" que les conséquences de problèmes de maintenance.

Quelles sont les nouvelles obligations du CRA ?

Le CRA vient donc imposer un cadre et des responsabilités claires. Comme détaillé dans nos diapositives 19, 20 et 22, le règlement définit plusieurs rôles :

1. Le Fabricant : Celui qui commercialise un produit sous son nom. Il doit appliquer les procédures de conformité, maintenir un SBOM (Software Bill of Materials), et gérer les vulnérabilités sur une période d'au moins 5 ans.
2. Le Distributeur : Il doit s'assurer que le produit est conforme et coopérer en cas de risque.
3. L'Intendant de logiciels ouverts (Open Source Steward) : Un nouveau rôle pour les entités gérant des projets Open Source non commerciaux. Il doit mettre en place une politique de cybersécurité et traiter les vulnérabilités.

L'exception Open Source protéger l'innovation

Le règlement n'a heureusement pas pour but de freiner l'innovation. Comme nous l'avons expliqué (diapositive 26), le CRA introduit une distinction fondamentale entre les activités commerciales et non commerciales. Seuls les produits distribués dans un cadre commercial sont soumis aux obligations des fabricants.

Un même logiciel peut donc exister sous deux formes :

• Une version Open Source non commercialisée, qui relève du statut d'« Open Source Steward ».
• Une version commercialisée par une entreprise comme la mienne, qui sera alors considérée comme « fabricant ».

Cette distinction est essentielle : elle protège le développement communautaire tout en responsabilisant les acteurs économiques qui en tirent profit.

De la conformité à la stratégie notre vision

L'obligation de produire un SBOM et de connaître ses dépendances nous force à transformer notre approche. La diapositive 28 schématise l'évolution que nous appelons de nos vœux :

1. Passer de l'Open Source subi (l'utilisation non maîtrisée)
2. À l'Open Source maîtrisé (le minimum imposé par le CRA),
3. Pour enfin atteindre l'Open Source décidé : une posture où nous ne sommes plus de simples consommateurs, mais des acteurs proactifs. Nous nous engageons stratégiquement, nous contribuons aux projets dont nos produits dépendent et nous bénéficions en retour de la mutualisation des efforts.

Comme nous l'avons souligné (diapositive 23), cette transformation doit être à la fois interne (politiques de conformité, stratégie cyber) et externe (contrats, contribution upstream).

Conclusion

Pour conclure, le message que Benjamin et moi avons souhaité faire passer est le suivant : le Cyber Resilience Act est en passe d'entrer en vigueur. Qu'il s'agisse d'un fardeau administratif reste indéniable, mais pour rester positifs et regarder vers l'avant, il faut le considérer comme une incitation puissante à une meilleure hygiène numérique pour les entreprises qui intègrent des composants Open Source. En nous obligeant à une transparence totale sur nos composants, le CRA nous pousse, nous acteurs du numérique ouvert, à devenir des citoyens encore plus responsables de l'écosystème.