Support technique
Documentation
Connexion
Nous contacter
TuxCare BlogLa dette de sécurité, ou quand les insectes deviennent mauvais
par Joao Correia
11 mars 2024 - Évangéliste technique
De temps en temps, le monde des technologies de l'information est saisi par une résurgence de préoccupations - parfois une tendance fugace, parfois un problème important. Dernièrement, le terme "dette de sécurité" a fait le tour des plateformes d'information sur les technologies de l'information. Cet article a pour but d'expliquer l'essence de la dette de sécurité et ses implications.
De la dette technique à la dette de sécurité
Le concept de "dette technique" est familier à beaucoup ; il fait référence aux défis qui se posent lorsque les projets prennent de l'ampleur au-delà des proportions gérables. Cette "taille" peut être mesurée en lignes de code, modules, fonctions ou autres paramètres, reflétant la capacité d'une équipe à ajouter simultanément de nouvelles fonctionnalités et à maintenir le code existant.
Par exemple, il est beaucoup plus difficile d'ajouter de nouvelles fonctionnalités à une application mature qu'à cette même application dont le développement ne fait que commencer. Il y a moins de pièces mobiles et moins d'interactions entre les différentes parties du code, ce qui fait que l'ajout de nouvelles fonctionnalités risque moins de casser les fonctionnalités existantes. Au fur et à mesure que l'application évolue, chaque changement peut entraîner une interaction inattendue ailleurs dans le code. Dans le jargon des développeurs, cela signifie simplement "vous avez ajouté un bogue". Confrontés à un temps et à des ressources limités, les développeurs doivent jongler entre les nouveaux développements et les corrections de bogues, ce qui ralentit la progression générale. Ce retard dans la maintenance constitue une "dette technique".
Certains de ces bogues, voire tous, lorsqu'ils restent suffisamment longtemps dans le code, peuvent se transformer en problèmes de sécurité, peuvent se transformer en problèmes de sécurité. Par exemple, une variable qui déborde ou qui ne déborde pas quelque part peut simplement signifier qu'un rapport reçoit une mauvaise valeur ou, si quelqu'un trouve un moyen de la déclencher, peut entraîner une corruption de la mémoire dans des parties de l'application qui n'ont rien à voir avec elle. Il s'agit de la "dette de sécurité", c'est-à-dire des bogues de sécurité qui se trouvent dans le code, parfois pendant des mois, voire des années, jusqu'à ce que quelqu'un prenne le temps de les corriger. Si elles ne sont pas corrigées, ces vulnérabilités peuvent être exploitées avant d'être corrigées.
Pourquoi ce retour en force ?
Le premier coupable est la complexité. Les bases de code ne cessent de s'étendre. On voit toujours de nouvelles fonctionnalités ajoutées aux logiciels, jamais l'inverse. Cela signifie que l'on ajoute du code, et non que l'on en supprime. Notre cerveau humain a du mal à comprendre toutes les subtilités de nos créations numériques.
Prenons l'exemple de la base de code du noyau Linux qui est passée de 2,4 millions de lignes de code en 2001 à plus de 20 millions en 2015. Personne, ni aucune équipe d'ailleurs, n'est en mesure d'en saisir correctement tous les aspects. Ainsi, chaque fois que quelqu'un y ajoute une nouvelle ligne de code, cela peut fonctionner parfaitement ou déclencher un effondrement ailleurs. En tirant à pile ou face, vous auriez les mêmes chances.
Ce phénomène n'est pas l'apanage du noyau, ni même des projets de cette ampleur, ni même des projets open source. Cette augmentation de la complexité se produit de la même manière dans les logiciels propriétaires à source fermée, mais nous ne disposons pas de mesures de la taille du code pour le démontrer. À titre de comparaison, Windows 95 a été livré sur 13 disquettes de 1,68 Mo (ce n'est pas une faute de frappe, ces disquettes Ces disquettes utilisaient une disposition différente des pistes pour contenir plus de données, et elles servaient également de mécanisme de protection contre la copie.). Windows 11 est livré sous la forme d'une iso d'environ 5 Go.
Donc oui, la base de code a augmenté.
Ce n'est pas non plus parce que les développeurs sont soudainement devenus moins bons. Le développeur typique peut être capable de comprendre avec précision quelques dizaines de lignes de code de mémoire. Un bon développeur est capable de comprendre le double ou le triple de ces lignes (je reste volontairement vague, car il est difficile d'évaluer la capacité d'un développeur à comprendre des lignes de code). c'est difficile à évaluer). Pour tous, regarder un code qu'ils n'ont pas vu en quelques jours ou semaines est comme lire une langue étrangère pour la première foiset le changement de contexte prend du temps.
Comprendre des projets entiers n'est plus une perspective attendue. Le fait que nous codions des bogues nous le rappelle brutalement.
C'est tout ?
Le problème est aggravé par la "complexité cachée", introduite avec chaque bibliothèque ou composant tiers ajouté. Un rapport récent a souligné que le projet Java moyen comportait environ 150 dépendancessoit une augmentation significative par rapport à l'année précédente. Cette complexité s'ajoute à la tâche déjà difficile de la gestion du code de première partie.
Remédier à la dette de sécurité
Tout ce code comporte intrinsèquement des bogues, dont beaucoup sont directement des problèmes de sécurité. Il est difficile de les traiter correctement et en temps utile. Le degré de difficulté dépend de plusieurs facteurs :
- La rapidité avec laquelle ils sont détectésLa rapidité avec laquelle ils sont détectés dépend à son tour des tests effectués dans le pipeline de développement et de compilation : Si vos contrôles de sécurité sont effectués à la fin d'une longue fenêtre de fusion, avec plusieurs développeurs modifiant le code sur une longue période, lorsque les alertes sont déclenchées, l'effort du développeur d'origine pour résoudre le problème est beaucoup plus important, car il ou elle ne sera plus en mesure de se rappeler la raison pour laquelle quelque chose a été mis en œuvre de cette manière.
- Quel est le degré d'exhaustivité de vos tests ?: Testez-vous uniquement des problèmes spécifiques ? Peut-être que l'analyse statique ne recherche que des schémas particuliers, comme des variables mal typées, des dépassements de tampon ou l'utilisation de NULL. Quelque chose d'autre peut passer inaperçu jusqu'à ce qu'il soit découvert dans la nature.
- Le nombre total de problèmes identifiés: Si vous avez un grand nombre de problèmes de sécurité à traiter, disposez-vous des ressources - temps, savoir-faire, main-d'œuvre - pour les résoudre tous ? Établissez-vous des priorités ? Que se passe-t-il si quelque chose se produit ailleurs et qu'un problème peu prioritaire devient soudain plus important ? Votre système est-il suffisamment souple pour y réagir ?
La dette de sécurité comporte de nombreux aspects, et le présent article n'aborde que certaines questions fondamentales. Son objectif est de tirer la sonnette d'alarme sur le problème de la dette technique qui se transforme en dette de sécurité lorsque la complexité s'accroît au-delà de la capacité d'un développeur ou d'une équipe à la gérer correctement.
Certaines tactiques peuvent être utilisées pour résoudre ce problème : de meilleurs tests de sécurité, des tests de sécurité plus précoces, des tests de sécurité avant de valider le code (au lieu de ne vérifier qu'une fois que tout le monde a validé), l'évaluation par les pairs, l'externalisation des vérifications de bibliothèques tierces à un tiersou même l'embauche de développeurs supplémentaires au fur et à mesure que les bases de code augmentent. Seule, aucune de ces suggestions ne résoudra entièrement le problème, mais ensemble, elles pourraient tenir la complexité à distance pendant un certain temps et en atténuer l'impact.
Note : Si vous souhaitez en savoir plus sur le problème, le podcast "Enterprise Linux Security" a un épisode 84 sur le sujet. Vous pouvez le trouver sur toutes les plateformes de podcast ou sur YouTube avec une session d'enregistrement en direct.
