Vulnérabilités dans le code
Les logiciels d'exploitation, les logiciels d'application ou les microprogrammes d'un système embarqué sont des composants élémentaires de toute infrastructure numérique. Cependant, l'accélération croissante et la pression du temps dans les projets de numérisation conduisent souvent à négliger les aspects impératifs de la sécurité de l'information. Les exigences en matière de développement de logiciels sont généralement axées sur les fonctions et mettent l'accent sur les aspects constructifs, de sorte que la vision destructrice des vulnérabilités potentielles en matière de sécurité est généralement en contradiction avec les objectifs de développement réels : de nombreux programmeurs n'ont tout simplement pas une vision structurée et affinée de la cybersécurité.
Dans ces conditions, les équipes de développement éprouvent des difficultés à revoir et à sécuriser en permanence le codage de leurs logiciels, comme en témoignent les nombreuses vulnérabilités que la société à but non lucratif MITRE Corporation publie chaque année dans sa liste CVE ( Common Vulnerabilities and Exposures). Les correctifs de sécurité régulièrement apportés par les fabricants de logiciels, même les plus connus, témoignent du travail de Sisyphe que représente la correction des bogues liés à la sécurité, sans parler de leur identification avant leur mise sur le marché.
Le code source ouvert - un cas particulier
Lorsqu'ils codent des logiciels qu'ils ont eux-mêmes développés, les programmeurs aiment recourir à des bibliothèques et à des modules open source. Les avantages pratiques sont évidents : ne pas avoir à réinventer la roue bénéficie de ce coup de pouce technologique, d'un développement rapide, de coûts de développement réduits, d'une plus grande transparence grâce au code source ouvert, et d'une plus grande interopérabilité grâce à des normes et des interfaces ouvertes.
On dit aussi souvent que le code source ouvert offre un haut degré de sécurité parce qu'il a été validé par de nombreux utilisateurs et que l'intelligence en essaim de la communauté du code source ouvert permet de corriger les bogues rapidement et efficacement.
Dans la pratique, cette confiance doit maintenant être différenciée et évaluée de manière critique. L'exemple le plus sérieux est la faille de sécurité Log4Shell, découverte en novembre 2021, dans la bibliothèque de logs Log4J, largement utilisée pour les applications Java. Vous avez peut-être entendu parler du niveau d'alerte rouge émis par l'Office fédéral allemand de la sécurité de l'information (BSI) pour Log4Shell. La bibliothèque Log4J, distribuée en tant que quasi-standard de travail fiable par la Fondation Apache, s'est imposée dans de nombreux systèmes depuis 2013, y compris dans des services web bien connus tels qu'Amazon AWS.
La complexité de ces bibliothèques bien développées et maintenues fournit implicitement des fonctionnalités puissantes dont un développeur importateur n'a souvent pas conscience dans son propre développement, mais qui peuvent être exploitées par des attaquants.
Un autre facteur d'insécurité des composants open source est ce que l'on appelle les attaques de la chaîne d'approvisionnement, c'est-à-dire les vulnérabilités intégrées intentionnellement par des personnes malveillantes qui se font passer pour des membres de la communauté open source et qui aident à développer le code. Une telle vulnérabilité est un moyen extrêmement efficace pour les pirates d'attaquer un grand nombre d'organisations utilisatrices en aval. Il n'est donc pas étonnant que ce vecteur d'attaque se développe rapidement : une étude de Sonatype a révélé une augmentation de 650 % entre 2020 et 2021.