Le code source ouvert, dit « Open Source », émerge. Chaque société conçoit désormais ses produits et services à partir de cette méthode d'ingénierie logicielle. Lorsqu’un développeur édite une application Open Source, il signifie son intention d’accorder à la communauté tech un accès gratuit au code source, ainsi qu’une opportunité de l’enrichir et de l’améliorer. Les multiples collaborations que ces projets engendrent permettent des percées technologiques significatives tout en rendant les logiciels plus accessibles aux individus qui ne peuvent se permettre les droits de licence.

Le recours à l’Open Source permet d’accélérer les cycles de développement et de réduire les coûts. En revanche, il comporte des risques, puisqu’il ne bénéficie pas du même niveau de contrôle que celui de logiciels développés en interne. Ainsi, lorsqu’une vulnérabilité est identifiée, il peut s’avérer difficile et coûteux de localiser chaque application utilisant un composant risqué.

Comment l’Open Source altère-t-il la chaîne logistique des logiciels ?

Aujourd’hui, 5 millions de bibliothèques Open Source ont été recensées ; mais la croissance est exponentielle, si bien que des millions de développeurs lanceront jusqu’à 500 millions nouvelles bibliothèques d’ici la prochaine décennie. Ce contexte accroît le vecteur de menace pour les entreprises ayant recours à l’Open Source dans leurs applications ; car si celui-ci permet davantage d’efficacité, les développeurs héritent également des vulnérabilités qui s’y associent.

Mettre uniquement l’accent sur le code interne – autrement dit, s’assurer que les développeurs sachent comment coder en toute sécurité et scanner leur travail - ne suffit plus. Un tel focus exclusif laisserait un trou béant dans notre couverture de sécurité, car il faut également penser aux bibliothèques Open Source que les développeurs intègrent dans leur code. Par exemple, le paysage actuel de la sécurité des logiciels est basé en grande partie sur les Vulnérabilités et expositions communes (CVE), si bien qu’aujourd’hui, attendre qu’une vulnérabilité soit ajoutée à une liste publique est tout simplement infaisable.

Cependant, utiliser une bibliothèque à risques ne rend pas nécessairement l’utilisateur vulnérable. En effet, il demeure crucial de garder à l’esprit que d’avoir conscience de la vulnérabilité d’un composant ne suffit pas : il faut également être capable d’identifier si ledit composant est utilisé de telle manière qu’il pourrait rendre cette vulnérabilité aisément exploitable. Prioriser ainsi est essentiel afin de sécuriser l’Open Source de manière appropriée. Dans de nombreux cas, lorsque les développeurs intègrent une bibliothèque open source dans leur code, ils n’en utilisent qu’une partie très réduite – une méthode ou fonctionnalité. Ainsi, même si la bibliothèque est marquée comme vulnérable, les données peuvent tout à fait ne pas avoir été endommagées par la partie défaillante, ou la méthode ou fonctionnalité utilisée peut ne pas avoir été impactée.

Les sociétés qui gèrent leur chaîne logistique de logiciels détiennent un avantage comparatif certain sur celles qui ne font pas de même. En effet, une chaîne logistique de logiciels bien contrôlée et protégée par des analyses fréquentes qui corrige en priorité les composants les plus risqués peuvent permettre de sécuriser son entreprise.

Les tendances dans la sécurité de l’Open Source.

Les composants Open Source vulnérables se répandent dans la plupart des logiciels. De plus, de  récentes études ont montré que les logiciels Open Source étaient parmi les plus lents dans la remédiation de failles une fois découvertes par les entreprises – en moyenne, il faut 93 jours à une entreprise afin de réparer seulement 25% de leurs failles Open Source. Ceci n’est qu’un exemple expliquant pourquoi la sécurité des logiciels Open Source est une problématique déterminante.

Dans le même temps, l’état d’esprit des cyber-attaquants évolue. La prolifération de l’Open Source a modifié l’économie de la cybercriminalité. Les hackeurs peuvent désormais générer plusieurs vulnérabilités en une seule attaque au lieu de pirater les applications une par une. Ainsi, non seulement les bibliothèques Open Source sont-elles de plus en plus ciblées par la cybercriminalité, mais les pirates travaillent à présent à la création d’un code Open Source malicieux que les entreprises incorporent machinalement dans leur base de code. Le ransomware est l’une des menaces les plus connues dans ce contexte.

De plus, le recours croissant au Cloud modifie fondamentalement notre vision de la sécurité informatique. Avec davantage d’applications basées sur le Cloud et un besoin croissant de scanner les vulnérabilités, les entreprises doivent se mettre à bonne échelle rapidement. Car sans l’échelle du Cloud, il est quasiment impossible de suivre le rythme de l’économie digitale.

On commence également à percevoir un changement de focus sur l’automatisation et la livraison continue qui permettent aux sociétés d’intégrer la sécurité dans les opérations des développeurs. Bien que les références du secteur industriels telles que OWASP, PCI, CISQ, NIST et FS-ISAC nécessitent à présent des politiques et contrôles explicites afin de gouverner l’utilisation de composants, de nombreuses entreprises luttent à les mettre en œuvre.

La collaboration Open Source prospérera en 2019

Les tendances en matière de production et consommation de logiciels Open Source sont en train de changer. S’agissant de la consommation, il est difficile d’identifier une entreprise qui n’utilise pas de code Open source pour la conception de ses produits et services.

A chaque instant, des milliers de bibliothèques Open Source sont créées. Celles-ci sont diffusées toujours plus rapidement et dans des sections de plus en plus petites. En définitive, cette croissance accélérée dans la quantité et la rapidité signifie qu’il est essentiel d’évaluer rapidement et fréquemment la sécurité des applications. Dans le même temps, la vitesse de développement des applications croît solidement, ce qui signifie que tout contrôle de sécurité qui ralentit ou interrompt le flux de travail d’un développeur ne sera pas efficace.

La sécurité des applications nécessite aujourd’hui d’être fluide, autrement dit automatisée. Nous aurons besoin de plus en plus d’automatisation et de machine learning afin d’identifier, localiser puis rapporter les vulnérabilités aux développeurs. La coopération entre les équipes de développement et celles de la sécurité mènera à la croissance et au niveau de vigilance requis pour la sécurité des composants d’Open Source.