DevSecOps is the new DevOps

phot hélène batard

Hélène Batard – Responsable Marketing

mars 16, 2023

Temps de lecture : 5 min

Sommaire

Le choix de développer sa propre solution logicielle (application lourde, site Internet, embarqué…) est bien souvent un facteur différenciant pour une entreprise. Il lui permet de mettre en valeur sa différence et sa valeur ajoutée.

Pourtant, le développement d’un tel logiciel est avant tout une aventure humaine. Elle va partir d’une idée pour aboutir, dans le meilleur des cas, à un produit. Comme toute aventure, elle possède une part de risques et aujourd’hui le plus important pour un développement logiciel est celui de la sécurité.

Il est important de noter, qu’ici, le mot sécurité, est pris au sens large et pas restreint à une facette de la sécurité logicielle. L’application doit être sécurisée dans sa conception, son développement et son exécution.

L’affaire Solarwinds de 2020 prouve qu’une erreur dans la sécurisation du code source de son application peut conduire à une cyberattaque de premier plan à l’échelle internationale et entacher pour de nombreuses années la réputation d’une entreprise.

Les attaques DDOS régulières par des réseaux de bots d’objets connectés démontrent le besoin de développer de vraies sécurités opérationnelles pour ces objets, mais également de former/forcer les utilisateurs finaux à éviter les comportements à risques (ignorer les mises à jour, ne pas changer les mots de passe par défaut…)

Les fuites de données récentes, comme celles d’une entreprise russe de covoiturage qui a mis en place du stockage externe un peu trop ouvert et qui permettait à tout un chacun de récupérer les documents d’identité des usagers de la plateforme, sont un bon exemple de problèmes de déploiement d’une application et probablement de gestion du passage à l’échelle.

Ces quelques exemples montrent que négliger la sécurité lors de la conception, le développement, le déploiement ou l’utilisation d’une application peut avoir de très lourdes conséquences sur une entreprise, un projet, un produit… les risques encourus vont du déficit d’image, à la faillite de l’entreprise en passant par toutes les problématiques juridiques possibles et imaginables quand on manipule des données sensibles.

Le développement sécurisé, c’est donc deux mots d’ordre : paranoïa et pragmatisme. Cela peut paraitre très antithétique, mais c’est à ce prix qu’une solution sera sécurisée.

schéma devsecops

🏁 Introduction au DevSecOps

Définition du DevSecOps

Les pratiques DevSecOps (Development Security Operations) consistent en une évolution des pratiques DevOps qui met la sécurité des applications ainsi que des infrastructures au cœur de chaque étape, du développement à la mise en production puis à l’opération.

Cette approche consiste notamment à placer la sécurité comme une pratique essentielle durant les phases de développement, mais aussi dans la mise en place d’outils de vérification automatique du code applicatif avant la mise en production, et enfin d’outils vérifiant la sécurité de l’application en production, mais également des infrastructures ; et ce, quel que soit l’environnement.

 

Objectifs du DevSecOps

L’objectif premier de cette approche est de réduire au maximum la surface d’attaque exposée à de potentiels acteurs malveillants.

Pour accomplir cet objectif premier, cette pratique peut être découpée en plusieurs sous-objectifs, notamment et de façon non-exhaustive :

  • Former les développeurs à délivrer un code plus sûr dès l’écriture
  • Garantir une première étape de la sécurité à travers des outils vérifiant le code dès son écriture (extensions dans les Environnements de Développement (IDE) : VScode, JetBrains par exemple)
  • Garantir lors des phases de build de l’application ou de l’infrastructure une vérification de la sécurité du code source et conforme à certains standards (outils de SAST – Static Application Security Testing)
  • Garantir une fois le build réalisé que l’application dans son état de production ne contient pas de vulnérabilités connues et facilement exploitables (outils de DAST – Dynamic Application Security Testing)
  • Utiliser un outil permettant de régulièrement auditer l’application dans chaque environnement pour vérifier la sécurité des accès au réseau ou la présence de CVE au niveau infrastructure ou système d’exploitation
  • Garantir la surveillance et la mise en place d’outils de sécurité permettant d’agir rapidement pour contenir une attaque détectée
  • Garantir que chaque détection de manquement à la sécurité de l’application ou de son infrastructure fera l’objet d’un changement planifié et sera résolue dans un temps raisonnable, proportionnel au risque de la faille détectée

📌 Les origines du DevSecOps

Il était une fois le DevOps

L’approche DevOps (Development Operations) a ouvert – il y a de nombreuses années – la voie au rapprochement des équipes de Développement (R&D – Recherches et Développements ou équipes produits) et d’Opérations.

Ce rapprochement a permis notamment d’itérer plus rapidement sur une solution et à chacune de ces équipes de comprendre et prendre en compte les problématiques de l’autre.

Ainsi, avec ces pratiques DevOps, le temps avant les mises en production des nouvelles fonctionnalités (features) d’une application ou de nouveaux éléments d’infrastructure ont été considérablement réduits.

Cette approche a notamment introduit et démocratisé de nombreux outils d’automatisation au sein des équipes, permettant notamment de construire ou compiler, de tester et de déployer le tout automatiquement.

Néanmoins, cette approche laissait de côté la sécurité, venant trop souvent contrôler l’application ou l’infrastructure uniquement une fois déployée, et pas à la source, laissant de nombreuses failles potentielles non-visibles par les équipes de sécurité lors de ces tests.

Il était donc essentiel d’introduire la sécurité à toutes les étapes du cycle de vie d’une application ou de son infrastructure en contrôlant la sécurité de façon continue.

 

Et avant le DevOps alors ?

Avant le DevOps, il était courant que le développement d’une application soit très long initialement, mais aussi durant son évolution.

De fait, les équipes de Développement et celles d’Opérations communiquaient peu entre elles, se blâmant parfois mutuellement lors des incidents ou des mises en production.

Pour des raisons d’agilité, mais également de l’évolution de la façon d’utiliser les applications et d’avoir des retours d’expérience des utilisateurs, il était nécessaire de pouvoir accélérer le développement des applications et donc la façon de les opérer.

Il était donc crucial de rétablir une communication entre le monde du développement et celui des opérations en créant un pont entre ces équipes, permettant d’itérer et ainsi de faire évoluer plus rapidement les applications et d’améliorer les méthodes d’opération et de surveillance de ces dernières.

Évidemment, les méthodes de gestion de projets ont été amenées à évoluer avec l’arrivée de ces nouvelles pratiques.

🌏 Et maintenant, ça se passe comment avec le DevSecOps ?

L’automatisation, au cœur du DevSecOps

Bien que l’utilité d’une équipe de sécurité soit indiscutable, il parait compliqué de faire reposer à cette équipe l’entière responsabilité de la sécurité de toutes les applications d’une entreprise, de la première ligne de code jusqu’aux mises en production.

Il est donc indispensable d’utiliser des outils d’automatisation afin de faciliter chaque étape du cycle de vie de l’application.

Il existe de nombreux outils d’automatisation, certains Open Source, d’autres avec des licences, ici sera présenté seulement le fonctionnement de ces outils.

 

Le linting

Parce qu’un code sécurisé est avant tout un code propre, il est nécessaire que chaque développeur ait un outil ou une extension de type “lint” installé dans son éditeur de code (IDE – Integrated Development Environment).

Cet outil permettra notamment de détecter de nombreux problèmes de syntaxe basiques :

  • Variables ou fonctions inexistantes
  • Variables ou fonctions inutilisées
  • Problèmes de syntaxe
  • Doubles déclarations
  • Non-conformité avec les “best practices” du langage (PEP8 ou PEP20 en Python, etc.)
  • Problèmes récurrents connus pour poser problème au compilateur si ce langage est compilé

Il existe des outils de linting pour presque chaque langage dans tous les IDE. Certains IDE intègrent par défaut ces outils lorsqu’ils sont spécialisés sur un langage en particulier (IntelliJ pour Java avec ESLint par exemple).

La pénurie de talents dans le domaine de la cybersécurité est un défi de plus en plus important pour les entreprises, les gouvernements et les organisations du monde entier. Avec la croissance rapide de la technologie et la dépendance accrue des organisations à l’égard des systèmes informatiques, la demande pour des professionnels qualifiés en cybersécurité ne cesse d’augmenter.

Mais on peut voir dans cette réalité inquiétante des opportunités sur le marché de l’emploi. Les métiers de la cybersécurité étant très recherchés, sont mis sur le devant de la scène. La mise en lumière de ce secteur, a donné naissance à de nouvelles vocations pour les jeunes et même des professionnels qui souhaitent se reconvertir, ou simplement muter vers un nouveau poste.

 

screenshot linter

On retrouvera souvent un linter dans le pipeline en première étape afin de remonter les erreurs aux développeurs si certaines ont pu être oubliées.

Ceci permettra dans certains cas de bloquer l’avancée du pipeline si des erreurs de syntaxes affectant la sécurité sont trouvées.

 

Le Static Application Security Testing

Cet outil, souvent nommé SAST, est en charge de trouver et faire remonter les vulnérabilités du code source.

Il peut dans certains cas faire remonter des failles de sécurité potentielles telles que :

  • Non-validation des paramètres d’entrée (saisies des utilisateurs ou variables passées entre les fonctions)
  • Permissions accordées trop larges
  • Ouverture des accès au réseau trop larges
  • Sensibilité aux attaques les plus communes (Injection SQL, XSS etc.)

À noter : chaque outil SAST est adapté à un ou plusieurs langages et permettra pour chaque langage un éventail de détections possible. Référez-vous à la documentation officielle de l’outil choisi pour avoir la liste complète des possibilités.

Ces failles de vulnérabilités sont – dans la plupart des outils – classées selon une criticité : Info, Low, Medium, High, Critical permettant aux équipes de se situer vis-à-vis de la sécurité du code source et des failles à corriger en priorité.

Il existe de nombreux outils SAST adaptés à chaque usage, très peu sur le marché couvrent tous les langages. Il sera donc nécessaire d’utiliser l’outil correspondant à l’usage, par exemple :

  • Semgrep pour le code applicatif (Python, Go, Javascript, etc.)
  • KICS (Keep Infrastructure Code Secure) pour le code infrastructure (Ansible, Dockerfile, Terraform, etc.)

Il s’utilise en général juste après une étape de lint et avant toute compilation ou déploiement. Il est supposé couper l’exécution du pipeline en cas de faille trouvée ayant une criticité supérieure ou égale au niveau choisi (par exemple arrêter l’exécution en cas de High ou en cas de Critical).

Le Dynamic Application Security Testing

Le DAST est un outil permettant d’effectuer des tests de sécurité en “boîte opaque”, donc sans connaissance du fonctionnement ou du code source.

Il s’exécute une fois l’application déployée dans un environnement proche de celui de production.

Il permet par exemple, en donnant l’URL[¹] de l’application Web ou bien l’IP et le port du service à tester, de tester les failles les plus communes auxquelles l’application est sensible, par exemple les 10 catégories d’attaques représentant le plus de risque de sécurité selon l’OWASP[²].

Les tests effectués par un outil DAST permettent ensuite d’avoir un rapport détaillé de toutes les failles détectées et classées selon leur criticité, en général : Info, Low, Medium, High, Critical

[¹] URL : Uniform Resource Locator, l’adresse http ou https d’un site internet

[²] OWASP : Open Web Application Security Project, une organisation caritative travaillant en communauté afin d’améliorer la sécurité des applications Web

L’Interactive Application Security Testing

Le IAST représente les outils capables de combiner les capacités d’un SAST et d’un DAST afin d’analyser d’un côté le code source et de l’autre, l’application, une fois déployée et de pouvoir établir des corrélations et des suggestions entre les deux.

L’Infrastructure as Code

Cette méthode, nommée IaC, consiste à utiliser un outil permettant le déploiement d’élément de l’infrastructure écrit sous la forme descriptive à l’aide d’un langage.

Bien que cet outil ne soit pas obligatoire à la mise en place des pratiques DevSecOps, ce dernier permet, lorsqu’il est utilisé, de les mettre en place depuis le code source au déploiement de l’infrastructure.

On pourra notamment utiliser un outil de SAST dédié permettant de faire remonter des problèmes de sécurité par exemple :

  • des ouvertures de ports trop larges sur un pare-feu
  • des permissions trop importantes sur des utilisateurs techniques
  • l’absence de certaines règles de pare-feu courantes pour les services exposés sur internet
  • la non-utilisation de solution de chiffrement au repos et en transit
  • etc.

On citera notamment Terraform et Pulumi qui permettent le déploiement sur plusieurs Cloud Provider tels qu’AWS, Azure, GCP, etc.

Les Pipelines

Les outils précédemment abordés dans cette leçon doivent être exécutés de façon séquentielle et automatiquement lorsqu’une nouvelle version du code source est envoyée sur le dépôt git.

Cette pratique d’automatisation prend place au sein d’une chaîne d’intégration et de déploiement continus nommé couramment une chaîne CI/CD (Continuous Integration/Continuous Deployment).

Le pipeline CI/CD est un outil qui, à l’aide d’un fichier descriptif, va exécuter des étapes séquentielles dans un environnement temporaire de développement permettant par exemple de :

  1. Cloner le dépôt git
  2. Linter le code source
  3. Exécuter un outil de SAST sur le code source
  4. Compiler le code source en application
  5. Faire des tests unitaires et fonctionnels sur l’application compilée
  6. Déployer l’application dans un environnement similaire à la production
  7. Lancer l’exécution d’un outil de DAST sur le point d’entrée applicatif
  8. Générer un rapport de chacune des étapes précédentes dans un format lisible
  9. Stocker le rapport dans un dossier distant
  10. Mettre à disposition l’archive contenant l’application compilée en tant qu’artefact de le pipeline.

Plusieurs pipelines peuvent s’enchaîner et dans le cas ci-dessus, le suivant pourrait être en charge de déployer l’application dans un environnement de démo ou de QA (Quality Assurance – Contrôle qualité) afin de tester de façon manuelle et humaine l’application avant sa mise en production.

Il est également possible dans la plupart des outils de pipeline de mettre en “pause” des exécutions ou d’attendre une intervention humaine. Par exemple, une fois l’étape de contrôle qualité humaine réalisée, une pipeline finale pourrait attendre une approbation d’un chef de projet afin de lancer la mise en production automatique de l’application.

On retrouvera souvent un linter dans le pipeline en première étape afin de remonter les erreurs aux développeurs si certaines ont pu être oubliées.

Ceci permettra dans certains cas de bloquer l’avancée du pipeline si des erreurs de syntaxes affectant la sécurité sont trouvées.

 

Le Static Application Security Testing

Cet outil, souvent nommé SAST, est en charge de trouver et faire remonter les vulnérabilités du code source.

Il peut dans certains cas faire remonter des failles de sécurité potentielles telles que :

Non-validation des paramètres d’entrée (saisies des utilisateurs ou variables passées entre les fonctions)

Permissions accordées trop larges

Ouverture des accès au réseau trop larges

Sensibilité aux attaques les plus communes (Injection SQL, XSS etc.)

À noter : chaque outil SAST est adapté à un ou plusieurs langages et permettra pour chaque langage un éventail de détections possible. Référez-vous à la documentation officielle de l’outil choisi pour avoir la liste complète des possibilités.

Ces failles de vulnérabilités sont – dans la plupart des outils – classées selon une criticité : Info, Low, Medium, High, Critical permettant aux équipes de se situer vis-à-vis de la sécurité du code source et des failles à corriger en priorité.

Il existe de nombreux outils SAST adaptés à chaque usage, très peu sur le marché couvrent tous les langages. Il sera donc nécessaire d’utiliser l’outil correspondant à l’usage, par exemple :

  • Semgrep pour le code applicatif (Python, Go, Javascript, etc.)
  • KICS (Keep Infrastructure Code Secure) pour le code infrastructure (Ansible, Dockerfile, Terraform, etc.)

 

Il s’utilise en général juste après une étape de lint et avant toute compilation ou déploiement. Il est supposé couper l’exécution du pipeline en cas de faille trouvée ayant une criticité supérieure ou égale au niveau choisi (par exemple arrêter l’exécution en cas de High ou en cas de Critical).

 

Le Dynamic Application Security Testing

Le DAST est un outil permettant d’effectuer des tests de sécurité en “boîte opaque”, donc sans connaissance du fonctionnement ou du code source.

Il s’exécute une fois l’application déployée dans un environnement proche de celui de production.

Il permet par exemple, en donnant l’URL[¹] de l’application Web ou bien l’IP et le port du service à tester, de tester les failles les plus communes auxquelles l’application est sensible, par exemple les 10 catégories d’attaques représentant le plus de risque de sécurité selon l’OWASP[²].

Les tests effectués par un outil DAST permettent ensuite d’avoir un rapport détaillé de toutes les failles détectées et classées selon leur criticité, en général : Info, Low, Medium, High, Critical

[¹] URL : Uniform Resource Locator, l’adresse http ou https d’un site internet

[²] OWASP : Open Web Application Security Project, une organisation caritative travaillant en communauté afin d’améliorer la sécurité des applications Web

 

L’Interactive Application Security Testing

Le IAST représente les outils capables de combiner les capacités d’un SAST et d’un DAST afin d’analyser d’un côté le code source et de l’autre, l’application, une fois déployée et de pouvoir établir des corrélations et des suggestions entre les deux.

 

L’Infrastructure as Code

Cette méthode, nommée IaC, consiste à utiliser un outil permettant le déploiement d’élément de l’infrastructure écrit sous la forme descriptive à l’aide d’un langage.

Bien que cet outil ne soit pas obligatoire à la mise en place des pratiques DevSecOps, ce dernier permet, lorsqu’il est utilisé, de les mettre en place depuis le code source au déploiement de l’infrastructure.

On pourra notamment utiliser un outil de SAST dédié permettant de faire remonter des problèmes de sécurité par exemple :

  • des ouvertures de ports trop larges sur un pare-feu
  • des permissions trop importantes sur des utilisateurs techniques
  • l’absence de certaines règles de pare-feu courantes pour les services exposés sur internet
  • la non-utilisation de solution de chiffrement au repos et en transit
  • etc.

 

On citera notamment Terraform et Pulumi qui permettent le déploiement sur plusieurs Cloud Provider tels qu’AWS, Azure, GCP, etc.

 

Les Pipelines

Les outils précédemment abordés dans cette leçon doivent être exécutés de façon séquentielle et automatiquement lorsqu’une nouvelle version du code source est envoyée sur le dépôt git.

Cette pratique d’automatisation prend place au sein d’une chaîne d’intégration et de déploiement continus nommé couramment une chaîne CI/CD (Continuous Integration/Continuous Deployment).

Le pipeline CI/CD est un outil qui, à l’aide d’un fichier descriptif, va exécuter des étapes séquentielles dans un environnement temporaire de développement permettant par exemple de :

  1. Cloner le dépôt git
  2. Linter le code source
  3. Exécuter un outil de SAST sur le code source
  4. Compiler le code source en application
  5. Faire des tests unitaires et fonctionnels sur l’application compilée
  6. Déployer l’application dans un environnement similaire à la production
  7. Lancer l’exécution d’un outil de DAST sur le point d’entrée applicatif
  8. Générer un rapport de chacune des étapes précédentes dans un format lisible
  9. Stocker le rapport dans un dossier distant
  10. Mettre à disposition l’archive contenant l’application compilée en tant qu’artefact de la pipeline.

 

Plusieurs pipelines peuvent s’enchaîner et dans le cas ci-dessus, le suivant pourrait être en charge de déployer l’application dans un environnement de démo ou de QA (Quality Assurance – Contrôle qualité) afin de tester de façon manuelle et humaine l’application avant sa mise en production.

Il est également possible dans la plupart des outils de pipeline de mettre en “pause” des exécutions ou d’attendre une intervention humaine. Par exemple, une fois l’étape de contrôle qualité humaine réalisée, une pipeline finale pourrait attendre une approbation d’un chef de projet afin de lancer la mise en production automatique de l’application.

Formez vos équipes !

Formation

Carrière

Cybersécurité

100% en ligne

Discutons ensemble de votre projet

Mail

information@seela.io