• Fréquence de déploiement : la cadence des mises en production réussies d’une organisation. Plus la fréquence est élevée, mieux c’est.
• Délai moyen de mise en œuvre des changements : le temps qu’il faut à un développeur pour passer en production. Plus il est faible, mieux c’est.
• Délai moyen de retour à la normale : le temps nécessaire à une équipe pour rétablir le service en cas de panne imprévue ou d’autre incident. Plus l’intervalle de temps est court, mieux c’est.
• Taux d’échec des changements - Fréquence à laquelle les changements apportés entraînent des échecs dans la production. Plus le pourcentage est faible, mieux c’est.

Les indicateurs DORA aident les entreprises à évaluer rapidement la santé globale de leur équipe et de leur production. Ces indicateurs sont influencés par de nombreuses mesures, mais ils constituent un moyen pratique d’évaluer les performances DevOps à un niveau élevé.
Cette méthodologie regroupe les organisations dans l’un des trois niveaux de performance globale : Faible, Moyen ou Élevé.

Le tableau ci-dessous présente la matrice des indicateurs de performance.

Mesures de gestion des secrets
Il est légitime de se demander : "Où la sécurité du code, et plus particulièrement la gestion des secrets, apparaît-elle dans les mesures de DORA ?" Ou : "Comment pouvons-nous rendre notre code plus sûr en ce qui concerne les secrets tout en livrant nos applications à un haut niveau de performance ?" Le secret ici, comme pour beaucoup de choses dans DevOps, est de "shift left".
Mais d’abord, il est nécessaire de mesurer la posture de sécurité du code. Il existe un modèle de maturité de gestion des secrets, une feuille de route rapide pour aider votre organisation à comprendre sa posture de sécurité autour des informations d’identification et comment l’améliorer.

Dans ce modèle, quatre domaines majeurs du cycle de développement durable (SDLC) sont cartographiés :
• Environnement du développeur
• Gestion du code source
• Pipeline CI/CD et artefacts
• Environnements d’exécution

À partir de là, il est possible d’évaluer la maturité d’une équipe sur une échelle de cinq niveaux pour chacun de ces domaines, avec l’intention de passer au niveau suivant. Le rapport complet est beaucoup plus détaillé, mais voici un résumé rapide de chaque niveau :

0. Non initié - Les secrets sont en clair et aucune détection des secrets n’est en place.
1. Débutants - Les secrets sont non chiffrés dans les fichiers de configuration, et un scan occasionnel de détection des secrets est déclenché manuellement.
2. Intermédiaire - Les secrets sont stockés dans un coffre-fort et partagés par un gestionnaire de secrets, et analysés en permanence à l’étape des demandes d’extraction/fusion.
3. Avancé - Les secrets sont stockés dans un coffre-fort et partagés exclusivement par l’intermédiaire d’un gestionnaire de secrets, et une politique de rotation des secrets bien définie est en place. Les champions de la sécurité adoptent l’analyse avant de pousser le code (pre-commit / pre-push) et les développeurs sont systématiquement impliqués dans le processus de remédiation.
4. Expert - Les secrets sont stockés dans un coffre-fort avec des contrôles d’accès et une journalisation. Les secrets dynamiques ont une portée limitée et tous les référentiels sont surveillés en permanence. Les flux de travail de remédiation sont automatisés et les développeurs corrigent directement les problèmes.

Quel est le lien avec DORA ?
Maintenant que le vocabulaire pour communiquer sur la gestion des secrets est clair, quel est son impact sur DORA ? Examinons chaque niveau du modèle de maturité et voyons comment il peut influer sur un flux, ce qui est une autre façon pour DORA de parler de performance.
Niveau 0 - Aucun plan en place
Comme les non-initiés ne s’en préoccupent pas, il peut sembler que cela n’ait pas d’incidence sur les résultats dans un premier temps. Les choses changent brusquement lorsqu’un incident de sécurité se produit. L’absence de plan de gestion des secrets peut avoir un impact considérable sur le temps moyen de retour à la normale, car l’équipe se démène pour faire face à l’incident.
Le temps nécessaire pour "se concentrer sur la sécurité" après un incident va peser lourd sur le délai de changement. Déterminer comment faire pivoter les clés affectées et comment remanier le code pour prévenir les violations ultérieures demande beaucoup d’attention et est stressant, surtout après un incident.

Niveau 1 - Débutant
À ce niveau de maturité, lorsque la détection des secrets a lieu, c’est à un stade avancé du cycle de développement du logiciel, lors de la phase de test préalable au lancement. Lorsqu’il est détecté aussi tardivement, le flux de travail va s’inverser, car le code qui échoue aux tests sera renvoyé au développeur pour qu’il le remanie et traite le secret exposé. Cette accumulation de correctifs provenant de tests échoués signifie que la fréquence de déploiement et le délai moyen de mise en œuvre des changements vont tous deux en souffrir.

Niveau 2 - Intermédiaire
À ce stade, étant donné que l’on stocke régulièrement des secrets en toute sécurité et que l’on recherche des secrets à chaque Peer Review, on détecte les erreurs avant la phase de test, ce qui réduit l’impact sur le flux de travail de l’équipe. Toutefois, l’incohérence signifie qu’il arrivera que des erreurs soient détectées trop tard, ce qui bloquera le travail et empêchera les éléments en attente de progresser. Les organisations qui se trouvent dans cette situation se situent généralement dans la catégorie des organisations moyennement performantes, alors qu’elles s’efforcent de devenir des organisations très performantes.

Niveau 3 - Avancé
Même si un incident occasionnel lié au secret affecte la fréquence de déploiement et le délai moyen de mise en œuvre des changements, dans l’ensemble, une organisation les traitera beaucoup plus rapidement et sera probablement déjà très performant ou en bonne voie de l’être. L’objectif pour les personnes de ce niveau est de standardiser les pratiques dans toutes les équipes et d’automatiser le travail comme la rotation des secrets et le feedback des développeurs lorsque des incidents surviennent.

Niveau 4 - Expert
À ce stade de son parcours, une entreprise peut occasionnellement rencontrer des incidents sporadiques liés aux secrets, mais il s’agira d’exceptions dans une organisation DevOps, par ailleurs en pleine effervescence. À ce niveau de maturité, chaque développeur recherchera automatiquement les secrets, en utilisant un outil comme ggshield exécuté via les hooks git avant que chaque commit ne soit terminé. Cette pratique signifie que les secrets vont rarement plus loin que le terminal du développeur.

Dans le même temps, l’organisation aura mis en place les processus appropriés, de sorte qu’il ne faudra que quelques instants pour modifier le code et gérer les secrets, sans impact notable sur la fréquence de déploiement ou le délai moyen de mise en œuvre des changements. C’est l’idéal vers lequel nous devrions tous tendre.

Les secrets font partie d’une équation plus large
De nombreux facteurs influencent le score DORA. La maturité de la gestion des secrets n’est qu’un facteur parmi d’autres, mais c’est un facteur important que toute organisation DevOps doit prendre en compte. Au-delà de la vélocité, elle peut également avoir un impact sur les résultats de l’entreprise en cas de violation. Il est essentiel de maîtriser les informations d’identification codées en dur dans l’ensemble du code, quel que soit le stade du cycle de développement logiciel.