L'actualité récente a mis un coup de projecteur dans la gueule de l'industrie du logiciel en général et dans celle de Microsoft en particulier. Accusation récurrente : vos logiciels ne sont pas sûrs, bourrés de bugs et pleins de trucs qui servent à rien ! Alors avoue charogne : pourquoi ?
ZipiZ veut apporter ces 2,80 F à un début de tentative d'explication embryonnaire.
Eh oui, m'sieur l'inspecteur, belle découverte que celle-là. L'industrie du logiciel est
en effet globalement, comme l'écrivait Libé, immature, impatiente et arrogante . Ces
"qualités" ne sont hélas pas l'apanage de la maison Billou. Il serait temps de s'apercevoir que l'objectif d'un éditeur de logiciels quel qu'il soit n'est pas de vendre des logiciels sans défaut, ce qui est
d'ailleurs dans la logique économique actuelle
pratiquement impossible et pas forcément nécessaire.
Dans le référentiel mis en place pour le développement d'un produit l'axe contraignant est le temps, pas la qualité. Le temps est toujours la dimension privilégiée par les outils de gestion de projet. D'ailleurs, pas folles les guêpes, aucun éditeur ne s'engage ni sur la perfection de ses
produits ni sur les dommages potentiellement occasionnés par les défauts de ceux-ci.. Et pour cause ! Si vous avez un doute à ce sujet, laissez tomber le décryptage des buzzwords marketing et relisez attentivement vos contrats d'utilisation.
On peut le regretter mais il a toujours été "convenable", "admis", "courant" de vendre à des clients le droit d'utiliser des logiciels comportant un nombre plus ou moins important de défauts.
Dans leur vie numérique, les produits passent par différents états de correction avant d'être
"lâchés dans le champ" comme un poulet ayant atteint la taille requise quand l'éditeur décide que le nombre d'erreurs résiduelles estimé n'empêche pas de le vendre (même quand parfois ces erreurs l'empêchent de fonctionner - si, si ça s'est vu).
Paradoxalement la correction ultérieure des erreurs donne lieu à des revenus supplémentaires par la vente de nouvelles versions. Alors pourquoi viser l'inaccessible perfection chronophage lorsque les défauts sont
eux-mêmes une source de profit. Faudrait être un petit peu con, non ? L'interrogation qui subsiste après ce constat est : saperlotte, la qualité d'un
logiciel ça vient d'où, donc ?
Mettons les deux pieds dans le plat du jour, et jetons nous à l'eau du bain avec le bébé : la qualité des logiciels est très liée à la qualité des développeurs. Eh oui !
Étonnant non ?
Je m'explique. Tous les développeurs produisent des erreurs en même temps que du code. C'est inévitable. Chez pratiquement tous les éditeurs, ce sont le développeurs qui réalisent les tests unitaires de ce qu'ils ont produit. Certains le font bien, d'autres mal. Pour certains (beaucoup ?) d'entre eux, la compilation sans erreur du code est l'objectif majeur qu'ils se sont fixés (quitte à enlever toute directive de contrôle gênante) et une garantie suffisante de son bon fonctionnement . Ils savent bien entendu que c'est faux mais, par une curieuse facétie de la nature, le développeur développe en même temps que du
code un sixième sens lui permettant de sentir les lignes où se trouvent les dysfonctionnements de ce qu'il vient d'écrire. Un septième sens extrêmement bienvenu lui permet d'éviter soigneusement de tester ces parties malades du code.
Le développeur a donc ce don très particulier de ne tester que ce qui fonctionne et de faire l'impasse sur ce qui pourrait planter. Lorsque les équipes de développement dépassent plusieurs dizaines voire centaines de têtes, cette capacité à fuir ses erreurs prend une dimension nettement multiplicative et il devient donc impossible, avec une telle
hétérogénéité de codeurs, de garantir la qualité et l'homogénéité du code (il suffit pour le mesurer d'observer la diversité des règles de
nommage dans les API Microsoft).
Les ingénieurs de l'assurance qualité (QA) n'interviennent pas à la sortie du code mais le plus souvent beaucoup plus
loin ; une fois l'intégration du produit réalisé. Il est inévitable que de nombreux bugs résiduels passent au travers de ces tests en bout de chaîne. Les tests réalisés par les outils du QA simulent le comportement des utilisateurs du produit. Ils mesurent donc la résistance à la charge (stress test), la réponse attendue aux fonctions demandées (tests fonctionnels), l'impact des modifications (non régression) etc... Ils ne pourront placer le programme dans toutes les situations possibles et a fortiori modéliser des comportements intentionnellement malicieux attaquant les probables défaillances des programmeurs. Typiquement, toutes les failles de
buffer overflow relève d'un problème de programmation, le contrôle de la taille de ce qui est attendu en entrée et les attaques en denial of service exploitent très souvent des fuites de mémoire générées par un
"oubli" de libérer des ressources ou de fermer des sessions. Des fautes typiques de programmation.
Il est bien sûr possible de mettre en place une structure pour limiter à la sortie du code le passage de ces erreurs dans le produit. Mais la revue de programme représente un coût important en ressources humaines et en temps. Et toute mesure organisationnelle retardant la sortie d'une version d'un produit a très peu de chance de survie dans l'industrie du quick and dirty.
En ce qui concerne les défauts de sécurité des produits, là aussi, c'est, dans la logique de développement, inévitable. On vient de le dire, les développeurs écrivent du code pour qu'il compile et si possible exécute les fonctions déterminées par le program management..
Dans une architecture où les programmes applicatifs reposent sur des couches intermédiaires (transport, routage, middleware, serveur etc...), ce qui est notamment le cas de toutes les applications
"internet", l'assurance qualité n'adressera par script que les couches supérieures de l'épiderme applicatif et dans les fonctions prévues du produit.
Quelle entreprise perdrait du temps et de l'argent dans l'exploration de toutes les interfaces de son produit avec les couches
qu'elle n'a pas elle-même codées et que le logiciel doit utiliser (OS, réseau, middleware, service) ou dans les utilisations
"détournées" de son produit ?
Chaque couche logicielle doit accorder une certaine confiance à l'interface qu'elle sollicite. Il est donc relativement simple d'abuser les routines généralistes des OS, d'acquérir des privilèges indus et d'utiliser des services accessibles à tous (serveurs
SMTP, WEB, FTP etc...) pour obtenir des données normalement protégées.
Les hackers ont beau jeu d'aller taper là où ça fera forcément mal : en développant des programmes pour titiller les profondeurs du code, en forgeant des trames impossibles à générer en utilisation
"normale", en introduisant du code interprétable dans des requêtes SQL ou en telnettant directement des services pour leur parler du pays dans une langue inconnue.
Qui plus est, la logique sécuritaire voudrait que les logiciels et donc chaque module du produit soient conçus pour ne pas fonctionner dans un certains nombre de cas. C'est un processus antinomique de l'activité même de production d'un programme. Voire incompatible avec tout process créatif. Imaginez, la conception des bagnoles sur un modèle de
"spécifications négatives" (voilà ce que vous ne devez pas pouvoir faire avec une voiture)... On ne verrait que des Ladas sur les routes.
Il y a cependant un domaine où la sécurité est délibérément "allégée" par l'éditeur. Les programmes d'installation de système d'exploitation, de bases de données, d'applicatifs. Un éditeur qui délivrerait un système en mode paranoïaque, inutilisable
"out of the box" se grillerait complètement auprès de ses clients. Personne n'a envie d'affronter les
"ça pas marche" d'une grande partie des utilisateurs qui veulent voir leur bouzin tourner un quart d'heure après avoir déballé le CD sans se taper l'équivalent de
"Guerre et Paix" en consignes d'installation. C'est pour cette raison que, par exemple, sous Windows NT les accès sur les ressources sont par défaut ouverts à
"everyone". Mais là encore Microsoft n'a pas l'exclusivité : observez les distribs Linux et leurs
installations "bourrins" ou n'importe quelle base de données et ses mots de passes administrateurs, ces utilisateurs par défaut jamais changés etc.
Toute l'industrie informatique s'est développée sur un mode de confiance relative en l'utilisateur. Tous les protocoles du net sont architecturés pour permette la communication, pas pour l'empêcher. Les équipes de développement dans le confort de leurs open spaces baignent toujours dans
cette culture du faisable et du possible.
L'industrie du logiciel n'est pas encore prête à changer de paradigme et à basculer dans les déclinaisons de la méfiance.
Immature par composition, impatiente par nécessité et arrogante par nature... Les hackers de tous poils ont encore de beaux jours devant eux.
