78 % des vulnérabilités se trouvent dans des dépendances indirectes, ce qui complique leur correction
26 février 2019
0 minutes de lectureBienvenue dans le rapport annuel 2019 de Snyk sur l’état de la sécurité de l’open source. Ce rapport se compose de plusieurs articles :
Le nombre de packages sur Maven Central double ; npm indexe un quart de million de nouveaux packages
Hausse de 88 % des vulnérabilités dans les bibliothèques applicatives en deux ans
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, conçu 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
Dépendances indirectes
Il est difficile d’imaginer l’époque où l’on développait des logiciels sans aucune dépendance open source. La gestion des dépendances d’un projet est une tâche importante qui exige toute la diligence nécessaire pour assurer le suivi des bibliothèques dont vous dépendez. Après tout, l’application que vous déployez regroupe votre code et vos dépendances.
Dans npm, Maven et Ruby, la plupart des dépendances sont indirectes : elles sont requises par les quelques bibliothèques définies explicitement. Les vulnérabilités des dépendances indirectes représentent 78 % de l’ensemble des vulnérabilités.
Snyk a analysé plus d’un million de projets instantanés et découvert que les vulnérabilités des dépendances indirectes représentent 78 % de l’ensemble des vulnérabilités. Cela souligne encore davantage le besoin crucial de bien comprendre l’arbre des dépendances et de pouvoir identifier précisément les particularités du chemin menant à une vulnérabilité afin de la corriger.
Bien sûr, trouver les vulnérabilités dans une dépendance n’est qu’une première étape. Déterminer avec précision tous les chemins de l’arbre des dépendances par lesquels il est possible d’atteindre la dépendance vulnérable est une question plus complexe.
Pouvoir suggérer les mesures à prendre pour éliminer la vulnérabilité tout en préservant la compatibilité entre les dépendances représente un défi encore plus important et particulièrement intéressant.

Risques et impact
Seul un développeur sur trois peut corriger en une journée ou moins une vulnérabilité de gravité élevée ou critique
La plupart d’entre vous ne seront probablement pas surpris d’apprendre que, dans le rapport Octoverse de GitHub de cette année, la sécurité est la catégorie d’applications d’intégration de projets la plus populaire, avec plusieurs intégrations destinées aux développeurs. Voici une citation de Gartner, cabinet d’analyse du secteur, tirée d’un récent rapport sur la sécurité des applications, qui souligne la nécessité pour les entreprises de tester la sécurité le plus tôt possible dans le cycle de vie des applications.
Près de la moitié des répondants (43 %) ont au moins 20 dépendances directes, ce qui renforce le besoin de surveiller les vulnérabilités open source introduites par ces bibliothèques.
Plus nous utilisons de logiciels open source, plus nous accumulons de risques en intégrant le code d’autrui, qui peut contenir des vulnérabilités, aujourd’hui ou à l’avenir. En outre, le risque ne dépend pas uniquement du niveau de sécurité du code : il concerne aussi le respect des licences du code que vous adoptez et la conformité de ce code à sa licence.
« Les entreprises devraient utiliser régulièrement des outils SCA pour auditer les dépôts contenant des ressources logicielles (comme les systèmes de gestion de versions et de configuration), afin de s’assurer que les logiciels qu’elles développent et/ou utilisent respectent les normes, règles et réglementations en matière de sécurité et de droit. Les développeurs d’applications devraient pouvoir accéder à des outils SCA pour examiner les composants qu’ils prévoient d’utiliser. »
Mark Horvath
Hype Cycle For Application Security 2018, Gartner
Passez à l’action
La composition des applications est complexe. En tant que mainteneurs et développeurs open source, vous pouvez prendre des mesures pour renforcer la sécurité des projets que vous possédez et auxquels vous contribuez.
Mainteneurs open source
En tant que mainteneur open source, vous devriez proposer des versions sécurisées de votre code et mettre en place une stratégie de communication destinée à ses utilisateurs. Vous renforcerez ainsi la sécurité d’autres projets et applications, ce qui profitera probablement aussi à vos propres projets.
Dans la mesure du possible, procédez à des revues de code sécurisées avec vos pairs et appliquez les bonnes pratiques de codage sécurisé. Intégrez les considérations de sécurité à votre liste de contrôle pour les revues de code et formez les personnes chargées de les effectuer afin qu’elles sachent quels éléments vérifier.
Auditez régulièrement votre base de code à la recherche de vulnérabilités, par exemple au moyen d’analyses statiques et dynamiques du code. Vous pouvez automatiser ces analyses dans votre processus de développement afin de détecter plus facilement les vulnérabilités avant qu’elles ne soient rendues publiques.
Définissez clairement une procédure simple pour communiquer les divulgations responsables, en vous appuyant sur votre propre politique ou en renvoyant vers un programme existant. Pour faire connaître votre engagement en matière de sécurité, envisagez d’adopter une politique SECURITY.MD et un badge de projet indiquant son niveau de sécurité.
Mettez en œuvre une stratégie de sécurité intégrée dès le début du cycle de développement (shift left), qui donne à votre équipe une visibilité sur les problèmes de sécurité pendant le développement, l’intégration continue et même lors de la création des pull requests, afin d’empêcher tout code vulnérable d’intégrer vos projets.
Développeurs open source
En tant qu’utilisateur de composants open source, vous avez la responsabilité de bien comprendre les dépendances directes et indirectes de vos projets, ainsi que les failles de sécurité susceptibles d’exister dans leur arbre de dépendances. Pensez à adopter les bonnes pratiques de sécurité suivantes :
Auditez régulièrement votre base de code à l’aide d’un outil qui détecte automatiquement les vulnérabilités dans vos dépendances tierces, fournit des conseils de correction à votre équipe et surveille les dépendances d’un projet même après son déploiement.
Si vous signalez une vulnérabilité de sécurité, respectez les politiques de divulgation responsable afin de ne pas mettre les utilisateurs en danger. Si vous ne savez pas comment procéder, vous pouvez la signaler à une entreprise de sécurité qui vous accompagnera tout au long du processus, comme dans le cadre du programme de divulgation responsable de Snyk.
Abonnez-vous aux canaux de communication relatifs à la sécurité de vos dépendances open source, s’ils en proposent, afin d’être informé des éventuelles vulnérabilités dès qu’elles sont signalées.
Poursuivez votre lecture avec nos articles consacrés aux principaux enseignements :
Le nombre de packages sur Maven Central double ; npm indexe un quart de million de nouveaux packages
Hausse de 88 % des vulnérabilités dans les bibliothèques applicatives en deux ans
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
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.
