Pourquoi la sécurité des outils internes est-elle cruciale ?

Cet article a été publié le 19 Septembre dans les "Tribunes" du JDNet Solutions.

Pour de nombreuses sociétés spécialisées dans le développement logiciel, la sécurité est devenue un enjeu important. A contrario, la sécurité des outils à usage interne reste à la traine.

Un nombre croissant de sociétés spécialisées dans le développement logiciel allouent d'importantes ressources à la validation du niveau de qualité de leurs produits.

Via l'intégration de tests de sécurité, certaines entreprises vont un cran plus loin dans les processus qualité, d'autres en sont encore à la phase de balbutiements dans le domaine, quant à  la dernière catégorie elle se demande encore de quoi il s'agit...

Le sujet est tout autre quant aux outils développés et utilisés en interne : très peu de sociétés on fait le choix de la sécurité pour cette catégorie d'outils. Cela amène à se poser quelques questions afin de comprendre cet état de fait :

• Pourquoi une société allouerait-elle des ressources pour sécuriser des produits n'ayant pas vocation à être diffusés ?
• Pourquoi les développeurs passeraient-ils du temps à développer de façon sécurisée des applications qui ne sortiront jamais de la société ?
• Pourquoi les employés d'une entreprise chercheraient-ils à compromettre la sécurité des outils internes ?

Tentons de répondre à ces interrogations.

Le comportement des développeurs
Un vieux proverbe est bien connu de ceux ayant passé une partie de leur carrière dans le développement logiciel : "Un développeur intelligent est un développeur paresseux".
Les développeurs ont effectivement tendance à réutiliser une partie du code source en le passant d'un programme à un autre. Cela peut prendre différentes formes non-exclusives les unes des autres :

• L'utilisation de fonctions regroupées sous la forme d'une librairie "métier"
• Le "copier-coller" de l'intégralité du code source implémentant un traitement particulier
• Le "copier-coller" d'un fragment du code source de l'appel à une fonction d'une API particulière

De façon très naturelle, le gisement représenté par les outils internes est souvent l'objet de "piochages" en tous genres. Ces programmes fonctionnent tout à fait correctement depuis parfois fort longtemps et leur niveau de qualité est généralement perçu en interne comme en externe comme bon voir très bon... En procédant par la réutilisation des codes sources, certains développeurs vont ainsi, malgré eux, exporter des failles de sécurité.

Ce sentiment de qualité perçue vis-à-vis des outils et programmes internes a aussi un impact auprès des équipes en charge des tests qualité. Un sentiment de confiance s'instaure et l'attirance est forte à ne pas tester les fonctionnalités rapatriées, laissant donc certaines parties sensibles du logiciel à la merci d'éventuels bugs latents.

Les outils internes mis à disposition des clients

L'expérience montre que certains outils internes finissent également par être mis à disposition des clients. Voici quelques raisons qui pourraient motiver ce choix :

• Les fonctionnalités de l'outil sont considérées comme apportant une forte valeur ajoutée à un produit ou service préexistant.
• L'usage interne récurrent et satisfaisant de l'outil est perçu comme étant un gage de qualité et de pérennité aux yeux du client.
• L'outil est embarqué comme un sous-élément d'un ensemble plus important et sa présence ne transpire pas. Aucune interface utilisateur ni documentation ne trahit sa présence.
• La durée de vie limitée de l'outil qui est simplement destiné à collecter des traces afin de diagnostiquer un problème ponctuel.
   

Et même si  -soyons fous! - des tests de sécurité étaient effectués avant la livraison de l'outil interne au client, les contraintes de temps ou de ressources, limiteraient sensiblement les correctifs réalisés,  et ce d'autant plus que les modifications requises seraient importantes.

Dans la pratique les tests sur les outils internes mis à disposition en externe ne sont que très rarement effectués. En effet le facteur "confiance en la technologie interne" est si fort que la question ne se pose quasiment jamais, que ce soit côté client ou fournisseur.

Pour conclure

Il apparaît donc important que les logiciels développés pour des besoins internes soient aussi l'objet d'une démarche sécurité. L'intégration de la sécurité dans le cycle de vie du développement logiciel (SDL ou "Software Development Lifecycle") est donc bien un sujet devant être traité de façon transverse et globale.

J'invite nos lecteurs spécialisés dans le développement logiciel à réagir en partageant avec nous leurs idées/opinions sur ce sujet via la fonction "commentaire".