Qu'est ce que le 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