La règle e-mail Ruby supprimée de Snyk Code

Snyk Code prend en charge différents langages importants dans l’écosystème cloud native, dont Ruby (et nous avons constaté une forte adoption : merci !). Nos chercheurs surveillent constamment nos ensembles de règles, en s’appuyant sur notre jeu d’entraînement composé de projets open source, mais aussi — et oui, c’est l’un des avantages d’un service SaaS — sur les performances des règles dans le code analysé. Pour rappel, Snyk n’utilise pas votre code pour entraîner ses modèles — mais nous agrégeons les statistiques d’utilisation.

Dans les données Ruby, nous avons repéré une anomalie (que des utilisateurs nous ont également signalée) :

Résultats relatifs de la règle HardcodedEmail par rapport aux autres.

Pourquoi nous avons supprimé la règle HardcodedEmail pour Ruby

Nous avions une règle qui recherchait les adresses e-mail dans le code Ruby et les signalait comme un problème potentiel de faible priorité. Même si il est recommandé de ne pas stocker d’adresses e-mail en dur dans le code, nous avons constaté que cette règle générait des alertes souvent ignorées ou laissées sans suite. Nous avons examiné les chiffres de plus près et il nous a semblé que le bruit généré n’avait aucun lien avec l’utilisation de la recommandation. Nous avons donc décidé de supprimer cette règle. D’autres règles s’appuient sur le flux de données pour détecter les identifiants ou les mots de passe mal utilisés : nous restons donc bien couverts à cet égard.

Qu’est-ce que cela signifie pour vous ? Si vous utilisez Ruby, attendez-vous bientôt à voir moins de résultats de faible priorité liés aux adresses e-mail.

Que retenir au-delà de la règle Ruby ?

Tout outil de test de sécurité des applications statique (SAST) — et, plus généralement, tout outil d’analyse statique du code — doit trouver un équilibre entre la précision (ne signaler que les vrais problèmes, au risque d’en manquer certains) et l’exhaustivité (détecter tous les problèmes possibles, mais générer beaucoup de bruit avec des faux positifs). Grâce à la rapidité de Snyk Code, nous pouvons tirer parti d’un jeu de test composé de 120 000 à 150 000 projets par langage, ce qui nous aide à maintenir cet équilibre entre précision et exhaustivité.

Nous disposons également des données d’utilisation de l’application Snyk. Nous nous en sommes servis dès le départ pour optimiser le système, et nous poursuivons ces efforts. Plusieurs raisons l’expliquent :

• L’environnement évolue constamment : JavaScript est célèbre pour voir apparaître une nouvelle bibliothèque à la mode toutes les deux semaines. Mais plaisanterie mise à part, chaque environnement de langage voit constamment apparaître de nouvelles bibliothèques ou évoluer celles qui existent. Nous utilisons le machine learning pour apprendre automatiquement ces évolutions et les intégrer à notre base de connaissances.

• Les bonnes pratiques ne sont pas toujours suivies : Même s’il est recommandé de ne pas inclure d’adresses e-mail codées en dur dans le code, nous devons accepter que la réalité soit parfois différente et qu’il existe de bonnes raisons de s’en écarter.

• De nouveaux types de problèmes apparaissent : Vous vous souvenez de Trojan Source ? Il s’agissait d’un type de problème entièrement nouveau, jamais observé auparavant. En quelques jours, l’équipe Snyk Code a pu proposer des règles pour le détecter dans tous les langages de programmation pris en charge, avec une grande précision.

Merci pour vos commentaires et vos suggestions d’amélioration du produit. En plus des décisions fondées sur les données, vos retours sont une source d’information précieuse pour nous. Nous vous écoutons et nous agissons. Si vous n’avez pas encore utilisé Snyk Code, c’est peut-être le bon moment pour commencer. Il vous suffit de créer gratuitement un compte Snyk pour obtenir des résultats en quelques secondes.

Essayez gratuitement notre outil de vérification du code Ruby pour découvrir comment Snyk Code analyse votre code et détecte les problèmes de sécurité et de qualité.