Skip to main content

81 % estiment que la sécurité relève des développeurs, mais qu’ils ne sont pas suffisamment outillés

Écrit par
the state op open source small

26 février 2019

0 minutes de lecture

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

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é de l’open source

Qui est responsable de la sécurité de l’open source ?

Nous avons cherché à savoir qui, dans la pratique, est aujourd’hui responsable de la sécurité d’une application ou d’une bibliothèque, et qui, selon les utilisateurs, devrait en assumer la responsabilité.

Selon 81 % des personnes interrogées, les développeurs devraient être responsables de la sécurité du code de leurs applications. Cette réponse souligne clairement le niveau d’implication et d’engagement attendu des développeurs et conforte le mouvement DevSecOps, auquel de nombreuses équipes adhèrent aujourd’hui.

Graphique à barres intitulé « Qui est responsable de la sécurité ? » indiquant que les développeurs sont responsables à 81 %, l’équipe de sécurité à 28 %, l’équipe des opérations à 23 %, personne à 12 % et les autres à 3 %.

Pour intégrer efficacement la sécurité au SDLC, il faut l’inclure dans l’ensemble du cycle de développement, de la conception à la mise en production. Cette approche diffère considérablement des tests de sécurité ponctuels plus traditionnels, menés à intervalles réguliers et inadaptés au modèle moderne de livraison logicielle, rapide et soutenu. Toutefois, les processus et les directives ne suffisent pas toujours. La formation, des outils simples d’utilisation et l’implication des équipes R&D et des parties prenantes sont tout aussi essentiels pour ancrer durablement les pratiques de sécurité dans une organisation.

Détecter les vulnérabilités

Il faut beaucoup de connaissances, d’expérience et un œil averti pour examiner correctement son propre code et y repérer d’éventuelles vulnérabilités. Cette tâche n’a rien de simple et, si elle est effectuée, elle ne l’est pas toujours. Le code vulnérable risque donc de passer inaperçu pendant longtemps. 

37 % des utilisateurs n’effectuent aucun test de sécurité pendant l’intégration continue (CI)

Les équipes qui pratiquent le DevOps ou disposent d’un pipeline CI/CD mature peuvent trouver plus facile d’intégrer des tests de sécurité à l’automatisation de leurs builds. Pourtant, nous constatons que près de 40 % des utilisateurs n’effectuent aucun test de sécurité lors de leurs exécutions CI. Un point encourageant, cependant : plus de la moitié d’entre eux testent au moins les dépendances open source pour y repérer des vulnérabilités. 

Autre constat de notre étude : les équipes qui intègrent la sécurité à leur travail réussissent aussi mieux la livraison continue. Pour cela, il est essentiel que les équipes de sécurité de l’information mettent à la disposition des développeurs et des équipes IT des bibliothèques, des packages, des chaînes d’outils et des processus préapprouvés, faciles à utiliser.

Nicole Forsgren, Accelerate

Graphique en barres intitulé « Tests de sécurité pendant l’intégration continue » : tests des dépendances open source à 57 %, absence de tests automatisés à 37 %, code source à 36 % et conteneurs à

Être informé des vulnérabilités

Du point de vue des utilisateurs, il est intéressant de comprendre comment ils sont informés des vulnérabilités dans les dépendances de leurs applications, afin de pouvoir réagir aux menaces potentielles dès qu’elles sont découvertes.

Un inquiétant 27 % des personnes interrogées déclarent ne disposer d’aucun moyen proactif ou automatique pour être informées des nouvelles vulnérabilités découvertes dans leurs applications. Seuls 36 % des utilisateurs confirment utiliser un outil de gestion ou d’analyse des dépendances pour détecter les vulnérabilités.

Diagramme en anneau montrant comment les développeurs découvrent les vulnérabilités : 36 % utilisent des outils d’analyse des dépendances, 27 % ont peu de chances d’en être informés, et les autres répondants ont donné d’autres réponses.

Quelques chiffres de Snyk

  • Au cours du seul second semestre 2018, Snyk a ouvert plus de 70 000 pull requests pour ses utilisateurs dans les écosystèmes Maven, RubyGems et npm, afin de corriger les vulnérabilités de leurs projets.

  • Parmi toutes les dépendances d’un projet Java analysé, Snyk a proposé une solution de correction pour 60 % des vulnérabilités détectées. Il n’est pas toujours possible de trouver une solution lorsqu’une dépendance directe est incompatible avec la version corrigée d’une dépendance indirecte. L’équipe sécurité de Snyk peut fournir des correctifs personnalisés pour résoudre certains de ces cas.

Délai d’adoption des correctifs de sécurité

Combien de temps faut-il aux utilisateurs pour adopter les nouvelles versions qui corrigent des vulnérabilités connues ? Nous avons examiné le registre PyPI de Python et son package websockets. Cet exemple montre que des versions vulnérables très utilisées l’étaient encore après la publication d’un correctif.

Le projet websockets est un package assez populaire et bien maintenu, lancé en 2013 et régulièrement mis à jour depuis.

En août 2018, une vulnérabilité de déni de service a été signalée à la communauté. Elle affectait les versions 4.0 et 4.0.1 du package. Au moment de sa divulgation, des versions plus récentes, intégrant le correctif de sécurité, étaient déjà disponibles dans le registre. Pourtant, les statistiques de téléchargement des versions vulnérables montrent que de nombreux utilisateurs ont continué à télécharger des versions vulnérables de websockets.

En décembre 2018, nous recensons encore 11 000 téléchargements du package websockets contenant la vulnérabilité, alors qu’une version corrigée, disponible sous la forme d’une mise à niveau majeure, existe depuis la version 5.0 de websockets.

Graphique linéaire montrant la baisse des téléchargements du paquet PyPI vulnérable websockets, de 30 000 en août à 11 000 en décembre 2018.

 Poursuivez votre lecture :

Lancez-vous dans les compétitions Capture The Flag

Apprenez à résoudre des défis de capture du drapeau en regardant à la demande notre atelier virtuel d’initiation.