Data Leaks Overview

The landing page for the Data Leaks (internally "Data Exposure") module. It rolls up every place ShadowMap found your data sitting where it should not be — public code repositories, leaked documents, container registries, exposed APIs, open S3 buckets, and shortened URLs — into one set of counts, a per-module bar chart, a severity grid, and a live feed of the most recent finds.

Overview

The page is built for a quick triage read: glance at the metrics strip to see where your exposure is concentrated, use the bar chart to spot the dominant module, read the Severity Breakdown to find the modules carrying Critical/High findings, and use the feed sidebar to see what came in most recently. Every number, bar, and badge is a link into the underlying module list, so the overview is meant to be a jumping-off point rather than a place you work.

The header carries a single control: a time-range selector (top right) with presets Last 7 days, Last 30 days, Last 90 days, and All time. It defaults to Last 30 days, and your choice is remembered in the browser per module (it persists across page loads). Changing the range reloads every card and resets the feed.

The page is gated by the Data Leaks Overview read permission. If you cannot see it, ask an admin to grant that permission to your role (see Roles & Permissions).

How it works

The mechanics below are not visible in the UI but determine what every number means.

What counts as a "leak"

The overview aggregates six independent sources, each with its own scanner, parser, and detail page. They are not the same kind of finding — a code repository hit is very different from an open S3 bucket — but the overview treats each as one row of "exposure" for counting purposes:

Module	What it finds
Code Repositories	Public GitHub/GitLab/Bitbucket repos containing your code, secrets, or internal references
Leaked Files	Documents exposed on file-sharing and sandbox services (e.g. Scribd, malware sandboxes) that reference your org
Leaked APIs	API endpoints exposed in public sources, grouped by the subdomain they belong to
Docker Containers	Public container registry images that reference or belong to your org, scanned layer-by-layer for secrets
S3 Buckets	Publicly readable cloud storage buckets attributable to your org
URL Shorteners	Shortened links (bit.ly and similar) that resolve to your assets or expose internal/credential-bearing URLs

The Total Leaks metric is simply the sum of the six module counts for the selected time range — it is a convenience roll-up, not a deduplicated count of unique incidents. A single underlying exposure (for example, a credential found both in a repo and a container) is counted once per module it appears in.

The time range filters by discovery date, not severity

The range selector maps to a "first seen" / discovery cut-off on the backend. "Last 30 days" means findings discovered in the last 30 days, and "All time" removes the cut-off entirely (it resolves to an unbounded window, so it shows your complete historical exposure). This is why switching to a shorter range can drop the counts to zero on a tenant whose exposure is older — the data is still there, it was just discovered before the window. Use All time to see your full standing exposure and the shorter windows to see what is new.

Counts on this page can differ from the module list pages by design

Two of the cards apply a stricter scope than a naive "count everything" query, so the overview reconciles with the visible state of each module rather than its raw row count:

• Code Repositories counts only the canonical visible scope (online and not dismissed), the same population the module's severity view uses. It deliberately does not count dismissed or offline repositories, so the overview total matches what you actually see when you open the module.
• The Severity Breakdown card is similarly scoped to the visible/online findings per module.

When you click a severity badge, the overview sends you to the module's All tab (for code repositories and Docker) or the module's default online tab (for APIs and shortened URLs), pre-filtered to the clicked risk band. Because "All" is a superset of the visible scope, the destination list may show a handful more rows than the badge counted (a few offline or dismissed items). This is intentional — it guarantees nothing the badge counted is missing from the list, at the cost of occasionally showing slightly more.

Severity drill-downs preserve each module's native risk format

Each module stores and filters its risk value differently — S3 Buckets use an integer band (0–5), Docker Containers and URL Shorteners use lowercase strings, Leaked APIs use Title-Case strings, and Code Repositories filter by a lowercase band label. The overview passes the clicked value through unchanged so the destination list filters correctly. You do not need to know any of this; just click the badge.

The feed is live, multi-source, and paginated per module

The Feeds sidebar interleaves the most recent finds across all six modules into one reverse-chronological stream (newest first), filling a page of 12 items by pulling from each source in turn. Each entry is a clickable link straight to that finding's detail view. Scrolling the feed loads more, tracking a separate offset per module so no source starves another. The feed is non-critical: if a feed request fails it fails silently and the rest of the page still loads.

Security Rating in the sidebar

The sidebar shows the Data Leaks sub-score of your overall ShadowMap Security Rating (a letter grade plus a number). A muted dash (—) means the score has not been computed for your tenant yet — it is not a failing grade. See Security Rating for how the score is calculated.

Understanding the data

Metrics strip

Six cards across the top:

Card	Meaning
Total Leaks	Sum of all six module counts, for the selected range
Code Repositories	Visible-scope repository count
Leaked Files	Leaked document count
API Exposures	Leaked API count
Docker Containers	Exposed container image count
S3 Buckets	Publicly readable bucket count

No trend arrows

These cards show counts only — there is no period-over-period up/down arrow. A real "since last period" delta is not yet computed on this page, and a fake arrow that implied growth on every populated card was deliberately removed. Use the time-range selector to compare windows manually.

Number of Leaks Across Modules (bar chart)

A bar per module, on a linear axis so bar heights are proportional to the actual counts — a module with 3,000 leaks towers over one with 3, which is the point. Each bar shows its value on top so small counts stay readable. Click any bar to jump to that module's list page. New tenants with no leaks see an empty-state card rather than a flat zero-height chart.

Severity Breakdown

A per-module grid of risk badges. Each badge is a coloured letter plus a count. The letter is the first character of the band name, and the colour encodes the band:

Band	Letter	Colour	Meaning
Critical	C	Red	Highest-impact exposure for that module
High	H	Orange	Serious exposure requiring prompt action
Medium	M	Amber	Moderate exposure
Low	L	Green	Low-impact finding
Informational	I	Green (same as Low)	Contextual / informational finding

Only modules that carry a risk value appear here — Code Repositories, Docker Containers, S3 Buckets, Leaked APIs, and URL Shorteners. Leaked Files are classified by threat level (below) rather than a risk band, so they are not in this grid. Click a badge to open that module filtered to the band. Hover or focus a badge to read the band name (it is also exposed to screen readers, so severity is never conveyed by colour alone).

Leaked File Types

A donut chart of the file types found in Leaked Files (file extensions/categories, grouped by their leading type), with a "Files" center label and a Threat Level summary underneath. Threat levels come from the file-analysis verdict:

Threat level	Display
Malicious / Suspicious	Red (danger)
Ambiguous	Amber (warning)
No verdict / No specific threat	Green (clean)
Other / unknown	Grey (neutral)

Hash-named "types" (raw hex blobs with no real extension) are collapsed into a single Unknown slice rather than cluttering the chart with one slice per hash.

Top Exposed Subdomains

A single merged table combining the two subdomain-attributable sources — Leaked APIs and URL Shorteners — into one ranked list (top 10 by count, highest first):

Column	Meaning
Sub-domain	The subdomain the exposures are attributed to
Source	API (cyan) or URL Shortener (purple) — which scanner found it
Count	Number of exposures attributed to that subdomain from that source

This answers "which of my subdomains is leaking the most?" at a glance, regardless of which of the two sources surfaced it.

Filtering & search

The overview has exactly one filter: the time-range selector in the header (7 / 30 / 90 days, or All time), which scopes every card and the feed simultaneously. There is no free-text search, no per-column filter, and no export on this page — it is a read-only summary. To search, filter by status, or export, open the individual module pages, each of which has its own full filter set.

The feed sidebar has its own source filter (the "All / Selected" dropdown) to show only feed entries from specific modules — Code Repositories, S3 Buckets, Docker Containers, Leaked Files, Leaked APIs, or URL Shorteners. This affects only the feed, not the cards.

Taking action

The overview is a navigation hub. There is nothing to triage, resolve, or close here — every action routes you to a module page where the real work happens:

1. Read the metrics strip and bar chart to find your dominant exposure module.
2. Click the bar (or a metric) to open that module's list.
3. Click a Severity Breakdown badge to open a module pre-filtered to a risk band — the fastest path to your Critical/High items.
4. Click a feed entry to open a specific finding's detail view.
5. From the module list, work each item: validate, mark its severity & status, and where appropriate raise a takedown.

Triage flow

Set the range to All time for a complete picture, then switch to Last 7/30 days to isolate what is new since your last review. The Severity Breakdown badges are the quickest route to the items that matter most.

Common questions

Why is my Total Leaks number higher than what I see inside a module? It usually is not — the overview deliberately uses the same visible scope as the modules (online, not dismissed) so they reconcile. If they still differ, check the time range: the overview and the module may be on different windows. Remember the total is a sum across six modules, so the same underlying exposure can contribute to more than one module's count.

I switched to "Last 7 days" and everything went to zero. Is the data gone? No. The range filters by discovery date. Your exposure was simply found more than 7 days ago. Switch to All time to see your full standing exposure.

Why do the severity badges and the destination list sometimes show slightly different counts? Severity badges are scoped to the visible/online population; clicking one lands you on the module's All (or default) tab, which is a superset that may include a few offline or dismissed rows. This is intentional so that nothing the badge counted is ever missing from the list.

Why are there no trend arrows on the metric cards? Period-over-period deltas are not yet wired into this page. Rather than show a misleading arrow, the cards display counts only. Compare windows manually with the time-range selector.

Why isn't Leaked Files in the Severity Breakdown? Leaked Files are classified by an analysis threat level (malicious / suspicious / ambiguous / clean), shown under the Leaked File Types donut, not by a Critical/High/Medium/Low risk band. The other five modules use risk bands and appear in the Severity grid.

The Security Rating shows a dash. Is that an F? No. A dash means the Data Leaks sub-score has not been computed for your tenant yet. An actual failing grade renders as a letter (e.g. F) with a number.

Why doesn't the time range reset when I come back later? By design — your selection is saved in the browser per module so you return to the same window you left.

Related

• Data Leaks — the parent module and full list of sources.
• Code Repositories — exposed public source code, secrets, and internal references.
• Leaked Files — documents exposed on sharing and sandbox services.
• Leaked APIs — exposed API endpoints, source of the API rows in Top Exposed Subdomains.
• Docker Containers — public container images scanned for leaked secrets.
• S3 Buckets — publicly readable cloud storage.
• Shortened URLs — exposed short links, source of the URL Shortener rows in Top Exposed Subdomains.
• Leaked Credentials — exposed usernames and passwords (separate list, not in the overview roll-up).
• Security Rating — how the Data Leaks sub-score in the sidebar is calculated.
• Severity & Status — how to triage the findings you reach from here.