« Qu’est-ce donc que le temps ? Si personne ne m’interroge, je le sais ; si je veux répondre à cette demande, je l’ignore » (St-Augustin)

Remplacez « temps » par « DevSecOps », et la phrase fonctionne tout aussi bien !

Il existe des termes qui semblent faire partie d’un patrimoine commun. Tout le monde les utilise, et le sens qu’ils recouvrent est une évidence pour chacun. Jusqu’à ce qu’on ait besoin de les définir précisément… Et là, c’est le drame !

Dans mon quotidien, le terme DevSecOps fait clairement partie de ces mots à la définition large, ambiguë et incertaine. Chacun a la sienne, moi y compris ! Ce qui peut être source de nombreuses incompréhensions quand vient le temps de définir une liste d’exigences, un RACI projet ou un dispositif de RUN !

Quand le flou règne en maître et qu’aucune autorité n’a la charge de fixer de point de référence, mon réflexe est souvent de fonctionner par analogies : mettre en regard le terme à définir de notions mieux cadrées, pour voir l’éclairage qu’elles peuvent lui apporter. 

En l’occurrence, je vais chercher dans cet article à définir la notion de « DevSecOps » en la mettant en parallèle du concept d’« agilité ». Plus précisément, je vais dresser les analogies possibles entre d’un côté les 12 principes agiles et de l’autre le terme « devsecops ».

Pour rappel l’Agile repose sur 4 valeurs :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

Ces valeurs se déclinent à travers 12 principes opérationnels. 

Dans la suite de cet article, je vais donc reprendre chacun de ces principes et les appliquer à la démarche d’accompagnement sécurité pour identifier les actions opérationnelles qui permettent de marquer une démarche sécurité du tampon « DevSecOps certified » ! (nb : cet article est divisé en 3 parties, chaque partie présente 4 principes chacune)

1) Satisfaction des clients

“Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.”

Ça peut paraître une évidence, mais il est important de rappeler qu’une démarche sécurité, qu’elle soit DevSecOps ou pas, vise avant tout à mettre en place un dispositif qui couvre le besoin du client final. En l’occurrence, avoir la garantie que ses biens seront protégés à leur juste valeur, ni trop, ni pas assez. Par “valeur”, je fais référence, pour synthétiser, à la fois au niveau de sensibilité DICT du bien (Disponibilité, Intégrité, Confidentialité et Traçabilité) et aux obligations de conformité légale et réglementaire qui lui sont rattachées. Mais ni plus, ni moins !

Une démarche DevSecOps émerge dans les organisations qui se sont mises en ordre de marche pour développer des projets applicatifs caractérisés par un time to market court, des livraisons tronçonnées, le passage au fil de l’eau d’un MVP à un produit standardisé… En un mot, qui vise à produire plus vite, sans sacrifier pour autant la qualité (ni exploser les coûts – ah, le fameux triangle…). 

Par conséquent, pour qu’une démarche DevSecOps soit adaptée, il faut qu’elle soit adoptée. C’est à dire que les bénéficiaires finaux, à savoir les clients, sentent qu’elle s’inscrit elle aussi dans ce sens de l’histoire “agile / devops” et qu’elle y apporte une réelle plus-value. 

Pour ce faire, une démarche DevSecOps s’appuie sur un ensemble d’outils qui permet de cadencer les activités sécurité au même rythme que les autres activités de build et d’aligner le vocabulaire et les périmètres d’étude :

• Des questionnaires d’analyse des risques adaptés aux projets en mode Agile et à un processus d’analyse plus court mais aussi plus itératif, afin de coller à la réalité terrain (la liste des fonctionnalités à développer n’est pas entièrement connue au début du projet mais mise à jour au fil de l’eau). 
• Des questionnaires d’audit eux aussi adaptés aux périmètres techniques et projets sur lesquels ils vont être appliqués. Par exemple, rien de plus consommateur en énergie, pour un bénéfice nul, que d’essayer d’auditer une plateforme cloud avec un questionnaire adapté à un environnement on premise. “Bonjour, vous avez 500 lignes à remplir dont 50% non applicables, à vous de les identifier….”
• La participation d’un référent sécurité à chaque réunion de définition des besoins sécurité organisée par le Product Owner (ou a minima à la première itération) pour faciliter la montée en compétence de ce dernier sur le sujet. A défaut, s’assurer au moins que le PO a reçu en amont une formation pratique et dispose d’un guide auquel se référer par la suite.
• Au lancement du projet, une réunion de relecture des référentiels sécurité génériques pour extraire uniquement le contenu applicable (en fonction des besoins client mais aussi du contexte technologique et méthodologique projet)
• En amont, un programme de sensibilisation et de formation à la sécurité des architectes, membres leader des équipes devops et référents en charge de l’exploitation (liste bien sûr non exhaustive, à adapter en fonction des réalités organisationnelles). Les référents des équipes sécurité ne peuvent, et ne doivent pas, être présents sur tous les projets pour répondre en temps et en lieu à chaque question client. L’émergence de “champions sécurité” directement issus des équipes projet est non seulement la seule alternative viable, mais aussi la plus souhaitable. Après tout, security is everyone business ! 

2) Accepter le changement du besoin

“Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.”

La seule chose qui ne change pas, c’est le changement ! C’est pourquoi une méthode DevSecOps est construite de façon à s’adapter aux changements fonctionnels et techniques projet : les besoins Métiers s’affinent, des contraintes techniques apparaissent, les priorités de livraison évoluent. C’est toujours le cas qu’il s’agisse d’un projet mené selon la méthode en V ou Agile. Mais cette gestion du changement est beaucoup plus critique dans un projet Agile, où le temps de réalisation est raccourci et les mises en production sont plus fréquentes.

Il est vain de penser qu’en réalisant l’analyse sécurité d’un projet en phase de cadrage ou de spécifications, tout le travail est fait et qu’aucune autre charge n’est à prévoir par la suite (cf. d’ailleurs le premier principe). 

C’est pour cela qu’une démarche DevSecOps intègre des solutions pour pouvoir suivre le projet tout au long de ses différents cycles de développement / MEP. De façon concrète cela signifie :

• Etre en lien régulier avec le Product Owner et le(s) tech lead(s) pour suivre les évolutions au fil de l’eau. Un bon moyen, par exemple, est d’assister de temps en temps aux réunions daily et/ou de revue du backlog, pour prendre le pouls du projet et répondre aux questions d’actualité. Une implication ponctuelle mais concrète est toujours plus efficace qu’un mail de sollicitation auquel les équipes projets n’ont pas toujours le temps de répondre…
• Lorsqu’elles sont requises, veiller à favoriser des phases d’étude / de POC de courte durée. Inutile d’envisager de tester pendant des semaines ou des mois une nouvelle solution de sécurité pour répondre aux besoins d’un projet cadencé par des MEP toutes les trois semaines. Surtout si, et il parait que ça arrive…, le périmètre fonctionnel ou technique projet change en cours de route… 
• Co-construire au maximum les solutions sécurité avec un large panel d’intervenants venant de divers horizons (sécurité mais aussi développement, architecture, exploitation, surveillance…). Cela permet non seulement de bénéficier des connaissances croisées, mais aussi d’anticiper les difficultés ou changements potentiels, d’identifier au plus tôt des solutions alternatives et d’acculturer tous ces experts aux discussion sécurité… pour qu’ils les mènent par eux-mêmes lors des prochains projets !

3) Livraisons fréquentes

“Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.”

Les livraisons fréquentes peuvent être vues comme un cauchemar par les équipes sécurité, parce qu’elles les forcent à augmenter leur temps de présence sur les projets (cf. principe #2). 

Mais cela peut-être vu également comme un avantage : le fait de livrer régulièrement des fonctionnalités (ou des morceaux de fonctionnalités) permet d’avoir plus rapidement des retours sur les avantages et limites des mesures de sécurité mises en place et donc de les réorienter rapidement si besoin est.

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

• Une intégration des besoins sécurité dans chaque sprint projet, sous forme de user story sécurité ou de critères de “done” des user stories fonctionnelles ou techniques.
• Une présence obligatoire d’un référent sécurité à la réunion de lancement du sprint 0 d’un projet. Pour les  autres sprints, s’il est impossible d’être présent régulièrement, favoriser a minima une présence aux réunions de sprint plannings (puis évaluer sur la base des fonctionnalités à livrer si la présence aux réunions de sprint demos et rétros est requise) et de revue du backlog (cf. également 2ème principe)
• Adapter le format de la documentation sécurité projet (souvent identifié comme “le dossier sécurité”) afin de faciliter sa mise à jour itérative.

4) Travail client-dev

“Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.”

Pour s’assurer que la sécurité est intégrée au plus proche des réalités terrain / produit, il est important que le référent sécurité échange régulièrement avec les personnes qui vont concrètement mettrent en oeuvre la solution.

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

• Des référents sécurité proactifs et impliqués dans les projets. Quand je parle d’“échange”, je fais référence à une communication orale et en face à face, pas à l’envoi ponctuel par mail d’un document de 100 pages sur l’ensemble des règles théoriques à implémenter. Et évidemment, plutôt en amont du sprint 0 qu’après la 3ème ou 4ème releases. Cela va sans dire, mais des fois…
• Des référents sécurité formés aux pratiques et outils des équipes de développement et aussi des développeurs / architectes / devops formés aux bonnes pratiques sécurité et aux outils spécifiques en fonction de leur contexte technologique (ex. : les services managés sécurité d’un fournisseur cloud). 
• Des relais / champions sécurité projet identifiés parmi les collaborateurs ayant bénéficié d’une formation sécurité et ayant une appétence sur le sujet (il paraît que ce n’est pas le cas de tout le monde… je me demande encore pourquoi, mais soit). Ce qui libérera du temps aux équipes de sécurité, qui pourront se concentrer par exemple sur la mise en place et le suivi des mesures de monitoring et contrôle (cf. le 3ème principe).
• La mise en place d’une communauté sécurité composée de référents de différentes entités, métier, domaines d’activité et/ou la présence des référents sécurité aux communautés cloud, devops, agile, etc. existantes dans l’organisation (et/ou dans l’équipe CCOE, si votre organisation en a une).

Voilà qui conclut pour cette première partie. Dans les deux parties suivantes, nous verrons les caractéristiques de la démarche DevSecOps en lien avec les principes suivants :

• Motivation des équipes
• Le dialogue face à face
• Opérationnel sinon rien
• Rythme soutenable
• L’excellence technique
• La simplicité
• Equipes auto-organisées
• Amélioration continue