Leaks & Secrets
Your exposed secrets, caught before an attacker uses them.
An API key left in a public Git repo, an open S3 bucket, a .env file served in clear: those are doors already open. We start from your root domain, pull up the repos, buckets and files exposed across your surface, flag the secrets that leaked and mask their value before writing anything. Continuously, not once a year.
- 1 domain
- in, the exposed secrets out
- Git, cloud, .env
- repos, buckets and files put through the checks
- 24/7
- continuous monitoring, not a one-off scan
Fonctionnalités
Tout ce qu'il faut pour sécuriser, sans le superflu.
Secrets exposed in Git repositories
API keys, tokens, database credentials and infra secrets left in a public repo or a code leak tied to your domain. The engine surfaces those exposed repos and flags the secrets sitting in the code, the commit history and config files versioned by mistake.
Open cloud buckets (S3, Azure, GCP)
Public S3 buckets, Azure Blob Storage, GCP Storage open to anyone. Dedicated modules check storage ACLs and flag endpoints vulnerable to SSRF, which can be used to reach cloud metadata. A bucket reachable from the Internet and tied to your domain surfaces in the inventory, along with what it lets leak.
Accessible .env files, configs and artifacts
A .env served in clear by a misconfigured server, a forgotten backup, an exposed config file, a public build artifact: each is a source of secrets a request away. Every discovered asset is tested for these sensitive files left accessible without authentication.
Endpoints that leak secrets
Some error pages, verbose API responses or overly talkative headers spit out tokens, internal paths or credentials. The scan flags these endpoints that disclose more than they should, exactly where an attacker looks for a free foothold.
Secrets masked before they are written
A found secret is never stored in clear. Its value is masked before it is written to the database: you know a key leaked, where, and of what type, without the platform keeping the exploitable secret. That is the default behaviour, not an option to enable.
Continuous monitoring and alerts
The surface is remapped continuously, on demand or scheduled. The day a new secret appears, or a bucket flips to public, the alert lands the same day in Slack, Teams, Jira, GitHub, GitLab, PagerDuty or an HMAC-signed webhook. You know before anyone else uses it.
Comment ça marche
Du setup à la première alerte.
- 01
You enter a domain
A single root domain name in, for example acme.com. No agent to install, no cloud access to connect, no token to provide. The scan starts right away and the scope stays under your control: we follow the chain from what you declare, no reckless attribution of repos or buckets that aren't yours.
- 02
We pull up exposed repos, buckets and files
From that domain, discovery rebuilds your surface (subdomains, IPs, services, cloud storage), then every asset runs through the secret-exposure checks: tied public Git repos, S3/Azure/GCP buckets and their ACLs, accessible .env files and configs, overly talkative endpoints, endpoints vulnerable to cloud SSRF. Anything that leaks a secret surfaces in the inventory.
- 03
Risk triage, then AI validation on critical cases
Findings are ranked by real risk, not dumped in a pile: an active cloud secret doesn't weigh like an expired test token. On High and Critical findings from a verified domain, you can trigger AI-native validation: an autonomous agent tries to confirm exploitability, its tooling running inside an ephemeral sandbox with filtered network egress, and keeps a proof with secrets masked. It is AI, not a pentester, and it is quota-limited (30 validations a month on Pro). We lower the noise, we don't promise zero false positives.
- 04
Continuous monitoring, an alert on the first exposed secret
Secrets don't leak just once: a new commit, a new cloud migration, a reconfigured server, and a value goes back into the wild. Scans run continuously and on demand, change detection flags every new secret or bucket flipped to public, and the alert lands the same day in Slack, Teams, Jira, GitHub, PagerDuty or a signed webhook. You know before the attacker does.
Bénéfices
L'impact concret pour vos équipes.
Find what leaked before the attacker does
An exposed secret gives no warning. The key left in a commit, the bucket opened during a migration, the .env served by a misconfigured server: they sit on your surface until someone picks them up. We start from a single root domain and pull up the exposed repos, buckets, files and endpoints tied to your perimeter, exactly where an attacker looks first. Every new scan compares the state to the previous one: a secret that appeared, a bucket gone public, a config file newly accessible surfaces on its own.
One exposed secret is a key that opens the rest
An API key unlocks a service, a token opens a session, a database credential frees up data. A single leaked secret can be enough to pivot into your infra. That is why these findings are taken seriously in prioritisation: an active cloud secret ranks ahead of a theoretical CVSS hidden behind a WAF. The graph links the asset where the secret leaks to the rest of your surface, to see what falls behind if someone uses it.
The leak handled without ever copying the secret in clear
Detecting a secret raises an obvious problem: not re-trapping it by storing it in turn. The secret's value is masked before it is written to the database; the platform keeps the fact, the type and the location, not the exploitable secret. You have enough to act (revoke, rotate the key, close the bucket) and enough to hand to an auditor, without a database dump replaying the leak. Data hosted in the EU, under European law, designed by an OSWE-certified pentester.
Aperçu
La plateforme en images.
Pourquoi own2pwn
Ce qu'on fait différemment.
The secret is never stored in clear
Most scanners happily copy the found secret into their own store: once detected, it leaks a second time. Here, the value is masked before it is written. You know a key leaked, of what type and where, without the platform keeping the exploitable secret. A database dump does not replay the leak.
Hosted in the European Union
Your exposed secrets, even masked, and the map of your leaks stay under European law: hosted in the EU, GDPR compliant, with strict per-customer isolation at the database level. Handing the inventory of your leaks to a US vendor exposes it to extraterritorial access requests; yours stays hosted in the EU.
Designed by an OSWE-certified pentester
The logic follows what an attacker looks for first: the public repo, the open bucket, the forgotten .env, the talkative endpoint. Prioritisation reflects a secret's real exploitability, not a generic score. It is an offensive method turned into SaaS, not a compliance checklist copied from a framework.
Continuous, not a one-off Git scan
A secrets audit once a quarter leaves a wide-open window: the key that leaks the next day stays exploitable for months. Detection runs continuously and on the first change, flagging the secret as soon as it appears. The discovery scan stays non-intrusive, built to run on production without coordinating a maintenance window.
Des tarifs lisibles, sans surprise.
- 1 monitored domain, up to 25 assets
- 10 scans / mo
- Multi-source discovery + more than 240 detection modules
- CVE correlation, KEV and EPSS prioritisation
- 2 AI-native validations / mo
- Email alerts, 1 user
- Free, no time limit
- Up to 5 domains, 250 tracked assets
- 100 scans / mo
- 30 AI-native validations / mo
- HMAC-signed webhooks (Slack, Teams, Discord, PagerDuty)
- Jira, GitHub, GitLab, Slack integrations
- PDF and CSV exports, API access (5 keys), up to 5 users
- Up to 15 domains, 1,000 tracked assets
- Unlimited scans
- 100 AI-native validations / mo
- SSO, RBAC and role management
- SIEM connector, custom integrations
- Priority support
- Unlimited domains, scans, assets and AI validations
- SSO / SAML, SCIM provisioning
- Enhanced AI validation (extended reasoning)
- SLA, GDPR-compliant DPA, NIS2 guidance
- Dedicated support
Questions fréquentes
Ce que vous voulez probablement savoir.
Parlons de votre besoin.
Démo, devis ou question technique : réponse sous 48 h ouvrées.