89 critical vulnerabilities and nothing is on fire - how to report security findings to executives
Your vulnerability scanner runs. The report lands. 89 CRITICAL vulnerabilities.
Now your CEO wants an explanation. Not a spreadsheet of CVE IDs - an explanation. Are we safe? Should we be worried? What are we doing about it?
Most engineers handle this in one of two ways: they either dump the raw Trivy output into a shared drive and hope nobody reads it, or they panic and say “everything is critical, we need to stop all feature work.”
Both are wrong. Here’s a better approach.
Why raw scan results are useless for leadership
A typical Trivy scan against 54 container images in a Kubernetes cluster might return something like this:
| Severity | Count |
|---|---|
| CRITICAL | 89 |
| HIGH | 612 |
| MEDIUM | 1,247 |
| LOW | 731 |
That table will terrify any non-technical person. And it should - 89 CRITICAL sounds catastrophic. But the number alone means nothing without context.
Here’s what that table doesn’t tell you:
- Are any of these exploitable in our environment?
- Are the affected components exposed to the internet?
- Is this number going up because we’re getting worse, or because new CVEs were published?
- What have we already done about it?
These are the questions leadership actually needs answered. The CVE IDs are irrelevant to them.
The framework: four sections that actually work
After writing monthly vulnerability reports for a production Kubernetes platform, I settled on a structure that consistently gets the right response from leadership - not panic, not apathy, but informed prioritization.
1. What we scanned and what changed
Start with scope. Leadership needs to understand what they’re looking at before they can evaluate the numbers.
“We scan all 54 infrastructure container images monthly using Trivy. This covers cluster components - storage, networking, monitoring, databases - not business applications. This month we upgraded 5 components and performed a Kubernetes engine upgrade.”
Two things happen here: you establish that this is a controlled, recurring process (not a one-off fire drill), and you anchor the numbers to a specific scope.
2. Why the number went up (even though we patched things)
This is the part that confuses executives the most. You upgraded 5 things, but the CRITICAL count went up?
The explanation is simple, but you have to say it explicitly:
“Between our scans, 27 new CVEs were published in public vulnerability databases. Trivy picked these up on the next scan. The increase reflects newly discovered vulnerabilities in software used by the entire industry - not a deterioration of our infrastructure.”
If you skip this section, leadership will assume you’re losing ground. The mental model most non-technical people have is: “we fixed things, so the number should go down.” You need to correct that model.
3. Breakdown by actual risk, not CVSS score
This is where most reports fail. They list CVEs sorted by CVSS score and call it a day. A CVSS 9.8 sounds terrifying - until you realize the affected component runs in an internal network with no external exposure, and the exploit requires sending a specially crafted CMS message to a service that doesn’t process CMS messages.
For each vulnerability category, answer three questions:
What is it, in plain language?
Don’t say “integer overflow in libexpat XML parsing library.” Say:
“A bug in a library that reads XML files. A specially crafted XML file could crash the component or potentially allow code execution.”
Does it actually affect us?
“This library runs inside our network load balancer, which handles internal routing only. It doesn’t parse XML files from users or external sources. The attack scenario requires direct access to the internal network.”
When will it be fixed?
“A patch exists, but it hasn’t been included in the load balancer’s official release yet. We’ve scheduled the upgrade for next month’s maintenance window.”
Here’s what that looks like in table form - the format I use in actual reports:
| Component group | CRITICALs | Real risk | Internet-exposed |
|---|---|---|---|
| Storage system | 32 | Low | No |
| Cluster networking | 12 | Low | No |
| Kubernetes engine | 19 | Low | No |
| Monitoring stack | 9 | Low | No |
| Load balancer | 6 | Minimal | No |
| Tracing + auth proxy | 5 | Low | No |
| Dashboards | 4 | Low | No |
| Log shipping | 2 | Minimal | No |
That “Internet-exposed: No” column across the board is the single most important piece of information in the report. It tells leadership: to exploit any of these, an attacker would need to be inside our network first.
4. What we did, what we’re doing, what we’re waiting on
Close with action. Not vague promises - concrete items with timelines.
| Priority | Action | Timeline |
|---|---|---|
| 1 | Monitor upstream releases for Go stdlib fix (affects 25+ images) | Ongoing |
| 2 | Upgrade storage system to patched version | Next maintenance window |
| 3 | Upgrade load balancer (fixes XML + SQLite CVEs) | March |
| 4 | Upgrade tracing system (blocked by upstream UI bug) | After upstream release |
Notice the pattern: most of our “inaction” is actually waiting for open-source maintainers to release patched versions. We don’t build these tools from source - we use official images. When a CVE hits the Go standard library, every Go-based tool in the cloud-native ecosystem is affected, and we can’t fix it faster than the upstream projects.
Leadership needs to understand this dependency chain. Otherwise they’ll ask “why haven’t you fixed it yet?” every week.
The one sentence that changes the conversation
In every report, I include some version of this:
“89 CRITICAL sounds alarming, but 90% of these come from a single vulnerability in the Go programming language that affects virtually every cloud-native tool in the world. This is not specific to our infrastructure - it’s an industry-wide issue, and we’re tracking upstream fixes.”
This single sentence does more to calibrate expectations than any amount of technical detail. It transforms “our infrastructure has 89 critical problems” into “the industry has a problem, and we’re on top of it.”
Common mistakes to avoid
Don’t hide the numbers. If you only show “we upgraded 5 things,” leadership won’t trust you when the numbers look bad. Show everything, then explain it.
Don’t use CVSS scores as risk ratings. CVSS measures theoretical severity in a vacuum. A CVSS 9.8 on an internal-only component with no external attack vector is not the same as a CVSS 9.8 on your public-facing API.
Don’t promise zero vulnerabilities. That’s not how this works. Any infrastructure running open-source software will always have known CVEs. The question is whether they’re exploitable in your environment, and whether you have a process to track and patch them.
Don’t send the report without the “so what.” A table of CVEs with no risk assessment is worse than no report at all - it creates anxiety without providing direction.
Why this matters for your organization
Monthly vulnerability reporting isn’t just a compliance checkbox. Done well, it builds trust with leadership, creates a paper trail of responsible management, and - critically - makes it easier to get maintenance windows approved.
When your CEO understands that “storage system upgrade” means “eliminating 32 CRITICAL vulnerabilities from our storage layer,” getting that maintenance window scheduled becomes much easier.
The goal isn’t zero CVEs. The goal is a leadership team that understands the risk landscape, trusts that you’re managing it, and gives you the time and resources to keep patching.
Running Kubernetes in production and need help building a vulnerability management process? Let’s talk.