Devensys Cybersecurity – The Blog

Le terme DevSecOps prend une place de plus en plus importante dans les discours des éditeurs de logiciels. Les termes utilisés sont nombreux: « DevOps », « CI/CD », « intégration continue », « ALM » ou encore « usine logicielle ». Les concepts derrière sont quant à eux plus obscurs. Il peut être donc important de les éclaircir et d’avoir une vue d’ensemble.

La suite de cet article présentera les différentes étapes du cycle « DevSecOps » et les concepts importants de chacun d’entre eux.

L’objectif du DevSecOps, c’est quoi?

Le DevSecOps, et la gestion du cycle de vie d’une application (ALM) en général, a plusieurs buts. Comme le montre le schéma ci-dessus, le principal intérêt est de mettre en place un process d’amélioration continue. On va ainsi se rapprocher du concept de cercles vertueux tel que la Deming Wheel. Cette vertuosité va être atteinte principalement par l’automatisation, mais aussi par la structuration des process.

Voici une liste non exhaustive des points traités.

• Donner une structure au travail en équipe (gestion de projet implémentant les processus agiles, gestionnaires 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 (unitaires / fonctionnels / performances) automatisés
• Valider le code plus rapidement et ainsi 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étriques et gestion d’erreurs pertinente
• Documenter les process et les actions

Chacun de ces process est couvert par une phase bien spécifique du cycle de vie, et est présenté ci-dessous.

La planification

Spécifications et Kanban

Le point de départ de tout projet, ce sont les spécifications. Tout projet évolue naturellement avec le temps. On a de nouvelles idées, des retours utilisateurs, ou simplement des effets de mode. Quelle qu’en soit la raison, il est important de noter les spécifications et leurs évolutions. La description et l’organisation de ces tâches sont au cœur des problématiques du projet. Ce sont elles qui déterminent la charge du projet, les dates de livraisons des fonctionnalités importantes, etc.

C’est là que rentre en jeu tous les concepts de méthodologie agile, planning poker ou encore la priorisation des tâches. C’est en vaste sujet que nous traiterons dans un futur article.

Les uses et abuses cases

Un concept crucial et pourtant souvent oublié, c’est la définition des cas d’abus et des risques potentiels. Si les cas d’utilisation (uses cases) sont maintenant passés comme courants, c’est beaucoup moins le cas de ces derniers. Ils sont pourtant le point de départ la sécurité d’une application.

La culture de sécurité est malheureusement peu répandue. Or il est essentiel de penser aux contournements possibles qu’un attaquant peut faire. Et si possible, il faut y penser dès la rédaction des spécifications.

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, aider l’équipe de prendre conscience des risques potentiels et d’intégrer nativement la sécurité dans leurs processus de développement. C’est aussi cela intégrer la partie « Sécurité » du DevSecOps.

Gestion & analyse de code

Les gestionnaires de code, un besoin incontournable

Depuis une vingtaine d’années, les gestionnaires de code ont apporté de grands changements dans le monde du développement. Microsoft Visual Source Code ou SVN ont été les premières vraies solutions sur ce sujet. Mais c’est l’arrivée de Git et le dépôt GitHub sur le marché qui a définitivement enterré les vieilles pratiques, telles que le travail en production via FTP.

Finis le code sur le poste de travail du développeur uniquement. Désormais le code est versionné, sauvegardé, décentralisé et partagé. L’utilisation massive de Git a 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. L’adhésion forte de Git à permis d’uniformiser les besoins, et surtout de passer un cap sur la sécurité des développements.

Le fait d’avoir le travail sauvegardé et décentralisé a fait naître des ambitions nouvelles. Le code est facilement partagé, notamment avec GitHub. Un intérêt renouvelé s’est porté sur la normalisation des pratiques de code, puisque le travail en communauté est plus simple.

Construire de la valeur autour de l’outil

Des outils d’analyse de code ou encore d’analyse algorithmique ont commencé à apparaître. En se câblant directement au système de gestion de code, il est possible d’avoir un rapport de qualité et de sécurité sur ce dernier.

On peut alors combiner cela au principe des Pull Requests et au workflow de validation humaine. Tout code produit est analysé automatiquement pour tous les problèmes rébarbatifs de normalisation, en plus d’être approuvé par un senior expérimenté. L’équipe met ainsi en place une formation continue en plus d’augmenter la qualité de l’application.

L’intégration continue & le testing

La CI (pour « continuous integration ») est un terme que l’on croise fréquemment, mais souvent utilisé de manière approximative. Elle 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 créer l’artefact qui servira pour la partie déploiement. Nous reviendrons sur ces deux notions un peu plus tard dans l’article.

On parle d’intégration continue pour décrire le processus servant à automatiquement générer un artefact à partir du code source validé. Le build consiste à :

• récupérer le code source après validation
• 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 société et projet étant différent, les besoins et les process seront à voir au cas par cas. Les besoins sont néanmoins communs dans la plupart des cas.

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

Les artefacts

Définition d’un artefact

Par expérience, la notion d’artefact est très probablement 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 peut être composé de nombreux fichiers ou type de fichiers différents.. Le cas le plus courant est une archive Zip (ou autre) qui contient l’ensemble des sources et fichiers nécessaires de votre application après nettoyage. Cela permet de plus facilement gérer le versionning (un seul fichier) et son intégrité (checksum). Mais cela peut aussi être un binaire, une dll, un container…

Principes fondamentaux

Le fait de ne pas altérer un artefact est extrêmement important. C’est la seule garantie que la validation d’un artefact à un instant T ait une valeur. L’erreur la plus courante est l’utilisation de branches Git en tant qu’outil de versionning applicatif (avec des branches de tests, preproduction, et production par exemple). C’est une grave erreur.

En effet, il peut être compliqué d’assurer la persistance d’une version, et notamment la restauration en cas d’erreur. Il existe évidemment des solutions à chaque cas. Mais le DevSecOps a pour principe la sécurité et la performance par la simplicité et l’automatisation, entre autres choses. L’utilisation de branche Git, pour poursuivre l’exemple, pose des problèmes de sécurité, d’intégrité et de simplicité. Pour retrouver le niveau fonctionnel que l’on aurait en utilisant les artefacts, il faut mettre en place des processus complexes.

Le DevSecOps doit rester un processus simple à comprendre et à analyser. Ce sont des points importants pour la maintenabilité et le transfert de compétences. Le maître mot est d’automatiser au possible afin de gagner du temps et éviter les erreurs humaines.

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 figée de cette dernière. Le travail consiste alors à savoir quels sont les processus à mettre en place pour valider et 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 clients privilégiés. Enfin, après validation, le déploiement peut s’effectuer sur la production.

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 exhaustive de vos besoins et des outils à mettre en face.

Personnellement, je privilégie les outils tels que App Insight ou New Relic. Ce sont des outils complets qui permettent à la fois une analyse de l’utilisation de l’application, du temps de réponse, mais aussi et surtout de toute la partie logicielle. On obtient ainsi des retours concernant le temps de requête, de l’exécution SQL, des 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.

Qui est en charge du DevSecOps?

Le DevSecOps regroupe plusieurs compétences transversales (Développement / sécurité / opérationnel (IT)). Mais les profils maîtrisant l’ensemble de ces compétences sont rares. Les solutions les plus couramment rencontrées 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

Comme souvent, c’est la culture de l’entreprise et les ressources disponibles à l’instant T qui motive la solution qui sera choisie. Le plus souvent, ce sont les chefs de projet avec une qualification technique qui s’en occupent. Ce sont en effet les premiers concernés par les sujets de planifications des besoins et de gestion de l’équipe. Il est cependant très fréquent de se faire accompagner par un expert afin de sécuriser la mise en place des processus et de respecter les bonnes pratiques.

Conclusion

Le DevSecOps est un sujet complexe, demandant des compétences pluridisciplinaires. Il est parfois difficile de prendre la décision de s’attaquer à un tel sujet, qui souvent est crucial pour un éditeur logiciel, mais pas seulement. Toute entreprise ayant un projet de développement logiciel est concernée, pour des raisons de gouvernance du code source, de sécurité et de transparence. Si sa mise en place peut avoir un coût en début de projet, les avantages que l’on en retire sont indubitables.

Si vous souhaitez être accompagné sur le sujet, dans le cadre d’une mise en place ou d’amélioration du processus existant, n’hésitez pas à prendre contact avec nous.