Fronde à l'OWASP : les projets qui se rebiffent

Vers une sécession massive à l'OWASP ? Une lettre ouverte au directeur exécutif et au conseil d'administration en laisse planer le spectre. Parmi ses quatre-vingts signataires, des contributeurs de longue date, ainsi que des (co)fondateurs et/ou (co)leaders de projets phares.

Leur mot d'ordre : l'OWASP, né il y a plus de vingt ans, doit évoluer. Leur appel se résume en cinq points :

- Publier et maintenir un plan de mobilisation (projets priorisés, financement prévu...) à la manière de celui de l'OSSF

- Restructurer la gouvernance pour favoriser la participation d'entreprises, de gouvernements, de sponsors majeurs et de fournisseurs technologiques clés

- Accroître le financement (les signataires estiment que pour les seuls projets sur lesquels ils s'impliquent, il faudrait 5 à 10 M$ par an)

- Fournir à la communauté une infrastructure et des services améliorés

- Mettre en place de véritables actions de gestion de la communauté, dans une optique d'attractivité

« Nous ne voulons pas devenir des projets open core, mais nous voulons pouvoir créer des projets open source de qualité commerciale », résument les intéressés.

De Kubernetes au XSS : les projets « bonnes pratiques »

Parmi les signataires, il y a les têtes de pont de plusieurs projets de documentation.

Rick Mitchell pour Web Security Testing Guide

Cole Conford pour Code Review Guide et XSS Prevention CheatSheet

Carlos Holguera et Sven Scheier pour MASTG (Mobile Application Security Testing Guide)

Grant Ongers pour Cornucopia (« gamification » des problématiques de sécurité auprès des développeurs)

On retrouve Rick Mitchell comme représentant du projet VWAD (Vulnerable Web Applications Directory), aux côtés de Simon Bennetts. Pour le fameux « Top 10 » OWASP, c'est Brian Glas. Et pour sa déclinaison ciblant Kubernetes, Jimmy Mesta.

De l'AST au SBOM : les projets de spécifications

Certains signataires sont impliqués dans des projets de spécifications et/ou de standards.

Jeff Williams et Cesar Kohl pour ASVS (Application Security Verification Standard)

Steve Springett et Patrick Dwyer pour CycloneDX (SBOM)

Sebastien Deleersnyder et Bart De Win pour SAMM (Software Assurance Maturity Model ; analyse de posture de sécurité logicielle)

Les porteurs de MASTG pour le projet de spécification associées MASVS (Mobile Application Security Verification Standard)

Utilitaires, bibliothèques et frameworks

Le « catalogue OWASP » comprend aussi des bibliothèques logicielles. Plusieurs de leurs chefs de file sont signataires de la lettre ouverte.

Jeremy Long pour Java Encoder (encodage contextuel pour se défendre des attaques XSS)

István Albert-Tóth pour CSRFGuard (intégration de jetons de session ou de requête pour protéger les applications des attaques CSRF)

Kevin V. Wall pour ESAPI (Enterprise Security API, destiné à ajouter des contrôles de sécurité dans les web apps existantes)

On retrouve Simon Bennetts et Rick Mitchell dans le cadre du projet ZAP (Zed Attack Proxy ; scanner de web apps), aux côtés de Ricardo Pereira.
D'autres signataires gèrent et/ou sont à l'origine d'applications ou de frameworks.

À nouveau Steve Springett, ainsi que Niklas Düster, pour Dependency-Track (analyse SBOM continue)

À nouveau Jeremy Long, pour dependency-check (analyse de composition logicielle)

Paul McCann pour Security Shepherd (pentesting sur la base du Top 10)

Paul Schwarzenberger pour Domain Protect (usage de FaaS pour l'analyse continue des enregistrements DNS et la découverte de sous-domaines vulnérables)

Abraham Aranguren et Viyat Bhalodia pour OWTF (Offensive Web Testing Framework)

Daniel Negaru pour Raider (test des processus HTTP)

Björn Kimminich, Jeroen Willemsen et Karan Peet Singh Sasan. Respectivement pour Juice Shop, WrongSecrets et VulnerableApp. Trois « applications d'entraînement » volontairement truffées de vulnérabilités.

À consulter pour davantage de contexte :

Top 10 OWASP : quelles vulnérabilités surveiller sur les web apps ?
Open source : les leviers pour un modèle durable
Dix pistes d'action pour sécuriser l'open source
Open hardware : l'open source à l'assaut des processeurs
Open source : esclave, liste noire... Quand la terminologie pose question

Illustration principale © monsitj - Adobe Stock