Par Alois Reitbauer, Chief Technology Strategist chez Dynatrace
Le projet de loi européenne sur la cyberrésilience (CRA – Cyber-Resilience Act), soutenu par les députés européens en juillet dernier, vise à réduire le risque de piratages et d’attaques malveillantes des équipements informatiques des citoyens européens. Ainsi, le CRA prévoit de rendre obligatoire la mise en œuvre des bonnes pratiques en matière de sécurité dans l’ensemble du secteur tech européen. Il imposera notamment des normes minimales de sécurité pour les produits technologiques destinés aux utilisateurs finaux vendus dans toute l’UE, tels que les appareils d’IoT, les ordinateurs de bureau ou encore les smartphones.
Pour
atteindre ses objectifs, le CRA doit également appliquer ces normes aux
logiciels et au matériel qui composent les chaînes d’approvisionnement à
l’origine des produits destinés aux utilisateurs finaux. Au-delà des solutions
commerciales, le CRA cherche également à appliquer ces normes de sécurité
stricte aux projets open source non commerciaux. Ce qui exposerait des dizaines
de milliers de contributeurs open source à des poursuites judiciaires et
nuirait considérablement au secteur tech européen. Les législateurs derrière le
projet de loi CRA doivent revoir de toute urgence la manière dont ils
considèrent les logiciels open source.
Pourquoi
le CRA menace l’open source
Le
CRA vise à imposer des obligations légales aux organisations pour garantir que
les produits et services qu’elles vendent au public soient suffisamment
sécurisés. Les organisations doivent donc s’assurer que leurs produits
répondent aux normes fixées en matière de reporting, de documentation,
d’évaluation des risques, ainsi que de correctifs de sécurité et de monitoring
après leur mise sur le marché. Les organisations qui ne s’y conforment pas
risquent, en plus de devoir payer des amendes, d’être tenues responsables, à
terme, d’incidents de sécurité.
Pour
que cela fonctionne dans la pratique, le CRA doit étendre ce régime à la chaîne
d’approvisionnement logicielle, c’est-à-dire aux fournisseurs et aux
développeurs qui distribuent des logiciels réutilisés pour les produits
destinés aux utilisateurs finaux. Tous les logiciels qui sont expédiés dans
l’Union européenne doivent être auto-certifiés par les développeurs comme étant
conformes aux normes de sécurité fixées par le CRA. Or, une grande partie de la
chaîne d’approvisionnement logicielle est constituée de logiciels open source
(OSS). On estime ainsi que plus de 97% de toutes les applications incluraient
du code open source. Et c’est là que le bât blesse : en l’état actuel du projet
de loi, les communautés qui maintiennent des projets open source doivent
appliquer les mêmes normes de sécurité à leur travail que les entreprises qui
vendent des solutions commerciales. On peut donc craindre qu’elles soient
légalement tenues responsables de tout incident de sécurité en aval qui
résulterait de problèmes liés à leur code.
Les
communautés open source sont non commerciales et n’existent que sur la base de
contributions volontaires. Très peu disposent donc des ressources nécessaires
pour garantir que leur code puisse être auto-certifié dans le cadre du CRA. Les
communautés et les contributeurs open source européens encourent donc le risque
soit de devoir cesser leurs opérations, soit d’être soumis à des actions
légales auxquelles ils n’ont pas les moyens financiers de faire face. Les
logiciels open source constituant le moteur de toute l’industrie technologique,
du fait de leur utilisation largement répandue, cela porterait un coup dur à
l’ensemble de l’écosystème tech européen.
Comment
rendre le CRA compatible avec les logiciels open source
L’objectif
du CRA est louable : mettre en place des garanties de base en matière de
sécurité pour les logiciels et les appareils avec lesquels nous interagissons
quotidiennement. Et il est encore possible d’atteindre cet objectif tout en
s’assurant que les communautés et les projets open source puissent continuer à
innover.
Le
problème vient du fait que, dans sa version actuelle, le CRA considère les
logiciels open source comme des solutions interchangeables avec les
alternatives commerciales. Mais cela ne reflète en rien la réalité : les
logiciels open source, dont l’utilisation est gratuite, sont rarement offerts
comme des solutions complètes. Ils constituent simplement un élément ou un
composant d’une offre plus large. Le CRA devrait donc considérer le code open
source comme un bien public, au même titre que l’air pur ou les bandes radio.
Au
lieu de chercher à réguler les projets et les communautés open source, le CRA
devrait confier la responsabilité de la sécurité aux entités commerciales qui
utilisent ce code dans les produits et services qu’elles fournissent à leurs
clients. Ainsi, la responsabilité incomberait aux entités commerciales de
s’assurer qu’elles comprennent les risques et qu’elles prennent les mesures
nécessaires pour renforcer la sécurité des produits qu’elles mettent sur le
marché. Pour cela, les organisations devraient pouvoir démontrer trois
capacités clés pour assurer la sécurité de leurs composants open source :
1. Une analyse des vulnérabilités au runtime – autrement dit, un
monitoring en continu pour détecter les vulnérabilités dans un produit et ses
composants, dès qu’elles sont introduites – à la fois dans le code sur-mesure
et le code open source. Les équipes de sécurité et de développement doivent être
capables de comprendre instantanément l’impact potentiel de toute vulnérabilité
détectée et disposer des informations nécessaires pour le résoudre rapidement,
avant que l’intégrité de leurs applications et de leurs données soit
compromise.
2.
Un durcissement des applications – via un audit des produits pour détecter leur
exposition aux principales menaces de sécurité ciblant des vulnérabilités
critiques, telles que les injections SQL et de commandes, en utilisant les
listes de menaces établies par le secteur, comme l’Open Worldwide Application
Security Project (OWASP). Les organisations doivent être capables de détecter
quand ces attaques se produisent et les bloquer avant qu’elles puissent faire
des dégâts.
3.
L’automatisation de la sécurité – en établissant des workflows automatisés pour
détecter, corriger et résoudre les incidents de sécurité ou les vulnérabilités
– pour les composants open source et au-delà. Cela permet de raccourcir les
délais de résolution et de réduire l’exposition des produits et des services à
des vulnérabilités critiques.
Et
si le CRA pouvait dynamiser l’open source européen ?
Si
ces normes étaient incluses dans le CRA, cette loi pourrait, à terme, devenir
un atout pour le développement de logiciels open source. Plutôt que de
décourager la participation à des projets open source, l’application par le CRA
d’une utilisation responsable de celui-ci pourrait inciter les organisations
responsables à investir dans la cartographie, la reconnaissance et le
renforcement des composants open source qu’elles utilisent dans leurs produits.
Cet investissement commercial accru se répercuterait inévitablement sur l’écosystème open source dans son ensemble, et se traduirait, sur le long terme, par davantage de ressources dédiées à la maintenance et à la mise à jour des projets. Les bénéfices pourraient être extraordinaires, en augmentant considérablement le rythme de l’innovation logicielle partout en Europe. Mieux encore, ces exigences garantiraient un écosystème open source plus sécurisé en Europe et au-delà. Et un objectif d’autant mieux atteint pour le CRA : une meilleure sécurité des produits et des services technologiques pour les citoyens européens.