Forums d'entraide informatique - Astuces - Conseils

Les vulnérabilités logicielles ou applicatives sont monnaie courante, à tel point que certains ironisent en évoquant ces programmes « qui tombent en marche », et pour lesquels les fournisseurs et éditeurs refusent de ne donner aucune garantie contractuelle [i]. Pourtant, malgré les différentes sources de responsabilité reconnues par la loi (I), ceux-ci continuent trop souvent encore de rester sourds aux doléances des utilisateurs. Dès lors, la politique de la « sécurité par la transparence », qui procède de techniques de recherche de vulnérabilités dont la légalité est strictement encadrée (2), trouve auprès de l'ensemble des protagonistes (y compris les juges [2] ?) un écho favorable, sans pour autant justifier certaines pratiques de divulgation irresponsable des failles de sécurité (3).
1. Des programmes qui « tombent en marche » : quelle responsabilité légale des fournisseurs/éditeurs au regard de la qualité et de la performance de leurs logiciels
L'actualité récente a été riche en pannes informatiques [3]. Si leur origine n'a pas toujours été explicitée avec force de détails, il s'agissait cette fois encore des conséquences d'un « bug », c'est- à-dire une erreur de conception dans le produit qui impacte la
fiabilité du système (voire peut mettre en cause sa sécurité dès lors que la vulnérabilité est découverte et devient exploitable par un tiers non autorisé).
Pourtant, bien que ces dysfonctionnements deviennent de plus en plus dommageables au fur et à mesure que les systèmes d'information touchent le cœur même de l'activité de l'entreprise, on continue d'observer chez les « particuliers », usagers de ces produits, comme un « seuil de tolérance » vis-à-vis des fournisseurs/éditeurs concernés. Se protégeant derrière une clause d'exonération générale de responsabilité, les fournisseurs de solutions de sécurité et les éditeurs de programmes continuent parfois encore de travailler suivant des standards de qualité inférieurs à ceux des autres industries [4], sans être inquiétés du fait du manque de fiabilité de leurs produits et de l'insécurité logicielle qui en découle. En effet, en présence d'une clause d'exonération totale de responsabilité (c'est-à-dire que le logiciel est fourni « tel que » [5]), c'est le licencié (le cas envisagé ici étant celui du particulier utilisateur) [6] qui prend la totalité du risque quant à la qualité et aux performances du logiciel.
D'une manière générale, le recours aux clauses limitatives ou élusives de responsabilité est autorisé pour limiter la responsabilité contractuelle [7] (entre cocontractants [8]) aussi bien en France (article 1150 du code civil) qu'aux Etats- Unis [9] (Uniform Commercial Code, article 2-316 - http://www. law.cornell.ed u/ucci 2 /2-3 I 6.html ). Néanmoins, elles font l'objet de certaines restrictions

ou de préservation de la loyauté et de l'équilibre des relations commerciales. Ainsi, en droit français, plusieurs fondements légaux peuvent permettre, en principe, de faire échec aux clauses qui nous intéressent ici.
(1)Limitations de portée générale
D'abord, pour être reconnues valides, les clauses limitatives ou élusives de responsabilité doivent avoir été légalement constituées et exécutées de bonne foi [10] (articles 1134 alinéa 3 et 113 code civil). Ensuite, selon une jurisprudence constante, ces clauses sont jugées en principe valables, sauf « en cas de dol [1 1 ] ou de faute lourde [12] » de la partie qui invoque le bénéfice de la clause (Cass.Civ. l, 24 février 1993 — JCP.G.1993.11 .22166). La Cour de Cassation n'admet pas non plus la validité des clauses limitatives de responsabilité dont l'effet est de plafonner l'indemnisation à un montant trop dérisoire. Enfin, conformément à la jurisprudence dite « Chronopost » [13], les juges sanctionnent également les clauses qui, en raison du manquement du débiteur à une obligation essentielle du contrat, ont pour effet de priver l'engagement de toute portée car le contrat n'a plus alors de raison d'être.
(2)Clauses abusives dans tes contrats conclus avec un consommateur ou un « non professionnel »
Dans les contrats conclus entre professionnels et non profes- sionnels [14] ou consommateurs, sont considérées abusives et dès lors réputées « non écrites », les clauses « qui ont pour objet ou pour effet de créer, au détriment du non professionnel ou du consommateur, un déséquilibre significatif entre les droits et les
obligations des parties au contrat » (article 132-1 du Code de la consommation [ I 5]). Ainsi, en matière de contrats proposés par les éditeurs ou distributeurs de logiciels ou progiciels destinés à l'utilisation sur micro-ordinateurs [16 ] , la Commission des clauses abusives a émis une recommandation [17] par laquelle elle considère comme abusives les clauses qui excluent toute garantie sur le logiciel ou son support. Dès lors, la doctrine estime en général que « les chances de survie d'une clause limitative opposée à un consommateur sont très faibles ».
(3)Responsabilité de plein droit du fait des produits défectueux
Un autre texte, la directive du 25 juillet 1985 [18] sur la responsabilité du fait des produits défectueux, serait de nature à rendre responsable les éditeurs de programmes malgré la clause d'exonération insérée dans les contrats conclus avec des consommateurs. Il s'agit d'un texte impératif qui prévoit l'application d'un régime de responsabilité sans faute des fabricants et distributeurs dès lors qu'un produit fini cause des dommages corporels ou matériels du fait d'un défaut. Précisons qu'en application de l'arrêt C-52/00 du 25 avril 2002 de la Cour de justice des Communautés européennes, le projet de loi du 16 juin 2004 relatif à la garantie de la conformité du bien au contrat due par le vendeur au consommateur et à la responsabilité du fait des produits défectueux, prévoit une modification de certains des articles 1386-1 à 1386-18 CC. L'une de ces modifications, de caractère exclusivement technique, consiste à rétablir, conformément à la directive 85/374 susvisée, un seuil d'indemnisation des dommages

Cependant, bien que la Commission européenne ait déclaré que la directive s'appliquait aux logiciels, le champ d'application concret de ces dispositions paraît plutôt ténu en la matière. En effet, il a été précisé à l'occasion d'une réponse ministérielle [20], que « les seuls dommages dont ladite loi assure la réparation sont /es atteintes physiques à la personne et les dommages matériels causés aux biens. L'application de ce texte aux logiciels ne vise donc que les situations où ceux-ci seraient à l'origine directe d'une atteinte à la sécurité des personnes ou des biens, hypothèses pour le moins résiduelles». Or, même dans les situations où un logiciel est intégré dans un système dont dépend directement la sécurité des personnes (instruments de bord dans un avion, appareils de contrôle sur un site industriel Seveso, ...), il est vraisemblable, ainsi que le soulignent plusieurs auteurs, que les responsables de la partie logicielle pourraient invoquer le bénéfice de l'article 1386-11 dernier alinéa, qui stipule que « le producteur de la partie composante n'est pas non plus responsable s'il établit que le défaut est imputable à la conception du produit dans lequel cette partie a été incorporée ou aux instructions données par Je producteur de ce produit ».
Remarque finale : nous ne développerons pas ici le principe de garantie des vices cachés qui existe dans les contrats de vente et où les clauses limitatives de responsabilité ne sont valables qu'entre professionnels « de même spécialité ». En effet, la nature juridique des contrats de licence d'utilisation d'un logiciel nous paraît (comme à d'autres auteurs spécialistes du sujet) incompatible avec la qualification de contrat de vente et ne permettrait donc pas l'application de cette garantie [21].
En définitive, les fondements légaux existent bien, et pas seulement ceux de nature à faire échec spécifiquement aux clauses limitatives de responsabilité. Par exemple, les « consommateurs de logiciels » pourraient également agir, suivant les cas, sur le
fondement du manquement à l'obligation d'information, de la publicité mensongère [22], de l'obligation de délivrance conforme [23] ou bien encore de la tromperie [24] ... Aussi la faiblesse du contentieux tendant à faire reconnaître la responsabilité des fournisseurs/éditeurs quant à la fiabilité et la sécurité de leurs programmes ne trouve pas vraiment d'explication dans une prétendue insuffisance de la loi et serait plutôt à rechercher du côté de la difficulté de la preuve [25], du seuil de juridicité ou de l'intérêt à agir. Gageons [26] dès lors que, si elle parvient à surmonter les obstacles juridiques à son intégration dans l'ordre juridique français [27], la transposition des principes de la « class action » [28] en droit français, telle que souhaitée par le Président de la République, M. Jacques Chirac, à l'occasion de ses voeux aux forces vives le 4 janvier dernier, viendra relancer la dynamique de ces actions judiciaires...
2. Recherche et divulgation de vulnérabilités: queues    ?
On vient de l'envisager, la voie judiciaire se révèle tantôt inexploitée, tantôt difficile à faire prospérer de façon à forcer les fournisseurs/éditeurs de programmes à adopter de nouveaux standards de qualité. Aussi d'autres voies ont-elles été privilégiées, et en particulier une approche de la sécurité « par la transparence ». Cette démarche s'appuie sur la recherche (2.1) et la divulgation (2.2) de vulnérabilités, ce qui comporte là encore des risques juridiques importants et nécessite de prendre des précautions.
2.1 Recherche de vulnérabilités : à propos du « reverse légat »
D'abord, parmi les méthodes de recherche de vulnérabilités, l'audit de code occupe une place de choix, qu'il s'agisse d'analyser

Le code source d'un programme « ouvert » ou encore le code décompilé d'une application dont les sources ne sont pas disponibles. Cependant, la rétroconception de programmes ou « reverse engeneering » peut s'entendre plus largement comme « l'analyse d'un système ou d'une solution technique afin d'en retrouver les principes de conception, dans le but de résoudre une difficulté ou de développer une solution plus performante » [29]. Ainsi, procède de l'ingénierie inverse non seulement la technique d'analyse de code source et binaire (on est alors dans une approche de type « boîte blanche »), telle qu'envisagée ci- dessus, mais aussi celle dite « d'injection de fautes » (approche de type « boîte noire »), les outils de recherche du rétroconcepteur étant à la fois un désassembleur (exemple incontournable : IDA Pro de la société Datarescue [30]), un déboggeur [31] et des logiciels de surveillance système [32]. Considérant que, suivant les finalités recherchées et les contextes d'application, on peut prétendre à un recours légitime aux techniques concernées, dans quels cas peut-on ainsi « regarder à l'intérieur d'un logiciel » ?
- La décompitation à des fins d'interopérabilité
En droit français, c'est la loi du IO mai 1994 sur la protection juridique des programmes d'ordinateur qui a introduit au bénéfice de l'utilisateur un « droit » de décompilation (les guillemets semblent plutôt appropriés ici car la décompilation n'est pas en réalité autorisée de plein droit — cf art. L.122.6-1.IV. 2 du Code de la Propriété intellectuelle — CP1). Le droit de reproduire, sans l'autorisation de l'auteur [33], le code du logiciel ou « d'en traduire la forme » [34] est donc enfermé dans des limites strictement définies. En particulier, les actes de décompilation doivent avoir pour seule finalité « rinteropérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels » et ils ne doivent porter que sur les « seules parties du logiciel d'origine nécessaires à l'interopérabdité » ... L'exercice du « droit de décompilation » en dehors des limites prévues par la loi [35] est constitutif d'un acte de contrefaçon.
A l'évidence, l'audit de code décompilé (ou désassemblé) en vue de la recherche de vulnérabilités ne ressort nullement de
l'objectif imparti par le législateur. Dès lors, faut-il en conclure que la rétroconception de programmes n'est pas possible en dehors de la finalité d'interopérabilité ?
- A des fins de maintenance ou d'adaptation du logiciel : une étape potentiellement nécessaire
Sauf lorsque l'auteur s'en est réservé le droit (ce qu'il ne manque jamais de faire en pratique [36], et excepté bien sûr pour les développements obéissant au modèle du « libre » et autres modèles voisins [37]), l'utilisateur légitime d'un logiciel peut en principe, si nécessaire, « reverser » un logiciel pour les besoins de sa maintenance. Le droit (on devrait plutôt écrire ici, la « faculté ») de correction accordé à l'utilisateur par l'article L.122-6-I, (I.) CPI peut donc justifier la décompilation du code (ou son désassemblage), en vue par exemple de « déboguer » le programme ... La doctrine considère également que le droit d'adaptation peut permettre à l'utilisateur légitime de faire évoluer un logiciel (toutefois avec la même réserve pratique que pour le « droit » de correction), ce qui pourrait l'autoriser dès lors à accéder aux sources d'un logiciel, par exemple pour l'adapter à une évolution de la réglementation administrative ou fiscale et permettre ainsi que l'utilisateur continue de disposer d'une utilisation conforme à sa destination [38].
- En vertu du « droit de comprendre »
Ensuite, il existe bien, en matière de logiciel, un « droit de comprendre » les idées et principes de base qui sous-tendent n'importe quel élément d'un programme. Ce droit, qui a été reconnu en même temps que le « droit de décompilation » susvisé, est celui prévu à l'article L.122-6-I (III.) du CPI. Celui-ci confère au titulaire de la licence le droit (sans l'autorisation de l'auteur) « d'observer, d'étudier et de tester le fonctionnement » d'un logiciel.
Ce droit doit s'exercer dans la limite des opérations « de chargement, d'affichage, d'exécution, de transmission ou de stockage

La méthode d'injection de fautes, qui permet éventuellement de déduire les instructions mêmes du code d'un programme, entre-t-elle dans le champ de cette exception ? Sans doute partiellement. Ainsi la technique de « fuzzing » (on parle aussi de stress testing), utilisée lors de la recherche de vulnérabilités sur des applications en closed source, consiste, par exemple, à « générer de façon automatique, des chaînes de caractères de tailles importantes et croissantes. Ces chaînes sont ensuite utilisées pour tester différents protocoles (FTP, HTTP, SMTP, etc.) et pour permettre de découvrir rapidement si les applications testées contiennent des débordements de butter ». [39] Dans ce cas, il semble bien que les limites du droit d'observer, d'étudier et tester le fonctionnement du logiciel soient respectées et que la technique soit autorisée.
Rien n'est moins sûr dans d'autres cas : ainsi, lorsque l'opération envisagée consisterait à tenter de faire lire et exécuter au programme un type de fichier pour lequel il n'est pas conçu en principe (ex. : injecter un fichier de format vidéo sur un lecteur de fichiers audio du type MP3 [40]), le « droit de comprendre » se heurterait dans cette hypothèse à une autre limitation : l'« usage conforme » du logiciel, c'est-à-dire la destination du logiciel stipulée dans le contrat de licence. Dès lors, le droit d'observer, d'étudier et de tester le fonctionnement du logiciel ne porterait que sur les éléments non protégés par le droit d'auteur, ce qui, ramené à l'essentiel, conduisait Michel Vivant à considérer que ce texte permet simplement de « regarder ... ce qu'il est permis de voir)) [41]. En effet, il est permis de se montrer réservé sur la portée d'une telle disposition sachant d'une part, que la reprise des idées et principes d'un programme est « de libre parcours » (sauf à entrer sur le terrain des agissements parasitaires et de la concurrence déloyale) et que, d'autre part, la seule analyse, sans acte de reproduction, d'un logiciel, ne peut en elle-même être constitutive d'un acte de contrefaçon...
- En vertu du « droit à t'anatyse critique »
Comme maître Iteanu dans sa plaidoirie en faveur du prévenu « Guillermito » [42] (voir encadré Actualités), on peut déplorer néanmoins que la précédente disposition n'ait jamais reçu aucune application devant les tribunaux, car couplée avec l'exception d'analyse critique, elle pourrait conforter la défense des auteurs de la presse informatique spécialisée qui dénoncent régulièrement des défauts de sécurité de certains programmes.
Ainsi, suivant l'article L.I22-5 du CPI : « Lorsque l'oeuvre a été divulguée, l'auteur ne peut interdire
3° Sous réserve que soient clairement indiqués le nom de l'auteur et la source
a) les analyses et courtes citations justifiées par le
caractère critique, polémique, pédagogique, scientifique ou d'information de l'oeuvre à laquelle elles sont incorporées. »
Nonobstant ce droit, il est important pour le journaliste ou le pigiste faisant usage de cette liberté d'expression, de bénéficier de la protection bienveillante (et pas simplement velléitaire) d'un directeur de publication, pour se trouver encore un peu plus à l'abri de revers judiciaires à l'occasion de la divulgation de vulnérabilités exploitables (cf infra).
Actualités - L'affaire« Guillerrnito en quelques mots
En résumé : Guillaume Tena est poursuivi par l'éditeur Tegam International pour avoir rendu publique une partie du code du logiciel antivirus Viguard, une publication réalisée dans le cadre d'un test tendant à mettre en exergue des faiblesses de sécurité du programme.
Fondements de la plainte : contrefaçon par reproduction, décompilation et diffusion gratuite non autorisées.
Réquisitions du Procureur de la République à l'audience du 4 janvier 2005 : 4 mois de prison avec sursis et 6.000 euros d'amende (auxquelles s'ajoute la demande en dommages-intérêts de la partie civile, à hauteur de 900.000 euros !).
Délibéré du 8 mars 2005: 5.000 euros d'amende avec sursis et aucune inscription au casier judiciaire.
jugement suries intérêts civils du 7 juin 2005 (malgré l'appel de la décision au pénal 1*) : 14.300 euros de dommages-intérêts et frais de justice de la partie civile.
Leçon de cette affaire ?: présentée par beaucoup comme la décision qui pèsera sur l'avenir du full disciosure en France, le jugement au fond du procès Guillermito est resté sur le terrain de la contrefaçon, malgré les tentatives de la défense de déplacer le débat sur celui de la primauté de la liberté d'expression sur les droits de propriété intellectuelle. Bref, une montagne (médiatique) qui accouche d'une souris **...
(*) Selon l'adage en effet, « le perla/ tient le civil en l'état » et donc le tribunal aurait dû surseoir à statuer. A défaut, si la cour relaxe Guillermito en appel, il y aura contrariété entre le jugement sur intérêt civil et l'arrêt de la cour ; pour autant, il appartiendra à Guillermito de faire appel de la décision au civil...
(**) « Il est vrai que les conséquences sont nulles pour Guillaume Tena » (commentaire de Me Olivier Iteanu au sortir du verdict rendu le 8 mars dernier)... Sur le pénal certes, mais pas sur le plan civil ... du moins jusqu'à la décision en appel (action pendante au jour de la
présente publication) !
09/2005. - Dans une autre affaire, qui rappelle les méthodes de démonstration technique utilisées en son temps par Serge Humpich (condamné pour introduction frauduleuse dans un système et contrefaçon de cartes bancaires), un récent dépôt de plainte pour contrefaçon et escroquerie en bande organisée vise cette fois deux informaticiens qui dénoncent des « trous dans la carte Vitale » : http://news.tfl.frinews/ multimedia/0„3246224,00.html

En vue dévaluer la dangerosité et la nocivité des programmes malveillants (matwares) et rte
déterminer les moyens de les neutraliser : l'activité de recherche en sécurité informatique
Concernant plus spécifiquement le domaine de la sécurité informatique, il est courant pour les professionnels de la sécurité (éditeurs d'anti-virus, fournisseurs de solutions de détection d'intrusion, CERTs, etc.) d'avoir recours à des techniques d'audit de code pour évaluer la dangerosité et la nocivité de programmes malveillants (malwares) dont les sources ne sont pas disponibles (et dans ce cas, ils utilisent généralement la technique du désassemblage). Les finalités poursuivies sont diverses : au- delà du débogage et du développement de correctifs, on peut citer l'analyse de binaires compilés sur une machine compromise comme la neutralisation d'un programme malveillant (ver ou virus) se propageant sur un réseau [43] ... Dans ces hypothèses, il est permis de penser que les programmes concernés (exploit, virus, vers, etc.) ayant une cause illicite (permettre la commission d'une infraction pénale : accès frauduleux à un système, atteinte aux données ou encore entrave au fonctionnement d'un système), ils ne peuvent prétendre à ia protection par le droit d'auteur [44]. En pratique, on voit mal d'ailleurs l'auteur d'un programme malveillant attrait devant les tribunaux se défendre en opposant que la victime a violé ses droits d'auteurs sur le programme ! :-)
Ainsi [45], la protection des systèmes d'information contre les risques d'infection virale ou de propagation de programmes malveillants doit permettre de justifier une atteinte au droit théorique de leurs auteurs. La défense des réseaux et systèmes d'information [46] constitue, que ce soit dans un cadre professionnel ou privé, un « motif légitime » qui doit permettre de recourir aux techniques de recherche de vulnérabilités, selon les cas, soit en réaction à un incident de sécurité, soit à l'occasion d'une « anomalie » révélée au cours des opérations d'audit ou d'administration du système. Dans tous les cas, le recours à ces techniques, et notamment aux techniques d'audit de code, doit être strictement nécessaire au but poursuivi : en l'occurrence, la neutralisation ou la mitigation de risques avérés [47j et l'endiguement des effets dommageables du malware sur le système cible (atteinte au secret ou à la confidentialité, atteinte à la vie privée, etc.).
- Pour « t'inspiration » te reverse comme méthode
d'ingénierie
En dernier lieu, comme l'indique la définition citée plus haut, le « reverse engeneering » reste encore légal lorsque l'analyse du système ou de la solution technique sert à en retrouver les
principes de conception « dans le but de développer une solution plus performante ». En effet, un principe du droit d'auteur est que « les idées restent de libre parcours »... Lorsqu'elle est ainsi utilisée pour accéder à moindre frais à un savoir ou une technologie, les limites qui s'appliquent à cette forme d'« ingénierie » résident alors dans la définition de la frontière du plagiat avec la contrefaçon... Cependant, nous ne développerons pas davantage ce point qui nous éloigne de notre sujet principal, qui est la

vulnérabilités. En définitive, comme le montre le résumé ci- contre, il existe de nombreuses motivations à la rétroconception de programmes, qui sont elles-mêmes très dépendantes des différents acteurs qui vont la réaliser entreprises, particuliers, groupes de pirates ou organisations criminelles [48] De même, chacune de ces catégories de personnes peut être diversement motivée à divulguer ses résultats concernant plus particulièrement les vulnérabilités découvertes.
2.2 Divulgation de vulnérabilités
Sécurité par la transparence, oui ...
La publication des failles de sécurité dans les systèmes informatiques et des vulnérabilités logicielles ou applicatives en général, procède de ce qu'on appelle « la sécurité par la transparence » dont on admet aujourd'hui couramment qu'elle augmente davantage la sécurité desdits systèmes que la politique inverse de « sécurité par l'obscurité » (bug secrecy).
En effet, la transparence représente une incitation forte pour les éditeurs de logiciels à fournir plus rapidement des correctifs de sécurité et à adopter des méthodes de développement sécurisées de façon à conserver une bonne image de marque et améliorer la qualité de ses produits.
Surtout, à travers le partage de l'information et la diffusion des connaissances, elle tend à rétablir dans le domaine de la lutte informatique, l'équilibre entre les professionnels de la sécurité d'une part et les délinquants informatiques d'autre part (« White hats know whai black hats know » [49]).
Cette « victoire » n'est cependant pas sans connaître une rançon !
Ainsi la divulgation de failles de sécurité emporte à l'inverse certains inconvénients, au premier rang desquels on peut citer l'expansion du nombre des personnes susceptibles d'exploiter la vulnérabilité publiée, ouvrant ainsi dans la théorie du « full disclosure » exposée par Bruce Schneier [50] une « fenêtre d'opportunité » (Window of Opportunity) où le risque d'exploitation s'achève seulement après la publication et la mise en oeuvre effective du correctif ou des mesures de contournement identifiées.
De plus, la divulgation de vulnérabilités s'accompagnant souvent de la diffusion d'exploits, la diminution du niveau d'expertise et de compétence requis explique le phénomène des « script kiddies [51] »...
Néanmoins, de l'avis de nombreux professionnels de la sécurité, l'approche par la transparence est une nécessité et les exploits du type 0-day, qui permettent une exploitation silencieuse ou concomitante de la vulnérabilité par des programmes malveillants, sont pires encore que les risques de cette politique. Il n'en demeure pas moins que la démarche de publication doit s'entourer de nombreuses précautions.
... mais de manière responsable : démarche idéale
et facteurs de risque ?
En effet, le risque juridique d'une action judiciaire introduite par un fournisseur est loin d'être théorique (exemple des affaires « Guillermito » et « Serge Humpich » déjà citées), la mauvaise publicité ainsi faite autour de ses produits pouvant déterminer l'éditeur de logiciel ou le fournisseur à agir, selon les cas, en contrefaçon [52], en accès frauduleux à un système, en dénigrement de produit, en violation de confidentialité (affaire « Cisco contre Mickaël Lynn » - BH US 2005 [53]) ou encore pour fourniture de moyens de piratage (article 323-3-1 nouveau du Code pénal [54], introduit par ta LCEN)...
Dès lors, idéalement, la démarche de publication d'une vulnérabilité devrait toujours être accomplie moyennant information préalable et collaboration (bénévoles) avec l'éditeur et après la publication d'un correctif et d'un bulletin de sécurité par celui-ci.
S'éloignant plus ou moins de ce « processus idéal » [55], les autres scenarii de divulgation comprennent différents facteurs de risques qu'il convient d'envisager pour pondérer l'hypothèse d'un revers judiciaire. Parmi ces facteurs, on relèvera, de manière non exhaustive, les indices suivants
Publication de données permettant d'exploiter directement la vulnérabilité

Publication de données techniques détaillées permettant de reproduire la vulnérabilité
IM Faible/haut niveau d'expertise requis
MM Système/environnement/logiciel standard (répandu) ou plutôt exotique ou complexe
Nombre d'utilisateurs potentiellement impactés 111111 Criticité ou sévérité de la vulnérabilité
MI Publication avec/sans « solutions de contournement » (palliatifs)
/111 Publication restreinte ou au contraire très large (mesure d'audience forums/web/..., nombre de tirages presse papier)
ffl Public visé : grand public / professionnels, communauté scientifique ...
▪    Publication précédée de l'information de l'éditeur / avec
ou sans délai [56] / avec ou sans assistance t à titre gratuit ou onéreux
▪    Publication à titre individuel (« white hat ») /
professionnels (laboratoires de recherche, département R&D, presse spécialisée ...)
IM Publication par le biais d'un réseau / instance professionnelle (par l'intermédiaire d'un CERT [57] par exemple).
▪    (...)
A ce jour, conscients des différents enjeux et respectueux des intérêts de chacun, les professionnels de la sécurité comme les éditeurs semblent avoir mis en place les conditions d'une diffusion responsable de l'information, adoptant pour les uns des politiques de divulgation empreintes à la fois d'obligations de coopération et de diligence [58], et organisant, pour les autres, les moyens de communication appropriés (bulletins de sécurité, hotline sécurité, adresse mail spécifique du type secure@company.com ...).
Conclusion
Cycles de développement trop courts, insuffisance des tests, impératif marketing de lancement du produit..., l'industrie informatique a produit à ce jour des milliards de lignes de code dont une part irréductible d'erreurs (bugs) qui engendrent quotidiennement des anomalies diverses dans les traitements effectués par les utilisateurs. Pour combattre l'insécurité logicielle et inciter les fournisseurs/ éditeurs à prendre leurs responsabilités, l'adoption d'une démarche de « sécurité par la transparence » s'appuyant notamment sur les techniques d'analyse de code n'est pas la panacée, d'autant qu'elle se heurte à des contraintes juridiques importantes. Pire encore, l'écriture et la fourniture d'exploits pour faire la démonstration des vulnérabilités que l'on a identifiées, sont devenues au regard du droit l'antichambre de la cybercriminalité. Ainsi, en l'absence d'intention spécifique prévue par le législateur, la répression nouvelle des « attitudes d'amont » [59] semble faire encore plus reculer la limite de ce qui est possible de faire pour tenter de forcer les fournisseurs et éditeurs à améliorer la sécurité et la qualité de leurs produits.
En définitive, on peut affirmer que la loi ne peut être le substitut au génie logiciel (méthodes de développement sécurisé, phases de test, évaluation ...), tout au plus un « recours de la dernière chance ». De plus, le lecteur l'aura compris, la sécurité par la transparence ne doit pas être entendue comme un full disclosure radical : la divulgation se limitant à une critique non constructive et concourant à accélérer l'exploitation d'une vulnérabilité en abaissant notablement le niveau d'expertise requis est selon nous (juridiquement) inacceptable. Quant à la solution..., on peut noter que l'assurance tendrait à être désignée outre-Atlantique comme un vecteur de responsabilisation des éditeurs de logiciels, à travers l'effet conjugué de produits labellisés et de la variation des primes d'assurance. De même, l'obligation de report d'incident pour les organismes victimes et de signalement des failles de sécurité pour les éditeurs est réclamée par diverses organisations... Dans tous les cas, la solution à la problématique de la qualité et de la sécurité des logiciels n'est tout simplement pas à voie unique (et certainement pas de nature législative, le droit français étant suffisamment pourvu [60]) et nécessite l'implication de l'ensemble des acteurs dans ce domaine.