Relever les défis de cybersécurité des logiciels open source avec la Linux Foundation

Snyk s’est récemment associé à la Linux Foundation pour publier un rapport sur l’état de la sécurité des logiciels open source (OSS). Ce rapport s’appuie sur plus de 550 réponses à une enquête et 15 entretiens avec des spécialistes de la maintenance de projets OSS et de la cybersécurité.

Après la publication du rapport, des experts de Snyk ont organisé un webinaire avec la Linux Foundation pour présenter certains de ses principaux enseignements : Relever les défis de cybersécurité des logiciels open source : table ronde d’experts. Les participants étaient Mic McCully (stratège de terrain, Snyk), Matt Jarvis (directeur des relations avec les développeurs, Snyk) et Steve Hendrick (vice-président de la recherche, Linux Foundation).

Poursuivez votre lecture pour découvrir comment renforcer la sécurité et la pérennité de l’open source.

Vulnérabilités de la chaîne d’approvisionnement logicielle

À mesure que les chaînes d’approvisionnement logicielles gagnent en complexité, la sécurité de l’open source devient plus cruciale que jamais. Par exemple, la plupart des logiciels actuels comportent de nombreuses dépendances indirectes ou transitives, difficiles à visualiser et à évaluer du point de vue de la sécurité des applications.

Lorsqu’un développeur intègre un package open source, celui-ci référence très souvent d’autres projets open source. Il se crée alors une hiérarchie, et les packages de niveau inférieur sont souvent appelés dépendances indirectes ou transitives.

Selon le rapport récemment publié, un projet OSS moyen présente 49 vulnérabilités réparties sur 79 dépendances directes. Ces chiffres varient toutefois d’un écosystème à l’autre : les projets JavaScript comptent nettement plus de vulnérabilités que ceux développés en Python, Go, Java et .NET.

L’emplacement de ces vulnérabilités au sein des packages est encore plus révélateur. Le rapport montre que plus de 40 % de ces problèmes de sécurité se trouvent dans des dépendances indirectes. Les équipes de développement ignorent donc souvent qu’elles intègrent du code vulnérable à leurs projets.

Comme nous l’avons constaté chez Snyk, ces vulnérabilités peuvent être enfouies très profondément. Certains problèmes de la chaîne d’approvisionnement logicielle proviennent souvent de dépendances situées à quatre ou cinq niveaux de profondeur.

La nécessité des SBOM et des politiques de sécurité OSS

Comme les problèmes de sécurité sont souvent enfouis au cœur d’arbres de dépendances complexes, l’idée

de créer une nomenclature logicielle (SBOM) gagne en popularité. Les SBOM répertorient officiellement les composants d’un logiciel et les relations au sein de sa chaîne d’approvisionnement, afin d’améliorer la transparence.

En réalité, nous devons savoir ce que contient un composant. Nous devons comprendre dans quelle mesure il est exploitable et si nous pouvons lui faire confiance. Lorsqu’il existe des dépendances transitives, il peut être très difficile d’obtenir ces informations.

Si de nombreuses entreprises ne créent pas de SBOM, c’est notamment parce que la sécurité de l’open source reste globalement insuffisante. En effet, les résultats de l’enquête menée pour le rapport révèlent que seulement 49 % des organisations ont une politique de sécurité qui couvre l’open source.

Sans politique relative aux logiciels open source, vous ne pouvez pas gérer efficacement les risques. Vous ne savez pas vraiment comment réagir face aux vulnérabilités, et votre posture de sécurité en pâtit.

Comment les organisations vérifient-elles la sécurité des packages OSS ?

Le rapport indique que 44 % des entreprises demandent à leurs développeurs d’examiner le code source à la recherche de vulnérabilités. Près d’une douzaine de types d’outils différents sont toutefois utilisés à cette fin. Parmi les plus courants figurent les tests statiques de sécurité des applications (SAST) et l’analyse de la composition logicielle (SCA).

Pour vérifier la sécurité des packages OSS, les organisations les évaluent aussi souvent avant de les adopter. Elles privilégient les projets OSS bien notés, dotés d’une communauté active qui publie régulièrement des modifications de code et d’une politique de sécurité rendue publique. Toutefois, ces composants peuvent tout de même présenter des vulnérabilités dans leurs dépendances transitives si les responsables du projet ne prennent pas eux-mêmes de mesures proactives pour assurer la sécurité OSS.

Ce que nous commençons à observer dans le secteur, ce sont de nouvelles façons de communiquer aux utilisateurs de logiciels open source des informations sur leur sécurité et leur fiabilité. Nous avons commencé avec les étoiles GitHub, mais il existe désormais les Scorecards OpenSSF et d’autres sources d’informations détaillées.

L’impact de Log4Shell dans la communauté Java

Le rapport met également en lumière des observations intéressantes sur la très répandue vulnérabilité Log4Shell dans la communauté Java. Fait notable, 79 % des projets touchés par Log4Shell présentent plusieurs occurrences de cette vulnérabilité dans leur base de code, et 60 % des cas se trouvent dans des dépendances indirectes.

Log4Shell a vraiment illustré cette idée : les projets open source peuvent être victimes de leur propre succès. Lorsqu’une bibliothèque open source comme Log4j est utilisée dans un très grand nombre de projets, les problèmes de sécurité peuvent avoir des conséquences considérables. Cela a vraiment mis en lumière la nécessité des outils d’analyse SCA.

Les vulnérabilités open source sont de plus en plus difficiles à corriger

Les chaînes d’approvisionnement logicielles se complexifient, et de nombreuses organisations peinent de plus en plus à obtenir une bonne visibilité sur la sécurité. Par conséquent, les vulnérabilités open source sont elles aussi plus difficiles à corriger. Le délai de correction est passé de 49 jours en 2018 à 110 jours en 2021.

En trois ans, le délai de correction a plus que doublé. Dans le même temps, deux autres évolutions ont eu lieu : 1) l’utilisation et le développement de logiciels ont connu une croissance fulgurante ; 2) nous consacrons beaucoup plus de temps et d’attention à la sécurité.

L’augmentation des délais de correction pose également un problème de ressources aux organisations. Certaines entreprises corrigent effectivement les problèmes critiques plus rapidement qu’auparavant, mais les vulnérabilités moins prioritaires sont traitées trop lentement, faute de ressources dédiées à la sécurité des applications. C’est pourquoi les outils SAST et SCA sont les deux principaux moyens utilisés par les entreprises pour répondre aux enjeux de sécurité.

Les outils d’analyse SAST et SCA peuvent être intégrés aux pipelines CI/CD et au processus de développement afin d’automatiser la détection et la correction de nombreuses vulnérabilités open source. Les organisations peuvent ainsi pallier certains des problèmes de ressources en sécurité des applications auxquels elles sont confrontées.

Il existe une forte corrélation entre l’automatisation du pipeline de déploiement et le délai de correction des problèmes de sécurité : avec un CI/CD entièrement automatisé, vous disposez de nombreux points d’intégration pour ajouter des contrôles de sécurité.

L’état de la sécurité open source en 2022

Cette conversation entre Snyk et The Linux Foundation a abordé plusieurs enseignements clés du rapport, mais il reste encore beaucoup à découvrir. Téléchargez le rapport complet pour en savoir plus sur la complexité et les risques liés au paysage actuel des chaînes d’approvisionnement logicielles : État de la sécurité open source 2022.