Comment Voltos utilise Snyk pour sécuriser son propre produit de sécurité

Cet article invité est signé Glenn Gillen. Glenn est l’un des cofondateurs de Voltos, un service qui vous aide à gérer en toute sécurité les identifiants de vos applications et services, et l’un des contributeurs au cours en ligne Tiny Security Wins: Quick steps to secure your dev environment. Auparavant, il dirigeait l’écosystème des modules complémentaires chez Heroku et investit activement dans des startups en phase de démarrage qui créent des outils pour les développeurs.

La plupart des entreprises affirment publiquement qu’elles « prennent très au sérieux la sécurité de leurs clients », principalement parce que prétendre le contraire serait désastreux pour leur image. Pour toute entreprise qui développe un produit axé sur la sécurité, c’est un mantra que toute l’équipe doit appliquer au quotidien : ne pas le faire finirait par éroder la confiance des clients et nous ferait mettre la clé sous la porte.

Chez Voltos, nous aidons les développeurs à gérer et à partager les identifiants et la configuration de leurs applications avec leur équipe et dans toute leur infrastructure. Négliger la sécurité compromet à la fois nos clients et nous-mêmes : nous ne pouvons donc pas nous permettre de prendre le moindre risque. Parmi les premières leçons que j’ai apprises en sécurité informatique : ne partez pas du principe que vous êtes la personne la plus compétente, que vous avez toutes les réponses ou que vous avez pensé à tout. Et surtout, n’ayez pas peur de demander de l’aide.

Snyk veille sur vos arrières

Nous suivons plutôt bien les dernières annonces de CVE dès leur publication, puis nous appliquons rapidement les correctifs, testons et déployons les changements en production. Mais quiconque a déjà essayé sait que cela représente énormément de travail. Et avec un écosystème tentaculaire de dépendances imbriquées provenant des communautés Node, React et Ruby, la charge ne cesse de croître. Ajoutez à cela le fait que personne, ni aucune équipe de l’entreprise, ne peut consacrer 100 % de son temps à cette tâche : il est facile d’imaginer qu’une faille puisse passer inaperçue.

Et certaines sont effectivement passées entre les mailles du filet, comme la vulnérabilité d’exposition de la mémoire à distance de gravité moyenne illustrée précédemment.

Ce processus suppose aussi que suivre toutes les CVE suffit pour être aussi bien protégé que possible. Or, environ 85 % des vulnérabilités npm/Node présentes dans la base de données Snyk n’avaient fait l’objet d’aucune annonce de CVE !

Il nous a fallu moins de cinq minutes pour créer un compte Snyk, lancer une analyse de nos applications les plus critiques et trouver un problème. Un seul clic a suffi pour créer une pull request (avec des instructions pour résoudre le problème !). Nous étions convaincus immédiatement.

Une intégration parfaite au flux de travail

Les meilleurs outils sont ceux qui s’intègrent discrètement à votre flux de travail ou qui améliorent tellement votre productivité que vous adaptez votre façon de travailler. Quiconque a essayé d’utiliser PGP avec sa messagerie sait généralement ce qu’un outil axé sur la sécurité implique pour le flux de travail : c’est une vraie galère.

Ce que nous aimons chez Snyk, c’est que l’outil se fait oublier.

Chaque pull request est automatiquement analysée pour détecter les vulnérabilités grâce à l’intégration GitHub intégrée. Comme nous ouvrons des PR tôt pour discuter des nouvelles fonctionnalités, les nouvelles vulnérabilités potentielles sont détectées dès qu’elles apparaissent. Pas une semaine plus tard, au moment du déploiement, quand il faut se démener pour trouver des solutions de remplacement. Pas après la mise en production du code. Et pas lors d’un audit de sécurité trimestriel, alors que les clients sont exposés depuis trois mois.

Nos dépôts font également l’objet d’analyses régulières, indépendamment des modifications apportées au code, et Slack nous envoie par e-mail des notifications concernant les vulnérabilités découvertes depuis notre dernier commit. C’est très utile pour les bases de code plus stables et moins activement développées : il est facile de ne pas remarquer les éléments qui fonctionnent tranquillement en arrière-plan, alors qu’ils peuvent représenter un risque majeur.

Analyse ponctuelle

Il nous arrive de vouloir analyser la sécurité de notre code sans suivre notre flux de travail habituel avec les PR GitHub. Il peut s’agir d’un projet personnel, d’un essai sur une nouvelle branche que vous n’êtes pas prêt à partager, ou simplement d’une analyse dans un langage de programmation autre que celui configuré par défaut pour le dépôt. L’outil Snyk CLI nous permet de lancer cette analyse quand nous en avons besoin, sans nous imposer un flux de travail unique pour toutes les situations.

Joindre le geste à la parole

Il ne fait aucun doute qu’il est très utile de pouvoir compter sur un tiers pour nous aider à détecter les vulnérabilités. Mais, à mon avis, l’un des aspects les plus précieux est le rappel subtil, au sein de l’équipe, que la sécurité est une valeur importante à nos yeux.

Chaque pull request ouverte par un membre de l’équipe reçoit cette petite coche verte. C’est un rappel constant : la sécurité doit être prise en compte dans tout ce que vous faites, à chaque instant.