Reports — "Dirt"

Active contributors: data insights & reporting (Dirt) team.

Purpose

Bitwarden's reports surface analytics about an organization's vault hygiene: weak passwords, reused passwords, exposed-in-breach passwords, inactive 2FA, unsecured websites, and more. The reports also include the audit-log facing event integrations described in systems/event-integrations.

The team's internal name is "Dirt" — Data Insights and Reporting Team. Their code-namespace lives at src/Core/Dirt/. They also own the audit-event ingest + processor pair (src/Events/, src/EventsProcessor/).

Where the code lives

src/Core/Dirt/
├── Entities/                     # PasswordHealthReport, BreachReport, ExposedPassword, etc.
├── Enums/
├── EventIntegrations/             # Slack, Teams, Webhook, HEC, Datadog (see systems/event-integrations)
├── Models/                        # Request / response shapes for the API + report data
├── Reports/                       # Report-specific commands / queries
│   └── ReportFeatures/            # Per-report folders
├── Repositories/
├── Services/
└── Utilities/

src/Api/Dirt/
├── Controllers/                   # /reports/... endpoints
└── Models/

src/Events/, src/EventsProcessor/   # Audit-event ingest/drain

Reports

The major reports surfaced by the Web Vault:

Report	What it shows
Exposed Passwords	Passwords found in HaveIBeenPwned breaches.
Reused Passwords	Same password used on multiple cipher entries.
Weak Passwords	Passwords below entropy / length threshold.
Inactive 2FA	Org members with 2FA disabled when policy requires it.
Unsecured Websites	Login URLs using http://.
Data Breach Report	Per-domain breach exposure for org credentials.
Member Access	Which collections / orgs each member can access.
Login Risk	Aggregated login telemetry.

Each report is implemented under src/Core/Dirt/Reports/ReportFeatures/<Name>/ with a IGetXReportQuery and a controller endpoint under src/Api/Dirt/Controllers/.

How a report is generated

Most reports are computed client-side to avoid sending plaintext passwords to the server. The server's role is to:

1. Provide the inputs (audit-log queries, org membership, breach indicator hashes).
2. Aggregate per-org statistics (counts, trend lines) — these are computed server-side from already-summarised data.
3. Persist a snapshot if the report is one customers archive.

For breach detection specifically, the client hashes the password (k-anonymity prefix) and queries an external service; the server forwards / proxies the queries when needed.

Audit events as a reporting source

Event rows (one per audit-relevant action) are the rawest reporting feed. They are written by the API via IEventService.LogXxxEventAsync, queued by Events, drained by EventsProcessor into either Cosmos DB / Azure Table Storage (cloud) or the SQL Event table (self-host). The Dirt team's queries read from this feed.

Integration points

• Api — exposes the report endpoints.
• Events + EventsProcessor — feed the audit-log dataset.
• HaveIBeenPwned — external lookup for breach indicators.
• Event integrations — see systems/event-integrations. The same Dirt team owns this.

Entry points for modification

• New report → add a folder under src/Core/Dirt/Reports/ReportFeatures/<Name>/ with a query + handler, expose via src/Api/Dirt/Controllers/ReportsController.cs.
• New event source for reports → add to EventType (src/Core/Enums/EventType.cs) and emit via IEventService.
• New external integration → see the integration framework in src/Core/Dirt/EventIntegrations/.