Le serverless, c’est formidable, mais qu’en est-il de la sécurité de mes fonctions AWS Lambda et de leurs dépendances ?

Les plateformes Function as a Service (FaaS) mettent à jour pour vous les dépendances de votre système d’exploitation, mais ne font rien pour sécuriser celles de votre application, par exemple celles provenant de npm, PyPI, Maven et autres. Ces bibliothèques sont tout aussi répandues et vulnérables que les dépendances du système d’exploitation. En tant que propriétaire de l’application, c’est à vous de les mettre à niveau ou de les corriger lorsqu’une vulnérabilité est divulguée.

De plus, sachant que les attaquants savent que les dépendances serveur au niveau du système d’exploitation, dont la mise à jour incombe au fournisseur cloud, sont rapidement corrigées, ils concentreront leur attention sur le code et les dépendances de l’application.

Pour souligner la complexité du suivi des dépendances d’une fonction, Snyk a montré dans son récent rapport State of Open Source Security 2019 que les vulnérabilités de sécurité dans les dépendances indirectes représentent 78 % de l’ensemble des vulnérabilités.

Cela signifie que, la plupart du temps, les vulnérabilités de sécurité se trouvent dans les dépendances indirectes installées par vos dépendances de premier niveau. Dans l’écosystème npm, une dépendance comporte en moyenne plus de 4 niveaux d’imbrication, ce qui complique le suivi de vos dépendances et de leur sécurité.

Comme pour le développement d’applications non serverless, vous devez chercher à protéger vos fonctions tout au long du cycle de développement. Commencez par l’environnement de développement intégré (IDE), à l’aide d’un plug-in qui vous signale les vulnérabilités des dépendances dont vous avez besoin pendant le développement, par exemple dans VSCode ou IntelliJ. Ensuite, testez la sécurité dans votre CI au moment de la compilation et avant le déploiement.

Et s’il existait un outil capable de vous aider à tester la sécurité en ouvrant automatiquement des pull requests pour corriger les vulnérabilités dès leur détection, ou en interrompant les builds d’intégration continue (CI) afin d’éviter les déploiements lorsqu’une nouvelle vulnérabilité de sécurité est introduite ?

J’ai partagé davantage d’informations sur la sécurité serverless dans un précédent article, 10 bonnes pratiques de sécurité serverless, que vous pourrez lire plus tard. Pour l’instant, poursuivons avec le récit de mon propre projet serverless :

Comment tester la sécurité de mes fonctions serverless sur AWS ?

Avec une plateforme serverless, il peut être difficile de surveiller les dépendances de sécurité des fonctions que vous avez déployées. Je vous propose de découvrir comment je procède avec Snyk pour mon propre projet personnel serverless, développé avec Node.js et déployé sur AWS Lambda.

Pour détecter et corriger automatiquement les vulnérabilités dans les dépendances de vos fonctions, commencez par connecter Snyk à un dépôt Git de votre choix.

J’ai testé avec mon dépôt personnel. J’ai parcouru mes dépôts GitHub pour trouver bazz, mon projet serverless. Une fois le projet analysé, j’ai moi aussi découvert des vulnérabilités de sécurité dans les dépendances utilisées par mes fonctions Lambda :

Oh là là ! J’ai pas mal de vulnérabilités dans mon projet frontend et dans le service API de mes fonctions serverless ! Il est temps de les éliminer. Je peux les corriger manuellement en ouvrant une PR de correction depuis l’interface Snyk de chaque projet, ou laisser le bot Snyk les détecter et ouvrir automatiquement une PR dans mon dépôt en mon nom. Il ne me reste qu’à vérifier que les tests réussissent, puis à fusionner la PR ! Regardez :

Imposer des déploiements sécurisés pour les fonctions serverless

En plus de la CI, de la surveillance des dépôts de code source et de l’application proactive de correctifs pour les vulnérabilités de sécurité, le processus de déploiement d’une fonction doit également faire l’objet d’un contrôle de sécurité. Les déploiements doivent être interrompus lorsque des vulnérabilités sont détectées dans les fonctions au moment de leur déploiement.

Imposer la surveillance de la sécurité de l’open source lors des déploiements serverless ajoute une couche de protection supplémentaire. Vous avez ainsi l’assurance que les fonctions ne sont pas déployées dans leurs environnements cibles avec des vulnérabilités open source connues dans les dépendances qui leur sont intégrées.

Le framework Serverless est une boîte à outils couramment utilisée pour développer et déployer des fonctions serverless. Son architecture de plug-ins permet d’intégrer des workflows personnalisés au cycle de vie des fonctions. Snyk propose un plug-in Serverless open source qui s’intègre facilement au framework.

Voici une image qui montre le plug-in protégeant activement une fonction contre son déploiement, après avoir détecté des vulnérabilités de sécurité dans ses dépendances open source :

Il est également recommandé de configurer le plug-in du framework Serverless pour créer un instantané des dépendances du projet à chaque déploiement, afin de les surveiller et de détecter toute nouvelle vulnérabilité dès sa découverte. Une solution comme Snyk peut vous alerter et corriger automatiquement le problème en ouvrant des pull requests qui corrigent les dépendances vulnérables.

Il faut parfois davantage de personnalisation et de contrôle sur le workflow CI/CD serverless. C’est là que l’utilitaire en ligne de commande open source de Snyk s’avère utile : il offre aux développeurs et aux ingénieurs DevOps un outil de sécurité flexible qu’ils peuvent intégrer à leurs workflows.

Vous pouvez installer Snyk dans un environnement local ou dans une tâche CI où le projet serverless est compilé, puis exécuter snyk test pour détecter les vulnérabilités, comme ceci :

$ npm install -g snyk
$ snyk test

Corriger les vulnérabilités de sécurité dès que possible est une bonne pratique. Il peut toutefois exister des écarts entre les versions des dépendances dans le dépôt de code source et celles présentes dans la fonction réellement déployée. Cela se produit surtout en raison des délais liés à la promotion du code vers un environnement de préproduction ou de production. La fonction déployée risque alors d’intégrer des dépendances obsolètes présentant des vulnérabilités connues.

Enfin, n’oubliez pas de consulter la liste détaillée que j’ai préparée : 10 bonnes pratiques de sécurité serverless ! Et créez un compte Snyk gratuit pour commencer à corriger les vulnérabilités.