Utilisez les règles de sécurité Snyk pour hiérarchiser les corrections plus efficacement

Les règles de sécurité Snyk gagnent en puissance grâce à une nouvelle action et deux nouvelles conditions, qui aident vos équipes de développement et de sécurité à évaluer les risques et à mieux cibler leurs efforts.

Pour les développeurs, moins il y a de « bruit », mieux c’est. Leur demander de corriger des problèmes qui ne sont tout simplement ni importants ni pertinents leur fait perdre un temps de développement précieux et risque fort de susciter frustration et méfiance. Cela ne les incitera certainement pas à assumer davantage de responsabilités et à prendre en charge la sécurité au sein de leur organisation.

Les règles de sécurité peuvent vous aider : elles permettent de hiérarchiser les problèmes à traiter et ceux qui peuvent être ignorés jusqu’à la résolution des problèmes les plus critiques. Appliquées aux différentes étapes du cycle de développement logiciel (SDLC), elles permettent aussi d’éviter que des composants vulnérables ou non conformes passent entre les mailles du filet. Les règles font partie intégrante du cadre de gouvernance de l’organisation et respectent les normes de sécurité et de conformité adoptées en interne.

Le moteur de règles amélioré intégré aux règles de sécurité Snyk comprend une nouvelle action Ignore, ainsi que de nouvelles conditions (CVE et ID Snyk). Vous disposez ainsi d’une gouvernance plus souple et plus précise, et pouvez mettre en place des stratégies de hiérarchisation plus efficaces dans toute votre organisation. 

Ignorer plusieurs vulnérabilités à la fois

Une règle de sécurité Snyk contient une ou plusieurs règles qui définissent précisément la manière de traiter les vulnérabilités de sécurité. Les règles déclenchent des actions en fonction d’une ou plusieurs conditions. Jusqu’à présent, elles ne proposaient qu’une seule action : ajuster le niveau de gravité des vulnérabilités. Selon le CWE d’une vulnérabilité et/ou la présence d’un exploit, les utilisateurs pouvaient modifier son niveau de gravité.

Vous pouvez désormais aussi ignorer complètement certaines vulnérabilités. Vous pouvez le faire en fonction des conditions déjà prises en charge, mais aussi des deux nouvelles conditions que nous venons d’ajouter : CVE et ID Snyk. Cet outil vous permet de résorber votre backlog de vulnérabilités de plusieurs façons.

Par exemple, vous pouvez configurer une règle de sécurité pour ignorer les vulnérabilités sans exploit connu :

En associant la nouvelle condition CVE aux attributs de projet, vous pouvez également ignorer une vulnérabilité précise que vous savez non pertinente pour certains types d’applications :

Vous pouvez également ignorer toute une catégorie de vulnérabilités à l’aide de la condition CWE :

Gestion précise des règles

Les projets diffèrent les uns des autres et nécessitent probablement des limites de sécurité et de conformité différentes. Un projet essentiel à l’activité de l’entreprise, par exemple, exige un contrôle plus étroit et plus strict qu’un projet interne isolé dans un environnement de développement et de test.

Snyk vous offre la précision nécessaire pour décider exactement comment appliquer les règles au sein de votre organisation. Vous pouvez les appliquer à un projet ou à un groupe de projets à l’aide de tags et d’attributs de projet : ces deux types de métadonnées peuvent être ajoutés manuellement ou automatiquement via l’API Snyk. Ils permettent de regrouper les projets en fonction de caractéristiques communes. Vous pouvez également appliquer des règles à des organisations spécifiques au sein d’un groupe Snyk (consultez notre documentation pour en savoir plus sur la hiérarchie des groupes, des organisations et des projets Snyk).

Prenons un exemple, cette fois avec les règles de licence Snyk.

L’équipe juridique de l’organisation X a estimé qu’il fallait imposer des exigences de conformité extrêmement strictes à tous les services frontend essentiels à l’activité et en production. En revanche, elle se montre moins préoccupée par la conformité des projets internes en cours de développement.

Dans un premier temps, l’organisation X ajoute les attributs Critical, Production et Frontend aux projets concernés dans Snyk.

Dans un deuxième temps, une nouvelle règle de licence est créée. Les attributs nouvellement ajoutés permettent de l’affecter aux projets concernés. Dans la règle, un niveau de gravité élevé peut être appliqué à toute licence copyleft détectée dans les projets, comme les licences GPL-3.0 et AGPL-3.0. 

Appliquées à chaque étape du SDLC

Une fois créées, les règles de sécurité et de licence Snyk s’appliquent à tous les projets concernés et sont appliquées aux différentes étapes du SDLC. Cela commence dès l’environnement de développement local du développeur, dans l’IDE ou la CLI, puis se poursuit dans les workflows basés sur Git, la CI/CD et jusqu’en production. Ces différents points de contrôle de sécurité et de conformité permettent de signaler les problèmes le plus tôt possible dans le processus de développement, lorsque leur correction demande moins de temps et d’efforts.

Par exemple, pour les projets GitHub surveillés par Snyk, toute nouvelle pull request soumise par un contributeur est vérifiée par rapport aux règles de sécurité et de licence affectées au projet. Le code vulnérable ou non conforme ne peut ainsi pas être intégré au dépôt, et les normes internes de l’organisation sont respectées.

Dans l’exemple ci-dessous, j’essaie d’ajouter le package fullpage.js pour permettre le défilement plein écran dans mon application JavaScript. La vérification de sécurité est réussie (la dernière version du package ne présente aucune vulnérabilité connue), mais la vérification de licence échoue, car la licence GPLv3 incluse enfreint notre règle de licence.

En cliquant sur le lien Details, vous obtenez des informations et du contexte plus détaillés sur l’échec du test :

De la même manière, les règles s’appliquent en CI/CD et garantissent la conformité des builds aux exigences de sécurité et de conformité. Dans l’exemple ci-dessous, un workflow de build GitHub Actions échoue en raison d’une vulnérabilité de gravité élevée détectée lors de l’analyse de Snyk.

Sécurité et rapidité ne sont pas incompatibles

En sécurité des applications, les règles jouent un rôle essentiel : elles permettent de concilier rapidité du développement et sécurité. L’équilibre exact varie d’une organisation à l’autre, mais, lorsqu’elles sont correctement déployées, les règles permettent aux équipes de développement et de sécurité de respecter les exigences de sécurité et de conformité de l’organisation tout en maximisant leur productivité. 

Pour y parvenir, les règles doivent…

• être suffisamment flexibles pour permettre de définir des règles précises et de les appliquer dans toute l’organisation

• s’intégrer aux processus et workflows de développement plutôt que de les compliquer

• permettre de hiérarchiser efficacement les problèmes afin de maximiser l’efficacité et la sécurité

• offrir aux personnes ou aux équipes qui les gèrent une visibilité claire sur les règles appliquées et leur périmètre

• prévoir une gouvernance suffisante pour permettre une gestion centralisée et garantir la conformité.

Toutes ces capacités sont au cœur des règles Snyk. Pour en savoir plus sur les règles Snyk et leur utilisation, consultez notre documentation technique.