Le DevSecOps : voilà un acronyme pas simple à définir, basé sur un autre pas toujours maitrisé, à savoir le DevOps. On va tenter de clarifier tout ça !
Pour répondre rapidement à la question par une définition courte, le DevSecOps est un terme qui vise à regrouper de multiples concepts, compétences et méthodologie autour d’un but commun : la gestion du cycle de vie d’une application. A savoir mettre en place ce qui est nécessaire pour qu’une entreprise soit capable de faire vivre son logiciel. Cela va de la création, à la maintenance, comme à sa potentielle « mort ». Exactement comme le cycle de vie d’un produit. Si le terme DevOps a évolué en DevSecOps, c’est qu’un élément crucial c’est intégré au centre de ce processus : la sécurité.
Mais profitons-en pour explorer les différents concepts de ce sujet fort passionnant !
Table des matières
D’où vient le terme DevSecOps ?
Quoi de plus simple que de commencer par un peu d’étymologie?
Le terme DevSecOps à pris corps autour du terme DevOps qui était déjà bien connu, pour rajouter la composante « Sec ». C’est donc un mot composé de trois parties :
- Ops : c’est la partie infrastructure. On souligne ici l’importance des compétences opérationnelles, donc infrastructure et réseau notamment
- Dev : la partie développement. On ne parle pas tant de compétence pure en termes de développement (pas besoin de savoir taper des lignes de code, bien que ça aide), mais surtout de compétences qui ont attrait au monde du développement : connaitre un peu l’architecture logicielle, savoir gérer un projet de développement, connaitre les problématiques, etc.
- Sec : c’est la composante « sécurité », qui a été ajoutée au début pour souligner son importance. La sécurité doit être au coeur de l’ensemble des réflexions du « DevOps », afin de protéger tout ce qui a trait au produit, mais plus largement à l’entreprise et à son image.
Par définition donc, le DevSecOps est très transverse, en ayant des connaissances assez poussées sur différent domaine. On va souvent parler du poste d’une personne, ou d’une équipe, quand on va parler de DevSecOps. Elle va être le « pont » entre les équipes de développement et les équipes « Infra/système/réseau ». Mais pour mieux comprendre tout cela, passons en revue ses objectifs.
L’objectif du DevSecOps, c’est quoi?
Le DevSecOps, et la gestion du cycle de vie d’une application (ALM) en général ont plusieurs buts:
- Faciliter le travail en équipe par l’utilisation de processus agiles et d’un gestionnaire de code type Git
- Augmenter la qualité, la maintenabilité et la sécurité du code par l’analyse manuelle (Pull Request) et automatique (outils) du code
- Renforcer la sécurité par l’utilisation de tests fonctionnels et de performances automatisés
- Valider plus rapidement et réduire la frustration par la mise en place de l’intégration continue
- Protéger son application et son infrastructure par la gestion des déploiements et la mise en place de workflow de validations
- Sécuriser la production par la mise en place de logs, métrique et gestion d’erreurs pertinentes
- Documenter les process et les actions
- etc…
Chacun de ces process est couvert par une phase bien spécifique du cycle de vie d’une application (voir schéma en introduction), et est présenté ci-dessous.
Les process du DevSecOps
1. La planification
La gestion de projet
Un projet, c’est avant tout des idées ! Et les idées, elles se conservent mieux dans le temps une fois écrites, et encore mieux si elles sont bien rangées. Le point d’entrée de notre process va donc être la planification du projet via ses spécifications. Quelle que soit l’étape du projet dans laquelle vous êtes, vous allez alimenter la base de spécifications (aussi appelé « product backlog »). Cela peut être par de nouvelle fonctionnalité, des petits changements, des bugs…
Le but va être ici de réussir à maintenir cette base de connaissance et de la valoriser. Ecrire les spécifications permet de ne pas les oublier. Les organiser, en utilisant les outils à disposition (priorité, catégories, etc.) permet de se concentrer sur les points à forte valeur ajoutée sur un temps donné. Cette étape cruciale vous permettra de tirer le meilleur profit de vos brainstormings, et de donner de la visibilité à votre projet.
C’est aussi à cette étape que l’on va parler de méthodologies de gestion d’équipes et de projet : méthodologie agile, scrum, planing poker.. Autant de méthodes qui ont pour but de mettre en place, via des rituels, de bonnes pratiques pour la gestion de projet, la cohésion d’équipes et le dialogue entre les différents intervenants. Pour aller plus loin sur le sujet, vous pouvez voir cet article sur l’utilisation d’Azure DevOps Boards.
Les uses cases & abuses cases
Le point important à aborder ici, et qui est souvent oublié, est la définition des cas d’abus et des risques potentiels de l’application. Si les cas d’utilisation sont maintenant passés comme utilisation courante dans les entreprises, c’est beaucoup moins le cas de ces derniers. Pourtant, c’est de là que part la sécurité d’une application.
Il est en effet très important de prendre l’habitude, lors de la rédaction des spécifications logicielles, de penser aux contournements possibles qu’un attaquant peut en faire. En comprenant comment l’application peut être détournée et attaquée, il est plus aisé de chiffrer et prioriser les tâches de sécurité et de les intégrer au projet. Brainstormer avec l’équipe à ce sujet peut, en outre, permettre à toute l’équipe de prendre conscience des risques potentiels et d’intégrer nativement la sécurité dans leurs processus de développement.
2. Gestion & analyse de code
Depuis une vingtaine d’années, ce qui a surement le plus bouleversé les habitudes de développement est probablement l’arrivée et la « démocratisation » des gestionnaires de code. Si Microsoft Visual Source Code ou SVN commençait à émerger, l’arrivée de Git sur le marché a définitivement enterré les vieilles pratiques.
Fini le code sur le poste de travail du développeur uniquement (tout du moins, on espère !). Maintenant le code est versionné, sauvegardé, décentralisé et partagé. L’utilisation massive de Git à permis de faciliter grandement le travail en équipe tout en augmentant la sécurité et la productivité. Moins de travail perdu, moins d’erreurs humaines, moins d’oublis, de dépendances… les avantages sont nombreux!
Le fait d’avoir le travail sauvegardé et décentralisé va permettre de voir émerger des processus nouveaux. Le code étant plus facilement partagé, notamment publiquement avec GitHub, un intérêt renouvelé c’est porté sur la normalisation des pratiques de code. Des outils d’analyse de code ou encore d’analyse algorithmique ont commencés à apparaître. En se câblant directement au système de gestion de code, il est alors possible d’avoir un rapport de qualité et de sécurité sur le code qui est produit.
On peut alors combiner cela au principe des Pull Requests, qui permettent un workflow de validation humaine. Tout code produit peut alors être analysé automatiquement pour tout les problème rébarbatifs de normalisations, en plus d’être approuvé par un senior expérimenté ce qui permet de former l’équipe en plus d’augmenter la qualité de l’application.
Vous pouvez voir un exemple de gestion de source et d’analyse de code sur l’article consacré à Azure DevOps Repos.
Il est possible de construire un workflow de validation autour de ce process
3. L’intégration continue & le testing
L’intégration continue, aussi appelée CI (continuous integration). Voilà un terme que l’on croise fréquemment mais qui est régulièrement utilisé de manière approximative. La CI est, pour reprendre le schéma du cycle de vie d’une application, la partie qui concerne le « build » et le « test ». Son but est de préparer et créer l’artefact qui servira pour la partie déploiement. Je reviendrais sur ces deux notions un peu plus tard dans l’article.
On parle d’intégration continue en ce sens qu’une fois le code validé (suite à une Pull Request par exemple, voir section précédente), celui-ci va automatiquement déclencher les processus de préparations de l’application pour déclencher la phase de testing. Le build va par exemple consister à récupérer le code source, installer les packages nécessaires, lancer les tests automatisés, vérifier que les fichiers de configuration des développeurs ne soient pas dans les sources, etc. Chaque application, chaque langage, chaque société peut avoir son process, même si une trame commune s’en dégage.
Si le processus de build et les tests sont validés, alors les sources sont nettoyées et un artefact est créé à partir de là.
4. Les artefacts (release management)
Par expérience, la notion d’artefact est très probablement celle qui est la moins bien comprise du concept de DevSecOps. Mais alors, qu’est-ce qu’un artefact?
La philosophie d’un artefact est d’avoir un objet unique, versionné, que l’on va pouvoir suivre durant toute sa vie. Le concept central est qu’une fois l’artefact généré, il ne doit pas être altéré pour aucune raison que ce soit. Toute modification entraîne la génération d’un nouvel artefact, et donc d’une nouvelle version.
Attention, la version d’un artefact n’est pas nécessairement liée à la version de votre application / librairie / code / fichiers, mais c’est souvent plus simple pour en suivre l’évolution.
Un artefact, en soi, peut être composé de tout ou n’importe quoi. Le cas le plus courant est une archive Zip (ou autre) qui contient l’ensemble des sources et des fichiers nécessaires de votre application après nettoyage. Mais cela peut aussi être un binaire, une dll, un container..
Le fait de ne pas altérer un artefact est extrêmement important, car c’est la seule garantie que la validation d’un artefact à un instant T ait une valeur. L’erreur la plus courante que je retrouve est l’utilisation de branche Git comme de versionning applicatif (avec des branches de tests, preprod, prod, etc.). C’est une grave erreur. En effet, il est très compliqué d’assurer la persistance d’une version, et notamment la restauration en cas d’erreur, à partir d’une branche Git. On peut éventuellement retrouver la version précédente via l’id de commit, mais cela demande des process complexes et des connaissances qui vont à l’encontre du process de cycle de vie d’une application.
5. La gestion des déploiements
Le déploiement continu, aussi appelé CD (continuous deployment) ou encore release management, concerne toute la partie de mise en application de l’artefact.
L’artefact contient donc l’application, et valide une version X de cette dernière. Le travail consiste alors à savoir quels sont les processus à mettre en place pour sécuriser l’application. Le cas le plus courant est la mise en place d’un processus de validation via plateforme de test, préproduction et production. L’équipe applicative est donc en mesure de tester sur un environnement ISO à la production. Si l’artefact est validé, il est déployé sans altération sur la plateforme de préproduction et soumis alors aux validations des équipes métier et client privilégié. Enfin, après validation, le déploiement peut s’effectuer sur la production.
6. Le monitoring de l’application
Enfin, une fois l’application en production, il va être important de surveiller son bon fonctionnement, analyser les retours utilisateurs, l’utilisation des fonctionnalités, etc.
De ce côté, ce ne sont pas les outils qui manquent. Google Analytics, AB Testing, hotjar… autant d’outils qui peuvent être intrusif, mais aussi aider dans l’amélioration de l’application. Il convient donc de faire une analyse juste de vos besoins et des outils à mettre en face.
Personnellement, je privilégie les outils tels que App Insight ou son concurrent New Relic. Ce sont des outils complets qui permette à la fois une analyse de l’utilisation de l’application, du temps de réponse, mais aussi et surtout de toute la partie logicielle. Des retours concernant le temps de requête, exécution SQL, performances par fonctions, etc. Toutes ces métriques permettent de détecter les points problématiques d’une application et d’agir en conséquence.
Si en plus vous travaillez sur les technologies .Net, il est incontournable !
Qui est en charge du DevSecOps?
Tout comme pour le DevOps, c’est souvent la première question qui est posée, et la plus compliquée. Comme son nom l’indique, le DevSecOps regroupe plusieurs compétences transverses (Développement / sécurité / opérationnel (IT)). Les profils maîtrisant ces compétences de manière transverse sont rares. Les solutions les plus courantes sont :
- Recrutement d’un profil, ce qui peut être long et coûteux
- Mise en place d’une équipe spécialisée : cela permet de répartir les compétences, ce qui est plus aisé, mais demande de monopoliser plusieurs profils
- Accompagnement par un tiers expert
L’expérience m’a montré que souvent, c’est la culture de l’entreprise et les ressources disponibles à l’instant T qui motive la solution qui sera choisie. En tant qu’expert, je ne serais que conseiller de privilégier un accompagnement par un tier expérimenté qui sera à même de faire un transfert de compétences vers une ou plusieurs personnes en interne. Le plus souvent, ce sont les chefs de projet à qualification technique qui s’occupent de la mise en place de la partie DevSecOps.
Et concrètement, comment ça se met en place ?
La formation
La sécurité, c’est avant tout de la formation ! Il faut connaitre les menaces, attaques, les risques, pour s’en prémunir. De la même façon qu’on change sa serrure par un barillet sécurisé quand on connait les risques de crochetages, c’est en connaissant vos menaces que vous pourrez vous protéger. Pour citer Sun Tzu : Connais ton ennemi et connais-toi toi-même eussiez-vous cent guerres à soutenir, cent fois vous serez victorieux. Vous devez connaitre votre produit et vos menaces.
On a vu aussi que le DevOps concerne plusieurs métiers et compétences. Développeur, chef de projet, IT… Aussi, chaque corps de métier doit être sensibilisé à la sécurité. De manière globale d’abord (avec des formations types CEH par exemple). Mais aussi à son métier en particulier (CASE pour les développeurs, AZ-500 pour les IT, etc.). Cette formation doit aussi être régulière, car les bonnes pratiques en termes de sécurité évoluent constamment, au même titre que les attaques. Des organismes tel que l’OWASP vous permettent de faire de la veille sur ce genre de sujet. Ils proposent aussi des outils et des supports de formation.
Enfin, utilisez les bonnes pratiques côté projet pour faire passer l’information entre les différents intervenants. La connaissance transite parfois de façon très efficace entre collègues au travers des Pull Request et des cérémonials Agile.
Les outils
Les outils sont une excellente aide à la mise en place du DevSecOps, même si on ne doit pas se reposer complètement dessus. C’est une aide nécessaire, mais non suffisante.
La plupart des projets ont bien intégré les concepts de base, notamment avec la CI/CD. L’utilisation de code compiler par exemple permet de s’assurer que le projet est un minimum conforme aux attentes, sinon la compilation « casse ». De même, l’utilisation de tests automatisés améliore là encore la sécurité du projet, et notamment sa disponibilité.
Sur ces pratiques communes, il est aisé de rajouter des tests automatisés pour couvrir les abuses case dont nous parlions plus haut. Cela améliore d’autant la sécurité sur le long terme, sans modifier le travail des développeurs (les tests sur les abuses cases sont technologiquement les mêmes que les tests classiques, autant côté développement que côté CI/CD).
A cela, afin de parfaire la sécurité par l’automatisation et l’utilisation d’outil, on intègre souvent des solutions SAST et/ou DAST. Des solutions telles que Sonarqube, Microfocus Fortify ou Veracode servent justement à appuyer le développement en proposant des métriques sur la maintenabilité du projet, et sa sécurité. Ces outils servent tout autant aux suivis du projet par la direction, que pour les développeurs qui ont souvent accès à l’information directement dans l’IDE, avec une explication du problème permettant à la fois de résoudre ce dernier, mais aussi de se former au passage.
Gardez néanmoins en tête que si les outils sont très utiles, il faut limiter l’utilisation de trop d’outils différents. Car c’est souvent coûteux en licence, en temps de paramétrage, mais aussi en utilisation pour les développeurs. Et surtout, au plus vous avez d’outils, au plus les configurations de sécurités de ces outils seront difficiles à gérer. Ce qui serait contre-productif et préjudiciable pour votre projet.
Pour conclure
J’espère avoir pu vous donner un éclairage sur les différents points importants qui concernent le DevSecOps. Aujourd’hui, il semble impensable d’aborder un projet de développement sans prendre en compte ces problématiques. Car un projet, ça doit être organisé. Car la sécurité doit être au cœur des préoccupations.
Il faut garder en tête que la sécurité, ce n’est pas optionnel. Au même titre qu’il parait évident que l’accès à votre maison doit être sécurisé, il en va de même pour votre application, vos données, et celles de vos clients et utilisateurs.
Nous avons vu plusieurs outils permettant de vous aider dans cette démarche. Associée à une formation continue, comme nous avons pu le voir, vous réduirez drastiquement les risques de vous retrouver avec un grave problème de sécurité à gérer.
Penser surtout à rester informé des bonnes pratiques en ce qui concerne ces sujets. Si vous êtes sur cet article, c’est que vous avez déjà la bonne démarche ! Des évènements sont régulièrement disponibles sur Linkedin, Meetup & autres. Des documentations sortent aussi régulièrement, comme les 6 astuces proposées par Microsoft, ou les publications de l’OWASP là encore.