What is security analytics, and how do you build it in Metabase?
Security analytics turns vulnerability findings, detections, control results, and identity events into shared metrics about how well your security program actually works — and whether it's getting better. In Metabase, build it by syncing summaries of those signals into a SQL database, modeling clean finding, detection, control-snapshot, and auth-rollup layers, and shipping dashboards that put security posture next to the business data everyone already trusts.
TL;DR — Use four adjacent models: vulnerability findings and assets; detections and incidents; daily control-result snapshots; daily auth-event rollups and identities. Keep raw telemetry in the SIEM or security data lake — the warehouse gets findings, entities, and history.
What does security analytics measure?
- Is total exposure shrinking — and where does it concentrate?
- Do we remediate within the SLAs we promised, per severity?
- How fast do we detect and contain what gets through?
- Would we pass the audit today — and which controls say no?
- Is MFA actually adopted, or just mandated?
- Is everything scanned and protected, or only the assets we know about?
- How does security posture correlate with delivery pace and spend?
Which tools feed security analytics?
| Tool | Best for | Getting data into Metabase |
|---|---|---|
| SonarQube | Quality gate pass rate by project; New vs. resolved findings | SonarQube Web API, pipeline, or SonarQube MCP Server for exploration |
| Tenable | Open criticals by asset group; Median time to remediate by severity | Tenable Vulnerability Management API, pipeline, or Tenable MCP Server for exploration |
| Okta | Failed login rate by app; MFA adoption by factor type | Okta System Log API, pipeline, or Okta MCP Server for exploration |
| CrowdStrike | Detection volume by severity and tactic; Median time to triage | CrowdStrike Falcon APIs, pipeline, or Falcon MCP Server for exploration |
| Snyk | Open issues by severity and project; New vs. fixed issues | Snyk REST API, pipeline, or Snyk MCP (CLI) for exploration |
| Wiz | Critical issues trend; Issue resolution SLA | Wiz GraphQL API, pipeline, or Wiz MCP Server for exploration |
| Auth0 | Login success and failure rate; Signup conversion | Auth0 Management API, pipeline, or Auth0 MCP Server for exploration |
| SentinelOne | Threat volume by classification; Mitigation status and unresolved threats | SentinelOne Management API, pipeline, or SentinelOne purple-mcp for exploration |
| Semgrep | Findings by rule and severity; New vs. resolved findings | Semgrep API, pipeline, or Semgrep MCP for exploration |
| Vanta | Control pass rate by framework; Failing tests with owner and age | Vanta API, pipeline, or Vanta MCP Server for exploration |
| Drata | Pass rate by framework; Failing monitors with owner | Drata Public API, pipeline, or Drata MCP Server for exploration |
| HackerOne | Report inflow and triage SLA; Time to triage and resolution | HackerOne API, pipeline, or HackerOne MCP Server for exploration |
| Bugcrowd | Submission inflow by severity; Validation and triage SLA | Bugcrowd REST API, pipeline, or Bugcrowd AI Connect MCP for exploration |
| Orca Security | Alerts by category and severity; Remediation trend | Orca Security API, pipeline, or Orca MCP Server for exploration |
| Cloudflare | Edge security events, WAF activity | GraphQL Analytics API or Logpush |
| GitHub | Dependabot alerts, code scanning, delivery joins | API, connector, or GitHub MCP |
What shared data models should you build?
Build clean models on top of raw source tables so each dashboard uses the same definitions.
vulnerability_findings— one row per deduplicated finding, with asset, severity (one scale), status, first-seen, and resolved timestampsassets— the authoritative inventory: stable IDs, owners, environment, and criticality — the join key and every coverage denominatordetections— one row per detection with severity, tactic, verdict, and the detected/triaged/contained timestampssecurity_incidents— one row per qualifying incident, joined to its detectionscontrol_results_daily— one row per control per framework per day; the snapshot table that makes posture a trendauth_events_daily— one row per app per outcome per day, rolled up from the identity provider's log streamidentities— one row per account with status, privilege, MFA enrollment, and strongest factorpeople_compliance— training, background-check, and offboarding state per person, joined to HR records
Which security metrics matter most?
- Open critical vulnerabilities — deduplicated open criticals, by asset group and age.
- Mean time to remediate — first-seen to resolved, as a median by severity.
- Vulnerability SLA compliance — findings closed within their severity SLA, counting the overdue.
- Mean time to detect (MTTD) — first activity to detection; a lower bound, honestly caveated.
- Control pass rate — passing controls per framework from daily snapshots.
- MFA adoption rate — strong second factors across active humans, segmented by privilege.
- Failed login rate — auth friction and attack signal, separated by failure reason.
- Scan coverage — scanned assets over the true inventory; the denominator for honesty.
How do you connect tools to Metabase?
- MCP + CLI — use MCP for a scoped, summarized live export, then
mb upload csvfor quick analysis. - Warehouse-backed pipeline — sync findings, detections, snapshots, and rollups with APIs, native exports, or the few managed connectors that exist in this category.
- Modeled layer — map each source into the shared finding, detection, control, and auth models while preserving source-specific extension tables.
Which dashboards should you build first?
- Vulnerability management— open exposure, remediation velocity, and SLA compliance.
- Compliance posture — control pass rates, failing controls, and audit readiness.
- Identity & access analytics — auth health, MFA adoption, and lifecycle hygiene.
- Incident response trends— detection volume, triage speed, and MTTD.
- AppSec findings— SAST, SCA, and bug-bounty findings across the SDLC.
- Attack surface coverage — whether everything is actually scanned and protected.
Common mistakes
Trying to warehouse raw security telemetry.→ Storage costs explode and queries crawl. Sync findings, entities, and daily rollups; keep raw signals in the SIEM or data lake.
Reporting durations as means.→ Remediation, triage, and detection times are right-skewed. Use medians with p90.
Skipping the snapshot tables.→ Security tools report current state. Without daily snapshots of open findings and control results, there are no trends — only today's number.
Ignoring the inventory join.→ Findings without an authoritative asset inventory can't answer coverage or ownership questions. Build the assets table first, from outside the scanners.
Related
Integrations
Terms
FAQ
What is security analytics?
Security analytics is the practice of turning your security program's operational records — vulnerability findings, detections, control results, and identity events — into governed, shareable business metrics. Where security consoles answer "what needs triage right now?", security analytics answers "is exposure shrinking, are we remediating within SLA, and would we pass the audit today?" In Metabase, you build it by syncing findings and daily snapshots from tools like Tenable, CrowdStrike, and Vanta into a SQL warehouse and modeling shared metrics on top.
What is the difference between security analytics and a SIEM?
A SIEM ingests raw events in near-real time for detection, correlation, and investigation — it's an operational security tool for analysts. Security analytics is longitudinal reporting on aggregated records: weekly and quarterly trends in exposure, remediation velocity, control posture, and identity hygiene, built in a BI tool the whole company can read. You need both — the SIEM to catch tonight's intrusion, the analytics layer to decide where next quarter's security investment goes.
Why not just use each security tool's built-in reporting?
Because every console reports its own slice with its own definitions, and the board asks questions that span all of them. Cross-tool reporting — total open criticals across Tenable, Wiz, and Snyk; MFA adoption next to control pass rate — is the view no single vendor covers. Metabase adds governed definitions, org-wide sharing without per-seat security-tool licenses, and joins with HR, asset, and business data.
Which metrics should a security dashboard track?
Start with the exposure core: open critical vulnerabilities, mean time to remediate, and vulnerability SLA compliance. Add mean time to detect for the SOC, control pass rate for compliance, MFA adoption and failed login rate for identity, and scan coverage to keep every other number honest — an unscanned asset has zero findings.
Which tools feed security analytics in Metabase?
Any tool whose data you can land in a SQL database. This cluster covers 14 guides: vulnerability and cloud security (Tenable, Wiz, Orca Security), application security (SonarQube, Snyk, Semgrep, HackerOne, Bugcrowd), endpoint security (CrowdStrike, SentinelOne), identity (Okta, Auth0), and compliance (Vanta, Drata). See the category overview for connection routes.
Is Metabase a replacement for my security tools?
No — it complements them. The scanners, EDR platforms, and compliance tools keep doing detection, enforcement, and evidence collection. Metabase is the reporting layer on top: shared definitions, trend history, owner accountability, and the cross-tool rollups that turn fourteen consoles into one picture for leadership.
What data do I need to get started?
One table starts the program:
vulnerability_findings with asset, severity, status, first-seen, and resolved timestamps — enough for the vulnerability management dashboard, remediation-time trends, and SLA compliance. Add daily control_results snapshots for compliance posture, and daily auth_events rollups for identity analytics, as those questions arrive.Can I build security dashboards without a data warehouse?
For a first pass, yes: pull a summarized export through a tool's MCP server and load it with the Metabase CLI (
mb upload csv) — each upload becomes a queryable table and model. That works for spot-checks and one-off analyses. Move to a database-backed sync once dashboards need scheduled refreshes, snapshot history for trends, and definitions people can trust; every integration guide documents both routes.