Aller au contenu principal
own2pwn
Retour à la plateforme EASM

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.

Comment ça marche

Du setup à la première alerte.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

01

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.

02

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.

03

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.

Findings filtrés sur la catégorie Leaks & secrets : secrets exposés détectés, dont un secret exposé sur GitHub
Findings filtrés sur la catégorie Leaks & secrets : secrets exposés détectés, dont un secret exposé sur GitHubLes findings filtrés sur les fuites de secrets, par exemple une clé retrouvée exposée sur GitHub. La clé cloud encore active passe avant le token de test expiré.
Liste des findings triés par gravité avec la répartition Critical, High, Medium, Low et Info
Liste des findings triés par gravité avec la répartition Critical, High, Medium, Low et InfoTous les findings triés par gravité, avec la répartition Critical à Info. On attaque par le haut.
Détail d'un finding avec son contexte et sa preuve
Détail d'un finding avec son contexte et sa preuveLe détail d'un finding : contexte et preuve à l'appui. De quoi comprendre sans rejouer le scan.

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.

Découverte
0 €
  • 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
Commencer gratuitement
Recommandé
Pro
99 € / mois
  • 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
  • TVA non applicable, art. 293 B du CGI
S'abonner
Business
299 € / mois
  • 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 par email, traitement prioritaire
  • TVA non applicable, art. 293 B du CGI
S'abonner
Enterprise
Sur devis
  • Domaines, scans, actifs et validations IA illimités
  • SSO / SAML, provisioning SCIM
  • Validation IA renforcée (raisonnement étendu)
  • DPA conforme RGPD, contrat-cadre et accompagnement NIS2
  • Interlocuteur unique : le pentester qui opère
Parler à un pentester

Questions fréquentes

Ce que vous voulez probablement savoir.

Quels types de secrets vous détectez ?

Clés API, tokens d'authentification, identifiants de base de données, secrets d'infrastructure et clés de service laissés dans un dépôt Git public, un bucket cloud ouvert, un fichier .env ou une config accessible, ou recrachés par un endpoint trop bavard. En clair : tout ce qui ressemble à un identifiant exploitable et qui traîne sur un actif rattaché à votre domaine. La détection est automatisée et suit ce qu'un attaquant fouille en premier ; elle ne remplace pas la vérification humaine d'un pentest, qui est une offre séparée.

Comment vous trouvez un dépôt Git exposé rattaché à mon domaine ?

On part de votre domaine racine et on remonte votre surface (sous-domaines, IP, services, stockage cloud) sans que vous ayez à fournir d'accès. Les dépôts publics et fuites de code rattachés à votre périmètre sont ensuite passés au crible pour les secrets qui traînent dans le code, l'historique de commits et les fichiers versionnés par erreur. Le périmètre reste sous votre contrôle : on déroule à partir des domaines que vous déclarez, pas d'attribution hasardeuse sur des dépôts qui ne sont pas à vous.

Vous détectez les buckets cloud ouverts (S3, Azure, GCP) ?

Oui. Buckets S3 publics, Azure Blob Storage, GCP Storage ouverts, instances de stockage exposées. 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. Si un bucket est joignable depuis Internet et rattaché à votre domaine, il remonte dans l'inventaire avec ce qu'il laisse fuiter : fichiers publics, secrets, configs.

Le secret trouvé est-il stocké en clair chez vous ?

Non. La valeur du secret est masquée avant d'être écrite en base, par défaut. La plateforme conserve le fait qu'une clé a fuité, son type et son emplacement, pas le secret exploitable lui-même. 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 notre base ne rejoue la fuite. Détecter un secret sans le repiéger en le recopiant, c'est le comportement de base, pas une option.

C'est différent d'un secret scanner type gitleaks ou trufflehog ?

Ces outils scannent un dépôt que vous leur pointez, souvent le vôtre, en interne. Ils ne voient que ce que vous leur donnez. Ici, on répond à la question d'avant : qu'est-ce qui a fuité sur votre surface externe, là où vous ne regardez pas ? On part d'un seul domaine, on découvre les dépôts publics, buckets et fichiers exposés que personne n'a inventoriés, et on surveille en continu ce qui apparaît. Les deux sont complémentaires : le scanner interne approfondit le dépôt connu, l'EASM trouve la fuite exposée que vous ignoriez.

La validation IA confirme quoi sur un secret exposé, et ses limites ?

Sur un finding High ou Critical d'un domaine vérifié, vous pouvez demander à un agent IA autonome de tenter de confirmer que le secret est réellement exploitable, dans la limite de garde-fous stricts (20 étapes, 300 secondes, 150 000 tokens par finding) et d'une sandbox éphémère à sortie réseau filtrée. S'il le prouve, le finding passe en confirmé avec une preuve conservée, secrets masqués. C'est de l'IA, pas un pentester humain, et c'est quotaé : 2 validations par mois en Découverte, 30 en Pro, 100 en Business, illimité en Enterprise. On ne promet pas le zéro faux positif ; la vérification humaine approfondie, c'est nos pentests, une offre séparée.

À quelle fréquence ma surface est-elle re-scannée pour les fuites ?

Vous programmez des scans périodiques (cron) et vous en déclenchez à la demande depuis l'interface ou l'API. À chaque passage, vous recevez le delta : nouveau secret apparu, bucket bascule en public, fichier de config nouvellement accessible, finding résolu. Les volumes dépendent du plan : 10 scans par mois en Découverte, 100 en Pro, illimité en Business et Enterprise. Vous suivez votre consommation en temps réel.

En quoi la détection de fuites aide ma conformité NIS2 ?

L'article 21 de NIS2 impose une gestion des risques qui inclut la cartographie des actifs et la surveillance continue de la surface exposée, secrets et shadow IT compris. La détection de fuites y contribue directement : inventaire vivant des secrets et actifs qui fuitent, alerte au premier changement, rapports PDF et CSV exportables pour vos auditeurs. Soyons clairs : elle ne couvre pas tout NIS2 à elle seule (gouvernance, réponse à incident, chaîne d'approvisionnement restent à votre charge). Elle adresse la partie connaître et maîtriser ce que vous exposez.

Parlons de votre besoin.

Démo, devis ou question technique : réponse sous 48 h ouvrées.