Interventions sur "éditeur"

Cet article renforce les exigences de transparence qui s'appliquent aux éditeurs de logiciels, en contraignant ces derniers à informer l'Anssi et leurs utilisateurs en cas de vulnérabilité significative ou d'incident informatique susceptibles d'affecter un de leurs produits. Le groupe Horizons et apparentés a déposé plusieurs amendements en commission et en séance afin d'apporter des précisions ou d'en demander. Ainsi, nous avons déposé un amendement, retravaillé à l'issue ...

Nous partageons l'objectif visé mais, aux termes de l'article 34, il est de la responsabilité des éditeurs de logiciels de déclarer leurs vulnérabilités. Or, ceux-ci ne sont pas habilités à apprécier l'atteinte à la sécurité nationale, qui est une prérogative de l'État. En commission, nous avons néanmoins souhaité mieux définir ce qu'est un incident informatique et préciser le caractère significatif des incidents et vulnérabilités visés, par trois amendements que nous allons examiner dans quelques in...

Si les éditeurs de logiciels libres, pardon : de logiciels – libres ou pas : peu importe – ont l'obligation de transmettre à l'Anssi les failles de sécurité qui affectent leurs produits ou les incidents qui peuvent compromettre la sécurité nationale, il serait bon qu'ils puissent être sanctionnés s'ils ne le font pas. Il est en effet probable qu'ils n'auront pas tous envie de coopérer de manière immédiate et qu...

La question qui se pose ici est celle de savoir si les éditeurs de logiciels transmettront les informations relatives aux vulnérabilités que présentent leurs propres produits, sachant, comme vient de l'expliquer notre collègue Bernalicis, que le public risque alors de se montrer peu enclin à les utiliser. Par conséquent, si l'on ne prévoit aucune sanction pour non-respect de l'obligation de signaler les failles de sécurité, le plus vraisemblable est que ces...

Les tenants de cette approche considèrent qu'il faut adopter une posture anticapitaliste vis-à-vis des éditeurs de logiciels. Elle est dogmatique, et M. Bernalicis l'a démontré lorsqu'il a évoqué, dans un lapsus, les logiciels libres. De très nombreuses failles logicielles, y compris celles qui sont intégrées dans des logiciels d'éditeurs capitalistes, si je puis dire, proviennent en fait de développements de la communauté du logiciel libre. Or on ne peut pas sanctionner, comme vous le proposez, une commu...

Je comprends la logique de ces amendements, qui soulèvent plusieurs questions, notamment celle de l'imbrication entre les logiciels libres et ceux des éditeurs commerciaux. Se pose aussi la question de la vitesse de divulgation des failles, dans la mesure où, si on ne dispose pas des correctifs, cette divulgation devient problématique, d'autant que je vous entends lorsque vous dites que l'argument de la réputation ne tient pas face aux risques pour la sécurité nationale que présenterait la révélation de failles pour lesquelles on ne dispose pas de corr...

Il ne faut oublier personne car il y va de la portée de la coercition pouvant peser sur les éditeurs de logiciels. Puisque vous avez refusé les sanctions financières pour défaut de communication d'une vulnérabilité, il faut à tous le moins que les éditeurs en informent les utilisateurs ou, à défaut, l'Anssi. Il ne faudrait donc pas que la rédaction actuelle rate la cible, et c'est la raison pour laquelle, en commission, je faisais partie de la minorité qui aurait préféré que l'on se réfère à t...

Mon intervention sera courte, car il s'agit d'un amendement très simple ayant pour objet de contraindre les éditeurs de logiciels à transmettre dans les plus brefs délais les informations nécessaires pour assurer la sécurité des données sensibles. L'amendement vise ainsi à introduire la notion d'immédiateté à l'article 34, en imposant aux éditeurs d'agir « dès que » leurs produits sont affectés ou susceptibles de l'être par une vulnérabilité significative.

Même avis défavorable, ma chère collègue, que pour votre amendement n° 1121 qui visait à rendre automatiques les mesures prévues à l'article 32. Il convient en effet de laisser de la flexibilité à l'Anssi et aux éditeurs dans leur réponse aux actes malveillants.

Il me semble que les mots « dès que » laissent de la flexibilité, étant donné qu'ils ne veulent pas dire « à la seconde où ». Cet amendement me paraît de bon sens et contenir une formulation offrant une meilleure réponse aux préoccupations de sécurité vis-à-vis des éditeurs de logiciels.

Il vise à préciser que le délai d'information fixé par l'Anssi est pris selon certains critères, en l'occurrence les risques pour la sécurité nationale, l'urgence et le temps nécessaire pour prendre les mesures correctives. L'objectif est ici d'encadrer la décision de l'Anssi, afin de garantir que le délai d'information soit fixé non pas de manière discrétionnaire selon les éditeurs, mais bien de façon cohérente en fonction de certains critères, en vue d'un égal traitement des éditeurs par l'Anssi en matière d'obligations.

En complétant les propos de notre collègue Chassaniol, je répondrai aussi à l'amendement n° 847 rectifié. Nous avons une vraie difficulté de temporalité. S'il faut en effet que l'Anssi ne traite pas les éditeurs de manière discriminatoire, ce qui suppose un encadrement, il faut aussi qu'un correctif soit apporté à chaque vulnérabilité car, dans le cas contraire, des attaquants seraient à même de s'en saisir : c'est ce que Mme Ménard soulevait en proposant l'ajout des mots « dès que ». Or, si nous avons besoin de correctifs, leur développement peut être plus ou moins long, ce qui nécessite de laisser de ...

C'est par exemple l'habitude de Microsoft. Pour proposer des logiciels à des prix moins élevés, les éditeurs font pour ainsi dire accomplir le débogage par les utilisateurs, un signalement parvenant automatiquement aux entreprises après chaque dysfonctionnement et leur permettant de prendre connaissance des failles de sécurité. Le délai d'information dont nous parlons pourrait donc être très important, car la phase de débogage peut s'étendre sur un ou deux ans. Je le répète, pour des raisons économique...

Nous restons sur le même thème. Ces amendements visent à obliger l'Anssi à enjoindre aux éditeurs de logiciels d'informer leurs utilisateurs en cas de vulnérabilité ou d'incident compromettant la sécurité de leurs systèmes d'information. Collègues, nous avons, tous, certainement, été déjà victimes de fuites de mot de passe, parfois même sans que nous en ayons été informés par les entreprises concernées. Or, aux termes du projet de loi, monsieur le ministre délégué, vous souhaitez qu'il soit...

Nous sommes ici dans un cas de figure où une faille de vulnérabilité a été constatée et, je l'espère, communiquée à l'Anssi. Celle-ci doit donc, aux termes des amendements que nous venons d'adopter, fixer un délai à l'éditeur concerné pour qu'il fournisse un correctif et informe ses utilisateurs professionnels de cette faille. Voilà où nous en sommes. Or imaginons que, patatras, l'éditeur du logiciel ne fasse pas ce que lui a demandé l'Anssi : dans ce cas, l'Agence peut, je dis bien peut, c'est-à-dire éventuellement, faire elle-même ce que l'éditeur a refusé. Eh bien non ! Si l'Anssi a demandé à l'éditeur d'informer s...

Et si l'éditeur refuse d'agir, l'Anssi doit donc le faire à sa place. C'est d'ailleurs pour cette raison que l'entreprise comprendra qu'il vaut mieux agir elle-même, plutôt que d'être tributaire d'une communication de l'Anssi. J'insiste, la possibilité d'agir à la place de l'éditeur n'est pas suffisante, surtout eu égard à ses capacités de négociation – ce qui nous fait revenir à la discussion précédente –, cel...

...équence. En commission, nous avons adopté un amendement de notre collègue Belhamiti visant à ce que le délai d'information des utilisateurs soit déterminé par l'Anssi. Et nous venons d'adopter les amendements n° 1634 et 1673 qui viennent préciser que ce délai dépend de l'urgence, des risques pour la sécurité nationale – je rappelle à nouveau que nous examinons une LPM – et du temps nécessaire aux éditeurs pour prendre les mesures correctives. Il est préférable d'apprécier concrètement ce qu'il convient de faire, en fonction de l'ampleur de l'incident et de la vulnérabilité. J'émets donc un avis défavorable sur ces amendements identiques.

Une fois de plus, votre raisonnement ne tient pas. Nous sommes dans le cas où un éditeur, après avoir été enjoint par l'Anssi d'avertir ses utilisateurs professionnels d'une vulnérabilité dans certains délais et de fournir le correctif adapté, ne le fait pas. Or si elle le lui a demandé, c'est que c'était pertinent, ou alors c'est que quelque chose ne tourne pas rond dans ma tête ou dans le raisonnement.

Mais si l'éditeur ne le fait pas ?

... au mieux contre-productive, au pire dangereuse, puisque les failles pourraient alors être exploitées. Afin d'assurer la pénalisation des entreprises qui ne signaleraient ou ne combleraient pas leurs failles, j'ai déposé un amendement après l'article 36 prévoyant que le Gouvernement remet au Parlement un rapport portant notamment sur la définition de sanctions applicables en cas de manquement des éditeurs. Nos collègues de la NUPES proposaient une amende à hauteur de 4 % du chiffre d'affaires : nous envisagions, pour notre part, une sanction proportionnelle. Un rapport nous permettra d'identifier la sanction la plus pertinente.