Santé des dépendances — évaluer les risques liés aux packages avec Snyk

Snyk a pour objectif de vous aider à utiliser l’open source en toute sécurité. Les vulnérabilités sont un indicateur de la mauvaise santé d’une dépendance, mais d’autres facteurs de risque entrent également en jeu.

C’est pourquoi toute une équipe travaille à faire de Snyk la référence pour obtenir des informations sur vos dépendances : de la sécurité aux licences, et désormais à leur santé.

Ce mois-ci, nous avons commencé à déployer la première phase de notre initiative Dependency Health, afin d’aider les développeurs à déterminer si l’une des dépendances de leur code présente un risque.

Catégories de risques liés à la santé

Les nouvelles informations sur les risques comprennent :

• Un indicateur signalant les packages obsolètes

• La date de première publication du package (maturité)

• La date de dernière mise à jour du package (activité)

• Dans les rapports uniquement, l’écart entre la version actuelle de votre package et la plus récente (retard de version)

Voici plus en détail ces nouvelles informations :

Statut problématique : ce package est-il obsolète ?

Pour npm, une dépendance est considérée comme « obsolète » si son responsable ne la met plus à jour. Nous signalons désormais ces packages sur snyk.io à l’aide d’une icône d’avertissement dans l’onglet Dependencies de vos rapports. Nous avons également ajouté un filtre qui vous permet d’afficher uniquement les packages obsolètes.

De plus, nous avons ajouté un avertissement sur la page du package concerné si sa dernière version est obsolète :

Parmi les packages concernés par cet avertissement, citons cryptiles, node-uuid et hoek.

Maturité — quand ce package a-t-il été publié pour la première fois ?

Lorsque nous avons demandé à notre communauté ce qui constituerait un signal d’alerte lors de l’installation d’un nouveau package, beaucoup ont cité la maturité en premier : ils voulaient savoir si le package existait depuis un certain temps. S’il avait été publié pour la première fois la semaine précédente, ils ne voudraient probablement pas l’installer. En revanche, une première publication datant de plus d’un an leur indiquerait qu’il est plus mature. Toutefois, certains packages peuvent être considérés à tort comme « matures » parce qu’ils existent depuis longtemps, alors qu’une seule version a été publiée. Nous affichons donc également la dernière version sémantique (semver). Si elle est inférieure à une version telle que 0.1.0, cela peut indiquer que le package est encore très peu abouti et qu’il vaut mieux attendre avant de l’utiliser. Nous affichons maintenant ces données dans le rapport :

Ces données figurent également sur la page du package :

Activité — le package est-il toujours maintenu ?

La date de dernière publication nous renseigne également sur le niveau d’activité du package. De nombreux packages sont de fait archivés, sans que leur responsable l’ait explicitement indiqué. Un package qui n’a pas été mis à jour depuis, par exemple, plus de 12 mois, ne le sera probablement plus. Il peut s’agir d’une bibliothèque conçue pour un usage unique et considérée comme complète, mais si ses dépendances ne sont pas mises à jour, elle présente un risque plus élevé.

Retard de version — des mises à jour sont-elles disponibles ?

Si vous préférez toujours utiliser la dernière version, nous affichons désormais une comparaison entre la version de la dépendance installée dans vos projets et la dernière version disponible pour ce même package (hors versions alpha et préversions).

Comme ces données concernent directement vos projets, elles sont uniquement visibles dans l’espace de rapports de Snyk.

Continuer à évaluer la qualité avec Snyk

Une note de 4,5 étoiles n’est pas un bon indicateur de la qualité d’un produit si elle ne repose que sur un seul avis. De la même manière, les données sur la santé des dépendances doivent être considérées dans un contexte plus large. C’est pourquoi nous enrichissons notre base de données avec différents indicateurs de qualité, afin d’aider nos clients à examiner les risques et à prendre des décisions plus éclairées. Nous vous recommandons de considérer chaque package dans son contexte global : il peut y avoir de bonnes raisons pour lesquelles il obtient un mauvais résultat selon un indicateur.

Et ce n’est pas fini…

Au cours des prochains mois, nous approfondirons et élargirons l’évaluation de la santé des dépendances : nous ajouterons des données aux catégories existantes, en créerons de nouvelles, comme la popularité, et proposerons des règles permettant d’automatiser l’évaluation.

Pour commencer

Les détails sont disponibles dans l’onglet Dependencies de l’espace de rapports Snyk (si votre offre Snyk inclut les rapports), ainsi que sur nos pages de packages, accessibles à toute la communauté open source.

Pour le moment, ces détails sont disponibles uniquement pour les packages npm. Dans les rapports, ces données sont actualisées chaque fois que Snyk crée un nouvel instantané du projet contenant la dépendance (par défaut, toutes les 24 heures).

Si votre offre inclut l’accès à notre API, vous pouvez utiliser notre Dependencies API pour créer vos propres rapports à l’aide de scripts. Vous pouvez également exporter au format CSV toutes vos dépendances afin d’aider votre équipe à hiérarchiser celles qui posent problème.

Essayez cette fonctionnalité et dites-nous quelles autres données vous aimeriez voir.