A product-security lead is asked one question in a dozen forms: how exposed is what we ship? The honest answer spans the whole software development lifecycle — the findings from every scanner, whether they’re being fixed inside their deadlines, which repositories carry the risk, whether the pipelines that build the code are hardened, what’s hiding in the dependency tree, and which APIs face the internet. The AppSec Dashboard (/app/appsec/dashboard) is the one screen that reads all of it at once, section by section, from the scanner output and repository metadata the program already ingests. This article walks each section: what the number means, which query feeds it, and — the part that separates a scoreboard from a lie — where the page is careful to say “unassessed” or “unknown” instead of inventing a passing grade.
Who’s involved
- Product-security / AppSec lead — owns the whole board: finding SLAs, repo posture, pipeline and supply-chain risk, API exposure.
- Engineering managers — read the repository matrix and SDLC coverage to see which teams carry unremediated risk and missing controls.
- Developers — work the findings that land in their repositories, inside the severity-based deadlines the SLA section tracks.
- Auditors — read the same posture as evidence that a secure-SDLC program actually runs, with documented, audit-logged exceptions.
The KPI hero
Four cards, each a question an executive asks. Active Findings counts everything open and in-progress across every scanner class. Critical & High pulls the highest-severity open findings forward and turns red when there are any. SLA Breached counts findings already past their remediation deadline, with a subtitle for how many more are approaching one. Active Repositories counts the repos under management and flags how many are still unclassified — because you can’t hold a repo to a production standard until you’ve said it’s production. Every card links into the findings register or the repository list; the links open the full list rather than a pre-filtered slice, so treat them as “take me there,” not “take me to exactly these rows.”
Findings by severity and class
Two cuts of the same finding set. The severity donut shows the open distribution from Critical down to Informational; the by-class bars break the same findings down by how they were discovered — SAST (static analysis), SCA (software-composition / dependency scanning), container and IaC scanning, and, when present, DAST, secrets, and API classes. The bars are scaled to the largest value present, not to a total, and the section says so — a full bar means “the biggest category here,” not “100% of findings.” The footer names the honest total: how many findings exist and how many are already remediated.
Remediation SLA health
This is where a finding count becomes a remediation program. Deadlines are severity-based: the more severe the finding, the shorter the clock. On the SLA clock is the count of active findings with a deadline; Breached are past it and need work now; At Risk are in the final quarter of their window — computed from the actual due date and first-seen date, not a guess. The two badges are the honesty of the section: Risk Accepted counts findings a human formally decided to accept, described as “documented, audit-logged decisions,” and False Positives counts findings dismissed with a recorded reason. Neither is swept into “remediated” — an accepted risk is a decision on the record, not a fixed bug, and the dashboard keeps them distinct.
Repository risk matrix
The matrix answers “which repos should we be talking about?” One row per repository, sorted by breached findings then total open — so the repos that most need attention sit at the top. Critical and High cells carry colored badges when they’re non-zero; the Breached column turns red the moment a repo has an overdue finding. A repository with no name resolves to an honest “Unknown repository” rather than a raw identifier — the matrix never leaks a database id into a column a person reads.
SDLC control coverage
Three controls, graded across the active repositories: branch protection, CODEOWNERS, and signed commits. Each card shows the percentage of active repos where the control is enforced, the letter grade that maps to it, and the enforced / absent / unverified breakdown underneath. Here’s the design detail worth internalizing: when there are no active repositories to measure, these grades show a dash — not an “F”, not “0%”. A fabricated failing grade on an empty program is a lie the dashboard refuses to tell; the honest state is “nothing to measure yet,” shown as an empty prompt. When repos do exist and a control genuinely isn’t enforced on any of them, that’s a real zero and a real F — the dash is reserved strictly for “there is nothing here to grade.”
Pipeline posture
The pipelines that build and ship the code are their own attack surface. This section grades them on secret-scanning coverage, signed builds, branch protection, and the share reaching SLSA Level 2+ — the point at which build provenance becomes non-forgeable. The SLSA build-level bars show the distribution from L0 to L3, and the by-platform bars show which CI systems those pipelines run on. It’s the supply-chain-of-the-build view: a signed, provenance-attested build from a hardened pipeline is a materially different artifact than one produced by an unattested job, and this is where that difference is visible.
Software supply chain
Every ingested SBOM (software bill of materials) rolls up here: how many documents, how many components across them, how many carry known vulnerabilities, and how much of the build has verified SLSA provenance. The VEX-coverage donut is the section’s sharp edge. VEX — a Vulnerability Exploitability eXchange statement — is how a team records “yes this component has CVE-X, and here’s whether it actually affects us.” The donut splits known vulnerabilities into those with a VEX statement and those without, and the known-vulnerabilities metric calls out how many are un-VEXed. A vulnerable dependency with no VEX statement isn’t necessarily exploitable — but nobody has said so on the record, and that’s exactly the queue a supply-chain program has to work down.
API security
The API inventory — populated by importing OpenAPI specifications — gets the same treatment as the code. The metrics count APIs and their endpoints; the endpoint-auth card shows what share of endpoints declare authentication, and it excludes endpoints whose spec declares no security at all from the denominator rather than guessing they’re unprotected — “unknown” is not counted as “insecure.” The OWASP coverage card and the OWASP API Top 10 posture bars read from a manual attestation: each of the ten 2023 categories is marked Addressed, At Risk, Not Applicable, or Unassessed, and coverage is measured over the assessed-and-applicable categories — so an unassessed category drags nothing and inflates nothing. The by-exposure bars separate public, partner, and internal APIs — here a public checkout API and an internal fulfillment API — because a Broken Object Level Authorization finding on a public API is a different fire than the same finding on an internal tool.
Findings trend
Opened versus resolved findings, week by week, over a window you choose (4, 8, 12, or 26 weeks). This is the “are we winning?” view: when the opened line runs above resolved for a stretch, the backlog is growing regardless of how good any single week looked. The section names its own provenance — the series are derived from the findings’ own first-seen and resolved timestamps, computed over a fixed week spine, not read from a stored weekly snapshot. That means a quiet week is a true zero, and the trend can’t drift out of sync with the findings it’s counting, because it is those findings, bucketed by date.
Needs attention
The last section is the work list, and it’s three queues at once. Oldest SLA breaches surfaces the findings that have been overdue longest, each with its repository and how many days past due. Critical vulnerabilities without a VEX statement pulls the un-VEXed critical component vulns forward by CVE — the supply-chain items nobody has yet ruled in or out. Unprotected production repositories names the repos classified production that have no branch protection — the SOC 2 red flag that shouldn’t exist. Each queue shows “showing N of M” when the full list is longer than the preview, so a short list is honestly short and a truncated one says so. When all three queues are empty, the section says so plainly rather than rendering three blank boxes.
What you walk away with
- A single read of SDLC exposure — findings, SLAs, repo posture, pipelines, supply chain, and APIs, from the scanner output you already ingest.
- An SLA program, not just a finding count — severity-based deadlines with breached and at-risk split out, and accepted-risk and false-positive kept honestly separate from “fixed.”
- Coverage grades that refuse to lie — a dash instead of a fake F when there are no repos to measure, and a real F only when a control genuinely isn’t enforced.
- A supply chain and API surface scored on what’s assessed — un-VEXed vulns and unassessed OWASP categories are visible as work, never hidden inside a coverage percentage.
- A trend you can trust — derived from the findings’ own timestamps, so a quiet week is a real zero and the chart can’t drift from the data.
- One work list of the oldest breaches, the un-ruled-out critical vulns, and the unprotected production repos — each a click from the record.
The registers behind these numbers each have their own walkthroughs in the AppSec cluster: managing AppSec findings, pipeline security posture, and the software supply chain and SBOM surface. This dashboard is where all of it becomes a program you can report on in one read.