La sécurité de l’open source expliquée

Ces dernières années, les logiciels open source se sont largement répandus grâce à leur nature collaborative et publique, ce qui les rend pratiques aussi bien pour les développeurs que pour les acteurs malveillants. Dès que des adversaires découvrent qu’une application est exposée à une vulnérabilité connue du public, ils peuvent attaquer n’importe quelle application développée à partir de ce code open source. Les vulnérabilités Log4j et Apache Struts montrent qu’il s’agit d’un risque réel, parfois grave, pour les organisations.

Il est essentiel de gérer les composants et dépendances open source pour atténuer ce risque. Pourtant, il est difficile de garder une visibilité sur tous les composants open source utilisés dans une application, et fastidieux de vérifier manuellement leur présence dans des bases de données de vulnérabilités connues. Les dépendances imbriquées compliquent encore les choses : il faut sécuriser non seulement le code écrit par les développeurs, mais aussi tout le code open source qu’ils utilisent et les dépendances qu’il contient.

Dans cet article, nous allons définir la sécurité open source, examiner les risques liés aux logiciels open source et présenter des outils et des processus permettant d’atténuer les risques auxquels les organisations s’exposent lorsqu’elles les utilisent.

Qu’est-ce que la sécurité open source ?

La sécurité open source concerne les risques et les vulnérabilités associés aux logiciels tiers, ainsi que les outils et les processus mis en œuvre pour sécuriser les logiciels open source. Les outils de sécurité peuvent automatiser la détection des bibliothèques et dépendances open source dans le code, analyser la manière dont ces composants sont utilisés dans les applications et déclencher des alertes ou des mesures correctives lorsqu’ils détectent des vulnérabilités. Des pratiques telles que l’authentification à deux facteurs ajoutent une couche de sécurité pour prévenir les violations.

4 avantages des logiciels open source

Les exigences métier accélèrent le développement logiciel et les cycles de mise en production. Pour y répondre, les développeurs se tournent de plus en plus vers les logiciels open source afin de compléter le code développé en interne.

Leur popularité tient à plusieurs facteurs :

1. Coût : les développeurs peuvent utiliser, modifier et partager librement les logiciels open source du domaine public, tandis qu’une communauté mondiale de développeurs et de bénévoles contribue à leur maintenance. Même les logiciels open source commerciaux sont relativement peu coûteux par rapport au développement de code sur mesure à partir de zéro.

2. Facilité d’utilisation : grâce à leur nature préconstruite et ouverte, les logiciels open source permettent aux développeurs de réutiliser du code existant pour répondre à leurs besoins spécifiques. Ils peuvent ainsi consacrer davantage de temps à des tâches à plus forte valeur ajoutée.

3. Qualité : puisque des communautés de développeurs créent, utilisent et examinent le code open source, celui-ci comporte, en théorie, moins de bugs, car les vulnérabilités sont rapidement découvertes et corrigées.

4. Rapidité : les logiciels open source permettent aux développeurs de commercialiser plus rapidement des applications utiles à l’entreprise.

Dans certains cas, l’adoption des logiciels open source a doublé, voire davantage. Les développeurs bénéficient ainsi d’économies d’échelle : davantage d’outils sont disponibles et le marché accueille des développeurs mieux formés. Toutefois, l’ouverture et la vulnérabilité, tout comme l’agilité et la qualité, impliquent des compromis.

Figure 1 : nouveaux packages créés chaque année par écosystème

Utiliser des logiciels open source signifie confier à des personnes que vous ne connaissez pas la maintenance du code dont dépendent vos applications. Il est donc essentiel de recourir à des systèmes et à des outils pour limiter les risques potentiels.

3 risques liés à la sécurité des logiciels open source

Presque toutes les applications cloud-native reposent sur des composants open source. Cependant, personne n’étant responsable de leur maintenance ou de leur sécurité, les logiciels open source comportent de nombreux risques, notamment :

1. Vulnérabilités dans les dépendances open source

Il peut s’agir de vulnérabilités connues ou inconnues. Parmi les vulnérabilités connues figurent celles qui ont reçu un identifiant CVE (Common Vulnerabilities and Exposures), celles qui ont été divulguées sur Internet, celles qui sont répertoriées dans des bases de données publiques ou privées sur les vulnérabilités. En général, plus une vulnérabilité est connue, plus il est urgent de la corriger.

Outre le suivi des vulnérabilités, il est également essentiel de recenser chaque dépendance open source dans une application. Les dépendances transitives, c’est-à-dire celles qui reposent sur d’autres dépendances, sont particulièrement préoccupantes, car les outils de sécurité et les audits les détectent moins facilement. Il est donc utile de recourir à des outils ou à des processus capables d’identifier et d’auditer toutes les dépendances d’une application.

2. Risques liés à la conformité des licences

Les développeurs doivent comprendre chaque type de licence logicielle associé aux packages open source qu’ils utilisent afin de respecter les conditions d’utilisation du code. Ils doivent pour cela connaître les conditions de licence et veiller à leur respect dans l’ensemble des projets. Pour faire respecter les licences open source, les organisations doivent avoir une visibilité approfondie sur l’utilisation des composants open source. Il est également important de surveiller en continu les licences, car le titulaire des droits d’auteur peut modifier celle d’une bibliothèque.

3. Packages open source non maintenus

Les packages open source sont généralement maintenus par un seul développeur ou une petite équipe, quand ils le sont. Les développeurs de projets communautaires open source ne sont pas tenus d’en assurer la maintenance, et les logiciels sont fournis « en l’état ». Il incombe donc aux utilisateurs de consacrer du temps et des ressources à la sécurité du code. Heureusement, des outils peuvent simplifier cette tâche, comme Snyk Advisor, qui analyse les packages selon leur niveau de maintenance, leur communauté, leur posture de sécurité et leur popularité, afin de vous aider à évaluer la santé des packages open source que vous utilisez.

Vous souhaitez en savoir plus sur les risques liés aux logiciels open source ? Découvrez notre article sur les 5 risques potentiels des logiciels open source.

Statistiques clés du rapport State of Open Source

Les données sont source de connaissances. C’est pourquoi Snyk a interrogé des développeurs et des professionnels de la sécurité afin de mieux comprendre leurs préoccupations en matière de sécurité open source, les tendances des vulnérabilités dans les packages et les images de conteneurs, ainsi que les pratiques adoptées par les mainteneurs et les organisations pour sécuriser leurs logiciels. Nous avons publié les résultats dans notre rapport State of Open Source Security 2020. Voici quelques-unes de ses principales conclusions.

L’adoption de l’open source progresse

Les écosystèmes open source ne cessent de se développer, sous l’effet des exigences du marché et des réalités économiques. npm était en tête, avec une croissance annuelle de plus de 33 % et 1,8 million de packages en mars 2022. La majorité des vulnérabilités open source continuent d’être découvertes dans des dépendances indirectes :

• npm : 86 %

• Ruby : 81 %

• Java : 74 %

La culture de la sécurité open source évolue vers une plus grande implication des développeurs

Les personnes interrogées ont indiqué que la sécurité relevait d’une responsabilité partagée entre les services :

• 85 % estiment que les développeurs sont responsables de la sécurité open source

• 55 % estimaient que les équipes de sécurité en étaient responsables

• 35 % estiment que les équipes opérationnelles ont aussi un rôle à jouer

Tendances des vulnérabilités

Le nombre de nouvelles vulnérabilités a diminué de 20 % dans l’ensemble, et les vulnérabilités de type cross-site scripting (XSS) étaient les plus fréquemment signalées.

Figure 2 : vulnérabilités identifiées dans les écosystèmes depuis 2014

Défis liés aux conteneurs et à l’orchestration

Les images de base officielles portant l’étiquette « latest » comportent souvent des vulnérabilités connues. C’est notamment le cas de l’image officielle node, qui en présente près de 700. Plus de 30 % des participants à l’enquête n’examinent pas les manifestes Kubernetes à la recherche de configurations non sécurisées, et les exigences relatives aux contrôles des ressources de sécurité dans Kubernetes sont rarement appliquées.

Figure 3 : vulnérabilités dans les images de conteneurs officielles

Tendances de la sécurité open source en 2022

Au cours de l’année passée, plusieurs tendances ont dominé les discussions sur la sécurité open source : la sécurité de la chaîne d’approvisionnement, l’évolution de la culture en matière de responsabilité, la baisse du nombre de nouvelles vulnérabilités découvertes, la dépendance envers les mainteneurs bénévoles de projets open source et l’évolution des attentes en matière de correction des vulnérabilités.

Les attaques contre la chaîne d’approvisionnement sont plus fréquentes

Les composants logiciels tiers sont hébergés dans des dépôts centralisés qui constituent la chaîne d’approvisionnement logicielle. Celle-ci représente un vecteur d’attaque intéressant, car les acteurs malveillants peuvent cibler des points vulnérables du pipeline de développement sans modifier les dépôts logiciels. Ils peuvent, par exemple, exploiter des failles de conception lors d’une attaque par confusion de dépendance ou d’espace de noms, ou compromettre des composants tiers pour accéder aux données des utilisateurs et aux systèmes internes.

Chaque maillon représente un vecteur d’attaque potentiel. Il est donc important de sécuriser la chaîne d’approvisionnement, du code source au déploiement. Les vulnérabilités de la chaîne d’approvisionnement ne sont pas nouvelles, mais elles ont été au cœur des discussions en 2021 et figuraient régulièrement dans le décret présidentiel de Biden sur la cybersécurité.

La culture évolue vers une responsabilité partagée en matière de sécurité

À qui incombe la responsabilité de la sécurité ? L’une des évolutions les plus encourageantes que nous ayons observées est l’adoption d’une responsabilité partagée entre les équipes de développement, de sécurité et d’exploitation.

L’évolution vers une approche DevSecOps est positive, mais 47 % des personnes interrogées ont indiqué qu’elles n’avaient mis en place aucun programme spécifique pour encourager la responsabilité partagée. Seules 15 % ont instauré des programmes de champions de la sécurité, considérés comme une pratique essentielle dans le Software Assurance Maturity Model (SAMM) de l’OWASP. Cela montre qu’il existe un écart entre la prise de conscience de l’importance d’une responsabilité partagée et sa mise en pratique.

Le rapport State of DevOps de Puppet nous a également appris qu’à mesure que les organisations perfectionnent leurs pratiques DevOps, leurs pratiques de sécurité évoluent elles aussi.

« À mesure que les pratiques DevOps s’améliorent, DevSecOps s’installe naturellement. Les organisations les plus avancées ont adopté une approche shift left : la majorité d’entre elles intègrent la sécurité dans les exigences (51 %), la conception (61 %), le développement (53 %) et les tests (52 %). À l’inverse, dans la plupart des organisations de niveau intermédiaire, la sécurité intervient lors d’un audit de production planifié (48 %) ou lorsqu’un problème est signalé en production (45 %). »

Rapport Puppet State of DevOps 2021

Moins de vulnérabilités découvertes

Le rapport révèle de manière surprenante une baisse globale de 20 % du nombre de nouvelles vulnérabilités. Cette tendance est particulièrement remarquable, car les écosystèmes open source connaissent une croissance fulgurante.

Rien n’explique clairement pourquoi le nombre de vulnérabilités open source a diminué alors que certains écosystèmes ont plus que doublé de taille. Cela laisse toutefois penser que les progrès en matière de sensibilisation à la sécurité, de pratiques et d’outils portent leurs fruits.

Nous continuerons à suivre cette tendance, mais il est encore trop tôt pour relâcher la vigilance concernant les contrôles et les pratiques de sécurité.

Les mainteneurs open source contestent les pratiques des entreprises

Les tensions risquent de s’accentuer entre les mainteneurs open source et les entreprises ou organisations qui tirent des revenus de produits conçus à partir de leurs logiciels sans financer leur travail.

Une enquête de Tidelift menée en 2021 auprès de 400 mainteneurs open source révèle que 46 % ne sont pas rémunérés et que seuls 26 % gagnent plus de 1 000 dollars par an pour leur travail de maintenance. Plus de la moitié (59 %) ont abandonné ou envisagé d’abandonner la maintenance d’un projet, et près de la moitié des personnes interrogées ont cité l’absence de rémunération comme principale raison de leur insatisfaction à l’égard de ce rôle.

Ce mécontentement a des conséquences concrètes. En janvier 2022, par exemple, le mainteneur du très populaire package npm colors a introduit du code malveillant qui provoque une boucle infinie et rend le package inutilisable.

La version défectueuse de colors a été téléchargée plus de 95 000 fois. Colors est utilisé par de nombreux autres projets, notamment l’outil en ligne de commande prompt (environ 500 000 téléchargements par semaine) et aws-cdk d’AWS (environ 2 millions de téléchargements par semaine). La situation est donc très préoccupante.

Un incident similaire a touché le célèbre package npm faker, maintenu par la même personne. Le mainteneur a ouvert un ticket indiquant qu’il ne maintiendrait plus gratuitement les projets, utilisés par de nombreuses entreprises du Fortune 500.

Les délais de correction des vulnérabilités ne répondent toujours pas aux attentes

Selon l’enquête 2020 Open Source Security, 47 % des répondants s’attendent à ce qu’une vulnérabilité soit corrigée dans la semaine suivant sa découverte, et près de 18 % attendent une correction en moins d’un jour.

Figure 4 : délai attendu pour la correction des vulnérabilités open source

En réalité, seules 35 % des vulnérabilités détectées dans les projets analysés ont été corrigées en moins de 20 jours, tandis que 36 % ont nécessité 70 jours ou plus. Le délai moyen de correction était de 68 jours.

Il est clair que les organisations doivent ajuster leurs attentes concernant leur niveau de risque. Elles doivent tenir compte des SLA relatifs à la correction des vulnérabilités open source, en particulier lorsqu’un contributeur individuel est chargé de la maintenance du code.

Indicateurs clés pour votre stratégie de sécurité open source

Pour commencer, suivez attentivement les indicateurs de sécurité open source des bibliothèques que vous utilisez. Pensez notamment aux indicateurs suivants :

• Le nombre de jours entre la découverte d’une vulnérabilité et sa correction

• Le délai moyen de fusion d’une pull request après le signalement d’un problème

• Le temps nécessaire pour corriger vous-même le code

Ces réponses vous donnent une meilleure visibilité sur votre réaction aux problèmes de sécurité dans les packages que vous utilisez. Vous pouvez ainsi définir une stratégie de gestion des composants, et détecter et corriger les vulnérabilités.

Par ailleurs, adoptez une démarche proactive à l’égard des packages open source que vous utilisez. Envoyez des pull requests aux responsables de maintenance pour les informer des problèmes. Comprenez l’incidence des logiciels open source sur votre activité et élaborez un argumentaire en faveur de leur gestion systématique.

6 fonctionnalités à rechercher dans un outil de sécurité open source

Les outils de sécurité jouent un rôle essentiel dans une stratégie de sécurité open source. Ils permettent d’analyser automatiquement le code open source à la recherche de vulnérabilités connues et s’appuient sur des bases de données de vulnérabilités pour évaluer leur impact potentiel et proposer des mesures correctives. Ces outils peuvent surveiller en continu le code en production et intégrer la sécurité, ainsi que la gestion des licences et de la gouvernance, tout au long du processus de développement logiciel.

1. Vue complète des packages et des vulnérabilités qui les affectent

La visibilité sur les composants et dépendances open source étant un enjeu de sécurité, l’inventaire et l’évaluation automatiques des composants permettent de maîtriser votre environnement open source. Recherchez une automatisation qui identifie les composants dans les pipelines CI/CD et évalue le niveau de menace qu’ils représentent. Les composants vulnérables sont-ils réellement utilisés par l’application ?

2. Gestion des licences

Les outils de sécurité peuvent vérifier en continu le code tiers et le code personnalisé pour détecter les vulnérabilités et les risques liés aux licences, au fur et à mesure de l’écriture du code dans l’environnement de développement. Vous n’avez ainsi plus besoin d’analyser les dépôts de code.

3. Automatisation

Les outils de sécurité vous permettent de surveiller et de détecter automatiquement les vulnérabilités. En cas de violation, ils peuvent évaluer les dégâts et élaborer une réponse adaptée. Vous pouvez également définir des règles relatives aux corrections, aux demandes, aux correctifs et aux mises à niveau des dépendances afin d’automatiser ces processus.

4. Intégrations directes aux outils, workflows et pipelines d’automatisation des développeurs

Intégrer directement la sécurité aux outils et processus des développeurs simplifie la sécurisation du code. Les plugins permettent aux développeurs d’appliquer facilement des corrections depuis leur CLI ou leur IDE. Les intégrations GitHub permettent de tester les dépôts, les projets et les pull requests, puis d’appliquer des corrections au moyen de pull requests automatisées.

5. Base de données à jour et enrichie, qui va au-delà des CVE connues

Les outils de sécurité vont au-delà des bases de données publiques sur les vulnérabilités connues et constituent leurs propres bases de données organisées. Elles recensent notamment les vulnérabilités associées à un numéro CVE, figurant dans des avis de sécurité, repérées dans des outils de suivi des problèmes ou évoquées sur des forums et les réseaux sociaux.

6. Surveillance continue des projets

Les outils de sécurité peuvent surveiller en continu les applications en production afin de prévenir automatiquement l’exploitation des vulnérabilités. Les applications peuvent ainsi surveiller efficacement leur propre état et se défendre contre les attaques et les problèmes liés aux licences.

Pour en savoir plus sur le choix d’un outil de sécurité permettant de surveiller les composants open source, consultez notre guide Comment choisir des outils SCA.

6 avantages de Snyk pour la sécurité de vos logiciels open source

Snyk Open Source propose un outil de sécurité pensé pour les développeurs, qui intègre la sécurité des applications à l’ensemble du pipeline de développement logiciel. Vous pouvez ainsi créer et déployer des applications reposant sur des logiciels open source, tout en protégeant le code contre les vulnérabilités et les problèmes de licences.

1. Compatible DevSecOps

Snyk Open Source s’intègre au cycle de développement logiciel (SDLC) dès la première ligne de code. Nous avons beaucoup investi dans les intégrations afin de rendre l’analyse de sécurité et des licences aussi fluide que possible. Les développeurs deviennent ainsi directement responsables de la sécurité de leurs applications et peuvent collaborer efficacement avec les équipes de sécurité et d’exploitation.

Nous avons également créé un DevSecOps Hub, qui présente les technologies, les processus et les personnes qui aident les organisations à instaurer une culture DevOps intégrant efficacement la sécurité. Notre DevSecOps Community rassemble développeurs et responsables de la sécurité grâce à un portail d’assistance, des événements virtuels et en présentiel, ainsi qu’un programme d’ambassadeurs qui permet aux référents sécurité d’échanger plus directement avec Snyk.

2. Corrigez les problèmes directement dans les workflows intégrés aux outils des développeurs

Snyk Open Source s’intègre aux outils des développeurs, comme Atlassian Bitbucket, Visual Studio Code, Maven Central, GitHub et JetBrains. Les développeurs peuvent ainsi accéder à Snyk et détecter les vulnérabilités et les problèmes de licences directement dans l’outil de leur choix.

3. Peu de faux positifs

L’équipe d’experts en sécurité de Snyk gère la base de données afin de maintenir un faible taux de faux positifs. Elle analyse et teste chaque élément, attribue un score et un vecteur CVSS à chaque vulnérabilité, mène des recherches propriétaires pour en découvrir de nouvelles et fournit, le cas échéant, des résumés rédigés par des experts avec des extraits de code.

4. Arborescence des dépendances

Snyk utilise le gestionnaire de packages de votre application pour créer une arborescence des dépendances, qui s’affiche dans l’interface Snyk. Vous pouvez ainsi visualiser le composant à l’origine d’un problème et permettre à Snyk de le corriger, même s’il s’agit d’une dépendance transitive. Vous pouvez aussi automatiser la création d’une nomenclature logicielle (SBOM) directement dans les workflows des développeurs. Une fois votre SBOM créée, vérifiez-y les vulnérabilités de sécurité à l’aide de SBOM Checker de Snyk.

5. Corrections automatisées

Lorsque des corrections sont disponibles, Snyk les suggère automatiquement depuis la CLI, l’IDE et les pipelines CI/CD. Si aucune correction n’est disponible pour une dépendance, Snyk peut vous avertir dès qu’une correction le devient ou que de nouvelles vulnérabilités sont découvertes.

6. Gouvernance et licences

Snyk Open Source License Compliance Management vous permet de gérer les licences directement dans les workflows des développeurs, grâce à une application automatisée des politiques et à une gestion détaillée. Vous pouvez ainsi surveiller chaque étape, de la première ligne de code jusqu’au déploiement de l’application, et vous assurer que vos projets respectent toutes les licences.

Play Video: Snyk Open Source Security Overview

Section FAQ

Qu’est-ce que la sécurité open source ?

La sécurité open source englobe les risques auxquels les développeurs et les équipes de sécurité sont aujourd’hui confrontés lorsqu’ils utilisent du code open source tiers dans leurs applications, ainsi que les processus, méthodes et outils déployés pour les limiter. Les récentes attaques exploitant des vulnérabilités dans le code open source ont coûté très cher aux organisations. Elles soulignent l’importance de la sécurité open source et la nécessité de mettre en œuvre et de surveiller les stratégies associées.

Pourquoi la sécurité open source est-elle importante ?

Les logiciels open source alimentent la transformation numérique que nous observons aujourd’hui et sont utilisés par des entreprises de toutes tailles, dans tous les secteurs d’activité. Mais ils comportent aussi des risques. Les reconnaître est une première étape importante, qui doit être suivie par un investissement dans un plan de sécurité open source bien défini et maintenu, incluant des tests et une surveillance continus.

Quels sont les risques de l’open source ?

Les développeurs intègrent de très nombreuses dépendances open source sans disposer de contrôles de sécurité ni de visibilité. Ces composants sont maintenus par des bénévoles externes à l’organisation, qui ne sont pas tenus de les mettre à jour ni de les sécuriser. En outre, leur nature publique permet aux acteurs malveillants de découvrir et d’exploiter les vulnérabilités dès que les développeurs en ont connaissance. Ce ne sont là que quelques-uns des risques liés aux logiciels open source.