Snyk in 30 : démo sur une sécurité pensée pour les développeurs

Dans notre dernière démo Snyk in 30, j’ai montré comment travailler sur une application, depuis l’IDE jusqu’à sa mise en production dans le cloud. J’ai également expliqué comment Snyk s’intègre aux outils qu’un développeur utilise au quotidien. Plus précisément, je me suis concentré sur les aspects pratiques de l’intégration de Snyk dans un environnement réel de développement et de cloud, en répondant à des questions comme : 

• Comment rendre la sécurité aussi simple que possible pour les développeurs ?

• Comment utiliser les outils Snyk de concert sans générer d’alertes redondantes ni de bruit inutile ?

• À quoi ressemble Snyk du point de vue des développeurs et des équipes de sécurité ?

La sécurité doit être pensée pour les développeurs

« Pêchez là où se trouvent les poissons » est un vieil adage commercial qui nous rappelle d’aller à la rencontre de nos clients. Si vous faites partie d’une équipe de sécurité qui aide les développeurs à détecter et corriger les problèmes, allez là où ils se trouvent : dans leurs outils et leur workflow. Il est également important de leur fournir des informations pertinentes sur lesquelles ils peuvent agir. 

C’est un défi particulier avec les applications modernes. Bien souvent, chaque aspect d’une application est défini dans le code : ses procédures de build et de test, son mode de fonctionnement et l’infrastructure dont elle a besoin. Si cela accélère les déploiements, les rend plus reproductibles et plus résilients, les chaînes d’approvisionnement logicielles sont aussi bien plus complexes et évoluent beaucoup plus vite qu’il y a quelques décennies. 

Lorsque l’on tient compte de tous ces facteurs, les équipes de sécurité doivent relever un défi de taille : trouver comment sécuriser tous ces éléments en mouvement d’une manière que des équipes de développement déjà très occupées accepteront et mettront en œuvre. C’est là qu’intervient la notion de sécurité pensée pour les développeurs. Au lieu de demander aux développeurs de quitter leurs workflows et environnements habituels, les outils de sécurité conçus pour eux les aident à corriger les problèmes directement là où ils travaillent, tout au long du pipeline du code au cloud. « Pêchez là où se trouvent les poissons. » 

Découvrez ici comment la sécurité des applications renforce la sécurité globale.

Chez Snyk, nous avons fait de l’accessibilité et de la simplicité de nos outils de sécurité une priorité pour les équipes de développement. Nous aidons les développeurs à détecter et corriger les problèmes de sécurité tout en travaillant sur leurs projets : en écrivant du code et en concevant l’application dans l’IDE, en validant le code et en le stockant dans des dépôts, en fusionnant les changements dans la branche principale, puis dans les pipelines et le cloud. Voici les étapes abordées lors de cette démo Snyk : 

Sécuriser le code pendant son développement

Le moyen le plus efficace et le moins coûteux de détecter et de corriger un problème de sécurité consiste à intervenir dès son apparition. Il est plus facile pour les développeurs d’apporter une modification pendant qu’ils codent activement et choisissent les packages tiers à utiliser. L’objectif est de les guider pour qu’ils corrigent les problèmes pendant qu’ils ont le code sous les yeux. 

J’ai montré comment l’outil de test statique de sécurité des applications (SAST) de Snyk fonctionne dans les IDE : il analyse le code en quelques secondes pour permettre aux développeurs de continuer à travailler rapidement. Il synchronise également les conseils de correction et les informations sur chaque vulnérabilité détectée dans l’IDE. Les développeurs peuvent ainsi comprendre comment le problème de sécurité a été introduit, comment il se propage dans le code et comment le corriger.

Analyser les dépendances tierces en plaçant les développeurs au premier plan

En plus du code développé en interne, nous pouvons également sécuriser les dépendances tierces. L’outil d’analyse de la composition logicielle (SCA) de Snyk établit un graphe complet des packages tiers utilisés dans l’application, ainsi que de leurs dépendances transitives. Il identifie ensuite les composants vulnérables. Qu’il s’agisse d’un package ajouté par le développeur ou d’une dépendance indirecte, Snyk lui indique précisément où apporter une modification pour corriger la vulnérabilité. Lorsqu’ils ajoutent des packages, les développeurs peuvent aussi consulter un score de recommandation, qui signale les facteurs susceptibles de rendre le package risqué à l’avenir, même en l’absence de vulnérabilités connues. Nous calculons ce score en tenant compte de facteurs tels que la taille de la communauté du composant et sa popularité, qui sont de bons indicateurs pour déterminer si un package open source conviendra à votre application sur le long terme. 

Dans cette démo, je me suis surtout intéressé au code de l’application dans l’IDE.  Snyk peut également analyser les fichiers YAML Kubernetes, les configurations IaC et même les conteneurs pendant le développement, en temps réel, et fournir des conseils de correction similaires, pensés pour les développeurs.

Automatiser la sécurité dans le pipeline

Une fois le code terminé, il est validé, envoyé dans les dépôts et prêt à être fusionné. Snyk s’intègre aux dépôts de code, tels que Github, Gitlab et Bitbucket. Cela ajoute une couche de sécurité et permet aussi de surveiller le code, même lorsqu’il n’est pas activement développé, afin de détecter toute nouvelle vulnérabilité zero-day. Snyk permet également d’effectuer l’une des analyses les plus simples et les plus exploitables : la vérification des PR. Si un développeur enregistre et valide un composant vulnérable, nos outils le signalent dans la pull request. Ces vérifications sont configurées automatiquement lors de l’intégration d’un dépôt : l’équipe de développement n’a rien à faire. Nous vérifions également les modifications apportées au code afin de nous assurer qu’elles n’introduisent aucune nouvelle vulnérabilité. Ces vérifications intégrées garantissent que les nouveaux changements ne créent pas de nouveaux problèmes.

L’intégration aux dépôts nous permet également d’accélérer la correction des problèmes en créant des PR. Nous pouvons corriger une seule vulnérabilité, plusieurs à la fois ou mettre à niveau des composants obsolètes à l’aide d’une PR de correction. Si les équipes ont confiance dans leurs procédures de test, ces corrections peuvent être entièrement automatisées.

Sécurité des conteneurs et gestion du bruit

Les conteneurs sont aujourd’hui l’un des moyens les plus populaires pour empaqueter et exécuter des applications. Ils accélèrent les opérations et évitent le problème du « ça marche sur ma machine », mais peuvent générer beaucoup de bruit lors des analyses de sécurité. « Pêcher là où se trouvent les poissons », c’est bien, mais si vous jetez un rocher de 90 kilos dans le lac, vous allez faire fuir les poissons. Snyk résout ce problème de bruit grâce à ses vérifications de sécurité des conteneurs.

Dans la démo, j’ai présenté le résultat d’une analyse typique de conteneur pour mon application : plus de 700 vulnérabilités étaient répertoriées. J’ai ensuite montré comment Snyk suggère des actions que les développeurs peuvent entreprendre sans avoir à examiner toutes ces vulnérabilités. J’ai d’abord expliqué comment choisir une image parent (ou image de base) pour construire l’application. Nous avons vu comment Snyk formule des recommandations qui me permettent, en tant que développeur, de modifier une seule ligne dans mon Dockerfile pour choisir une meilleure image parent et éliminer des centaines de problèmes. 

Nous avons ensuite examiné un autre processus de build utilisé par de nombreuses entreprises : une équipe centrale, chargée de la plateforme ou du DevOps, sélectionne un ensemble interne d’images de base « de référence » que les développeurs doivent utiliser. Dans la démo, nous avons montré comment Snyk peut les guider vers ces images et les aider à se concentrer sur les vulnérabilités qu’ils risquent d’ajouter au conteneur, plutôt que sur le bruit généré par une image parent.

Sécuriser les déploiements en plaçant les développeurs au premier plan

Avec nos outils de sécurisation de l’infrastructure cloud, les développeurs peuvent également s’assurer que leurs configurations cloud sont sécurisées. Comme indiqué, ces analyses peuvent être exécutées dans l’IDE. Dans la démo, j’ai utilisé la CLI Snyk pour analyser la configuration Terraform. Là encore, les analyses IaC ont tendance à générer du bruit. Lorsque vous analysez uniquement le fichier de configuration, vous partez du pire scénario et signalez tous les problèmes possibles. Mais la situation change lorsque vous combinez les analyses IaC avec le contexte de l’environnement cloud en production. Dans la démo, nous avons examiné une application utilisant un compartiment de stockage AWS S3. En analysant uniquement l’IaC, j’ai obtenu quatre avertissements concernant des paramètres de sécurité incorrects pour le compartiment S3. Cependant, dans mon environnement cloud en production, une politique gérée de manière centralisée ignore ces paramètres non sécurisés et garantit la sécurité de chaque compartiment S3. Dans ce cas, Snyk a combiné l’analyse IaC au contexte cloud pour éliminer les alertes sans pertinence et se concentrer sur les problèmes de configuration plus importants. Et comme Snyk réunit le cloud et l’IaC, les équipes de sécurité n’ont qu’un seul moteur de politiques unifié à gérer pour couvrir l’ensemble de l’environnement de déploiement.

Snyk est aussi conçu pour les équipes de sécurité !

Même si j’ai consacré une grande partie de ma présentation aux fonctionnalités de Snyk pensées pour les développeurs, cette démo a également montré comment les équipes de sécurité utilisent nos outils. Snyk leur offre une visibilité centralisée et des rapports sur toutes ces vulnérabilités, dans chaque application et chaque ligne de code. Les équipes de sécurité peuvent consulter les détails des problèmes liés au cloud ou au code, puis affiner leur recherche par référentiel de conformité, environnement ou problème spécifique. Elles peuvent ensuite enregistrer les vues de rapport les plus utiles, puis les exporter ou les partager sous forme de liens. 

Regardez cette démo Snyk in 30 pour en savoir plus

Pour voir ces outils en action, regardez la démo Snyk in 30 dans son intégralité. En bonus, les participants ont également posé plusieurs questions pertinentes pendant la séance de questions-réponses. Au cours des dernières minutes du webinaire, nous avons pu aborder les sujets suivants :

• Les mesures de sécurité internes de Snyk lors du traitement du code de ses clients

• Plus d’informations sur notre partenariat autour du test dynamique de sécurité des applications (DAST)

• Plus de détails techniques sur notre intégration aux environnements de développement

Pour en savoir plus sur notre plateforme pensée pour les développeurs et approfondir cette séance de questions-réponses, regardez la présentation ici.