Dom Richter, Co-Fondateur de Mondoo – Série d’entretiens

Dom Richter, Co-Fondateur de Mondoo est un leader de produit expérimenté avec une expertise approfondie dans le développement de logiciels modernes, la conception de produits et le leadership d’équipes. Avec une expérience qui couvre les technologies de backend, frontend et d’automatisation, il a dirigé des équipes d’ingénieurs de haute performance à travers une culture de confiance, d’expérimentation et d’innovation axée sur les objectifs. Son travail se situe à l’intersection de l’IA, de la cybersécurité et du DevOps, où il met l’accent sur la collaboration, l’apprentissage continu et la fourniture d’une valeur significative aux utilisateurs finals.

Mondoo est une plateforme d’automatisation de la sécurité et de la conformité qui permet aux organisations d’évaluer, de surveiller et de sécuriser en continu leur infrastructure sur les environnements cloud, sur site et hybrides. En exploitant les politiques en tant que code et les insights basés sur le machine learning, Mondoo aide les équipes à identifier les vulnérabilités, à appliquer les normes de conformité et à renforcer la posture de sécurité sans ralentir l’innovation. La plateforme s’intègre sans effort dans les flux de travail DevOps modernes, ce qui rend la conformité continue une réalité accessible pour les entreprises de toutes tailles.

Qu’est-ce qui vous a inspiré pour co-fonder Mondoo, et comment votre expérience en tant que hacker et leader de produit – ainsi que vos expériences chez Google (GOOGL ), Chef et dans les startups précédentes – a-t-elle façonné la mission de l’entreprise ?

Lorsque j’étais dans les tranchées, en train de pénétrer des systèmes dans le cadre de mon travail de pentester, j’ai trouvé de nombreuses faiblesses facilement évitables. En même temps, la sécurité était souvent tellement axée sur le fait de submerger les utilisateurs d’alertes qu’ils perdaient de vue ce qui était important. À l’époque, j’ai pensé : « Il doit y avoir un simple bouton que je peux appuyer pour résoudre ces problèmes ».

J’ai ensuite changé de camp et commencé à défendre les systèmes. J’ai appris à exploiter correctement les choses à grande échelle, avec l’automatisation et le code. C’est utile que vous soyez en train de gérer un petit réseau domestique ou que vous exploitiez une grande entreprise technologique. Les idées sont les mêmes. Finalement, c’est cette combinaison de sécurité et d’ingénierie de plateforme qui m’a motivé à co-fonder Mondoo. Je voulais faire une différence dans l’état de la sécurité, et non simplement ajouter un autre outil de scan qui générerait davantage d’alertes. Je trouve très motivant de voir comment nos clients sont capables d’améliorer rapidement leur posture avec Mondoo, après avoir été bloqués pendant des années. Plusieurs clients nous ont dit que Mondoo a réduit leurs vulnérabilités ouvertes de 60 %, ce qui est un excellent résultat. Nous essayons d’atteindre 100 % avec notre gestion des vulnérabilités agentic.

Vous avez décrit la remediation – le processus de correction réelle des vulnérabilités après leur découverte – comme un mythe. Pourquoi, selon vous, l’industrie continue-t-elle à investir lourdement dans le scan et la déclaration, tout en laissant les équipes lutter pour appliquer les corrections ?

Ceci est largement le résultat de la façon dont les équipes de sécurité et de plateforme sont configurées, en particulier dans les grandes organisations. Pendant très longtemps, nous les avons traitées comme des entités séparées, chacune avec ses propres objectifs, outils et priorités. Mais la loi de Conway prouve ce qui se passe : vous expédiez votre organigramme au lieu de résoudre le problème. J’ai vu les deux équipes pointer du doigt l’autre – souvent pour de très bonnes raisons.

Nous sommes maintenant enfin en train de vivre un changement dans l’industrie, où les entreprises réalisent qu’elles veulent plus de la sécurité. Elles ne veulent pas un bloqueur commercial. Elles veulent un moteur. Grâce à des leaders visionnaires qui émergent maintenant pour repousser les limites, nous voyons enfin un changement dans l’industrie et dans les solutions.

Comment les organisations peuvent-elles surmonter la faille culturelle entre les équipes de sécurité et de DevOps qui ralentit souvent la remediation ?

DevSecOps est un bon début ; vous devez rapprocher les développeurs et les équipes de sécurité. Vous pouvez embaucher des rôles multifonctionnels qui peuvent aider à combler l’écart, comme des ingénieurs SecOps ou des experts en plateforme avec une expérience en sécurité. De plus, rassembler physiquement les équipes aide. Il est crucial que la direction encourage et joue un rôle dans ce processus. Établissez des objectifs et des métriques partagés et suivez-les.

Pour soutenir vos équipes, vous souhaitez ensuite rassembler l’outillage et la technologie. Je ne parle pas simplement de verser des tickets de sécurité dans les systèmes de ticketing. Vous souhaitez établir un modèle partagé qui donne aux deux équipes ce dont elles ont besoin. Par exemple, nous avons constaté qu’en automatisant les corrections de vulnérabilités où nous donnons aux équipes de plateforme suffisamment de contexte et, surtout, la correction spécifique qu’elles doivent appliquer, cela les aide à exécuter beaucoup plus rapidement les demandes. Plus vous combinez cela avec l’automatisation et créez des demandes de modification dans les systèmes d’automatisation (comme Terraform et Ansible), plus il est facile. Vous souhaitez également avoir un bon chemin de communication retour, c’est-à-dire faciliter aux équipes de plateforme de s’opposer, obtenir des exceptions et signaler les problèmes systémiques. Tout cela encourage la collaboration et comble l’écart.

Quel rôle, selon vous, la direction devrait-elle jouer pour créer de la responsabilité et de la collaboration autour de la correction des problèmes de sécurité ?

En tant que leaders, nous avons deux contributeurs majeurs à la capacité d’exécution de nos équipes : ce que nous communiquons et ce que nous mesurons. Si les leaders ne parlent que de la collecte de résultats et pointent du doigt les autres équipes comme goulet d’étranglement, alors leurs équipes traiteront cela de la même manière. Si ils mesurent le nombre de problèmes de sécurité et non leur qualité et les actions prises, alors les équipes optimiseront pour cela.

Nous créons les bonnes conditions en travaillant avec d’autres leaders à travers les frontières, en reconnaissant la nature partagée de cette zone, et en nous concentrant sur les résultats partagés plutôt que sur les métriques cloisonnées. Une fois de plus, nous voyons que lorsque les leaders abordent le problème partagé ensemble, ils réalisent plus pour leurs équipes individuelles et plus pour l’entreprise, car ils conduisent les résultats qui comptent.

Les scores de risque sont largement utilisés, mais manquent souvent de contexte, et la fatigue des alertes submerge de nombreuses équipes. Comment les organisations devraient-elles repenser la priorisation pour que les problèmes appropriés soient corrigés ?

Pour une priorisation efficace, vous avez besoin de contexte commercial et de contexte technique. Le contexte commercial inclut la connaissance des actifs numériques qui maintiennent les lumières allumées dans votre entreprise et qui doivent être protégés pour maintenir votre bonne réputation. Par exemple, la base de données contenant les photos privées des utilisateurs ou les passerelles qui traitent tout le trafic du site Web sont de haute priorité par rapport aux systèmes de test qui ne sont pas connectés à Internet. Lorsque nous examinons les résultats de sécurité, nous devons connaître le contexte commercial. Si vous affichez « critique » sur une découverte de faible priorité, vos équipes seront désensibilisées et ne le prendront pas au sérieux. Si un problème est vraiment critique, vous devez clairement montrer pourquoi.

Ensuite, il y a le contexte technique. Cela signifie connaître le système, sa configuration, son emplacement, ses balises, ses applications, ses packages et ses utilisateurs. Mais ce n’est pas tout. Vous devez élever votre point de vue. Vous devez comprendre comment une faille de sécurité peut exposer vos systèmes critiques, comment ils sont connectés et intégrés, en regardant non seulement un ou deux systèmes individuels, mais en les regardant comme un cluster. Nous devons également savoir comment ces systèmes sont automatisés et construits pour indiquer rapidement aux gens où regarder et comment corriger le problème à sa source.

Alors que les attaquants utilisent de plus en plus l’IA pour armer leurs attaques, comment les défenseurs peuvent-ils utiliser l’IA de manière responsable pour rester en tête sans créer de nouveaux risques ?

L’utilisation de l’IA multiplie considérablement votre capacité à corriger les vulnérabilités, et à le faire à une vitesse de machine. Cependant, si les systèmes d’IA ne sont pas sécurisés, ils peuvent potentiellement introduire de nouveaux risques dans l’environnement. Lors du déploiement de systèmes d’IA alimentés, il est important de s’assurer qu’ils utilisent une architecture sécurisée et transparente, et permettent un enregistrement et une surveillance d’événements complets. En restreignant les autorisations d’agent aux seules nécessaires pour effectuer les tâches assignées, les risques peuvent être minimisés. D’autres garde-fous, tels que permettre aux utilisateurs d’interrompre ou d’arrêter les systèmes d’IA agentic lorsqu’il est nécessaire, et de procéder à des audits réguliers sur les agents et leurs actions, sont également quelque chose que je recommanderais vivement.

Quels garde-fous, selon vous, sont essentiels lorsqu’on accorde à l’automatisation la capacité de corriger en production ?

Pour chaque action que l’automatisation peut prendre, vous avez besoin de garde-fous pour vous assurer qu’elle agit dans son périmètre attendu. Si vous créez un agent d’IA et lui donnez un accès libre à votre infrastructure entière, il cassera des choses plus tôt que plus tard.

Heureusement, nous comprenons bien les garde-fous grâce au travail acharné dans l’automatisation de plateforme au cours des deux dernières décennies. Les systèmes d’automatisation modernes ont des restrictions en place qui contrôlent les actions qui peuvent être prises. Chez Mondoo, nous combinons les corrections d’IA avec des cadres de politique adverses qui vérifient leurs actions. Toute correction est créée en code, peut être testée, vérifiée et, surtout, restreinte lorsqu’il est nécessaire.

Comment voyez-vous l’évolution de l’équilibre entre la remediation menée par l’homme et la remediation menée par la machine au cours des cinq prochaines années ?

De même que les voitures autonomes, nous allons voir les équipes adopter l’automatisation menée par la machine dans de plus en plus de domaines, un pas à la fois. Ils commenceront par se concentrer sur un sous-ensemble de la portée de la sécurité, comme les systèmes de faible priorité, et introduire l’automatisation agentic pour cela, en créant des métriques et en suivant les objectifs, puis en déployant progressivement. Une fois que cela est automatisé, vous étendez à d’autres domaines.

Finalement, la focalisation de l’automatisation devrait être sur les domaines qui sont grands en échelle avec de nombreuses similitudes. Ceux-ci bénéficient le plus de la cohérence que l’automatisation apporte. Je crois que dans cinq ans, toutes les actions de correction majeures seront menées par la machine et que les systèmes seront étroitement intégrés entre la sécurité et les opérations de plateforme.

Quelle est votre vision à long terme de la façon dont la gestion des vulnérabilités devrait ressembler d’ici la fin de cette décennie ?

D’ici la fin de la décennie, la gestion des vulnérabilités aura une focalisation beaucoup plus forte sur l’automatisation et la correction. Notre rôle en tant que spécialistes de la sécurité sera plus axé sur l’évolution de cette automatisation, en travaillant avec les équipes de plateforme sur la sécurisation de leurs environnements IT en constante évolution. Ces systèmes seront plus étroitement intégrés, en utilisant l’automatisation de plateforme et l’IA agentic pour prendre des actions à grande échelle tout en étant sécurisés et prévisibles.

Pour les petites équipes de sécurité à ressources limitées, quels premiers pas pratiques peuvent-elles prendre pour améliorer la remediation et la résilience ?

Commencez par l’automatisation des correctifs. Introduisez l’automatisation tôt – surtout lorsque vous avez des ressources limitées – et intégrez la sécurité dès le départ. C’est la étape la plus simple qui diminue déjà considérablement l’exposition aux analyses automatisées que les attaquants utilisent.

Je vous remercie pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Mondoo.