wigglestick - stock.adobe.com
Doctolib divise par deux ses incidents de sécurité liés aux secrets
Doctolib multiplie les applications pour les professionnels de santé. Autant d’applications qui traitent des données dont la sécurité ne tolère aucune approximation, tout particulièrement dans la gestion des secrets par les développeurs.
Doctolib compte aujourd’hui 2 900 personnes. Le site Web destiné aux patients ne représente qu’une petite partie de ce que l’éditeur de services propose, et tout particulièrement aux soignants : depuis la gestion des rendez-vous, la prise de notes lors de la consultation jusqu’à la gestion des dossiers patients.
L’activité « Tech & Product » représente 800 personnes, dont 20 pour l’équipe Cyber. Il y a environ 2 ans, cette équipe s’est intéressée à la problématique des secrets et à la manière de protéger les certificats et mots de passe : « nous voulions veiller à ce que nos secrets le restent ! Nous devions ainsi nous assurer qu’ils n’apparaissent pas dans le code et qu’ils soient tous protégés dans un bastion », résume Tanguy Segarra, Blue Team Tech Lead chez Doctolib.
Et à juste titre : « les exemples de secrets malencontreusement poussés sur GitHub sont légion dans les médias et même si nos repository ne sont pas accessibles au grand public, nous ne voulions pas courir ce risque ».
Doctolib disposait déjà du Vault d’HashiCorp pour stocker de manière sûre ses secrets, mais un tel dispositif ne met pas à l’abri de retrouver des secrets glissés dans le code en phase de développement et qui se retrouvent malencontreusement en phase de test, ou même en production.
Une approche initiale trop consommatrice de ressources humaines
Au départ, l’équipe projet a mis en œuvre un outil de détection des secrets publié par Yelp sur GitHub. L’idée était d’effectuer un scan systématique du code produit par les développeurs, puis de contacter ces derniers afin que ceux-ci réalisent les corrections nécessaires dans le code source.
« Scanner de manière exhaustive le code et contacter systématiquement les développeurs était une approche extrêmement laborieuse », reconnaît le responsable : « nous avions un rôle d’intermédiaire peu valorisant. Cela nous demandait beaucoup d’efforts pour une tâche à faible valeur ajoutée. Nous avions développé une orchestration avec Yelp Detect-Secrets, mais nous avions besoin d’une solution capable d’automatiser ce processus ».
L’équipe projet va se mettre en quête d’une solution « Best of Breed » pour automatiser ce traitement des secrets. Cette approche est assez commune chez Doctolib, qui n’hésite pas à faire appel aux meilleures solutions existantes sur le marché afin de répondre au mieux aux besoins de ses équipes.
Cette démarche a conduit l’équipe projet à sélectionner la solution GitGardian. Néanmoins, imposer une solution cyber à des équipes de développement n’est pas si simple : « les développeurs peuvent être réfractaires à la mise en place de nouvelles contraintes », explique Tanguy Segarra. Car, « l’outil est alors vu comme une entrave à leur travail quotidien. Or ce n’est pas le but. L’idée est de cadrer le travail et d’entraîner l’adoption de bonnes pratiques vis-à-vis des secrets, en mettant en place une rotation de ces secrets auprès des développeurs ».
Toutefois, en matière de conduite du changement, impossible de mettre en place un tel outil de manière trop agressive et de bloquer le jour J toutes les pull-request lorsque le code n’est pas conforme aux règles de sécurité définies dans l’outil. Une telle démarche aurait irrémédiablement conduit à un rejet par des équipes soumises à leurs propres contraintes de productivité.
Un démarrage prudent avant d’accélérer
La démarche retenue pour déployer GitGuardian fut de démarrer par une équipe d’une cinquantaine de personnes qui travaille sur de gros dépôts de code. Des présentations de l’outil ont été menées auprès des développeurs, des présentations très rapides pour que chacun s’imprègne de l’outil et des principaux concepts.
L’idée était aussi de ne pas introduire de règles trop strictes au départ pour faciliter l’adoption de l’outil auprès des équipes DevOps : l’objectif « était bien d’inciter les développeurs à adopter une hygiène cyber vis-à-vis du code qu’ils produisent. La démarche était progressive et tolérait certains bypass au début ».
Ce premier déploiement sur un périmètre restreint a permis d’apporter quelques ajustements aux tests de validité et aux règles de sévérité mises en place avant l’élargissement de l’outil à l’ensemble des équipes. Quatre niveaux de sévérité ont été définis dans l’outil, avec une attention toute particulière au code s’exécutant sur les plateformes Cloud : « très rapidement nous avons mis en place les premiers filtres, afin de protéger notamment les secrets les plus critiques. L’atout de GitGuardian est de nous avoir permis de prioriser une cinquantaine d’incidents à traiter urgemment, ce dont nous ne disposions pas jusqu’alors ».
L’intégralité du code sous surveillance
Après ce premier pilote, le déploiement de GitGuardian est élargi à toutes les équipes et tous les repository en septembre 2023. Désormais, la solution inspecte de manière systématique les repository de Doctolib. L’intégralité du code est sous surveillance permanente et un système d’alerte automatique a été mis en place : « nous disposons maintenant d’une catégorisation automatique des secrets et les tickets sont générés par l’outil afin que les corrections soient traitées au plus vite par les équipes ».
L’effet de la solution a été immédiat. Sur la période 2018 à 2022, le succès du service Doctolib a poussé l’éditeur à multiplier les projets et nouveaux développements. Le nombre d’incidents est passé de 130 en 2019 à un pic de 2 200 en 2023. Après le déploiement de GitGuardian, le nombre d’incidents a été divisé par plus de deux et cette tendance encourageante se maintient pour 2024.
Pour Tanguy Segarra, c’est la combinaison du Vault HashiCorp et de GitGuardian qui a permis d’atteindre un résultat aussi significatif aussi rapidement sans se mettre à dos les développeurs.
Propos recueillis lors des Assises de la sécurité 2024.
