Les mainteneurs open source veulent renforcer la sécurité, mais 70 % manquent de compétences

Bienvenue dans le rapport annuel 2019 de Snyk sur l’état de la sécurité open source. Ce rapport se compose de plusieurs articles :

• Le nombre de packages Maven Central double ; npm indexe un quart de million de nouveaux packages

• Les vulnérabilités des bibliothèques applicatives ont augmenté de 88 % en deux ans

• 81 % estiment que la sécurité doit relever des développeurs, mais ceux-ci ne sont pas suffisamment équipés

• Les mainteneurs open source veulent renforcer la sécurité, mais 70 % manquent de compétences

• Les dix images Docker les plus populaires contiennent chacune au moins 30 vulnérabilités

• Les vulnérabilités ReDoS dans npm bondissent de 143 % et les attaques XSS continuent de progresser

• 78 % des vulnérabilités se trouvent dans des dépendances indirectes, ce qui complique leur correction

Vous pouvez également télécharger notre superbe rapport PDF réalisé avec soin, qui rassemble toutes ces informations et bien plus encore.

Télécharger le rapport 2019 sur l’état de la sécurité open source

La posture de sécurité des mainteneurs open source

La plupart des développeurs et des mainteneurs conviendront sans doute que la sécurité doit jouer un rôle important dans la création de produits et l’écriture de code. Toutefois, il n’existe pas de règles toutes faites à suivre pour créer des projets open source. Les normes de sécurité des mainteneurs peuvent donc varier considérablement.

Les mainteneurs consacrent leur temps et leurs efforts à différents aspects du projet, souvent fonctionnels, ce qui peut reléguer la sécurité au second plan dans leur processus.

Depuis notre précédent rapport, publié en 2017, l’engagement et la sensibilisation en matière de sécurité suivent une tendance positive. 

Les mainteneurs open source déclarent que leurs connaissances en sécurité s’améliorent, mais restent insuffisantes, avec une moyenne de 6,6/10

Cette année, la majorité des répondants ont évalué leurs connaissances en sécurité comme moyennes, avec une note moyenne de 6,6 sur 10. Une petite partie d’entre eux (7 %) les a jugées faibles. La proportion de répondants ayant des connaissances moyennes, qui représente la majorité, a en réalité baissé : elle est passée de 56 % l’an dernier à 63 % cette année.

Les évolutions les plus marquées concernent les niveaux faible et élevé. L’an dernier, seuls 17 % jugeaient leurs connaissances en sécurité élevées ; cette année, cette proportion atteint près de 30 %. Nous observons également une forte baisse des connaissances jugées faibles : elles concernaient 26 % des répondants l’an dernier, contre seulement 7 % cette année. 

70 % des mainteneurs open source déclarent ne pas avoir de solides connaissances en sécurité

Audits de sécurité

Un audit de sécurité peut être intégré à une revue de code, au cours de laquelle les pairs vérifient le respect des bonnes pratiques de codage sécurisé. Il peut également prendre différentes formes, comme les tests statiques ou dynamiques de sécurité des applications. Qu’ils soient manuels ou automatisés, les audits sont essentiels pour détecter et réduire les vulnérabilités de votre application. Ils doivent être réalisés aussi régulièrement et tôt que possible pendant le développement, afin de réduire les risques d’exposition et de fuite de données ultérieurs. 

Un mainteneur open source sur quatre n’audite pas sa base de code

L’an dernier, 44 % des répondants déclaraient n’avoir jamais réalisé d’audit de sécurité. Cette année, ce chiffre est nettement inférieur : 26 % des utilisateurs indiquent ne pas auditer leur code source. Nous observons cette année une évolution positive vers des audits répétés, tous cycles confondus. Par rapport au rapport de l’an dernier, la proportion d’utilisateurs qui auditent leur code source plus régulièrement a augmenté de 10 % en moyenne, pour les cycles trimestriels et annuels.

Les professionnels de la sécurité invoquent souvent le principe du « shift left » pour traiter les préoccupations et les problèmes potentiels de sécurité plus tôt dans le cycle de vie des applications. Cette approche peut aider les développeurs à découvrir de précieuses informations grâce à l’automatisation et permettre aux équipes de sécurité de suivre le rythme soutenu du développement continu moderne.

Détecter les problèmes plus tôt, en particulier en matière de sécurité, est essentiel, voire parfois crucial, pour réduire le coût des incidents découverts uniquement en production. Pour agir plus tôt et inciter les développeurs à adopter ces pratiques, il est possible de choisir des outils conçus pour eux et capables de s’intégrer à leurs workflows existants.

Comment les mainteneurs découvrent-ils les vulnérabilités ?

Les mainteneurs sont plus susceptibles d’être alertés d’un problème de sécurité que de le découvrir eux-mêmes. Une bonne pratique reconnue dans le secteur consiste à mettre en place une politique de divulgation responsable, qui explique comment les chercheurs en sécurité et les particuliers peuvent signaler sans risque les vulnérabilités aux mainteneurs du projet.

D’après les données de l’enquête, près de la moitié des répondants (48 %) découvrent une vulnérabilité dans leur code par un canal public, par exemple lorsqu’une autre personne ouvre un ticket public ou les contacte par e-mail.

72 % des utilisateurs déclarent découvrir les vulnérabilités de leur code en examinant eux-mêmes leur code. Cependant, 62 % indiquent avoir un niveau moyen de connaissances en sécurité, et seuls 30 % estiment que leur expertise en sécurité est élevée.

Par ailleurs, même si la majorité des utilisateurs (72 %) déclarent examiner leur propre code pour y repérer des vulnérabilités, 48 % ne les découvrent qu’après l’ouverture d’un ticket public par une autre personne. Cela montre à quel point il est difficile de compter sur un seul mainteneur pour examiner le code, même si cette personne est réputée bien connaître la sécurité.

De l’intégration à la divulgation

L’une des questions de recherche auxquelles nous voulions répondre était la suivante : combien de temps s’écoule entre l’introduction d’une vulnérabilité dans la base de code, sa découverte et sa divulgation ? Pour y répondre, nous avons analysé plusieurs bibliothèques npm populaires ainsi que les vulnérabilités qui y ont été découvertes en 2018.

Comme cette analyse est plus chronophage et difficile à automatiser avec précision, nous avons examiné les six principales bibliothèques npm et analysé leurs bases de code afin de comparer les dates des commits qui ont introduit et corrigé les vulnérabilités. Bien sûr, nos calculs sont légèrement biaisés en raison de la petite taille de l’échantillon, mais l’ordre de grandeur et les chiffres restent intéressants !

Parmi ces sept bibliothèques, le délai de correction le plus court à partir de l’introduction de la vulnérabilité était de près d’un an, soit exactement 289 jours. Le délai médian était de presque 2,5 ans, et le pire cas observé était de 5,9 ans.

À la une : Equifax, un an après

Un rapport récent du gouvernement américain a qualifié la célèbre fuite de données d’Equifax de totalement évitable et montré combien il est important de détecter les problèmes de sécurité plus tôt en intégrant la sécurité au workflow de développement.

Avec une approche DevSecOps et de bonnes pratiques, une équipe de développement aurait pu empêcher la vulnérabilité Struts d’avoir un tel impact si :

• les développeurs avaient détecté le problème grâce à des outils d’analyse des dépendances open source intégrés à leur workflow, sous forme de plugins d’IDE ou de linters de code.

• chaque nouvelle compilation lancée par un serveur CI avait automatiquement testé les dépendances de l’application à l’aide d’un plugin CI ou d’une commande CLI exécutée comme tâche. La nouvelle vulnérabilité aurait alors été immédiatement signalée, interrompant la tâche CI et imposant une correction avant de poursuivre.

• une solution de surveillance avait averti les développeurs de la nouvelle vulnérabilité dans leurs dépendances.

Une surveillance plus poussée et des informations sur le comportement de l’application à l’exécution, ainsi que sur les fonctions vulnérables qu’elle appelle, auraient pu signaler les vulnérabilités de la bibliothèque Struts.

Publication des correctifs

La rapidité de correction et de déploiement est essentielle à une divulgation responsable des vulnérabilités. Il est important de pouvoir corriger le problème le plus vite possible afin de réduire le temps pendant lequel la vulnérabilité reste dans le code, tout en laissant aux utilisateurs suffisamment de temps pour passer à une version corrigée, idéalement avant que l’information ne soit largement connue.

Les communautés open source reposant en grande partie sur le travail bénévole des développeurs (un GRAND merci à toutes les personnes formidables qui contribuent aux logiciels open source : votre travail généreux est très apprécié, même s’il est rarement reconnu ou salué publiquement !), il est intéressant de voir à quelle vitesse les mainteneurs de logiciels open source peuvent réagir à une vulnérabilité et publier un correctif.

Une écrasante majorité des utilisateurs, soit 84 %, déclarent qu’ils seraient susceptibles de publier un correctif en moins d’une semaine. 56 % pensent pouvoir traiter le problème en une journée, tandis que 22 % indiquent pouvoir corriger un problème de sécurité quelques heures seulement après le signalement de la vulnérabilité : tous les héros ne portent pas de cape !

Taux de correction

En examinant la Snyk Vulnerability Database, nous pouvons déterminer quels packages ont publié des versions qui corrigent des vulnérabilités. Le constat est loin d’être idéal pour certains écosystèmes — nous pensons notamment à JavaScript ! Java et Python présentent des écosystèmes très attentifs aux vulnérabilités, tandis que JavaScript et Node.js, dans leur ensemble, montrent que seuls 59 % des packages disposent de correctifs connus pour les vulnérabilités divulguées.

À la une : la divulgation responsable des vulnérabilités

L’un des principaux avantages d’une politique de divulgation responsable est de protéger les utilisateurs. Lorsqu’une vulnérabilité est signalée et examinée de manière confidentielle avec le mainteneur du projet, celui-ci peut préparer un correctif avant que l’information ne soit communiquée au grand public. S’il peut agir rapidement et publier un correctif, les utilisateurs disposent d’un délai pour passer à la version corrigée. Ce délai réduit considérablement le nombre d’utilisateurs qui utilisent les versions vulnérables.

Nous pensons qu’une politique de divulgation responsable témoigne également du fort engagement du mainteneur en faveur de la sécurité. Nous recommandons d’ajouter un badge sur la page d’accueil du projet et d’inclure un fichier de politique SECURITY.MD dans son dépôt.

Dans notre dernier rapport, nous avons constaté que les mainteneurs ayant mis en place une politique de divulgation publique sont beaucoup plus susceptibles de recevoir des signalements confidentiels de la part des utilisateurs que ceux qui n’en ont pas.

Environ 21 % des mainteneurs sans politique de divulgation publique ont été informés en privé d’une vulnérabilité, contre 73 % des mainteneurs qui en avaient une.

Les sites Web sont exposés aux vulnérabilités de sécurité Web et gagneraient à disposer de directives claires en matière de politiques de sécurité Web. Une proposition émergente visant à y contribuer est SECURITY.TXT (RFC 5785), déjà adoptée par les premiers acteurs. Un tel fichier de politique sert à communiquer efficacement aux chercheurs en sécurité les coordonnées pertinentes, les langages préférés, la politique précise et les moyens de communication, y compris les clés publiques permettant de divulguer une vulnérabilité de manière sécurisée et efficace. 

Poursuivez votre lecture :

• Le nombre de packages Maven Central double ; npm indexe un quart de million de nouveaux packages

• Les vulnérabilités des bibliothèques applicatives ont augmenté de 88 % en deux ans

• 81 % estiment que la sécurité doit relever des développeurs, mais ceux-ci ne sont pas suffisamment équipés

• Les mainteneurs open source veulent renforcer la sécurité, mais 70 % manquent de compétences

• Les dix images Docker les plus populaires contiennent chacune au moins 30 vulnérabilités

• Les vulnérabilités ReDoS dans npm bondissent de 143 % et les attaques XSS continuent de progresser

• 78 % des vulnérabilités se trouvent dans des dépendances indirectes, ce qui complique leur correction