L’open source est une aubaine pour les développeurs, mais parfois aussi une malédiction. Quel est le degré de sécurité du code source ouvert aujourd’hui ?
Nous retournons à la fin de l’année 2021. Le monde s’est arrêté pendant un certain temps, et ce n’était pas seulement à cause du covid-19. Log4j, un système qui conserve les journaux et qui est utilisé par des millions de systèmes basés sur Java, contenait une vulnérabilité. “Une erreur de programmation permettait aux pirates d’exécuter leur propre code malveillant via Log4j et même de se connecter à un serveur distant pour y introduire des logiciels malveillants”, explique Dirk Deridder, directeur de l’infrastructure informatique, des systèmes, des services et de l’assistance chez Smals.
Presque personne n’a été épargné. L’iCloud d’Apple, les services de Cloudflare, Amazon, VMware et IBM, Twitter et le service de jeux Steam, entre autres, ont été touchés par le bogue. Remarque : grâce à des mesures de sécurité supplémentaires, les attaques ont heureusement pu être stoppées.
Qu’est-ce qui a rendu cette situation complexe ? Apache, en tant que développeur de Log4J, a déployé un correctif pour le zero-day, mais cela n’a pas suffi. En effet, de nombreuses organisations utilisent des logiciels tiers qui intègrent Log4j. Elles ont dû attendre que tous leurs fournisseurs de logiciels mettent en œuvre le correctif d’Apache, puis procéder elles-mêmes à la mise à jour.
L’affaire Log4j était un scénario catastrophe, dans lequel l’open source a fait faillite. Deridder : “Ceux qui travaillent avec l’open source ont un outil puissant entre les mains. À condition que vous soyez vous-même suffisamment conscient de cette puissance.”
Transparence
Un environnement open source est basé sur la transparence : le code que vous partagez est visible par tous. Cela a un impact positif sur la qualité du code. Les développeurs ne partageront pas facilement un code inexact, au risque qu’il soit corrigé ou submergé par les critiques. La nature ouverte est un gage de qualité.
“Avec l’open source, vous collaborez avec différentes personnes, mais pas au sein d’une même entreprise. Cela vous oblige à respecter certaines normes, de sorte que le verrouillage des fournisseurs n’a aucune chance”, explique M. Deridder. Ces normes ouvertes offrent un degré élevé de portabilité, les développeurs pouvant déployer le même code sur différentes plates-formes.
Sécurité
Bien que l’open source soit une communauté, remplie de développeurs qui partagent le même objectif, cela ne signifie pas qu’elle est à l’abri des dangers extérieurs. La responsabilité ultime du code n’incombe pas à la personne qui le partage, mais à l’utilisateur final qui l’adopte.
“On ne peut pas s’attendre à ce qu’un développeur bénévole qui partage son code avec d’autres pendant son temps libre dispose des ressources nécessaires pour détecter un code ou des pratiques malhonnêtes”, explique M. Deridder. C’est donc à l’utilisateur final qu’il incombe d’inspecter le code acquis pour y déceler des problèmes, bien que cela ne soit pas toujours possible lorsque des dizaines de milliers de lignes de code sont en jeu.
L’Open Source est devenu tellement banal qu’on n’en parle pas assez.
Dirk Deridder, Director IT Infrastructure, Systems, Services & Support bij Smals
M. Deridder estime que l’augmentation du nombre de cybermenaces constitue un défi majeur pour le concept d’open source. Les pirates informatiques ciblent de plus en plus les projets open source, ce qui crée de nouveaux défis. “Mais je vois cela d’un œil positif : il pourrait bien s’agir de l’électrochoc nécessaire pour remettre l’open source sur le devant de la scène”, déclare M. Deridder.
SBOM
Chez Smals, Deridder insiste toujours sur le SBoM, la “Software Bill of Materials”. “Vous pouvez considérer cela comme une liste d’ingrédients logiciels. Il s’agit d’une liste de tous les composants, bibliothèques et cadres utilisés dans un produit logiciel spécifique”.
Le SBoM contient aussi souvent des informations importantes telles que les versions des composants, les licences et les problèmes de sécurité connus. “Le SBoM est précieux car il vous permet de savoir ce que vous avez en termes de logiciels”, explique-t-il.
lire aussi
Dans quelle mesure les logiciels libres sont-ils sûrs alors que les gens s’y fient de plus en plus ?
En l’utilisant, les organisations pourront automatiquement mieux gérer et sécuriser leurs produits, selon M. Deridder. Les différentes réglementations et normes exigent souvent un tel SBoM. Un dernier avantage supplémentaire est l’amélioration de la rentabilité, car vous savez ce qui est présent et où. Une meilleure vue d’ensemble permet de trouver des solutions plus rapides, ce qui se traduit par une réduction des coûts.
Nano-communautés
“En théorie, le code source ouvert est le code le plus sûr, car le monde entier peut y avoir accès. Malheureusement, c’est un rêve. La réalité est que pour les centaines de millions de paquets, il n’y a pas assez de personnes dans la communauté open source pour tout pénétrer rigoureusement”, a déclaré M. Deridder.
Il cite Linux comme un bastion avec des leaders forts. “Là, l’histoire est vraie, mais en même temps, il y a des dizaines de milliers d’autres personnes qui construisent quelque chose, déposent le code dans l’open source parce qu’il leur a rendu service, et s’en vont vers le ciel. Vous avez souvent affaire à des nano-communautés. C’est là que se trouve le talon d’Achille de l’open source”.
Deridder respire l’open source et souhaite diffuser ce message le plus largement possible. “Chez Smals, nous encourageons l’utilisation de l’open source et avons développé notre propre micro-communauté appelée ReUse“. Le code couramment utilisé par les agences gouvernementales y est “recyclé”. Récemment, Smals a lancé un site web amélioré où vous pouvez trouver un catalogue constamment mis à jour qui contient une centaine de composants réutilisables : API, systèmes, bibliothèques et produits.