Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. DevSecOps
  3. Analyse de sécurité en DevSecOps
Extrait - DevSecOps Développez et administrez vos services en toute sécurité
Extraits du livre
DevSecOps Développez et administrez vos services en toute sécurité
1 avis
Revenir à la page d'achat du livre

Analyse de sécurité en DevSecOps

Introduction

Lors des différents chapitres précédents, nous avons abordé plusieurs outils et pratiques permettant de sécuriser vos développements et vos déploiements.

Revenons quelques instants sur les différentes étapes importantes du cycle de vie du logiciel sur lesquelles il est possible d’appliquer de la sécurité.

images/08EP01.png

Avant même de rentrer dans les détails de ce schéma, le Threat Modeling correspond à la première véritable étape à effectuer. Viennent ensuite les vérifications liées aux tests de « precommit » et de vérification des secrets au sein des dépôts de code. Nous retrouvons le SCA (Software Composition Analysis) permettant de référencer et de vérifier l’utilisation de dépendances qui pourraient être vulnérables, puis le SAST et le DAST. Ce sont ces différentes étapes que nous allons traiter dans ce chapitre.

SCA (Software Composition Analysis)

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 à :

  • 48 dépendances en moyenne pour un projet .NET.

  • 56 dépendances en moyenne pour un projet Go.

  • 40 dépendances en moyenne pour un projet Java.

  • 174 dépendances en moyenne pour un projet JavaScript.

  • 25 dépendances en moyenne pour un projet Python.

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 :

  • 23 vulnérabilités...

SAST (Static Application Security Testing)

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...

DAST (Dynamic Application Security Testing)

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...

Sécurité de l’Infrastructure as Code

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.

images/08EP34.png

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.

images/08EP35.png

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...

Développement d’une application Python au sein d’un pipeline DevSecOps

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é :

  • Vérification de la conformité du code de notre application avec Flake8.

  • Analyse statique de la sécurité des dépendances de notre code (SCA) avec Safety.

  • Analyse statique de la sécurité du code (SAST ou Static Application Security Testing) avec Bandit.

images/08EP60.png

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 :

  • Lint de notre fichier Dockerfile avec Hadolint

  • Build de l’image Docker

  • Tests des fonctionnalités principales de l’image Docker

  • Tests de sécurité de l’image avec Trivy et Dockle

  • Push de la release dans le GitLab Container Registry

images/08EP61.png

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 :

  • Lint des fichiers de Deployment et de Service avec KubeLinter

  • Analyse de sécurité des fichiers de Deployment et de Service avec Checkov

images/08EP62.png

Vous pourrez ensuite continuer le pipeline pour...

Conclusion

Dans ce chapitre, nous nous sommes focalisés sur les analyses de sécurité qu’il est possible d’effectuer au sein de pipelines d’intégration continue. Le SCA ou OSS est essentiel au vu des statistiques impliquant de nombreuses failles de sécurité dans la plupart des librairies open source que tous les développeurs utilisent. Heureusement, des outils sont disponibles pour nous aider à les identifier et à les corriger, quel que soit le langage de développement.

Lorsque la sécurité des librairies utilisées a été vérifiée, il est intéressant de passer ensuite au SAST afin d’analyser la sécurité du code source de l’application ou du logiciel. Ici encore, de nombreux outils sont à disposition, certains spécifiques à un langage, d’autres, comme Semgrep, généralistes et applicables à la plupart des langages. Mais le SAST ne fait qu’analyser le code source, et nous avons souvent besoin de compléter avec du DAST afin d’intégrer le comportement temps réel de l’application dans un environnement proche de celui de production. Pour effectuer du DAST sur des applications web, l’outil le plus utilisé reste Zed Attack Proxy, qui présente plusieurs niveaux de scans.

Lorsque notre code et nos images ont été vérifiés, nous pouvons chercher à automatiser leur déploiement dans les environnements des fournisseurs de service Cloud comme GCP, AWS ou Azure, via Terraform. Cependant il est possible d’intégrer de nouvelles failles inhérentes aux services Cloud utilisés, c’est pour cela qu’il est également important de renforcer la sécurité de nos déploiements avec des outils...