Depuis des décennies, l’utilisation des bibliothèques open source est un outil populaire auprès des développeurs. Ce n’est pas une surprise si l’on considère les avantages qu’ils présentent : gratuité, malléabilité et efficacité. Au fond, pourquoi passer du temps à concevoir quelque chose que quelqu’un d’autre aura déjà fait ? De fait, presque toutes les applications que nous utilisons contiennent désormais des composants open source. L’immense réservoir de code source a ainsi permis à des entreprises non spécialisées dans les logiciels, de toutes tailles et de tous secteurs, de créer des logiciels.

Cependant, des risques importants liés à l’utilisation des composants open source existent et les chefs d’entreprise et développeurs doivent en être pleinement conscients. Si les bibliothèques open source permettent aux développeurs de travailler plus rapidement et plus intelligemment, il est important de se rappeler qu’elles ne sont pas statiques. La popularité et l’utilisation des bibliothèques changent et évoluent, ce qui rend difficile pour les développeurs de suivre les dernières mises à jour de sécurité de ces bibliothèques. Aujourd’hui, plus que jamais, les entreprises sont exposées à un risque accru de fuites de données et de cyberattaques dommageables en raison de la prolifération des logiciels open source.

Examinons donc plus en détail les risques associés à l’open source et les limites d’un état d’esprit qui consiste à « mettre en place puis oublier ».

Les risques de l’approche « tout mettre en place puis tout oublier ».

Souvent, les développeurs ne se rendent pas compte qu’ils doivent mettre à jour une bibliothèque. Ils ont en effet tendance à « mettre en place et oublier », laissant la plupart des bibliothèques sans mise à jour. Environ 95 % des entreprises IT s’appuient aujourd’hui sur des bibliothèques open source, mais dans 79 % des cas, ces bibliothèques tierces ne sont jamais mises à jour après avoir été intégrées dans un code source.

Quelles sont les freins rencontrés par les développeurs pour mettre à jour les bibliothèques open source vulnérables ? Le manque d’informations contextuelles peut constituer un obstacle. Il peut s’agir d’une raison aussi simple que de ne pas comprendre la gravité ou l’impact d’une vulnérabilité. Par exemple, si un développeur ne comprend pas pourquoi une faille d’injection SQL est dangereuse, il peut la considérer comme sans importance. Parfois, visualiser le chemin de code – reliant le code de première partie à la vulnérabilité d’une partie tierce – peut aider les développeurs à comprendre comment et pourquoi leur application est vulnérable et aussi prioriser les efforts de remediation.

On estime que les développeurs qui déclarent avoir besoin de davantage d’informations contextuelles mettent plus de sept mois pour corriger 50 % des failles. En revanche, pour ceux qui estiment disposer d’informations contextuelles précises, par exemple la manière dont une vulnérabilité influe sur la sécurité de leur application, le temps de remédiation se réduit à trois semaines.

La bonne nouvelle est que, lorsqu’ils sont avertis de la présence de bibliothèques vulnérables, les développeurs peuvent agir rapidement. En effet, près de 17 % des bibliothèques vulnérables sont corrigées dans l’heure qui suit l’analyse qui a alerté le développeur, et 25 % le sont dans les sept jours. En outre, la plupart des failles de sécurité des logiciels libres ne nécessitent que des corrections mineures. En effet, 92 % des failles des bibliothèques peuvent être corrigées par une mise à jour, et 69 % d’entre elles ne nécessitent qu’un changement de version mineur.

Changer la culture de la sécurité

On a beaucoup parlé du « déplacement vers la gauche » (shifting left), qui consiste à faire remonter les responsabilités et les fonctionnalités en amont du cycle de vie du développement logiciel. Bien qu’il s’agisse d’une bonne technique, il est toutefois nécessaire d’aller plus loin, notamment dans les situations de type DevOps. Le développement de logiciels évolue très rapidement et passe souvent par des contrôles automatisés. Les entreprises qui ont des pratiques de sécurité très intégrées ont une bonne longueur d’avance grâce à la stratégie de DevSecOps. La formation des développeurs et des équipes de sécurité est essentielle afin d’appréhender l’importance de ce changement d’approche, faire évoluer la culture de l’entreprise et ainsi considérer l’éducation à la sécurité comme une véritable plus-value pour les employés.

En ce sens, l’approche DevSecOps intègre les équipes chargées des opérations de sécurité dans l’équation afin qu’elles puissent collaborer de manière transparente avec les développeurs et les ingénieurs informatiques. Alors que le DevOps encourage la livraison continue, le DevSecOps s’attache à la sécurité continue, c’est-à-dire la gestion constante et holistique de la sécurité tout au long du cycle de vie du développement du logiciel. De même, le DevSecOps oblige à l’amélioration continue dans le domaine de la sécurité. En d’autres termes, quel que soit le niveau de sécurité que vous estimez avoir atteint dans votre environnement, il faut toujours chercher à l’améliorer. Il existe ainsi quatre approches principales d’intégrer la sécurité dans le développement :

1- Une bonne formation des développeurs est essentielle. Il existe de nombreux outils qui offrent une formation pratique que les développeurs peuvent utiliser pendant qu’ils codent.

2- Encourager la communication et la collaboration continues entre toutes les équipes dans le cadre des processus DevOps existants. Comprendre les pressions et les flux de travail des équipes permet à chacun de fonctionner avec les mêmes objectifs en tête.

3- S’assurer que les développeurs vérifient l’ensemble de la base de code (y compris le code open source), et pas seulement le sien.

4- Automatiser autant que possible pour accélérer le processus de développement et fournir aux développeurs un retour d’information clair auquel ils peuvent donner suite.

Soutenir les développeurs, une condition à la réussite de leur mission

Les bibliothèques open source resteront un outil important et utile pour les développeurs, mais on ne peut plus ignorer les risques de sécurité qui sont pris avec ce code. Les équipes chargées de la sécurité doivent collaborer plus étroitement avec les équipes de développement pour changer la mentalité du « tout mettre en place et puis oublier » et s’assurer que les bons processus sont mis en place pour que les développeurs aient accès à toutes les informations contextuelles nécessaires pour corriger les vulnérabilités en amont.

L’intégration du DevSecOps est un pas dans la bonne direction. Cependant, les responsables commerciaux et techniques doivent faire davantage pour redéfinir les priorités du temps consacré à la correction des vulnérabilités et à la réduction de la dette de sécurité, tout comme le temps consacré à l’évolutivité, à la résilience, à la qualité, etc. D’un point de vue culturel, nous devons accorder plus d’importance et de ressources au fait de laisser aux développeurs le temps de traiter les vulnérabilités, au lieu d’attendre de leur part qu’ils créent sans cesse de nouvelles fonctionnalités. Après tout, un logiciel brillant sera rapidement sans valeur s’il peut être facilement piraté.
___________________

Par Nabil Bousselham, architecte de solutions informatique chez Veracode