48.4k Log in Get started
Dashboard

What does an application security findings dashboard show in Metabase?

An application security findings dashboard shows code-level risk across the SDLC: open findings by severity and repo, fix rate, quality-gate pass rates, and the CWEs that keep coming back. It's built from findings synced from tools such as SonarQube, Snyk, Semgrep, and bounty platforms like HackerOne.

For: AppSec engineers, engineering managers, and security leadership.Grain: one row per finding, across SAST, SCA, and bug-bounty sources.

What does an AppSec findings dashboard look like?

Here's the layout this guide builds, at the grain of a single finding: the open backlog and its severity mix at the top, then who owns the risky ones and how fast they get fixed, then the rules, CWEs, and dependencies driving the volume. Read it weekly to see whether resolution is keeping pace with intake.

AppSec findings dashboard in Metabase showing severity mix, findings by repo and team, fix rate, and top CWEs.
An example AppSec findings dashboard in Metabase, built from Semgrep, SonarQube, and Snyk data. Figures are illustrative.

Which cards belong on an AppSec findings dashboard?

  • Open findings by severity and repo (stacked bar)
  • New vs. resolved findings per week (line)
  • Fix rate and median time to fix by severity (bar)
  • Quality-gate pass rate on main branches (line)
  • Top rules and CWEs by finding volume (table)
  • Dependency (SCA) risk — vulnerable packages by repo (table)

What data does the dashboard need?

  • appsec_findings — one row per finding with source, repo, rule or CWE, severity, status, introduced_at, and resolved_at.
  • repos — repository list with owning team and criticality.

How do you build it?

  1. Sync findings from each source into one table, mapping every tool's severity scale to a shared four-level one and keeping the original for audit.
  2. Key findings per source — repo + rule + location for SAST, repo + dependency + CVE for SCA, report ID for bounty — so counts don't collide.
  3. Separate fixed from wontfix and accepted_risk statuses so fix rate reflects code changes, not dismissals.
  4. Build the open-by-severity and new-vs-resolved cards first; add quality-gate and CWE views once severity mapping is stable.

Example card SQL

New vs. resolved findings per week by source toolPostgreSQL
WITH new_findings AS (
  SELECT
    DATE_TRUNC('week', introduced_at) AS week,
    source,
    COUNT(*) AS new_count
  FROM appsec_findings
  WHERE introduced_at >= CURRENT_DATE - INTERVAL '12 weeks'
  GROUP BY week, source
),
resolved_findings AS (
  SELECT
    DATE_TRUNC('week', resolved_at) AS week,
    source,
    COUNT(*) AS resolved_count
  FROM appsec_findings
  WHERE resolved_at >= CURRENT_DATE - INTERVAL '12 weeks'
  GROUP BY week, source
)
SELECT
  COALESCE(n.week, r.week) AS week,
  COALESCE(n.source, r.source) AS source,
  COALESCE(n.new_count, 0) AS new_findings,
  COALESCE(r.resolved_count, 0) AS resolved_findings
FROM new_findings n
FULL OUTER JOIN resolved_findings r USING (week, source)
ORDER BY week, source;

Metrics

Open critical vulnerabilitiesMean time to remediateScan coverage

Integrations

SonarQube + MetabaseSnyk + MetabaseSemgrep + MetabaseHackerOne + MetabaseBugcrowd + Metabase

Dashboards

Vulnerability managementAttack surface coverage

FAQ

What is an application security findings dashboard?
It's the SDLC-wide view of code-level risk: open findings by severity and repo, new vs. resolved per week, fix rate, and the rules and CWEs that generate the most volume. It pulls static analysis from SonarQube and Semgrep, dependency findings from Snyk, and bug-bounty reports into one table, so an engineering leader sees the whole application-security picture — a core view in a security analytics stack — instead of four disconnected tool consoles.
How do you combine SAST, SCA, and bounty findings without double-counting?
Keep the source column and count within source before summing across it. SAST findings key on repo + rule + location, SCA findings on repo + dependency + CVE, bounty reports on report ID — they rarely collide, but when a bounty report and a Snyk CVE describe the same flaw, link them with a shared reference field rather than merging rows. The one true double-count risk is running two SAST tools on the same repo: dedupe those on repo + CWE + file, the same canonical-key move the vulnerability management dashboard uses for infrastructure scanners.
How do you normalize severity across tools?
Every tool ships its own scale — SonarQube has blocker/critical/major, Semgrep has ERROR/WARNING, bounty platforms use CVSS. Map them all to one four-level scale (critical/high/medium/low) in the sync job, keep the original value in a source_severity column for audit, and document the mapping. The dashboard is only trustworthy if "critical" means the same thing in every row; without the mapping, the severity chart just reflects which tool shouts loudest.
Why do bug-bounty reports belong on this dashboard?
Bounty reports from HackerOne or Bugcrowd are ground truth: exploitable issues a human actually demonstrated, versus static findings that might be unreachable. Putting them beside scanner output shows which rule families your scanners miss — recurring bounty-report CWEs that never appear in SAST results are a detection gap worth new Semgrep rules. They also deserve the fastest time-to-remediate target of any source, since each one is confirmed exploitable.
How do you measure fix rate honestly?
Split resolutions by status instead of lumping them: fixed means the code changed, while wontfix and accepted_risk mean the finding was dismissed. Fix rate is fixed ÷ (fixed + still open), with dismissals excluded from the numerator and shown on their own card — a team "resolving" half its backlog as accepted-risk looks identical to a team fixing it unless you separate the two. Trend the dismissal share too: a rising accepted-risk rate is a policy conversation, not a hygiene win.