Leaks & Secrets
Vos secrets exposés, repérés avant qu'un attaquant s'en serve.
Une clé API laissée dans un dépôt Git public, un bucket S3 ouvert, un fichier .env accessible en clair : ce sont des portes déjà ouvertes. On part de votre domaine racine, on remonte les dépôts, buckets et fichiers exposés rattachés à votre surface, on repère les secrets qui ont fuité et on masque leur valeur avant de rien écrire. En continu, pas une fois par an.
- 1 domaine
- en entrée, les secrets exposés en sortie
- Git, cloud, .env
- dépôts, buckets et fichiers passés au crible
- 24/7
- surveillance continue, pas un scan ponctuel
Fonctionnalités
Tout ce qu'il faut pour sécuriser, sans le superflu.
Secrets exposés dans les dépôts Git
Clés API, tokens, identifiants de base de données et secrets d'infra laissés dans un dépôt public ou une fuite de code rattachée à votre domaine. Le moteur remonte ces dépôts exposés et signale les secrets qui traînent dans le code, l'historique de commits et les fichiers de config versionnés par erreur.
Buckets cloud ouverts (S3, Azure, GCP)
Buckets S3 publics, Azure Blob Storage, GCP Storage ouverts à tout venant. Des modules dédiés vérifient les ACL de stockage et repèrent les endpoints vulnérables au SSRF, qui peuvent servir à atteindre les métadonnées cloud. Un bucket joignable depuis Internet et rattaché à votre domaine remonte dans l'inventaire, avec ce qu'il laisse fuiter.
Fichiers .env, configs et artefacts accessibles
Un .env servi en clair par un serveur mal configuré, un backup oublié, un fichier de config exposé, un artefact de build public : autant de sources de secrets à portée de requête. Chaque actif découvert est testé pour ces fichiers sensibles laissés accessibles sans authentification.
Endpoints qui divulguent des secrets
Certaines pages d'erreur, réponses d'API verbeuses ou en-têtes trop bavards recrachent des tokens, des chemins internes ou des identifiants. Le scan repère ces endpoints qui divulguent plus qu'ils ne devraient, là où un attaquant irait chercher un point d'appui gratuit.
Secrets masqués avant écriture en base
Un secret trouvé n'est jamais stocké en clair. Sa valeur est masquée avant d'être écrite en base : vous savez qu'une clé a fuité, où, et de quel type, sans que la plateforme conserve le secret exploitable. C'est le comportement par défaut, pas une option à activer.
Surveillance continue et alerte
La surface est recartographiée en continu, à la demande ou planifiée. Le jour où un nouveau secret apparaît, ou qu'un bucket bascule en public, l'alerte tombe le même jour vers Slack, Teams, Jira, GitHub, GitLab, PagerDuty ou un webhook signé HMAC. Vous le savez avant que quelqu'un d'autre s'en serve.
Comment ça marche
Du setup à la première alerte.
- 01
Vous saisissez un domaine
Un seul nom de domaine racine en entrée, par exemple acme.com. Pas d'agent à installer, pas d'accès cloud à connecter, pas de token à fournir. Le scan démarre dans la foulée et le périmètre reste sous votre contrôle : on remonte à partir de ce que vous déclarez, pas d'attribution hasardeuse sur des dépôts ou des buckets qui ne sont pas à vous.
- 02
On remonte dépôts, buckets et fichiers exposés
À partir de ce domaine, la découverte reconstruit votre surface (sous-domaines, IP, services, stockage cloud) puis chaque actif passe sous les contrôles d'exposition de secrets : dépôts Git publics rattachés, buckets S3/Azure/GCP et leurs ACL, fichiers .env et configs accessibles, endpoints trop bavards, endpoints vulnérables au SSRF cloud. Ce qui laisse filer un secret remonte dans l'inventaire.
- 03
Tri par risque, puis validation IA sur les cas critiques
Les findings sont classés par risque réel, pas jetés en vrac : un secret cloud actif ne pèse pas comme un token de test expiré. Sur les findings High et Critical d'un domaine vérifié, vous pouvez déclencher la validation IA-native : un agent autonome tente de confirmer l'exploitabilité, son outillage tournant dans une sandbox éphémère à sortie réseau filtrée, et garde une preuve avec les secrets masqués. C'est de l'IA, pas un pentester, et c'est quotaé (30 validations par mois en Pro). On baisse le bruit, on ne promet pas le zéro faux positif.
- 04
Surveillance continue, alerte au premier secret exposé
Les secrets ne fuient pas qu'une fois : un nouveau commit, une nouvelle migration cloud, un serveur reconfiguré, et une valeur repart dans la nature. Les scans tournent en continu et à la demande, la détection de changement signale tout nouveau secret ou bucket bascule en public, et l'alerte tombe le même jour dans Slack, Teams, Jira, GitHub, PagerDuty ou un webhook signé. Vous le savez avant l'attaquant.
Bénéfices
L'impact concret pour vos équipes.
Trouvez ce qui a fuité avant l'attaquant
Un secret exposé ne prévient pas. La clé laissée dans un commit, le bucket ouvert lors d'une migration, le .env servi par un serveur mal configuré : ils dorment sur votre surface jusqu'à ce que quelqu'un les ramasse. On part d'un seul domaine racine et on remonte les dépôts, buckets, fichiers et endpoints exposés rattachés à votre périmètre, exactement là où un attaquant fouille en premier. Chaque nouveau scan compare l'état à la fois précédente : un secret apparu, un bucket devenu public, un fichier de config nouvellement accessible remonte tout seul.
Un secret exposé, c'est une clé qui ouvre le reste
Une clé API donne accès à un service, un token ouvre une session, un identifiant de base débloque des données. Un seul secret qui fuite peut suffire à pivoter dans votre infra. C'est pour ça que ces findings sont pris au sérieux dans la priorisation : un secret cloud actif remonte devant un CVSS théorique planqué derrière un WAF. Le graphe relie l'actif où fuite le secret au reste de votre surface, pour voir ce qui tombe derrière si quelqu'un l'utilise.
La fuite traitée sans jamais recopier le secret en clair
Détecter un secret pose un problème évident : ne pas le repiéger en le stockant à son tour. La valeur du secret est masquée avant écriture en base ; la plateforme garde le fait, le type et l'emplacement, pas le secret exploitable. Vous avez de quoi agir (révoquer, faire tourner la clé, fermer le bucket) et de quoi le remettre à un auditeur, sans qu'un dump de la base ne rejoue la fuite. Données hébergées dans l'UE, sous droit européen, conçu par un pentester certifié OSWE.
Aperçu
La plateforme en images.
Pourquoi own2pwn
Ce qu'on fait différemment.
Le secret n'est jamais stocké en clair
La plupart des scanners recopient joyeusement le secret trouvé dans leur base : une fois détecté, il fuite une deuxième fois. Ici, la valeur est masquée avant écriture. Vous savez qu'une clé a fuité, de quel type et où, sans que la plateforme conserve le secret exploitable. Un dump de la base ne rejoue pas la fuite.
Hébergé dans l'Union européenne
Vos secrets exposés, même masqués, et la carte de vos fuites restent sous droit européen : hébergement dans l'UE, conforme RGPD, isolation stricte par client au niveau base de données. Confier l'inventaire de vos fuites à un éditeur américain, c'est l'exposer à des demandes d'accès extraterritoriales ; le vôtre reste hébergé dans l'UE.
Conçu par un pentester certifié OSWE
La logique suit ce qu'un attaquant cherche en premier : le dépôt public, le bucket ouvert, le .env oublié, l'endpoint bavard. La priorisation reflète l'exploitabilité réelle d'un secret, pas un score générique. C'est une méthode offensive mise en SaaS, pas une checklist de conformité recopiée d'un framework.
En continu, pas un scan Git ponctuel
Un audit de secrets une fois par trimestre laisse une fenêtre grande ouverte : la clé qui fuite le lendemain reste exploitable des mois. La détection tourne en continu et au premier changement, elle repère le secret dès qu'il apparaît. Le scan de découverte reste non-intrusif, pensé pour tourner sur de la prod sans coordonner une fenêtre de maintenance.
Des tarifs lisibles, sans surprise.
- 1 domaine surveillé, jusqu'à 25 actifs
- 10 scans / mois
- Découverte multi-source + plus de 240 modules de détection
- Corrélation CVE, priorisation KEV et EPSS
- 2 validations IA-native / mois
- Alertes email, 1 utilisateur
- Gratuit, sans limite de durée
- Jusqu'à 5 domaines, 250 actifs suivis
- 100 scans / mois
- 30 validations IA-native / mois
- Webhooks signés HMAC (Slack, Teams, Discord, PagerDuty)
- Intégrations Jira, GitHub, GitLab, Slack
- Exports PDF et CSV, API (5 clés), jusqu'à 5 utilisateurs
- Jusqu'à 15 domaines, 1 000 actifs suivis
- Scans illimités
- 100 validations IA-native / mois
- SSO, RBAC et gestion des rôles
- Connecteur SIEM, intégrations sur mesure
- Support prioritaire
- Domaines, scans, actifs et validations IA illimités
- SSO / SAML, provisioning SCIM
- Validation IA renforcée (raisonnement étendu)
- SLA, DPA conforme RGPD, accompagnement NIS2
- Support dédié
Questions fréquentes
Ce que vous voulez probablement savoir.
Pour aller plus loin
La découverte d'actifs, en pratique
Énumération de sous-domaines, ASN, ports et actifs cloud pour cartographier votre surface.
Lire →EASM : le guide complet
Définition, fonctionnement étape par étape, et différence avec un scanner ou un pentest.
Lire →EASM et conformité NIS2
Cartographier sa surface d'attaque externe pour répondre à l'article 21 NIS2.
Lire →Parlons de votre besoin.
Démo, devis ou question technique : réponse sous 48 h ouvrées.