CRA et open source :
qui est responsable des composants OSS ?
Votre produit embarque des bibliothèques open source. Une CVE critique est publiée sur l’une d’elles. Qui est responsable ? Le mainteneur du projet OSS ou vous, le fabricant ? La réponse du CRA est sans ambiguïté.
C’est l’une des questions les plus débattues autour du CRA depuis son adoption : que se passe-t-il avec les composants open source ? Un fabricant qui intègre React, OpenSSL ou FreeRTOS dans son produit est-il responsable des vulnérabilités de ces bibliothèques ? La réponse est oui — avec des nuances importantes selon la nature de l’utilisation.
1. Ce que dit le CRA sur l’open source
Le CRA a fait l’objet d’intenses discussions sur le traitement de l’open source lors de son élaboration. La communauté OSS craignait que le règlement ne rende les mainteneur bénévoles responsables de la conformité CRA de tous les produits commerciaux qui utilisent leurs bibliothèques.
Le texte final a tranché clairement : les logiciels open source développés sans intention commerciale directe sont exemptés des obligations CRA. Un développeur bénévole qui maintient une bibliothèque sur GitHub n’est pas soumis au CRA.
Le considérant 18 du CRA : les logiciels open source développés ou fournis en dehors d’une activité commerciale ne devraient pas être soumis au règlement. Ce qui compte, c’est l’intention commerciale — pas le fait que le code soit publié sous licence ouverte.
2. Mais qui est responsable quand vous intégrez de l’OSS ?
L’exemption OSS s’arrête net dès que vous intégrez un composant open source dans un produit commercial. À partir de ce moment, vous devenez responsable de ce composant au sens du CRA — exactement comme si vous l’aviez développé vous-même.
C’est le principe de la chaîne de responsabilité du CRA : la conformité incombe au fabricant qui met le produit sur le marché, pas aux contributeurs des composants qu’il utilise.
| Situation | Qui est responsable CRA | Obligations |
|---|---|---|
| Mainteneur bénévole d’une lib OSS | Exempté | Aucune obligation CRA |
| Entreprise qui publie une lib OSS dans le cadre de son activité commerciale | Concernée | Obligations CRA applicables sur la lib |
| Fabricant qui intègre une lib OSS dans son produit commercial | Responsable | Toutes les obligations CRA — SBOM, CVE, notification |
| Distributeur qui revend un produit tiers avec composants OSS | Partiellement | Obligations de transparence et de notification |
3. Ce que ça implique concrètement pour votre SBOM
Le SBOM que le CRA vous impose de produire doit couvrir tous les composants de votre produit — y compris les bibliothèques open source, et y compris leurs dépendances transitives. Il n’y a pas d’exception pour les composants dont vous n’êtes pas l’auteur.
En pratique, pour un produit Node.js ou Python typique, cela représente souvent plusieurs centaines de composants dont la grande majorité sont des dépendances indirectes que vous n’avez jamais choisies explicitement.
Le piège des dépendances transitives : si votre produit utilise une bibliothèque A qui dépend d’une bibliothèque B, et qu’une CVE est publiée sur B — vous êtes concerné par le délai de notification CRA de 24h. Même si vous n’avez jamais entendu parler de B et ne l’avez jamais sélectionné vous-même.
4. La question des composants OSS sans mainteneur actif
C’est le cas le plus délicat — et le plus fréquent dans l’industrie. Une bibliothèque open source intégrée il y a 5 ans dans un firmware embarqué, dont le mainteneur a abandonné le projet, avec des CVE ouvertes non corrigées.
Le CRA ne vous dispense pas de vos obligations parce que le composant est abandonné. Vos options sont limitées mais claires :
- Remplacer le composant par une alternative maintenue — c’est la solution propre mais parfois coûteuse en termes de refactoring.
- Forker et maintenir vous-même — vous devenez le mainteneur effectif. Vous avez la maîtrise des correctifs mais vous assumez la charge de maintenance.
- Documenter et mitiger — si remplacement et fork sont impossibles à court terme, documenter l’exposition, mettre en place des mitigations compensatoires et planifier la migration. La documentation de cette décision fait partie du dossier technique CRA.
Ce que les autorités vérifieront : pas que vous n’ayez aucun composant vulnérable, mais que vous sachiez lesquels sont vulnérables, que vous ayez analysé l’impact réel et que vous gériez le risque de façon documentée et traçable.
SBOM automatisé incluant toutes les dépendances transitives, surveillance CVE en temps réel et alertes contextualisées par produit.
5. OSS commercial — le cas des entreprises qui publient de l’open source
Une subtilité importante que beaucoup d’entreprises manquent : si votre entreprise publie des composants open source dans le cadre de son activité commerciale — même gratuitement — ces composants peuvent être soumis au CRA.
Le critère déterminant n’est pas le modèle de prix mais l’intention commerciale. Publier un SDK open source pour attirer des développeurs vers votre plateforme payante, c’est une activité commerciale. Dans ce cas, le SDK peut être soumis au CRA.
6. Ce que vous devez faire maintenant
- Générer un SBOM complet incluant toutes les dépendances transitives — c’est la base. Sans inventaire exhaustif, vous ne pouvez pas connaître votre exposition réelle aux composants OSS vulnérables.
- Identifier les composants OSS sans mainteneur actif — repérez les bibliothèques dont le dernier commit date de plus de 2 ans ou dont les issues de sécurité restent ouvertes sans réponse.
- Évaluer les CVE ouvertes sur vos composants OSS — combien de CVE connues affectent des composants de vos produits ? Certaines sont peut-être non exploitables dans votre configuration, d’autres nécessitent une action immédiate.
- Documenter les décisions de maintien de composants risqués — pour chaque composant problématique que vous maintenez en production faute d’alternative, documentez le risque, les mitigations en place et le calendrier de migration prévu.
Maîtrisez vos composants OSS avant le CRA
SBOM automatisé avec dépendances transitives, corrélation CVE sur tous vos composants open source et documentation des décisions — prêt pour l’audit.