.png&w=3840&q=75&dpl=dpl_4WWtFHEr9P8wkcdWCGky2WYKjEiM)
Comment le Cyber Resilience Act traite-t-il les logiciels open source (FOSS) ?
Réponse directe
Les logiciels open source non commerciaux développés en dehors d'une activité commerciale échappent largement au Règlement sur la cyberrésilience. La monétisation peut changer la donne : réserver des fonctionnalités au paiement ou percevoir des dons supérieurs aux coûts de développement peut rendre le projet commercial. Un fabricant commercial qui intègre de l'open source reste pleinement responsable du produit final.
Points clés
- Le FOSS non commercial est largement hors champ (considérant 18).
- Accepter des dons modestes ne déclenche pas à lui seul un statut commercial.
- Le statut commercial peut résulter de fonctionnalités payantes, d'offres dual-license ou de dons supérieurs aux coûts.
- Les gardiens de logiciels open source relèvent d'un régime allégé et sont exemptés d'amendes (art. 24, 64).
- Le fabricant commercial est pleinement responsable des composants open source intégrés ; la responsabilité ne se transfère pas aux mainteneurs bénévoles.
La réponse complète
Le RCR exclut les logiciels open source qui ne sont pas fournis dans le cadre d'une activité commerciale : les projets réellement non commerciaux en sont donc largement exclus. La nuance tient à la monétisation : accepter des dons ne rend pas à lui seul un projet commercial, mais réserver des fonctionnalités ou mises à jour essentielles derrière un paiement, proposer une offre entreprise payante à côté d'une version communautaire gratuite, ou percevoir des dons supérieurs aux coûts de développement peut basculer le projet dans le champ commercial (art. 24).
Un rôle dédié de « gardien de logiciels open source » s'applique aux entités qui assurent un soutien durable à de l'open source à vocation commerciale ; les gardiens doivent maintenir une politique de cybersécurité et coopérer avec les autorités, mais sont exemptés d'amendes administratives (art. 64). Point crucial : lorsqu'un fabricant commercial intègre des composants open source dans un produit qu'il met sur le marché, il assume l'entière responsabilité juridique de la sécurité du produit final. La responsabilité ne peut être renvoyée en amont vers des mainteneurs bénévoles.
Comment Acuna GRC s’en charge
- Solution
RCR
Suivez chaque vulnérabilité jusqu’à sa correction, gardez la documentation technique RCR, tracez les failles exploitées et réutilisez votre travail NIS2.
- Module
Gestion des vulnérabilités
Les éléments vulnérables remontés par vos scanners, regroupés en un constat par vulnérabilité, avec un responsable et une échéance.
- Espace de travail
Comply
Les référentiels que vous choisissez, les périmètres et étiquettes qui segmentent votre organisation, la bibliothèque de mesures communes et leur correspondance entre référentiels.
Sources
- RCR article 24 (gardiens de logiciels open source)
- RCR article 64 (sanctions / exemption des gardiens)
Cette page explique les règles en termes généraux et ne constitue pas un conseil juridique.
Découvrez comment Acuna GRC le pilote.
Dites-nous vos référentiels et votre équipe. Nous vous montrons comment Acuna GRC pilote le programme.
Hébergé en Suisse, dans l'UE ou aux États-Unis