Dans la 3ème et dernière partie de cet article, je continue l’exploration des principes Agile pour voir de quelle façon ils nous aident à définir le terme, parfois oh combien nébuleux, de “DevSecOps” ! Pour rappel, la 1ère partie de cet article se trouve ici et la 2ème partie ici.

9) L’excellence technique

“Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.”

Qualité, qualité, qualité ! C’est le maître mot à avoir en tête pour toute livraison d’un produit. Cette exigence de qualité est évidemment un intrant important quand on se positionne au niveau d’une démarche DevSecOps : d’abord parce qu’elle garantit que les solutions de sécurité, comme tous les autres composants du produit, offrent un niveau d’efficacité technique sans faille ; ensuite parce qu’elle permet à la sécurité de se positionner comme un des contributeurs qui améliore la valeur ajoutée finale du produit réalisé.

Par conséquent, une démarche DevSecOps s’appuie sur :

• des experts (qu’ils soient dans ou hors des équipes sécurité) formés aux spécificités propres à la gestion de la sécurité dans un environnement devops. Certes, les piliers de la sécurité restent les mêmes : protection de la disponibilité, de l’intégrité, de la confidentialité et de la traçabilité et capacité à mener des analyses de risques objectives et complètes. Mais les solutions à mettre en oeuvre s’intègrent dans un périmètre technique et s’appuient sur des outils nouveaux qu’il est impératif de maîtriser pour proposer des solutions au design adapté et cohérentes avec les besoins d’utilisation et les objectifs métiers. Dit comme ça, cela peut paraître une évidence. Mais combien de fois voit-on des solutions qui ne sont qu’un copié/collé de mesures construites pour des solutions techniques et fonctionnelles qui n’ont que peu de rapport avec les nouvelles façons de faire devops et agile ?
• une démarche de co-construction des mesures de sécurité en faisant appel à des sachants non sécurité. Chaque partie prenante maîtrise un aspect du problème et il est impératif de garder l’esprit ouvert et de travailler de façon collaborative pour traiter l’ensemble des enjeux et proposer des solutions à la fois réalistes et efficaces (cf. le principe #2)
• des solutions sécurité qui mettent en avant leur capacité à standardiser les livraisons, et ainsi à participer à l’exigence de qualité générale du produit

10) La simplicité

“La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.”

À ce sujet, on peut faire référence au principe de développement KISS (“Keep it simple and stupid”) qui rappelle qu’il est important de ne développer que le strict nécessaire. Même principe pour la sécurité : il est important de proposer des solutions qui couvrent strictement et uniquement le besoin du moment, quitte à élargir leur périmètre d’action ou leurs fonctionnalités dans un second temps, quand le besoin produit le nécessitera.

Par conséquent, une démarche DevSecOps s’appuie des solutions (cf. les principe #1 et #7) :

• qui répondent aux besoins d’aujourd’hui (cf. principe P#8) ;
• découpées en fonctionnalités sécurité déployables dans un seul sprint (cf. principe P#7);
• qui s’appuient autant que possible sur des briques déjà disponibles dans l’environnement ou des solutions tierces existantes (plutôt que de chercher à réinventer la roue) (cf. principe P#2) ;
• conçues et intégrées au produit final selon des jalons définis au sein d’une méthode d’ISP (Intégration de la Sécurité dans les Projets) adaptée aux projets en mode Agile (cf. principe P#1) .

11) Equipes auto-organisées

“Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.”

Dans une logique DevOps, les équipes projet doivent être laissées au maximum autonomes car elles sont les plus à même de savoir comment allier efficacité du fonctionnement au quotidien et atteinte des objectifs des processus d’entreprise. 

Dans le même ordre d’idée, une démarche DevSecOps s’appuie sur :

• la co-construction des processus sécurité avec un panel de représentants des équipes projets et d’exploitation, pour allier au maximum efficacité et pragmatisme ;
• la mise en place d’un processus automatisé de contrôle en continu des projets en mode DevOps pour alerter au fil de l’eau les équipes des non-conformité sécurité, tout en leur laissant la charge de la remédiation et de la mise à jour a posteriori de leurs pratiques (avec renfort en parallèle des actions de formation et sensibilisation sécurité).

12) Amélioration continue

“À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.”

“ L’amélioration continue vaut mieux que la perfection retardée” (Mark Twain)

On retrouve ici une référence aux notions d’amélioration continue et de roue de deming (Plan-Do-Check-Act), avec lesquelles le monde de la sécurité est relativement familier. Cette pratique est à conserver lors de l’intégration de la sécurité dans une démarche DevOps, surtout au tout début, lorsque l’organisation et les nouvelles façons de faire ne sont pas encore totalement fixées et maîtrisées par tous. 

Par conséquent, une démarche DevSecOps s’appuie sur :

• une participation des référents sécurité, lors des cycles projet, aux étapes de rétro, pour faire le bilan des pratiques sécurité qui ont fonctionné, de celles à améliorer ou à modifier/éliminer ;
• de façon plus générale, la mise en place en fin de projet d’une période de bilan sur les apports de la sécurité, tant au niveau des solutions techniques que dans les méthodes de travail. Bilan à formaliser ensuite dans des REX internes à présenter à la fois au sein des équipe sécurité et dans les diverses communautés existantes dans l’organisation ;
• une mise à jour récurrente des référentiels et processus sécurité pour intégrer les opportunités d’évolution identifiés lors de ces bilan projets.

Pour conclure, je vous propose de faire un synthèse des bonnes pratiques sécurité évoquées dans les trois articles de cette série, et qui permettent de caractériser une démarche DevSecOps :

Des processus et référentiels sécurité …

• adaptés à la gouvernance projet DevOps (contenu et format), notamment au niveau des questionnaires d’analyse des risques, d’audit  (principes #1 & #12), du “dossier sécurité” de chaque projet (P#3) et du processus d’ISP (P#10 & #11)  
• réévalués conjointement avec les PO et les tech leads des équipes projets (P#11)
• Résumés dans un guide DevSecOps mis à disposition du PO  (P#1)

Une gouvernance projet basée sur …

• des critères objectifs d’évaluation du niveau d’implication requis d’un référent dédié de l’équipe sécurité et une présence a minima de ce dernier dans les comités d’évaluation des projets en mode DevOps avant lancement (P#6)
• idéalement la présence d’un référent sécurité à chaque réunion de définition des besoins sécurité (P#1 & #5), ou a minima lors du sprint 0 (pour initier la démarche et revoir les référentiels sécurité applicables) (P#3)
• le maintien d’un échange au fil de l’eau avec le PO et le(s) tech lead(s) (P#2)
• des relais / champions sécurité identifiés parmi les membres de l’équipe projet (P#4)
• la présence d’un référent sécurité aux rétro projet (P#12)
• une autonomie laissée à l’équipe projet d’adapter les processus sécurité à ses modes de travail (P#11)

Des solutions sécurité …

• reposant sur des phases d’étude / POC de courte durée (P#2)
• co-construite avec un large panel d’intervenants d’horizons divers (P#2 & #9)
• découpées en tâches facilement implémentables dans un seul sprint (P#7 & #10)
• qui  s’appuient autant que possible sur des briques déjà disponibles (P#10)
• intégrées au sein d’US sécurité (avec définition claire du statut « done ») ou dans les “critères sécurité” des US produits (P#3 & # 7)
• intégrées aux sprints sur base d’une gestion des priorités qui permet de couvrir la stricte réponse aux besoins sécurité immédiats du produit, quitte à déployer une solution temporaire à affiner dans le temps (P#8 & #10)

Une communication basée sur…

• une posture proactive des référents sécurité et des échanges directs et en face à face avec les PO & leads projets (P#4)
• un discours sécurité orienté solutions (P#5), et la priorité aux solutions qui permettent de faciliter la standardisation des livraisons (P#9)

Formation & communautés : 

En amont des projets et selon une approche transverse…

• la création de canaux d’échange entre l’équipe sécurité et les référents clés des équipes projet (P#6)
• la formation du PO au processus d’ISP (P#1 & #11) 
• la formation des référents sécurité au devops et la sensibilisation des équipes projets aux bonnes pratiques d’architecture et de développement sécurité adaptées aux technologies et processus utilisées au sein du monde devops (P#1, 4, 6, 9)
• la constitution d’une communauté sécurité devops et/ou la participation de référents sécurité aux communautés devops, agile, etc (P#4)

En sortie de chaque projet…

• la création et la diffusion de REX sécurité, notamment au sein des communautés devops, agile, etc en place dans l’organisation (P# 5, #8, & #12)
• la mise à jour des référentiels et processus sécurité sur base des REX projet (P#1)