Analyse de sécurité en DevSecOps

1. État de l’utilisation de l’open source

Dans le développement, peu importe le langage de haut niveau utilisé, les librairies et les codes open source sont très utilisés aujourd’hui. Nous pouvons même aller jusqu’à dire que leur utilisation a explosé ces dernières années.

Cependant, ce n’est pas parce que ces librairies sont open source, gratuites ou libres, qu’elles ne sont pas exemptes de failles de sécurité. En effet, la plupart du temps, ces librairies ne sont maintenues à jour que par un groupe restreint de bénévoles qui donnent de leur temps personnel. C’est pour cette raison que les patches pour corriger les vulnérabilités sont beaucoup moins souvent déployés que sur d’autres types de librairies. 

Dans son rapport de 2022 sur l’état de la sécurité dans l’open source, la société Snyk (https://snyk.io) délivre plusieurs constats.

Plus un projet présente un nombre important de dépendances, plus il est complexe de le maintenir à jour en matière de sécurité et de veiller à ce que les librairies utilisées ne soient pas vulnérables. Or, en moyenne, en fonction du langage, le nombre de dépendances par projet est égal à :

Avec la même méthodologie, Snyk a calculé le nombre de vulnérabilités par projet en fonction du langage et obtient les résultats suivants :

1. Introduction au SAST

Le SAST correspond à des techniques qui se focalisent sur le code source, plutôt que sur le comportement « live » (comme le DAST), afin de détecter de mauvaises utilisations de fonctions, de librairies, ou des pratiques qui fragiliseraient la sécurité de votre application. L’analyse s’effectue donc avant même que le code ne soit compilé, ce qui représente un véritable avantage pour gagner un maximum de temps et résoudre les problèmes détectés avant que des ressources ne soient utilisées pour compiler le code et le déployer.

Le sujet fait débat, car la philosophie des outils SAST propose d’utiliser des scans automatiques sur le code source pour y détecter des problèmes, plutôt que de « perdre » trop de temps à former tous les développeurs sur l’ensemble des bonnes pratiques et des règles du développement sécurisé. La situation idéale se situe plutôt au milieu de la voie. En effet, il est plus intéressant de former à un niveau basique ou confirmé les développeurs aux techniques de développement sécurisé propres à leur langage, et d’utiliser des outils comme ceux de SAST, plutôt que de ne se reposer que sur les capacités du SAST à détecter les problèmes. Les outils SAST sont très puissants, mais ils présentent un problème bien connu de toutes les équipes sécurité : le nombre important de faux positifs. Un faux positif représente une alerte de sécurité à la suite d’une analyse, qui s’avère ne finalement pas être une vulnérabilité du fait...

1. Introduction au DAST

Jusqu’ici, nous avons surtout effectué des scans sur les dépendances et le code source de nos applications. Cela signifie qu’avant même d’être buildé et compilé, le code peut déjà être vérifié et modifié pour y corriger un certain nombre de vulnérabilités. Cependant, le comportement réel de l’application, ainsi que son environnement, n’ont pour le moment pas été pris en compte dans ces différentes analyses.

Les outils de DAST effectuent des scans de votre application depuis l’extérieur, comme un attaquant réel le ferait, pendant qu’elle est fonctionnelle et en cours d’exécution. C’est pourquoi le DAST ne s’applique qu’à la fin des pipelines CI/CD, puisqu’il est nécessaire que l’application soit buildée et exécutée.

Lorsque vous faites du DAST, les outils s’attardent surtout sur les inputs et les outputs de l’application, sans même avoir besoin de connaître les langages qui ont été utilisés pour son développement. Les outils DAST sont donc pour la plupart indifférents au langage.

Comme les tests sont effectués sur une application en cours d’exécution, il y a beaucoup moins de faux positifs qu’avec les méthodes de SCA ou de SAST. Cependant, la réalisation des tests prend beaucoup plus de temps, et nécessite la plupart du temps, à un moment donné, des actions manuelles.

Pour rentrer un petit plus dans les détails, le DAST cherche à découvrir et exploiter les vulnérabilités d’une application en cours d’exécution. Pour cela, il existe principalement trois étapes...

1. Introduction à Terraform

Terraform est un outil indispensable à tous les ingénieurs Cloud qui souhaitent s’inscrire dans la mouvance de l’Infrastructure as Code (IaC). Dans cette philosophie, tous les éléments de l’infrastructure et de ses services doivent être modélisés sous la forme de fichiers.

L’avantage le plus important de Terraform par rapport aux autres outils existants est qu’il est compatible avec tous les principaux fournisseurs de services Cloud. Il est donc inutile de vous connecter à l’interface web d’AWS, GCP ou Azure, il vous suffit d’écrire vos fichiers, qui vont décrire l’ensemble de l’infrastructure que vous souhaitez avoir.

Le deuxième avantage principal est l’idempotence, c’est-à-dire que, dans les fichiers Terraform, vous décrivez un état désiré de votre infrastructure.

Par exemple, vous dites que vous souhaitez avoir trois machines virtuelles dans la région Europe-west-3 qui s’appellent NGINX, MYSQL et BACKEND avec la configuration associée.

Terraform regarde alors quelles ressources existent déjà dans l’infrastructure et décide de ce qu’il doit ajouter, supprimer ou modifier. Imaginons que, sur votre infrastructure GCP, il n’y a pour l’instant que deux machines virtuelles dans europe-west-3 : NGINX et MYSQL. Terraform ne crée alors que la machine BACKEND, sans avoir à recréer les machines déjà existantes.

Terraform a besoin de deux étapes pour établir une topologie sur un fournisseur de services. Après avoir décrit l’infrastructure désirée dans vos fichiers, vous devez planifier les changements potentiels, grâce à la commande...

1. Objectifs

Nous allons développer une application très simple qui affiche une page web avec un champ depuis lequel l’utilisateur peut taper un mot de passe. Nous réutilisons le code password_check.py que nous avons développé plus tôt dans cet ouvrage pour vérifier si le mot de passe tapé appartient à la liste des 500 ou 10 000 mots de passe les plus utilisés.

Le premier Stage de notre pipeline a trois jobs qui effectuent les vérifications suivantes au niveau du code réalisé :

Une fois le code validé par les différents tests, il est intégré au sein d’une image Docker que nous construisons. Notre pipeline ajoute donc de nouveaux stages :

Nous terminons par la création de deux fichiers Kubernetes décrivant le Deployment de l’application, ainsi que la création d’un Service de type LoadBalancer afin de rediriger le trafic client. Nous analysons également la sécurité de ces fichiers avec deux jobs supplémentaires :

Vous pourrez ensuite continuer le pipeline pour...