Most AppSec leads walk into a board or CISO review with a slide that says something like "4,200 open findings, down from 4,600 last quarter" — and it lands with nobody, because it answers a question no executive asked. CVSS v3.1, the scoring standard maintained by FIRST and used throughout the National Vulnerability Database, was explicitly designed to measure technical severity, not exploitability or business impact; it has no field for "is this reachable," "is this being exploited right now," or "does this sit in front of customer data." Meanwhile CISA's Known Exploited Vulnerabilities (KEV) catalog — the real, actively maintained list of CVEs with confirmed in-the-wild exploitation, which Binding Operational Directive 22-01 has required federal agencies to remediate on fixed timelines since November 2021 — routinely contains vulnerabilities with mid-range CVSS scores that a severity-sorted dashboard would bury on page three. The gap between "technically severe" and "actually dangerous" is exactly where AppSec communication breaks down. This post covers the metrics that translate scanner output into business risk, the mistakes that erode a CISO's trust in your numbers, and how to build a report that survives a follow-up question.
Why doesn't a raw CVE or finding count tell a CISO anything useful?
A raw count doesn't tell a CISO anything useful because it conflates volume with risk, and volume is mostly a function of how many dependencies you have, not how insecure you are. A modern service can easily carry 200-500 direct and transitive dependencies, and it's normal for 5-15% of them to have a known CVE at any given moment — most of which are never invoked by the application at runtime. Reporting "we have 380 open vulnerabilities" without qualifying how many are reachable is equivalent to reporting a hospital's total patient count as a measure of how sick the building is. The more useful framing splits the number: total findings, reachable findings, and findings that are both reachable and either KEV-listed or have a high EPSS score. A CISO who hears "380 open, 34 reachable, 4 actively exploited elsewhere" can make a staffing decision. One who hears "380 open" can only ask you to explain yourself, which is the meeting you were trying to avoid.
What's the difference between CVSS severity and actual exploitability?
CVSS severity measures how bad a vulnerability could be if triggered under ideal conditions; exploitability measures the probability it will actually be triggered. FIRST's own Exploit Prediction Scoring System (EPSS) exists specifically to fill this gap — it's a machine-learned model, published and updated daily, that estimates the probability a given CVE will be exploited in the wild within the next 30 days, based on real telemetry rather than a static rubric. A CVE can carry a CVSS base score of 9.8 and an EPSS probability under 1%, or a "medium" CVSS score of 6.1 and sit on the CISA KEV list because it's being actively used in ransomware campaigns right now. Reporting severity alone treats those two cases as interchangeable; reporting exploitability alongside severity tells the CISO which one needs an emergency patch window and which one can wait for the normal release cycle. This distinction is also the reason KEV membership, not CVSS score, is the trigger federal agencies must act on under BOD 22-01 — a real regulatory precedent for prioritizing confirmed exploitation over theoretical severity.
Why does reachability matter more than dependency-tree depth?
Reachability matters more than dependency-tree depth because an unreachable vulnerability, however deep or shallow in your tree, cannot be exploited through your application regardless of its CVSS score. A dependency scanner matches your lockfile against a CVE database and reports every match, full stop — it has no idea whether your code ever calls the vulnerable function. Reachability analysis builds an actual call graph from your entry points and checks whether execution can reach the flagged line; multiple vendor studies from 2023-2024 have found that a large majority of CVEs surfaced by dependency scanning in typical applications sit in code paths that are never invoked at runtime. That's the number worth putting in front of a CISO: not "we have 380 vulnerable dependencies" but "34 of those 380 are on a path our application actually executes." It also reframes the ask — instead of requesting headcount to triage 380 tickets, you're requesting a sprint to fix 34, which is a budget conversation a CISO can actually approve.
What does mean-time-to-remediate actually measure, and why does patch cadence matter to the board?
Mean-time-to-remediate (MTTR) measures how long a known, actionable vulnerability sits unpatched after disclosure — and it matters to the board because delay, not discovery, is usually what turns a CVE into a breach. The 2017 Equifax breach is the textbook public case: it was publicly attributed, including in subsequent GAO and House Oversight Committee reporting, to exploitation of a known Apache Struts vulnerability (CVE-2017-5638) that had a vendor-published patch available before the breach occurred — the failure was in the remediation window, not in detection. Vendor MTTR benchmarks (from firms like Veracode and Edgescan) vary year to year and should always be cited as survey data specific to that vendor's customer base, not treated as a universal industry constant. What's safe and useful to report internally is your own trend: rolling 30- and 90-day MTTR by severity band and by environment, split by whether the finding was reachable in production. A CISO doesn't need to know the industry average — they need to know whether your own remediation velocity is improving quarter over quarter, and whether it's faster for the findings that actually matter.
What are the most common mistakes AppSec teams make when reporting to executives?
The most common mistake is presenting severity-only dashboards — walls of critical/high/medium/low counts with no reachability, exploitability, or business-context layer — which trains executives to distrust every future report because the numbers never seem to correlate with actual incidents. A close second is omitting supply-chain and build-pipeline risk entirely, because it doesn't show up as a clean CVE count: Alex Birsan's 2021 dependency-confusion research, disclosed on his own blog, showed that public/private package-namespace collisions let him execute code inside internal build systems at more than 30 companies, including Apple, Microsoft, PayPal, and Tesla, without a single traditional CVE involved. The 2020 SolarWinds SUNBURST compromise and the xz-utils backdoor (CVE-2024-3094, discovered by Andres Freund in March 2024 during a routine performance investigation) are similarly instructive — both were deep, build-pipeline-level compromises that a CVE-count dashboard would never have flagged as a top risk beforehand. A third mistake is reporting policy exceptions as a footnote instead of a headline metric — an executive needs to know the compliance rate against your own guardrail policies (what percentage of production deployments passed without an override) as much as they need to know the open finding count, because that number tells them whether the program's rules are actually being enforced or quietly bypassed.
How Safeguard Helps
Safeguard's Program Overview dashboard is built around the metrics this post argues for, not raw severity counts: open critical/high findings by environment, KEV-listed findings in production (which should read zero), and rolling 30- and 90-day time-to-remediate, all in one exec-facing view. Underneath it, Safeguard's prioritization engine computes a 0-100 Priority Score per finding from reachability, EPSS probability, KEV status, runtime exposure, and business-context tags like regulated data or revenue-critical ownership — in aggregate, that reachability layer alone typically removes 60-80% of findings from the "urgent" queue before EPSS and environment filtering even apply. For the board itself, Safeguard's Executive Packs generate a five-page Security Posture Executive Summary and templated board-pack PDFs directly from that same data, so the report a CISO hands upward is built from the same reachable, exploit-weighted numbers the engineering team is actually triaging against — not a separate spreadsheet assembled the night before the meeting.