Guide de la sécurité open source

En raison de leur nature publique et collaborative, les logiciels open source ont gagné en popularité ces dernières années : ils simplifient la tâche des développeurs, mais aussi celles des acteurs malveillants. Quand une faille dans un code open source est rendue publique, les pirates peuvent alors cibler toutes les applications qui l’utilisent. Il suffit de se pencher sur le cas de Log4j et d’Apache Struts pour voir que toute vulnérabilité pose un risque réel et parfois sérieux pour les organisations.

Pour limiter les risques, une gestion efficace des composants et des dépendances open source est primordiale. Le problème ? Maintenir une bonne visibilité sur tous les composants open source d’une application n’est pas aisé, surtout quand il faut vérifier chacun d’eux en les recoupant avec une base de données de failles connues. Pour ne rien arranger, les dépendances imbriquées corsent un peu plus la tâche, car il faut non seulement sécuriser le code rédigé par les développeurs, mais aussi les éléments open source qu’ils utilisent et les dépendances à l’intérieur de ce code.

Dans cet article, nous verrons ensemble ce qu’est la sécurité open source, les risques propres aux logiciels open source et les outils et processus à adopter pour limiter votre exposition.

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

La sécurité open source vise à limiter les vulnérabilités et les risques inhérents aux logiciels tiers. Cette stratégie passe par des outils et des mesures permettant entre autres d’automatiser la découverte des bibliothèques open source et des dépendances dans le code, d’analyser comment ces éléments sont utilisés dans l’application et de déclencher des alertes ou d’envoyer des conseils de correction quand des vulnérabilités sont détectées. Certaines pratiques, comme la double authentification, peuvent ajouter un second niveau de protection face aux menaces.

Les logiciels open source offrent 4 grands avantages

Pour répondre à la demande, les développeurs doivent assurer des cycles de développement et de lancement logiciel plus courts. Ce rythme effréné les oblige à piocher davantage dans les ressources open source pour gagner du temps et compléter le code rédigé en interne.

Il faut dire que les avantages sont nombreux :

1. Le coût : les développeurs peuvent utiliser, modifier et partager des logiciels open source en accès gratuit sans avoir à gérer leur maintenance, qui est assurée par une communauté de bénévoles. Même les paquets open source payants sont peu coûteux si on les compare au temps nécessaire pour rédiger du code sur mesure de A à Z.

2. La facilité d’utilisation : préconfigurés et ouverts, les logiciels open source permettent aux développeurs de reprendre du code existant pour certaines portions simples et de consacrer plus de temps aux tâches à forte valeur ajoutée.

3. La qualité : étant donné qu’une communauté de développeurs rédige, utilise et inspecte le code open source, il contient théoriquement moins de bugs, et les vulnérabilités sont rapidement détectées et corrigées.

4. La rapidité : en tirant parti du contenu open source, les développeurs peuvent réduire le délai de mise sur le marché de leurs applications.

L’adoption des logiciels open source a plus que doublé dans certains secteurs. Cet essor génère de belles économies d’échelle, car l’offre d’outils est toujours plus vaste et des développeurs mieux formés à ce type de logiciels arrivent sur le marché. Le revers de la médaille de cette configuration ouverte, c’est qu’elle apporte aussi son lot de risques.

Figure 1 : nouveaux paquets créés par écosystème et par an

Quand vous utilisez des ressources open source, vous n’êtes pas maître à bord : vous devez compter sur de parfaits inconnus pour assurer la maintenance du code qui alimente vos applications. Aussi, il est primordial d’utiliser des systèmes et des outils pour minimiser les dangers.

Les logiciels open source présentent 3 risques de sécurité majeurs

La quasi-totalité des applications natives du cloud a recours à des composants open source. Toutefois, comme personne n’est directement responsable de la maintenance et de la sécurité des logiciels open source, ceux-ci comportent leur lot de risques. Notamment :

1. Les vulnérabilités dans les dépendances open source

Il y a les failles connues et celles qui n’ont pas encore été détectées. Dans la première catégorie, on retrouve les dysfonctionnements qui ont reçu un numéro de type Vulnérabilités et expositions courantes (CVE), les bugs mentionnés sur le Web et les failles recensées dans les bases de données des vulnérabilités publiques et privées. En général, plus une vulnérabilité est connue, plus il est urgent d’agir pour la corriger.

Parallèlement au suivi des vulnérabilités, il est aussi primordial de recenser chaque dépendance open source au sein d’une application. Les dépendances transitives – à savoir les dépendances qui reposent sur d’autres dépendances – sont particulièrement sensibles, car les outils de sécurité et d’audit peuvent avoir du mal à les repérer. Il est donc important d’adopter des solutions et des processus capables d’identifier et d’auditer toutes les dépendances d’une application.

2. Les risques liés à la conformité des licences

D’un bout à l’autre de leurs projets, les développeurs doivent scrupuleusement respecter les modalités d’utilisation de chaque licence logicielle contenue dans un paquet open source. Pour garantir un emploi conforme aux licences open source, votre organisation doit avoir une visibilité parfaite sur les composants qui sont utilisés dans vos applications. Il est aussi important d’opérer un suivi régulier sur vos licences, car le détenteur des droits d’auteur peut parfois modifier leur portée au sein d’une bibliothèque.

3. Le manque de maintenance des paquets open source

Typiquement, la maintenance des paquets open source – quand maintenance il y a – est menée par un développeur en solo ou une petite équipe. Dans la communauté open source, les développeurs n’ont aucune obligation de tenir à jour leur logiciel, qui est proposé « en l’état ». Aussi, il incombe aux utilisateurs d’investir le temps et les ressources nécessaires pour vérifier que le code est sûr. Heureusement, de nombreux outils peuvent vous simplifier la tâche. C’est notamment le cas de Snyk Advisor, qui analyse les paquets par niveau de maintenance, communauté, posture de sécurité et popularité pour vous aider à bien évaluer la santé du contenu open source que vous utilisez.

Envie d’en savoir plus sur les risques liés aux logiciels open source ? Cet article passe en revue 5 risques potentiels de ce type de logiciel.

Les statistiques clés de notre rapport sur la sécurité des logiciels open source

Snyk a mené son enquête auprès des développeurs et des experts de la sécurité pour connaître les risques, les tendances et les failles propres aux images de conteneurs et aux paquets open source, ainsi que les mesures adoptées par les organisations et les personnes en charge de la maintenance du code pour sécuriser leurs logiciels. Nous avons compilé nos résultats dans notre État des lieux de l’open source en 2020. Voyons ensemble ces principales conclusions :

L’open source connaît une adoption croissante

Portés par une demande élevée et les contraintes des entreprises, les écosystèmes open source sont aujourd’hui en pleine expansion. Le leader du secteur est npm, qui enregistre une croissance de plus de 33 % et compte 1,8 million de paquets dans sa bibliothèque en mars 2022. La majorité des vulnérabilités des systèmes d’exploitation sont toujours repérées dans des dépendances indirectes :

• npm : 86 %

• Ruby : 81 %

• Java : 74 %

Les développeurs ont une responsabilité accrue dans la sécurité open source

Les participants à notre enquête considèrent que la sécurité est une responsabilité partagée entre plusieurs services :

• 85 % jugent que les développeurs ont une responsabilité à tenir

• 55 % jugent que l’équipe chargée de la sécurité a un rôle à jouer

• 35 % jugent que les opérations doivent participer à la sécurité

Les tendances en matière de vulnérabilités

Au global, les nouvelles vulnérabilités ont baissé de 20 %. Ce sont les failles de type cross-site scripting (XSS) qui sont les plus répertoriées.

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

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

Parmi les images de base officielles récentes, beaucoup comportent des failles connues. À elle seule, l’image de Node officielle contient près de 700 vulnérabilités référencées. Plus de 30 % des participants à notre enquête n’examinent pas les manifestes Kubernetes pour y rechercher des configurations vulnérables. Par ailleurs, les exigences dictées par Kubernetes pour les contrôles des ressources ne sont pas systématiquement appliquées.

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

Les tendances de la sécurité open source en 2022

Ces dernières années, des thèmes tels que la sécurité des chaînes d’approvisionnement, l’évolution de la responsabilité, la baisse des nouvelles failles détectées, la dépendance aux bénévoles pour la maintenance du code open source et les nouvelles attentes en matière de correction des vulnérabilités dominent le discours sur la sécurité open source.

Les chaînes d’approvisionnement deviennent une cible de choix

Les composants de logiciel tiers se trouvent dans un référentiel centralisé : c’est ce qu’on appelle la chaîne d’approvisionnement logicielle. Les pirates s’y attaquent volontiers, car ils peuvent ainsi cibler des points vulnérables dans le pipeline de développement sans avoir à changer de référentiel. Ils peuvent par exemple utiliser des failles de conception à l’aide d’une attaque par confusion de dépendance/de noms d’espaces, ou encore exploiter des composants tiers pour corrompre les données utilisateur et accéder aux systèmes internes.

Chaque maillon est un vecteur potentiel d’attaques : il est donc vital de sécuriser toute la chaîne, du code source au déploiement. Il ne s’agit pas d’un problème nouveau. La sécurité de bout en bout était déjà au cœur des conversations en 2021 et fut un leitmotiv du décret présidentiel sur la cybersécurité de Joe Biden.

L’évolution vers une responsabilité partagée en matière de sécurité

Il est très intéressant de voir qu’on se dirige vers un consensus sur une responsabilité partagée entre les développeurs, les équipes de sécurité et les opérations.

Si cet engouement pour l’approche DevSecOps est le bienvenu, 47 % des participants sondés avouent ne pas avoir de programme dédié pour inciter à la responsabilité partagée, et seuls 15 % ont déployé un programme d’ambassadeurs de la sécurité. Il s’agit pourtant d’une pratique clé selon le modèle OWASP sur la maturité de l’assurance logicielle (SAMM). Autrement dit, la prise de conscience en matière de responsabilité partagée est bien réelle, mais les actions ne suivent pas encore.

L’état des lieux DevOps mené par Puppet nous révèle quant à lui qu’une organisation plus mature dans ses pratiques DevOps sera aussi plus mature dans ses pratiques de sécurité.

« Quand les pratiques DevOps sont améliorées, le DevSecOps suit naturellement. Les organisations à forte évolution sont passées à la sécurité shift-left, la majorité d’entre elles intégrant la sécurité dans les exigences (51 %), le design (61 %), la phase de build (53 %) et les tests (52 %). En comparaison, dans la plupart des structures moins avancées, la sécurité entre en jeu quand il y a un audit programmé de la production (48 %) et quand il y a un problème signalé en production (45 %). »

Puppet State of DevOps Report 2021 (État des lieux du DevOps en 2021 - Puppet)

Il y a moins de nouvelles vulnérabilités détectées

On observe une baisse de 20 % des nouvelles vulnérabilités signalées, ce qui surprend quand on sait que les écosystèmes open source sont en plein boom.

Aucune raison claire n’explique cette tendance dans un secteur qui grossit à vue d’œil. Il se peut que la sensibilisation à la sécurité porte ses fruits et que les pratiques et les outils de sécurisation soient plus efficaces.

Nous allons continuer à suivre ce phénomène de près. Pour l’heure, il est encore trop tôt pour relâcher sa garde en matière de sécurité.

La grogne monte parmi les gestionnaires de code open

Les bénévoles qui assurent la maintenance du contenu open source sont irrités de voir les entreprises monétiser des produits construits à partir de leur code sans leur reverser un centime.

Une enquête menée par Tidelift en 2021 en dit long sur le sujet. Sur les 400 gestionnaires de code open source sondés, 46 % ne sont pas payés et seulement 26 % touchent plus de 1 000 $ par an pour leur travail de maintenance. Plus de la moitié d’entre eux (59 %) ont déjà quitté ou envisager de quitter la maintenance d’un projet et près 50 % de ce panel place le manque de compensation financière en tête de ses doléances.

Cette grogne a des conséquences bien réelles. Par exemple, en janvier 2022, la personne en charge de la maintenance du très utilisé paquet colors npm a volontairement corrompu son code pour créer une boucle sans fin et faire échouer toute utilisation.

Cette version piégée a été téléchargée plus de 95 000 fois. Colors est employé dans de nombreux projets, comme l’assistant de ligne de commande (téléchargé 500 000 de fois par semaine environ) et aws-cdk d’AWS (téléchargé 2 millions de fois par semaine environ). C’est donc une menace qu’il ne faut pas prendre à la légère.

Un incident similaire s’est produit avec le paquet npm Faker, lui aussi très populaire et maintenu par la même personne. Il a exprimé son ras-le-bol dans un ticket où il indique qu’il n’acceptait plus de mener gratuitement la maintenance des projets (qui sont employés par de nombreuses entreprises du Fortune 500).

Les délais de correction des failles restent en deçà des attentes

Dans notre enquête sur la sécurité open source datant de 2020, 47 % des participants estiment qu’une vulnérabilité doit être corrigée en une semaine et près de 18 % fixent ce délai à un jour.

Figure 4 : attentes en matière de correction des vulnérabilités open source

La réalité est bien différente : seulement 35 % des failles décelées au sein des projets sont corrigées en moins de 20 jours. Dans 36 % des cas, la correction nécessite même 70 jours ou plus. Au global, le délai moyen de correction s’élève à 68 jours.

Les organisations doivent intégrer des délais réalistes dans leur posture de sécurité, en particulier quand un seul contributeur assure la maintenance du code concerné.

Les indicateurs clés pour votre stratégie de sécurité open source

Pour commencer, il est judicieux de suivre certains indicateurs de sécurité open source pour les bibliothèques que vous utilisez. Notamment :

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

• Le délai moyen de fusion des requêtes d’extraction suite à un ticket

• Le temps requis pour corriger le code par vous-même

Ces chiffres vous donneront de bonnes indications sur la qualité de votre réponse face aux problèmes de sécurité des paquets que vous utilisez. Ils vous guideront aussi pour créer une stratégie pour gérer les composants et déceler, puis corriger les vulnérabilités.

En parallèle, vous devez faire preuve d’initiative. Envoyez des requêtes d’extraction aux gestionnaires pour les alerter des problèmes, cartographiez l’impact du code open source sur votre entreprise et montez un dossier pour démontrer tous les avantages d’une gestion systématisée des logiciels open source à vos décisionnaires.

6 capacités indispensables dans un outil de sécurité open source

Comme leur nom l’indique, ces outils joueront un rôle central dans votre stratégie de sécurité open source. Ils sont capables d’automatiser la recherche de failles connues dans le code open source, de vous indiquer leur impact potentiel d’après les informations des bases de données des vulnérabilités et de vous aiguiller étape par étape pour corriger ces défaillances. Ces outils peuvent aussi suivre la production de code en continu et intégrer les questions de sécurité, de gouvernance et de respect des licences tout au long du cycle de développement logiciel.

1. Une vue complète des paquets et des vulnérabilités qui les affectent

La visibilité des dépendances et des composants open source faisant partie des défis de sécurité, un outil capable de recenser et d’évaluer automatiquement les composants vous donne un vrai contrôle sur l’environnement open source. Nous vous conseillons d’opter pour une automatisation qui peut identifier les composants au sein des pipelines de CI/CD et d’évaluer le degré de menace qu’ils posent pour savoir si des éléments vulnérables sont utilisés dans vos applications.

2. La gestion des licences

Les outils de sécurité peuvent scruter le code tiers et personnalisé en continu à la recherche de vulnérabilités et de risques de licence au moment de sa rédaction dans l’environnement de développement. De cette façon, il n’est plus nécessaire d’analyser les référentiels de code.

3. L’automatisation

Grâce aux outils de sécurité, vous pouvez automatiquement suivre et détecter les vulnérabilités. En cas de violation, ils peuvent recenser le contenu impacté et mettre sur pied une réponse appropriée. Vous pouvez aussi définir des politiques pour régir les correctifs, les requêtes, les patches et les mises à niveau de dépendances, et ainsi automatiser également ces processus.

4. L’intégration directe avec les pipelines d’automatisation, les workflows et les outils des développeurs

Quand la notion de sécurité est directement intégrée dans les outils et les processus de développement, la sécurisation du code est bien plus facile. Grâce aux plugins, les développeurs peuvent aisément appliquer des correctifs directement depuis leur CLI ou leur IDE. De la même façon, une intégration avec GitHub vous permettra de tester les référentiels, les projets et les requêtes d’extraction, mais aussi d’automatiser ces dernières pour l’application des correctifs.

5. Une base de données riche qui ne se limite pas aux vulnérabilités et expositions courantes

Les outils de sécurité proposent des bases de données propriétaires plus fournies que les listes de vulnérabilités connues accessibles au grand public. On y trouve les vulnérabilités référencées par un numéro CVE, celles sous le coup d’un avertissement de sécurité, celles qui sont reliées à un ticket, celles qui sont mentionnées sur les forums et les réseaux sociaux, et plus encore.

6. Le monitoring des projets en continu

Les outils de sécurité peuvent surveiller en continu les applications en production pour prévenir automatiquement toute exploitation d’une vulnérabilité. Grâce à ce soutien, vos applications sont mieux équipées pour se défendre en cas d’attaque ou réagir face à un problème de licence.

Pour savoir comment choisir le bon outil de sécurité pour monitorer vos composants open source, consultez notre guide dédié aux outils d’analyse SCA.

6 avantages de l’utilisation de Snyk pour votre sécurité open source

Pensé pour les développeurs, l’outil Snyk Open Source incorpore la sécurité des applications dans tout le pipeline de développement logiciel, vous permettant de créer et de déployer des applications intégrant du code open source tout en vous prémunissant des vulnérabilités et questions de licence.

1. Compatibilité DevSecOps

Snyk Open Source s’intègre dans le cycle du développement logiciel dès la première ligne de code. Nous avons investi sans relâche pour rendre l’analyse de la sécurité et des licences aussi fluide que possible. Les développeurs sont directement responsables de la sécurité de leurs applications, mais peuvent échanger de façon productive avec les équipes chargées de la sécurité et des opérations.

Nous avons également créé un Hub DevSecOps qui met en lumière les technologies, les processus et les synergies nécessaires pour développer une culture DevOps qui fait de la sécurité un fil rouge. Notre communauté DevSecOps, qui rassemble développeurs et leaders de la sécurité, vous donnera quant à elle accès à un portail d’aide, à des événements virtuels et en présentiel et à un programme d’ambassadeur dont les membres sont accompagnés de près par Snyk.

2. Correction directement dans les workflows des développeurs

Snyk Open Source peut s’intégrer dans les outils de développement comme Atlassian Bitbucket, Visual Studio Code, Maven Central, GitHub et JetBrains pour permettre à vos équipes de détecter et de corriger les vulnérabilités et les problèmes de licence dans leur outil préféré.

3. Peu de faux positifs

Les experts en sécurité de Snyk mettent tout en œuvre pour réduire au maximum le taux de faux positifs grâce à une base de données optimisée. Ils analysent et testent chaque élément de ce répertoire, attribuent un score CVSS et un vecteur à chaque vulnérabilité, mènent leurs propres recherches pour détecter de nouvelles failles et fournissent des résumés établis à la main avec extraits de code lorsque cela est possible.

4. Arborescence des dépendances

Snyk met à profit le gestionnaire de paquets de votre application pour créer et afficher une arborescence de ses dépendances dans l’interface utilisateur. Cela permet à notre outil d’identifier plus facilement tout composant vulnérable et de le corriger, même si cela concerne une dépendance transitive, mais aussi d’automatiser la création des nomenclatures de logiciels (SBOM), qui se fait directement dans les workflows des développeurs. Une fois que votre nomenclature est prête, vous pouvez l’analyser à la rechercher de failles à l’aide de l’outil SBOM Checker de Snyk.

5. Corrections automatisées

Snyk suggère automatiquement des mesures pour corriger les failles directement dans l’environnement CLI, l’IDE et les pipelines de CI/CD. Si aucun correctif n’est disponible pour une dépendance, Snyk peut vous alerter dès qu’il devient disponible ou si d’autres failles sont détectées pour cette vulnérabilité.

6. Gouvernance et respect des licences

L’outil de gestion de la conformité aux licences Snyk Open Source propose une application automatisée des politiques et un contrôle granulaire pour gérer vos licences directement depuis les workflows de développement. Il vous permet de garantir le respect des licences à chaque étape de vos projets, de la première ligne au déploiement de l’application.

FAQ

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

La sécurité open source vise à combattre les risques que les équipes de développement et de sécurité encourent lorsqu’elles exécutent du code open source tiers dans leurs applications. Cela passe par des mesures, des méthodologies et des outils de protection adaptés. Les dernières attaques exploitant des failles de code open source ont coûté très cher aux entreprises impactées, mettant en lumière toute l’importance de la sécurité open source et des stratégies associées.

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

L’open source alimente le processus de transformation digitale que nous observons aujourd’hui. Des entreprises de toutes tailles s’en servent dans tous les secteurs. Mais cette pratique comporte aussi des risques qu’il est important de bien cerner dès le début. Cette analyse initiale doit s’accompagner d’un plan de sécurité open source bien articulé, qui inclut monitoring et tests de sécurité continus.

Quels sont les risques inhérents à l’open source ?

De base, les développeurs n’ont pas de visibilité et de contrôles réels sur les dépendances open source qu’ils utilisent dans leur code. Ces composants open source sont maintenus par des volontaires extérieurs à l’organisation : ils le font de bonne grâce et n’ont pas l’obligation de mettre à jour ou de sécuriser leur contenu. De plus, en raison de la nature publique de l’open source, un acteur malveillant peut facilement étudier et exploiter les vulnérabilités qui sont signalées aux développeurs. Comme vous le voyez, le code open source présente de nombreux risques.