Les failles de sécurité dans le code
Le logiciel du système d'exploitation, le logiciel d'application ou le micrologiciel d'un système embarqué sont des composants élémentaires de toute infrastructure numérique. Cependant, l'accélération croissante et la pression des délais dans les projets de numérisation conduisent souvent à négliger les aspects impératifs de la sécurité de l'information. Les exigences de développement des logiciels sont généralement centré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 le plus souvent diamétralement opposée aux objectifs réels de développement : de nombreux programmeurs n'ont tout simplement pas non plus une vision structurée et aiguisée de la cybersécurité.
Dans ces conditions, les équipes de développement ont du mal à revoir et à sécuriser en permanence le codage de leurs logiciels, comme en témoignent les nombreuses vulnérabilités que l'organisation à but non lucratif MITRE Corporation publie chaque année dans sa liste CVE (Common Vulnerabilities and Exposures). Les correctifs de sécurité apportés régulièrement par des fabricants de logiciels, même bien connus, témoignent de la tâche sisyphéenne consistant à éliminer les bogues liés à la sécurité, sans parler de leur identification avant même leur lancement sur le marché.
Code source ouvert - un cas particulier
Lorsqu'ils codent un logiciel qu'ils ont développé eux-mêmes, les programmeurs utilisent volontiers des bibliothèques et des modules open source. Les avantages pratiques sont évidents : si vous ne devez pas réinventer la roue encore et encore, vous bénéficiez d'un coup de pouce technologique, d'un développement plus rapide, d'une réduction des coûts de développement, d'une plus grande transparence grâce au code source ouvert et d'une meilleure interopérabilité grâce aux normes et interfaces ouvertes.
On dit aussi souvent que le code issu de l'open source offre un haut degré de sécurité car le code a été validé par de nombreux utilisateurs et l'intelligence en essaim de la communauté open source permet une correction rapide et efficace des bugs.
En pratique, cette confiance doit désormais être évaluée de manière différenciée et critique. L'exemple le plus grave est la vulnérabilité de sécurité zero-day Log4Shell dans la bibliothèque de journalisation Log4J, largement utilisée pour les applications Java, qui a été découverte en novembre 2021. 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 fonctionnant de manière fiable via la Fondation Apache, s'est établie dans de nombreux systèmes depuis 2013 - y compris des services Web bien connus comme Amazon AWS.
La complexité de ces bibliothèques bien développées et également entretenues fournit implicitement des fonctionnalités puissantes dont un développeur importateur n'est souvent pas conscient dans son propre nouveau développement combiné, mais qui peuvent être exploitées par des attaquants.
Un autre facteur d'insécurité des composants open source est ce qu'on appelle les attaques de la chaîne d'approvisionnement, c'est-à-dire les vulnérabilités intégrées intentionnellement par des acteurs malveillants qui se font passer pour des membres de la communauté open source et participent au développement du 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 connaisse une croissance rapide : une étude de Sonatype a diagnostiqué une augmentation de 650 % en comparant 2020 et 2021.
