Dans la 2ème partie de cet article, je vais continuer 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.

5) Motivation des équipes

“Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.”

Dans un monde “agile”, l’humain est replacé au coeur du dispositif. Ce ne sont plus les processus, les KPI et les OKR qui priment (vous ne savez pas ce à quoi fait référence le dernier terme ? Pas grave, ce n’est justement pas important…). La clé est de créer l’émulation au sein d’une équipe et de maintenir l’envie de s’impliquer en montrant à chacun qu’il a la capacité à faire ce pour quoi il est attendu. 

Une démarche DevSecOps permet donc à chaque intervenant projet, hors équipe sécurité, de se sentir en capacité de traiter les aspects sécurité, voire d’aimer ça (ok, là on approche d’une vision idyllique mais “Celui qui avance avec confiance dans la direction de ses rêves connaîtra un succès inattendu dans la vie ordinaire”, Nancy H. Kleinbaum. Convaincus ?) 

Par conséquent, une démarche DevSecOps s’appuie sur … la capacité pour l’équipe sécurité d’apporter des croissants frais à tous les daily meetings ! Bon, plus sérieusement (mais pensez-y quand même) : 

• Une attention apportée sur la posture et le discours. Qui n’a pas déjà entendu la traditionnelle remarque « les gens de la sécurité ne savent dire que non… » ? C’est très réducteur, et frustrant pour tous ceux qui essaient sincèrement de faire de la sécurité une plus-value métier et non un frein (et en même temps, qui achèterait une voiture sans frein ?). Mais il n’y a pas de fumée sans feu. Le fond importe autant que le forme et il y a beaucoup à gagner à avoir un discours orienté solutions, d’anticiper les difficultés pouvant être amenées par des exigences et de participer à la recherche des alternatives avec l’équipe projet (plutôt que de rester enfermé dans une tour d’ivoire, par exemple…). 
• Dans la même idée, privilégier les échanges menés dans le cadre de réunions, de rencontre en face à face avec les membres des équipes projet et une démarche d’accompagnement itérative et pédagogique (cf. le principe #4). Plutôt que de se contenter d’envoyer des mails et des liens vers des référentiels, parfois abscons. 
• S’impliquer sur un projet dès le début plutôt que d’arriver à la fin, avec une grille de contrôles “surprise” à la main. Personne n’aime avoir une épée de Damoclès au-dessus de la tête ni se faire superviser par “l’inspecteur des travaux finis” (cf. le principe #3)
• Formaliser des REX sur la façon dont l’accompagnement sécurité a été concrètement mené dans de précédents projets, et les présenter dans des sessions d’échange des communautés DevOps, Agile, etc. Cela permettra aux référents projet de mieux comprendre comment prendre en main la sécurité dans leurs prochains projets.

6) Le dialogue face à face

“La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.”

Cela peut paraître une évidence mais rien ne remplace une communication en présentiel. Soit, des facteurs extérieurs peuvent rendre cet objectif un peu complexe à mener (par exemple dans le cas de projets menés avec des intervenants répartis sur plusieurs zones géographiques, ou encore une situation de confinement exceptionnelle…).

Cela signifie qu’une posture “face à face” se travaille aussi en amont, dans le temps, et chaque fois que possible, pour que les cas où ce n’est pas possible soient des exceptions et non la norme.

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

• une priorisation des projets. Parfois, beaucoup d’initiatives sont menées en parallèle, Il et il est humainement impossible d’être partout pour pouvoir tout adresser. Il est donc important d’être partie prenante dans les comités et processus qui évaluent tous les projets avant leur lancement et de disposer de critères pour identifier ceux qui doivent bénéficier d’une présence dédiée et en continu d’un référent sécurité.
• des référents formés à la sécurité au sein de chaque équipe projet. L’objectif reste que tous les projets soient accompagnés par un ou plusieurs intervenant(s) responsable(s) de s’assurer que les enjeux sécurité sont traités de façon adéquate. Cela ne peut pas toujours être fait par une personne de l’équipe sécurité; et la situation idéale est même que les équipes projet disposent des capacités nécessaires pour être autonome sur cet aspect. C’est pourquoi il est important d’avoir mené en amont des campagnes de sensibilisation et de formation pour que chacun comprenne la part qu’il lui est dévolu et soit en mesure de se l’approprier (cf. le principe #4)
• la création d’une relation avec les piliers des équipes projet en amont des phase de lancement. Pourquoi attendre qu’un projet démarre pour porter les messages sécurité ? En organisant des points d’échange exploratoires au fil de l’eau avec les tech leads, les architectes, les coachs Agile (oui, oui, vos futurs meilleurs amis!), les responsables et référents senior des équipes d’exploitation, etc., il est possible de démontrer une ouverture et un engagement a priori, pour établir un climat de confiance avant que “la bataille” soit lancée. Cela simplifiera la collaboration par la suite, car la sécurité sera vue comme un enabler et un membre de l’équipe présente sur le terrain de jeu plutôt qu’un intervenant en retrait.

7) Opérationnel sinon rien

“Un logiciel opérationnel est la principale mesure d’avancement.”

Quand on mesure l’état d’avancement d’un produit ou service, l’Agile rappelle que seules les tâches finies sont mesurées. Tout ce qui est entamé mais non terminé est considéré comme à 0% d’avancement. Et rien de plus déprimant qu’un backlog qui grossit à vue d’oeil, surchargé par exemple de tâches sécurité jamais terminées.

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

• Un découpage granulaire des exigences sécurité et leur transposition en tâches facilement implémentables dans un seul sprint, quitte à faire évoluer les fonctionnalités sécurité au fil des sprints en ajoutant de nouvelles tâches. 
• Une clarification dès le sprint 0 des critères qui permettent d’attribuer le statut « done » à une user story sécurité, et des “critères sécurité” qui permettent de valider la réalisation d’une user story fonctionnelle ou technique (cf. le principe #3)

8) Rythme soutenable

“Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.”

En résumé, inutile d’empiler les exigences, les comités et les tableaux d’avancement à l’excès. À moins de chercher à ce que les processus sécurité soient continuellement contournés sous prétexte qu’ils ajoutent une charge décorrélée de leur plus-value. La valeur est à chercher dans la qualité et la pertinence de ce qui est produit, pas dans la quantité. Small is beautiful ! 

De toute façon, à moins de disposer d’un droit de veto absolu, ce qui est rarement le cas et, entre nous soit dit, pas vraiment souhaitable, il est irréaliste de penser qu’un projet sera durablement retardé ou arrêté parce qu’il ne répond pas à toutes les exigences sécurité qu’on aura pu lui formuler. En réalité, il sortira quand même, plus ou moins bien protégé, et tout le reste sera repoussé “après la mise en production”. Ce qui parfois signifie jamais…

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

• Une gestion des priorités quant aux mesures à mettre à oeuvre. Pour commencer, il est inutile de travailler aujourd’hui sur les problèmes de demain. En général, un projet Métier est en mesure d’exprimer quelques besoins sécurité à court terme. Autant commencer par traiter uniquement ceux-là, plutôt que de se projeter sur ceux qui pourraient survenir dans 6 mois. 
• Pour faire un parallèle avec les concepts utilisés en architecture applicative, cette approche est similaire à celle désignée sous le terme “YAGNI” (You Ain’t Gonna Need It) : inutile d’inclure au produit final des éléments qui ne sont pas utiles dans l’immédiat. Il sera toujours temps de les ajouter au moment voulu.
• Même logique en termes de solution : c’est une tendance naturelle de vouloir déployer dès le début une mesure de sécurité finale, “parfaite”, qui fait appel aux meilleurs standards de l’industrie. Mais cela peut aussi nécessite de longues études, des POCs, qui repoussent d’autant la date d’implémentation. Il est souvent souhaitable de commencer par déployer une solution temporaire, qui couvre les principaux besoins sécurité d’un projet, surtout quand les équipes BUILD et RUN de ces solutions ont un niveau de maturité encore faible sur ces mesures. Des travaux d’optimisation pourront être menés en parallèle de la montée en puissance du projet Métier (et d’une augmentation de ses besoins sécurité) (cf. les principes #2 et #3)
• Pour faire à nouveau un parallèle avec des concepts utilisés en architecture applicative, cette approche est similaire à celle désignée sous le terme “MoSCoW” (Must have, Should have, Could have, Won’t have) : en se basant sur les résultats de l’analyse de risque sécurité, il serait opportun de déterminer le minimum vital sécurité pour une application ou un composant en étiquetant chacune des mesures avec une des 4 catégories “Must”, “Should”, “Could”, “Won’t” afin de livrer rapidement la valeur essentielle pour les utilisateurs.
• Pour finir, au risque de me répéter, avoir identifié en amont des référents sécurité directement dans les équipes projet et avoir communiqué des REX sécurité dans les communautés Sécurité, Devops, etc et moins l’équipe sécurité aura besoin d’être sur tous les fronts et de faire des journées de 48h…

Voilà qui conclut cette 2ème partie. Dans la dernière partie, nous verrons les caractéristiques du démarche DevSecOps en lien avec les principes suivants :

• L’excellence technique
• La simplicité
• Equipes auto-organisées
• Amélioration continue