Vulnerability Management Needs a New Executive Lens at Runtime

Most vulnerability management programs still operate like it’s 2008: scan, score, ticket, pray. The output is a queue and it’s exhausting. The only consistent KPI is “number of findings,” which is the security equivalent of measuring hospital performance by how many patients are in the waiting room.

Oligo Runtime Vulnerability Management (RVM) is the antidote. It treats vulnerability risk as a live operating condition shaped by exploit activity, exposure paths, and production reality—not by how scary a CVSS number looks in a spreadsheet. The executive job is to decide what’s real, what’s uncertain, what’s hidden, and what will surprise you anyway.

That’s why the Rumsfeld Matrix works so well here: it’s not a meme; it’s a decision model for operating under uncertainty. And vulnerability management is fundamentally an uncertainty problem. The four quadrants in the matrix (Known Knowns, Known Unknowns, Unknown Knowns, Unknown Unknowns) map exactly to how executive decisions about risk get made – or avoided.

The trap: “severity” without context

Most organizations confuse “severity” with “risk.” Severity is a property of a vulnerability in isolation. Risk is a property of a vulnerability in your environment—exposure, compensating controls, and attacker behavior included.

Modern programs are steadily converging vulnerability management and exposure management because they’re tired of drowning in un-actionable findings. And continuous monitoring isn’t a checkbox but rather it’s the mechanism that compresses uncertainty over time. Let’s apply the Rumsfeld matrix to runtime vulnerability management and bring some new thinking to this age-old problem.

‍

Quadrant 1: Known Knowns

“This is real. It’s reachable. It matters. Act.”

This quadrant is where you have enough verified truth to act decisively: not “scanner says,” but “runtime proves.”

Examples 

• Actively exploited CVE + internet-facing + reachability confirmed: this is not a Jira ticket. It’s an incident-grade decision—patch, hotfix, or compensating control today.
• Vulnerable function is invoked in production: libraries can be present and harmless; execution paths are what matter. If it’s being called, it’s a Known Known.  The closest you can get to knowing true risk is seeing a known vulnerable function executing in your environment.

If your “Known Knowns” list is mostly scanner findings, you’re not doing runtime vulnerability management—you’re doing vulnerability accounting. Accounting is much more appropriate to filing your taxes than to managing risk.  

What should you be doing about this?  Measure containment and blast-radius reduction, not “tickets burned down.”

Quadrant 2: Known Unknowns

“We know what we need to learn. Fund the truth.”

Known Unknowns are the questions you can name but can’t yet answer. This quadrant is where programs mature—or become performative.

Examples

• High-profile CVE drops; scanners light up; exposure unknown: is it on a public login edge or an internal batch job? Until you answer, prioritization is fiction.
• Compensating controls are assumed: “We block that at the edge.” Great—show proof it blocks the exploit behavior.  And by the way, if it’s a zero day you are beholden to your WAF provider to provide the needed signature file.  (Hint: there’s a better way…)
• Ownership ambiguity in microservices: “who owns this dependency at runtime?” If you can’t answer fast, it’s an engineering governance problem, not an AppSec tooling problem.  And regardless of whose problem it is internally, it remains an organizational risk.

Most orgs spend money on scanning and starve validation. That’s backwards. Scanning creates Known Unknowns. Validation converts them to Known Knowns. Fund the conversion engine.  Why scan static code when the world we live in, circa 2026, is all about runtime?

What should you be doing about this? Manage your runtime signals to better understand what in your environment is invoked and presents real risk.  Continuous monitoring at runtime is the backbone that helps turn unknowns into decisions.

Quadrant 3: Unknown Knowns

“The org already knows… but the program doesn’t.”

This quadrant is the stealth tax on security leadership. Knowledge exists somewhere—tribal memory, SRE runbooks, some Notion page, in Slack, etc. —but it’s not visible to the decision system.

It creates the classic dysfunction: Security doesn’t trust Engineering’s “we mitigated it.”  Engineering doesn’t trust Security’s “this is urgent.”  Everyone might be right, yet nobody can prove it.

Examples

• Compensating controls exist but aren’t inventoried/validated: claims without evidence are just stories.  Do you have the call stacks to back up your claim? If not, cool story bro….
• Legacy routes people forgot are reachable: diagrams lie; runtime tells the truth.  We all know documentation is the last thing to get updated (if ever).
• Postmortems that never become guardrails: the company paid for the lesson and then failed to institutionalize it.  How many times can this happen to you until you are told to find employment elsewhere?

Unknown Knowns are governance debt. If you don’t pay it down, you’ll keep rediscovering the same failures like they’re new.  We all have enough debt to deal with every day- do you want to break this cycle and start making progress against real risk?

What should you be doing about this?

• Create a Compensating Controls Register (what, where, what it blocks, how validated, owner).  Our CADR allows you to block exploits by CWE type (you read that right!), providing true zero day protection.
• Require “show me” proof in reviews. If a team claims mitigation, they show runtime evidence. Oligo can show you the call stack and help you stop guessing.
• Convert incident learnings into detections, policy-as-code, and repeatable guardrails.  Oligo provides significant (98%+ on average) noise detection to begin with using our runtime sensor.  Marry that to the ability to block by CWE type in a single click and you get even higher fidelity about what risks are real and need to be your area of concern/focus.

Quadrant 4: Unknown Unknowns

“You won’t predict it. You must be built to survive it.”

Unknown Unknowns are 0-days, novel exploit chains, unexpected interactions, supply chain compromises, new attacker tradecraft. If your strategy is “we’ll patch fast,” you’re already losing—because the decisive window is often exploit → detection/containment, not disclosure → patch.

Examples

• New exploit technique bypasses your signatures. SAST doesn’t help. You need realtime detection and blocking.
• Dependency compromise: scanners show “no known CVEs,” but behavior is malicious. 
• Feature flags/config drift expose surfaces: nobody “coded a vuln,” but production reality changed.  Vibe coding makes this problem orders of magnitude worse.

Unknown Unknowns are why compliance AppSec is a trap. Compliance tells you that you followed a process; it doesn’t tell you you’re safe when the world changes.

What should you be doing about this?  Invest in detection + containment as first-class outcomes.  Don’t bother scanning the repo any longer as it is no longer the source of truth.  Runtime is where the risk lives. Stop checking the box and start making progress on retiring risk in your environment.

‍

A New Operating Model

Mature runtime vulnerability management is a conveyor belt that moves issues across quadrants.  Evaluating vulnerability risk as organization risk helps you reframe the executive operating model for how runtime vulnerability management is viewed and helps you convert uncertainty (don’t just count findings) to actionable findings.  The goals of this approach are:

• Move Unknown Unknowns to Known Unknowns (surface signals)
• Move Known Unknowns → Known Knowns (validate impact/control efficacy)
• Move Unknown Knowns → Known Knowns (harvest tribal knowledge into observable controls)

If your AppSec program can’t explain how it systematically performs these conversions, your “prioritization” is mostly vibes and it’s a matter of time until a real risk jeopardizes your organization.

Metrics leaders should demand (and stop accepting vanity KPIs)

Stop measuring:

• number of vulnerabilities found
• number of tickets closed
• mean CVSS

Start measuring:

• % of critical findings with verified exposure status (exploited / not exploited / unknown)
• median time from CVE detection → exposure confirmed/denied
• median time from exploitation signal → containment
• coverage of compensating controls with validation evidence
• blast radius reduction (how quickly you can constrain behavior)

These metrics force the program to trade in truth, not volume.

What to fund next quarter (if you want this to be real)

1. Validation signals (invocation/exposure) over “more scans”
2. Observable controls (controls register + evidence)
3. Containment muscle (CADR blocking)
4. AppSec tooling that drives decisions that reduce risk, not produce more noise

Summary

The Rumsfeld Matrix is your executive dashboard:

• Known Knowns tell you what to act on. 
• Known Unknowns tell you what to investigate. 
• Unknown Knowns tell you what to surface and institutionalize. 
• Unknown Unknowns tell you what to design for—because surprise is great for your birthday, not when you’re trying to run a corporate application security program.

If you want to stop living in a world of noise, filled with unknowns then you need to get to runtime. Oligo is doing this for companies in all industries, of all sizes and complexity. Let us help you.