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

Dom Richter, Co-Fondateur de Mondoo est un leader de produit chevronné avec une expertise approfondie dans le développement de logiciels modernes, la conception de produits et le leadership d’équipes. Avec une expérience couvrant les technologies de backend, de frontend et d’automatisation, il a dirigé des équipes d’ingénierie de haute performance à travers une culture de confiance, d’expérimentation et d’innovation axée sur l’objectif. Son travail se situe à l’intersection de l’IA, de la cybersécurité et de 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 de continuellement évaluer, surveiller et sécuriser leur infrastructure dans les environnements cloud, sur site et hybrides. En exploitant les insights basés sur le code de politique et l’apprentissage automatique, 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, rendant la conformité continue une réalité accessible pour les entreprises de toutes tailles.

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

Lorsque j’étais dans les tranchées en train de pénétrer dans 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 comptait vraiment. À 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 ai commencé à défendre les systèmes. J’ai appris à les exploiter correctement à grande échelle, avec l’automatisation et le code. C’est utile que vous exploitiez 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 scanneur qui générerait plus 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 pensez-vous que l’industrie continue d’investir lourdement dans le scanning et la déclaration tout en laissant les équipes lutter pour effectuer les corrections ?

Ceci est en grande partie 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 la plus grande partie du temps, 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 dirigeants 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 DevOps qui ralentit souvent la remediation ?

DevSecOps est un bon début ; vous devez rapprocher les développeurs et la sécurité. Vous pouvez embaucher des rôles polyvalents 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, le fait de rassembler physiquement les équipes aide. Il est crucial que la direction encourage et participe à ce processus. Établissez des objectifs et des métriques partagés et suivez-les.

Pour soutenir vos équipes, vous voulez ensuite rassembler l’outillage et la technologie. Je ne parle pas simplement de décharger les tickets de sécurité dans les systèmes de ticketing. Vous voulez é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 voulez également avoir un bon chemin de communication retour, c’est-à-dire faciliter la tâche pour les équipes de plateforme de s’opposer, d’obtenir des exceptions et de signaler les problèmes systémiques. Tout cela encourage la collaboration et comble l’écart.

Quel rôle pensez-vous que la direction devrait jouer dans la création de responsabilité et de collaboration autour de la correction des problèmes de sécurité ?

En tant que dirigeants, nous avons deux contributeurs majeurs à la capacité d’exécution de nos équipes : ce que nous communiquons et ce que nous mesurons. Si les dirigeants 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 conditions appropriées en travaillant avec d’autres dirigeants au-delà des frontières, en reconnaissant la nature partagée de ce domaine et en nous concentrant sur les résultats partagés plutôt que sur des métriques cloisonnées. À plusieurs reprises, nous voyons que lorsque les dirigeants 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 d’alerte 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 de quels actifs numériques maintiennent les lumières allumées dans votre entreprise et 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 un résultat de faible priorité, vos équipes seront déssensibilisé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 un problème 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 dire rapidement aux gens où regarder et comment corriger le problème à sa source.

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 alimentés par l’IA, 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 terminer 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 lorsque nécessaire, et effectuer des audits réguliers sur les agents et leurs actions, sont également quelque chose que je recommanderais vivement.

Quels garde-fous pensez-vous être essentiels lors de l’octroi à l’automatisation de la capacité de corriger en production ?

Pour chaque action que l’automatisation peut prendre, vous avez besoin de garde-fous en place pour vous assurer qu’elle agit dans son étendue attendue. Si vous créez un agent d’IA et lui donnez un accès libre à votre infrastructure entière, il cassera des choses tôt ou 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 agentic alimentées par l’IA avec des cadres de politique adverse qui vérifient leurs actions. Toute correction est créée en code, peut être testée, vérifiée et, surtout, restreinte lorsque 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 manière similaire aux 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 élargissez à 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 qu’en 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 les opérations de sécurité et de plateforme.

Quelle est votre vision à long terme pour la gestion des vulnérabilités d’ici la fin de la 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 travail en tant que spécialistes de la sécurité consistera à faire évoluer cette automatisation, à travailler avec les équipes de plateforme pour sécuriser leurs environnements informatiques 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ûrs et prévisibles.

Pour les petites équipes de sécurité avec des ressources limitées, quels sont les premiers pas pratiques qu’elles peuvent 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 première étape la plus simple qui diminue déjà considérablement l’exposition aux analyses automatisées que les attaquants utilisent.

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