Le but de ce papier est de démontrer en quoi les contrats de licence
sur les logiciels informatiques influent sur la sécurité globale
des systèmes. Aucun éditeur n'est particulièrement visé
mais les logiciels les plus diffusés sont certainement les plus concernés
par les remarques qui suivent.
Dans toute la suite le terme logiciel englobe les applications de toutes natures
ainsi que les systèmes d'exploitation.
Avez-vous déjà lu en entier un contrat de licence portant sur
un logiciel ? Plus particulièrement les sections consacrées aux
garanties ? Ces sections sont selon moi édifiantes car sans être
juriste on y comprend aisément que les éditeurs limitent soigneusement
leurs responsabilités. En effet, ils stipulent explicitement qu'ils ne
peuvent être tenus pour responsables des dommages que pourrait causer
l'utilisation de leurs produits.
De telles limitations de garanties peuvent-elles encore être considérées
comme normales voire même morales à l'heure où de plus en
plus d'éléments de notre vie sont contrôlés par des
logiciels ? Des clauses du même genre feraient sourire ou frémir
dans l'industrie automobile par exemple car si le système de freinage
ne remplissait pas sa fonction une fois sur trois, il serait facile d'imaginer
les conséquences pour le véhicule, son conducteur et aussi pour
son constructeur.
L'une des conséquences majeures des limitations de responsabilité
est selon moi une absence totale d'engagement sur la qualité des produits.
En limitant sa responsabilité vis à vis du consommateur (utilisateur
du logiciel) l'éditeur peut se contenter de standards de qualité
très faibles puisque les défauts ou défaillances des produits
ne peuvent pas lui être reprochés. En effet, l'objectif n'est plus
alors de produire la meilleure qualité logicielle possible mais plutôt
d'assurer le minimum ; ce minimum étant le plus bas niveau de qualité
acceptable par le marché. Ainsi, le consommateur choisira non plus le
meilleur produit mais le moins mauvais.
Dans le monde du logiciel on est très loin des plans d'assurance qualité
et des processus de certification tellement répandus dans l'industrie.
L'absence d'une démarche de qualité globale et la réduction
des cycles de commercialisation (time to market) conduisent à une réduction
sensible des campagnes de tests fonctionnels et à une absence quasi totale
de tests de sécurité*.
Dès lors, on ne peut s'attendre qu'à des produits peu fiables
et dont la sécurité n'a pas été évaluée.
La richesse fonctionnelle et la complexité grandissante des logiciels
rendent leur fiabilisation de plus en plus difficile. La fiabilité fait
partie des propriétés que toute démarche qualité
vise à améliorer. C'est pourquoi un engagement fort des éditeurs
me semble nécessaire afin de mettre en œuvre la rigueur et les processus
qui permettront d'améliorer la fiabilité des systèmes.
La disponibilité des systèmes repose pour beaucoup sur la fiabilité
des logiciels qui y sont installés ; on peut comprendre aisément
en quoi la dégradation de la qualité de ces derniers peut poser
des problèmes de disponibilité. Améliorer la fiabilité
des logiciels revient à œuvrer pour rendre les systèmes informatiques
globalement plus disponibles.
Le problème se pose d'une façon encore plus cruciale en ce qui
concerne les systèmes d'exploitation. En effet, il n'est pas possible
d'espérer construire un ensemble fiable si le système d'exploitation
sur lequel il repose n'offre aucune garantie de fiabilité.
Actuellement, à ma connaissance aucun éditeur n'accepte dans
ses contrats de licence de responsabilités quant à l'interopérabilité
de ses produits avec ceux d'autres éditeurs. Pourtant, rares sont les
logiciels pouvant remplir l'ensemble de leurs tâches de façon complètement
indépendante sans s'appuyer sur les fonctionnalités d'autres briques
logicielles. D'une façon générale, les systèmes
informatiques sont des ensembles complexes formés de nombreux éléments
(logiciels pour la plupart) interagissant de manière continue. Les éditeurs
des différents éléments logiciels ne garantissent donc
en aucune manière que leurs produits ont la capacité de s'intégrer
sans problèmes au sein des systèmes existants ou de remplir une
quelconque fonction dans un environnement réel.
Il est vrai que la diversité des environnements et la complexité
grandissante des systèmes déjà en place rendent des tests
d'intégration et d'interopérabilité exhaustifs difficilement
envisageable mais l'absence d'obligations fourni aux éditeurs un parapluie
au dessous duquel il est très aisé de s'abriter.
Dès lors que l'on permet à un logiciel de s'exécuter sur
une machine il faut savoir qu'on lui accorde le contrôle total de celle
ci. Cela veut dire que l'on fait confiance au logiciel pour qu'il exécute
la tâche pour laquelle il a été acheté et pas autre
chose. On lui fait aussi confiance pour exécuter sa tâche sans
mettre en danger le fonctionnement des autres programmes présents sur
la machine. Les contrats de licence tels qu'ils sont formulés actuellement
font de cette confiance un risque réel. L'utilisateur prend le risque
de compromettre sa machine en en confiant le contrôle à un programme
dont les auteurs ne garantissent pas le bon comportement. Malheureusement la
seule référence de l'utilisateur est un discours commercial car
il n'a ni la possibilité (sauf pour les logiciels open source) ni la
capacité de vérifier par lui même si sa confiance est bien
placée.
Une autre disposition intéressante des contrats de licence concerne le
reverse engineering (ingénierie à rebours ;-)). Cette pratique
qui pourrait sauver bien des situations est très souvent complètement
proscrite par les éditeurs.
Les termes des contrats de licence permettent aux éditeurs de produire des logiciels sans réel engagement de qualité, engagement pourtant nécessaire à la fourniture de produits fiables. La concurrence et le marché sont les seuls éléments qui poussent encore les éditeurs à améliorer leurs produits. Pourtant au delà de l'assurance qualité qui déjà fait défaut, un engagement sur la sécurité et une responsabilisation des éditeurs seraient les éléments clés qui pourraient rendre les logiciels plus surs.
Luc DELPHA
dernière modification 14/02/2001
* J'aborderai dans un autre article la difficulté et les spécificités
des tests de sécurité.