Qu'est ce que le DevSecOps ?

Dans le monde entier, l’intérêt et l’adoption du DevSecOps se développent rapidement. Mais qu’est-ce que le DevSecOps ?

Sommaire

  • Introduction, la genèse du DevSecOps
  • DevSecOps, une culture avant tout
  • La méthodologie du DevSecOps
  • Les avantages du DevSecOps
  • Pour aller plus loin

Introduction, la genèse du DevSecOps

Développer et mettre sur le marché un SaaS ou un logiciel peut être long est complexe.

Les développeurs (Dev), les équipes opérationnelles (Ops) et les équipes sécurités (Sec) interagissent ensemble pour répondre à 3 enjeux précis :

  • Time To Market (TTM) : Mettre en ligne de nouvelles fonctionnalités toujours plus rapidement pour aligner les applications de l’entreprise aux attentes des clients.
  • Stabiliser les applications : Garantir que les applications soient toujours disponibles et fonctionnelles pour les clients afin de limiter le risque de perdre du chiffre d’affaire ou d’impacter l’image de marque négativement
  • Sécurité des données : Garantir un niveau de sécurité important en continu pour ne pas se faire hacker ses données.

Dans les organisations traditionnelles, chaque acteur (Dev, Ops, Sec) est responsable de traiter un seul enjeu. Le développeur s’occupe de développer de nouvelles fonctionnalités, l’équipe opérationnelle stabilise les applications et l’équipe sécurité s’occupe de la sécurité.

Cette organisation est bien souvent inefficiente, et impact la productivité des équipes :

Les développeurs :

  • Pour livrer dans les temps, ils créent sans le vouloir des bugs et engendre de la dette technique.
  • Parce qu’ils ne sont pas expert, ils créent des failles de sécurité sur la production sans le savoir.

Les équipes opérationnelles :

  • Pour éviter de créer des instabilités sur la production des clients, elles ralentissent ou bloquent les développeurs dans la mise en ligne de nouvelles fonctionnalités.
  • Comme elles ne maîtrisent toujours pas les technologies utilisées par les développeurs, elles n’arrivent pas à gérer le support des applications.

Les équipes sécurités :

  • Pour éviter de créer des failles de sécurité sur la production pour les clients, elles ralentissent ou bloquent les développeurs dans la mise en ligne de nouvelles fonctionnalités.
  • Créer des recommandations de sécurité qui ne sont jamais appliquées car les développeurs ou Ops n’ont pas le temps pour les traiter.

Avoir un développeur, une équipe Ops, et une équipe sécurité ne suffit pas à répondre correctement à tous les enjeux de l’entreprise. Il est donc nécessaire de travailler profondément la culture et l’organisation.

La culture DevSecOps qui combine le développement (Dev), sécurité (Sec) et opération (Ops) résout ces enjeux en coordonnant les équipes, les processus et les technologies.

DevSecOps, une culture avant tout

Plus qu’une méthodologie de développement de logiciels, le DevSecOps est une culture.

Afin d’intégrer les bonnes pratiques de sécurité et de développement, le DevSecOps demande à mettre en place une culture d’entreprise, une organisation, et des outils dès le début et tout au long des projets.

Voici les notions que la culture DevSecOps apporte :

  • « Security by design » : Pour garantir un niveau de sécurité élevé, les experts sécurités doivent être acteurs. Ils sont intégrés dans les équipes projets et doivent mettre en place des processus de sécurité qui sont assimilés dans les processus de travail des développeurs et des équipes opérationnelles.
  • « You build It, You run It » : Pour responsabiliser les développeurs à la qualité du code et améliorer la qualité de service sur les projets, les développeurs doivent aider les équipes supports à traiter les incidents de production.
  • « Everything as Code » : Pour améliorer l’auditabilité, la reproductibilité, la qualité du code et corriger plus rapidement les anomalies, tout ce qui est réalisé doit être réalisé as code (Infrastructure as code, Compliance as Code, Test as Code…)
  • « Always improve » : Pour améliorer la stabilité et la sécurité dans le temps, les équipes doivent se former en continue et chaque incident doit donner lieu à un post-mortem.

La méthodologie du DevSecOps

La culture DevSecOps est centrée vers une méthodologie de planification, d’exécution et d’amélioration continue. Cette méthodologie est composé de 8 phases :

Plan :

Cette phase consiste à planifier les développements via un ensemble de différents livrable comme les dossier d’analyse de risques, la roadmap technique, le dossier d’architecture, le plan de monitoring, ou même les plans de formations.

Code :

Après avoir planifié les travaux, vient la phase de développement, c’est dans cette phase que tous les livrables de développement sont réalisés.

Cette phase comprends les développements applicatifs, mais aussi le développement as code de l’infrastructure, des outils sécurité, de monitoring et de supervision.

Afin de garantir une forte sécurité et d’éviter au maximum les failles sécurité comme les injection SQL ou XSS, les bonnes pratiques DevSecOps impose de réaliser dans cette phase une analyse statique du code (SAST) et de les dépendances (SCA).

L’analyse SAST consiste à intégrer dans ses processus de développement des outils de relecture statique sur les IDE ou via des pre-commits pour détecter les failles de sécurité mais aussi les données sensible et les mauvaises pratiques de développement qu’il ne faut surtout pas pousser en production ou dans les outils de gestion de code.

De le même façon que l’analyse SAST l’analyse des dépendances (SCA) met en évidence les vulnérabilités (CVE) des dépendances utilisés dans les livrables et permet aux développeurs de les corriger avant de les pousser en production.

Build :

C’est dans la phase de build que les développements sont compilés. C’est en général dans cette phase que l’on peut mettre en évidence les plus gros bug technique à corriger mais aussi de préparer la mise en production du code.

Test :

La phase de test est l’une de plus importante des phases de la méthodologie. C’est cette phase qui va permettre de garantir un niveau de contrôle de qualité de code et de sécurité by design sur tous les livrables.

Plusieurs types de tests sont lancés sur les livrables, comme les tests de qualité, les tests unitaires, les tests d’intégration, et les tests de sécurité dynamique (DAST).

Tout comme le SAST, les analyses DAST permettent de détecter différents problèmes de sécurité. Cette analyse n’est par contre pas réalisé directement sur les livrables mais sur les endpoints et web services des livrables déployés sur des environnement de test dédié.

Afin d’accélérer les développements et d’augmenter la stabilité de la production, il est commun de mettre en place des environnements de test à la demande pour réaliser des tests supplémentaires. Il est à noter que les bonnes pratiques DevSecOps préconise de réaliser TOUS les tests as code et de limiter au maximum les tests manuels.

Dans le DevSecOps cette phase est très souvent automatisé dans un pipeline d’intégration continue (CI) via des outils de CI / CD comme Gitlab-CI.

Release :

Après avoir compilé et testé les développements, vient la phase de release. Cette phase consiste à versionner, packager, et stocker un ensemble de code sous forme d’artifact / binaire inaltérables et seront utilisés lors de la mise en production.

Deploy :

Le code étant packagé, et testé, il est maintenant prêt pour partir en production. C’est dans la phase de déploiement que les nouvelles fonctionnalités sont mise en production.

Dans le DevSecOps cette phase est très souvent automatisé dans un pipeline déploiement continue (CD) via des outils de CI / CD comme Github Action.

Monitor :

Une fois les développements mis en production, vient la phase de monitoring. Cette phase consiste à analyser en continue les métriques et les logs des solutions déployés afin de détecter et bloquer des comportements qui pourrait ou mettent à mal l’application niveau disponibilité ou sécurité (SIEM, RASP). Il existe un très grand nombre d’outil DevSecOps permettant de monitorer les logs, les connexions ainsi que les usages des logiciels pour avoir une visibilité à 360 des logiciels déployés.

Operate :

Dans le cas ou un incident, intrusion et / ou problème est détecté vient la phase de supervision. Une analyse est réalisé afin de détecter les différentes root causes. un rapport de problème est émis avec les différentes informations de l’incident et les éléments qui permettront de planifier un correctif sur la prochaine itération de la méthodologie.

C’est dans cette phase que les rapports de disponibilité et de sécurité sont émis

Les avantages du DevSecOps

Mettre en place et évangéliser la culture DevSecOps peut être initialement très complexe. Il faut mobiliser, motiver tous les acteurs à suivre les principes et à travailler en équipe.

Toutefois, appliquer ses principes et sa méthodologie apporte un grand nombre d’avantages :

  • Amélioration de la sécurité
  • Amélioration de la qualité de service (QoS)
  • Diminution de la dette technique
  • Livraison plus rapide et plus fréquente
  • Diminution des frictions entre les différentes équipes (Dev, Sec, Ops)

Pour aller plus loin

  • Comment mettre en place le DevOps dans son entreprise
  • Comment mesurer le ROI d’un projet DevOps et maximiser les métriques
  • Qu’est ce que l’inner sourcing
  • Les outils du DevSecOps
En découvrir plus sur le DevOps
Comment Keltio m'aide sur le DevOps ?