Jeff Williams, fondateur d’OWASP et fondateur et CTO de Contrast Security – Série d’entretiens

Jeff Williams, fondateur d’OWASP et fondateur et CTO de Contrast Security, est considéré comme l’une des figures les plus influentes de la sécurité des applications modernes. Au cours des dernières décennies, il a contribué à façonner la manière dont les organisations abordent le développement de logiciels sécurisés, la gestion des vulnérabilités et la protection des applications à l’exécution. Williams a joué un rôle central dans la construction d’OWASP à partir d’une petite initiative de bénévoles en une fondation de sécurité à but non lucratif reconnue mondialement, en contribuant à des projets emblématiques tels que le Top 10 d’OWASP, WebGoat, ESAPI, ASVS et la feuille de triche de prévention XSS. Avant de fonder Contrast Security en 2014, il a également fondé Aspect Security, l’une des premières sociétés dédiées exclusivement à la consultation en sécurité des applications, à la formation, aux tests de pénétration et aux pratiques de développement sécurisé pour les entreprises.

OWASP est une fondation à but non lucratif axée sur l’amélioration de la sécurité des logiciels grâce à des projets open source, à la collaboration communautaire mondiale, à l’éducation et aux normes industrielles. Fondée en 2001, l’organisation est devenue l’une des autorités les plus importantes en matière de sécurité des applications, avec des centaines de chapitres locaux, des milliers de contributeurs et des ressources largement adoptées utilisées par les développeurs, les professionnels de la sécurité, les entreprises et les gouvernements du monde entier. OWASP est surtout connue pour des projets tels que le Top 10 d’OWASP, qui identifie les risques de sécurité les plus critiques pour les applications Web, ainsi que de nombreux cadres de sécurité, outils de test, projets de documentation et initiatives de formation. L’organisation fonctionne avec une philosophie de neutralité des fournisseurs, ce qui rend ses ressources éducatives et ses conseils de sécurité librement accessibles à la communauté technologique mondiale.

Contrast Security est une société de sécurité des applications axée sur la protection des logiciels à partir de l’exécution de l’application elle-même, plutôt que de s’appuyer uniquement sur des outils de scan externes. La plate-forme de l’entreprise utilise la technologie d’instrumentation à l’exécution pour fournir une visibilité en temps réel sur les vulnérabilités, les attaques, les API, les dépendances open source et le comportement des applications dans les environnements de développement et de production. Ses offres couvrent des domaines tels que les tests de sécurité d’application interactifs (IAST), la détection et la réponse d’application (ADR), la protection d’application autonome à l’exécution (RASP) et l’analyse de composition de logiciels. Contrast Security s’est positionnée autour de l’intégration de la sécurité directement dans les flux de travail DevSecOps modernes, permettant aux développeurs, aux équipes de sécurité des applications et aux équipes de sécurité d’identifier et de remédier aux vulnérabilités plus rapidement tout en maintenant des cycles de livraison de logiciels rapides.

Après avoir contribué à façonner la sécurité des applications modernes grâce à votre travail avec le projet Open Web Application Security (OWASP), quel écart dans l’industrie vous a conduit à fonder Contrast Security, et comment cette thèse originale a-t-elle résisté à l’évolution des défis de sécurité ?

L’industrie se noyait dans des résultats de scan théoriques et était incapable de se concentrer sur les problèmes qui comptent vraiment. Les équipes de sécurité avaient des outils de scan générant d’énormes retards sans savoir lesquelles des vulnérabilités étaient accessibles, exploitables ou sous attaque en production. Nous avons fondé Contrast sur une idée simple : les décisions de sécurité devraient provenir de l’observation directe d’applications en cours d’exécution, et non de suppositions à partir de l’extérieur.

En fin de compte, j’espère que l’industrie évoluera jusqu’au point où nous cesserons de tourner en rond pour trouver des problèmes, les corriger et en trouver davantage pour toujours. J’espère que nous pourrons commencer à créer des logiciels dotés d’une architecture de sécurité solide et d’un argument solide selon lequel ils disposent des défenses appropriées pour les menaces attendues. La combinaison de la sécurité à l’exécution et de l’IA a le potentiel, mais nous sommes encore loin.

Vous avez décrit l’émergence de « vulnérabilités de type Mythos ». Qu’est-ce qui définit cette nouvelle classe de risque, et pourquoi sont-elles si difficiles à détecter pour les outils de sécurité conventionnels ?

Les vulnérabilités de type Mythos sont des failles qui émergent de la complexité des piles logicielles modernes. L’interaction entre le comportement des frameworks, les dépendances et les modèles d’architecture est si complexe que les développeurs ne la comprennent souvent pas pleinement. Les outils conventionnels sont toujours optimisés pour des modèles relativement simples et des événements observables. Les vulnérabilités de type Mythos nécessitent souvent une compréhension du comportement de l’application, du flux d’exécution et du contexte d’exécution à un niveau beaucoup plus profond.

Pourquoi des catégories entières de vulnérabilités ne génèrent-elles pas d’alertes dans les environnements de sécurité des opérations (SOC) modernes, et que cela révèle-t-il sur la manière dont les équipes de sécurité mesurent actuellement les risques ?

La plupart des SOC sont construits autour d’événements observables : journaux, signatures, trafic réseau, activité de point de terminaison. Mais de nombreuses attaques d’application ne produisent pas de signaux significatifs dans ces systèmes. Le développeur n’a pas su qu’il y avait une vulnérabilité et n’a pas ajouté de journalisation qui révélerait une exploitation. La plupart des exploits d’applications sont donc complètement invisibles dans les journaux. Les équipes SOC ne peuvent répondre qu’à ce qu’elles peuvent voir. Il est donc crucial de s’assurer que nous instrumentons l’application avec des capteurs de sécurité qui peuvent détecter et signaler un comportement anormal.

Les architectures d’applications modernes telles que les microservices, les API et les systèmes sans serveur ont évolué rapidement. Où ces architectures dépassent-elles les approches de sécurité basées sur la détection actuelles ?

Ces architectures ont brisé l’ancien modèle de périmètre. Les requêtes traversent désormais des dizaines de services, des fonctions éphémères, des API, des files d’attente et des dépendances tierces avant de compléter une transaction. La plupart des systèmes de détection ne voient que des fragments et non le chemin d’exécution complet. Ils peuvent inspecter les paquets ou les journaux, mais ils ne peuvent pas comprendre l’intention, le flux de données ou si du code dangereux a réellement été exécuté. La sécurité est une question de contexte, nous devons donc construire un modèle, un jumeau numérique, de notre infrastructure d’application qui nous permet (ou aux agents IA) de raisonner sur ce que nous voyons se passer.

Le Top 10 d’OWASP continue de mettre en évidence des problèmes tels que la conception non sécurisée et les composants vulnérables. Pourquoi ces risques persistent-ils malgré une prise de conscience et des outils largement répandus ?

La prise de conscience ne résout pas les problèmes d’incitation ou de complexité. La plupart des organisations mesurent encore le succès par le volume de scan, la fermeture de tickets ou les listes de contrôle de conformité plutôt que par la réduction réelle de l’exposition.

En même temps, les chaînes d’approvisionnement logicielles ont explosé en taille. Les développeurs assemblent des applications à partir de milliers de composants qu’ils n’ont pas écrits et qu’ils n’ont certainement pas évalués pour la sécurité. Les équipes de sécurité sont submergées en essayant de trier les risques théoriques et ne peuvent pas se concentrer sur les 1 à 2 % qui comptent vraiment. Sans preuve d’exécution, la priorisation se brise. Et avec l’émergence de modèles d’IA puissants et de harnais, le volume augmente de manière exponentielle.

Comment les organisations devraient-elles repenser leur dépendance à l’égard des journaux et des alertes lorsque certaines des vulnérabilités les plus critiques ne laissent pas de signaux observables ?

Les journaux sont la preuve de ce que les applications choisissent de signaler, et non nécessairement la preuve de ce qui s’est réellement passé. C’est une distinction dangereuse. Les organisations doivent passer d’une observation indirecte à une observation directe. Au lieu d’espérer qu’une exploitation crée un artefact détectable, les systèmes de sécurité devraient identifier le comportement vulnérable et le comportement d’exploitation à l’exécution. Si du code dangereux est exécuté, le système devrait le savoir immédiatement — que les entrées de journal existent ou non.

Vous avez plaidé en faveur de la visibilité à l’exécution comme solution. Qu’est-ce que la véritable visibilité à l’exécution ressemble-t-elle dans la pratique, et comment change-t-elle la façon dont les équipes de sécurité opèrent au quotidien ?

La véritable visibilité à l’exécution signifie comprendre ce que l’application fait réellement en production : quels itinéraires sont exposés, quels bibliothèques sont actives, où les flux de données sensibles, quel code est exécuté et si une attaque a atteint une fonctionnalité vulnérable. Sur le plan opérationnel, cela change la sécurité d’un exercice de chasse réactive en une discipline de précision. Les équipes arrêtent de poursuivre de vastes retards de vulnérabilités et commencent à se concentrer sur le petit pourcentage d’expositions qui sont accessibles, critiques et activement ciblées. Cela améliore considérablement le rapport signal/bruit et la rapidité de réponse. En moyenne, seulement 38 % des bibliothèques open source empaquetées dans une application sont réellement chargées en mémoire et exécutées. Et tout le code de ce sous-ensemble n’est pas utilisé. La sécurité à l’exécution permet donc de se concentrer sur le code qui s’exécute réellement, et non sur toutes les bibliothèques et fonctions inutilisées qui accompagnent une application.

Comment la sécurité basée sur l’instrumentation se compare-t-elle aux approches traditionnelles telles que SAST, DAST ou la surveillance du périmètre en termes d’efficacité et d’évolutivité ?

Les outils traditionnels déduisent le risque de l’extérieur. L’instrumentation observe la réalité en observant le code réel lorsqu’il s’exécute. L’instrumentation peut voir les chemins d’exécution réels, le comportement des frameworks, le contexte d’authentification, le flux de données et le succès de l’exploitation en temps réel. Cela élimine d’énormes catégories de faux positifs et expose des vulnérabilités que les outils de périmètre complètement manquent.
À l’échelle, cette précision devient critique. Les organisations ne peuvent plus trier manuellement des millions de résultats théoriques. Les preuves d’exécution deviennent le seul filtre durable. L’exécution fonctionne en temps réel, elle constitue donc une meilleure correspondance pour les pipelines de développement et de CI/CD que le scan et le tri. Et l’exécution est continue, vous n’êtes donc pas limité à une vue instantanée de la sécurité.

À mesure que les systèmes d’IA et les applications autonomes deviennent plus prépondérants, ces vulnérabilités invisibles deviennent-elles plus dangereuses, et comment les équipes devraient-elles se préparer ?

Les systèmes d’IA rendent les vulnérabilités invisibles encore plus dangereuses car ils accélèrent les deux côtés du problème. Les développeurs génèrent des logiciels plus rapidement, et les attaquants trouvent et exploitent les faiblesses plus rapidement. Mais la plupart des programmes de sécurité s’appuient encore sur des processus humains qui ne peuvent pas fonctionner à la vitesse de l’IA. Les équipes devraient se préparer de deux manières. Premièrement, construire des défenses plus solides à l’exécution qui peuvent détecter, bloquer et contenir les attaques en production pendant que les vulnérabilités sont corrigées. Cela donne aux organisations une couverture aérienne. Deuxièmement, utiliser l’IA et l’automatisation pour écrire du code plus sécurisé dès le départ — avec une meilleure conception, des tests, des examens et une vérification. Sinon, nous créons simplement des risques plus rapidement que nous ne pouvons les gérer.

Si vous conseilliez un chef de la sécurité des opérations (SOC) moderne aujourd’hui, quels seraient les premiers pas concrets qu’il devrait prendre pour combler ce fossé de visibilité avant qu’il ne conduise à une faille majeure ?

Tout d’abord, accepter que la télémétrie de périmètre seule est insuffisante pour la sécurité des applications modernes. En fait, il est impossible de voir ou d’arrêter de nombreuses attaques d’application et d’API au périmètre. Le SOC a besoin de visibilité à l’intérieur des applications en cours d’exécution, et non seulement de l’infrastructure qui les héberge. Deuxièmement, donner la priorité aux preuves d’exécution plutôt qu’aux résultats théoriques. Se concentrer sur les vulnérabilités qui se trouvent dans le code actif, identifier les chemins d’attaque actifs et les services exposés qui sont réellement exécutés en production. Enfin, unifier la sécurité des applications et l’ingénierie de détection. Le SOC futur ne peut plus traiter les applications comme des boîtes noires opaques. Les applications sont maintenant la surface d’attaque principale, et elles ont besoin d’une visibilité de premier plan à l’exécution.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter OWASP ou Contrast Security.