Ignorer des vulnérabilités avec Snyk

Ignorer une vulnérabilité ? Cela semble paradoxal. Pourquoi voudrait-on ignorer une vulnérabilité ?

Même si ignorer des problèmes de sécurité ne devrait pas être votre pratique par défaut, cela reste parfois nécessaire. Aujourd’hui, les équipes de développement et de sécurité font face à des milliers de vulnérabilités en attente de traitement. Pour maintenir un rythme de développement rapide, elles doivent pouvoir prioriser efficacement leur travail. Quelles vulnérabilités nécessitent une attention immédiate, lesquelles peuvent être traitées plus tard et lesquelles peuvent être complètement ignorées ?

Toutes les vulnérabilités ne se valent pas. Certaines sont critiques, tandis que d’autres présentent une gravité moindre. Certaines peuvent être corrigées immédiatement, d’autres non. Certaines vulnérabilités ne sont pas pertinentes pour certains projets (par exemple, une vulnérabilité par déni de service dans un service accessible uniquement en interne). Ces caractéristiques, parmi d’autres, constituent des raisons valables d’ignorer une vulnérabilité lors du triage.

Les solutions de sécurité doivent permettre aux développeurs de supprimer des vulnérabilités de leurs résultats, tout en donnant aux équipes de sécurité le niveau de contrôle nécessaire sur les personnes qui ignorent tel ou tel problème (et pour quelle raison). Là encore, ignorer une vulnérabilité n’est pas une bonne pratique en soi, mais une mesure à appliquer avec modération et conformément aux politiques de votre organisation.

Options d’ignorance dans Snyk

La plateforme Snyk propose différentes façons d’ignorer des problèmes : avec la CLI, l’API, l’interface utilisateur ou le fichier de règles .snyk. La méthode à utiliser dépend de votre cas d’usage, mais il est important de comprendre un principe : les exclusions dans Snyk sont locales. Cela signifie qu’elles sont limitées à un projet, à un type d’intégration et à une organisation. Par exemple, un problème ignoré dans un projet importé via GitHub ne sera pas ignoré dans un projet importé avec la CLI Snyk.

Examinons cela de plus près.

Utiliser la CLI Snyk

La CLI Snyk est un outil extrêmement utile qui vous aide à détecter et à corriger les vulnérabilités, manuellement dans votre environnement de développement local ou automatiquement dans le cadre de votre pipeline CI/CD. Vous pouvez analyser votre projet avec la commande snyk test. L’analyse renvoie la liste de tous les problèmes détectés dans le projet, ainsi que des recommandations de mise à niveau et de correction, le cas échéant.

Si vous souhaitez ignorer une vulnérabilité spécifique pour l’une des raisons décrites ci-dessus, que ce soit lors de vos tests locaux ou dans vos pipelines de build, utilisez la commande snyk ignore, qui accepte des sous-commandes facultatives (entre crochets). Ces sous-commandes vous permettent de définir la portée de l’exclusion : une date d’expiration de la règle et sa raison. La commande ci-dessous ignore une vulnérabilité d’exposition d’informations dans le package npm hbs, car aucune correction n’est disponible :

1snyk ignore –id=SNYK-JS-HBS-1566555 [--expiry=2022-05-30] [--reason=no fix available]

L’id est un identifiant unique que Snyk attribue aux problèmes. Vous le trouverez à plusieurs endroits dans l’interface Snyk. Si vous utilisez la CLI Snyk, l’identifiant figure à la fin de l’URL du problème dans la Snyk Vulnerability Database.

L’exécution de cette commande ajoute une nouvelle règle au fichier de règles .snyk. Si ce fichier n’existe pas encore, la commande le crée et y ajoute la règle. Toutes les analyses ultérieures exécutées avec snyk test respecteront cette règle.

Conseils pratiques :

• Vous ne savez pas quelle syntaxe CLI Snyk utiliser pour ignorer des problèmes ? Saisissez simplement snyk ignore –help.

• Dans les paramètres de votre organisation, dans l’interface Snyk, vous pouvez réserver aux administrateurs le droit d’ignorer des problèmes.

• Pour Snyk Code et les tests de dépendances non gérées dans Snyk Open Source, il peut être plus utile d’ignorer des répertoires que des problèmes individuels. La commande snyk ignore permet également de le faire.

Utiliser le fichier de règles .snyk

Comme indiqué précédemment, la commande snyk ignore crée un fichier appelé fichier de règles .snyk. Ce fichier sert généralement à configurer le comportement et la portée des commandes CLI snyk test et snyk monitor, ainsi que des tests exécutés via l’API et l’interface Snyk et des paramètres de langage. Vous pouvez également créer manuellement le fichier de règles .snyk à la racine du projet ou dans un répertoire spécifique du projet.

Pour ignorer des vulnérabilités, le fichier doit inclure un en-tête :

1# Snyk (https://snyk.io) policy file, patches or ignores known vulnerabilities.
2 version: v1.22.1

Il doit également inclure la syntaxe YAML suivante pour chaque règle d’exclusion :

1Ignore:
2  snyk-vulnid:
3    - path to library using > seperator :
4      reason: 'text string'
5      expires: 'datetime string'

Sachez que si le fichier de règles .snyk est stocké dans un sous-répertoire de votre projet, vous devrez en préciser l’emplacement lors de l’exécution de la commande snyk ignore dans la CLI Snyk.

Nous vous recommandons de gérer le fichier .snyk avec Git. Ainsi, les tests exécutés via l’interface Snyk respecteront les règles définies localement. Pour en savoir plus sur le fichier de règles .snyk, sa création et son utilisation pour ignorer des vulnérabilités, consultez notre documentation sur le fichier de règles .snyk.

Utiliser l’interface Snyk

Vous pouvez également ignorer des problèmes dans l’interface Snyk : cliquez simplement sur le bouton Ignorer sur la fiche d’un problème. Une fenêtre de dialogue s’ouvre et vous permet de choisir la raison de l’exclusion et sa durée. (Vous pouvez même décider d’ignorer un problème jusqu’à ce qu’une correction soit disponible.)

Lorsque vous choisissez l’option Ignorer pour un problème dans l’interface Snyk, plusieurs choses se produisent. Mais il est important de retenir que le problème lui-même ne disparaît pas. Ne vous inquiétez pas si vous venez d’ignorer une vulnérabilité critique !

Le problème ne s’affichera plus, mais vous pourrez toujours le consulter sur la page du projet en utilisant le filtre Ignorés, activé par défaut. Point important : toute action d’exclusion effectuée dans l’interface Snyk est consignée (avec des informations sur la personne qui a ignoré le problème, la date et la raison) :

1Ignore:
2  snyk-vulnid:
3    - path to library using > seperator :
4      reason: 'text string'
5      expires: 'datetime string'

Conseils pratiques :

• Les exclusions appliquées dans l’interface Snyk aux projets importés dans Snyk via la CLI Snyk (avec snyk monitor) sont synchronisées avec votre projet local. En revanche, les exclusions appliquées dans l’interface Snyk aux projets importés dans Snyk via une intégration de gestion du code source (SCM), par exemple GitHub ou Bitbucket, ne le sont pas.

• Dans les paramètres de votre organisation, vous pouvez exiger qu’une raison soit indiquée pour chaque exclusion effectuée dans l’interface Snyk.

Utiliser les politiques de sécurité (Snyk Open Source et Snyk Container uniquement)

Pour la plupart des organisations, il est important de pouvoir ignorer des problèmes à grande échelle de façon plus automatisée.

Les politiques de sécurité Snyk sont essentiellement des règles qui permettent de prioriser ou de déprioriser automatiquement les problèmes. Elles sont définies au niveau du groupe, dans l’onglet Policies de la barre de navigation de l’interface Snyk, et peuvent s’appliquer à des organisations ou à des projets spécifiques (avec l’option Attributs du projet). Vous bénéficiez ainsi d’un contrôle précis sur l’application de vos règles d’exclusion.

Pour ignorer des problèmes à l’aide des politiques de sécurité Snyk, définissez d’abord les conditions qui doivent être réunies pour qu’un problème soit ignoré, puis sélectionnez l’option d’exclusion.

Les exclusions appliquées par une politique de sécurité ignorent toutes les vulnérabilités correspondant aux conditions définies dans la règle. Elles s’appliquent à toutes les vulnérabilités existantes qui remplissent ces conditions, ainsi qu’à toutes les occurrences futures détectées. Les problèmes ignorés via une politique de sécurité sont signalés comme tels.

Par exemple, cette vulnérabilité de traversée de répertoires dans le package Python populaire Django a été ignorée par une politique définie pour les projets internes :

Conseil pratique : lorsque vous définissez l’action Ignorer dans une politique de sécurité, vous pouvez sélectionner les types d’exclusion Ne sera pas corrigé et Non vulnérable, puis ajouter la raison à afficher. Ces informations apparaissent sur la fiche du problème dans votre projet.

Utiliser l’API Snyk

Vous pouvez utiliser l’API Snyk pour appliquer des règles d’exclusion plus globales. Nous vous recommandons de faire preuve d’une extrême prudence, car cette approche pourrait entraîner des faux négatifs lors des étapes ultérieures de vos tests.

Une règle d’exclusion basée sur un chemin, configurée avec l’API Snyk, ressemblerait à ceci :

1POST https://snyk.io/api/v1/org/orgId/project/projectId/ignore/issueId

Le contenu de la requête API ressemblerait à ceci :

1{ 
2“ignorePath”:””,
3“Reason”:”no fix available”,
4“reasonType”:”wont-fix”,
5“disregardIfFixable”:true
6}

Vous pouvez également utiliser l’API pour créer une liste de problèmes ignorés. Nous vous le recommandons pour suivre les exclusions globales à l’échelle de l’organisation :

1https://snyk.io/api/v1/org/orgId/project/projectId/ignores

Autres bonnes pratiques en matière d’exclusions

La plateforme Snyk propose différentes façons d’utiliser les exclusions avec discernement, tout en offrant un niveau de contrôle qui permet d’éviter que des problèmes critiques passent inaperçus. Voici quelques bonnes pratiques à adopter avec ces méthodes.

Exiger une raison pour chaque exclusion

Nous vous recommandons d’exiger des développeurs qu’ils indiquent pourquoi ils ignorent un problème. Comme indiqué plus haut, les administrateurs peuvent imposer cette exigence pour les exclusions effectuées dans l’interface Snyk. Pour celles effectuées via la CLI ou l’API Snyk, vous devez demander à vos équipes de développement de suivre cette pratique.

Réserver les exclusions aux administrateurs

Nous vous recommandons d’activer l’option permettant d’utiliser les exclusions pour chacune de vos organisations dans Snyk. (Cette autorisation peut également être configurée dans l’interface Snyk.) Notez toutefois que cela ne limite que les exclusions effectuées avec la CLI et l’API Snyk. Les développeurs pourront toujours définir des règles d’exclusion dans le fichier de règles .snyk.

Examiner régulièrement les exclusions

Pour améliorer la visibilité, surveillez régulièrement les exclusions effectuées par vos différentes équipes dans votre compte Snyk. Pour cela, vous pouvez utiliser la commande curl indiquée plus haut afin de récupérer automatiquement la liste des problèmes ignorés et de l’examiner. Vous pouvez également consulter l’onglet Reports, où Snyk affiche le nombre de problèmes ignorés.

Procéder avec prudence

Ignorer un problème de sécurité, ou même un problème de licence, devrait toujours rester une exception plutôt qu’une pratique courante. Trouvez le juste équilibre entre la productivité des développeurs et les mesures de sécurité en définissant avec soin la politique d’exclusion acceptée dans votre organisation et en fournissant aux développeurs des outils qui leur permettent d’ignorer des problèmes dans les limites que vous avez fixées.

Voici quelques points à retenir sur la gestion des exclusions dans Snyk Code et Snyk Infrastructure as Code (Snyk IaC) :

• Ignorer des problèmes Snyk Code dans l’interface Snyk peut concerner un éventail de problèmes plus large qu’avec les autres produits Snyk. Pour comprendre pourquoi, consultez notre documentation. Notre article de blog Secure coding with Snyk Code: Ignore functionality with a twist approfondit le sujet des exclusions dans Snyk Code.

• L’utilisation du fichier de règles .snyk pour ignorer des problèmes détectés par Snyk Infrastructure as Code comporte certaines particularités, comme la restriction de la portée à un seul fichier. Pour en savoir plus, consultez notre article de blog Improve security by knowing when to ignore IaC vulnerabilities et notre documentation.

Bonne gestion des exclusions !