Exposure Management Is Not a Tool, It’s a Discipline.

Brad Hibbert, COO and Chief Strategy Officer at Brinqa, on the 20-year evolution from vulnerability scanning to AI-powered exposure management, and what it means for your security program.

You closed 400 critical vulnerabilities last quarter. So did your competitors. So did the companies that got breached. Closing vulnerabilities isn't the problem, knowing which ones actually threatened your business is. If your program measures success in tickets closed rather than risk removed, you're optimizing for the wrong outcome.

In a recent Cloud Security Podcast episode, Brinqa Chief Operations and Strategy Officer Brad Hibbert joined host Ashish Rajan to trace how vulnerability management has evolved into exposure management, why that shift matters, and how AI is changing the decisioning layer entirely.

Cloud, Containers, and APIs: How the Attack Surface Outgrew Traditional Vulnerability Management

Hibbert started in vulnerability management years ago, when many considered quarterly server scans a mature program. "They might have done a scan once a quarter to meet their compliance requirement. Then they moved it to monthly." The environment was relatively contained: a data center, some internet-facing web servers, a clear perimeter.

That world no longer exists. Today, a single server might support multiple business services simultaneously, one serving internal employees, another serving external customers. Cloud workloads, containers, and APIs operate in environments that are software-defined and ephemeral. Add in threat intelligence feeds, identity systems, and custom application code, and the scope of what needs to be tracked, prioritized, and remediated has grown exponentially.

"Everything's more interconnected now than it's ever been," Hibbert said. "Context matters a lot more than it did in the past. It's not just about getting the raw findings, it's figuring out, with the context of the business, what to focus on to have the biggest impact on risk reduction."

What Is Exposure Management, and How Is It Different from Risk-Based Vulnerability Management?

Risk-based vulnerability management was a meaningful step forward from raw vulnerability lists. By layering in asset context and threat intelligence, teams could move from "fix everything" to "fix what matters most." But it still operated within silos – each tool, each team, each domain producing its own prioritized view.

Exposure management is the layer above. It connects risk across all domains and all tools, providing a unified, business-aligned view of what actually matters. As opposed to focusing on CVEs to fix, exposure management focuses on which exposures can lead to compromise.

"Risk-based vulnerability management is a great first step," Hibbert explained, "but it's very siloed into those individual teams and platforms. Exposure management gets to the next level of diligence. It's not about how many critical vulnerabilities you closed that day. It's about how much risk you took out of the organization."

The key questions exposure management is designed to answer:

• Is this exposure reachable in my environment?
• Is it exploitable?
• If exploited, what is the blast radius?
• Which business services does it put at risk?

This shifts the program's objective from reporting to remediation, from producing a prioritized list of issues to actually mobilizing the right teams to remove risk from the environment.

The Ownership Problem: Risk Owners vs. Remediation Owners

One of the most persistent challenges in vulnerability management has always been ownership. Who owns the vulnerability? Who owns the fix? In traditional programs, the answer was usually simple: the server team owns the server risk.

But in a world where a single server supports multiple business services, that mapping breaks down. "The server team's not going to know which one of these services is most important to the business," Hibbert said. "It would be the service owners that would understand: am I willing to accept this risk?"

Traditional vulnerability programs lack shared context, so remediation teams (IT, Cloud, App teams), don’t trust the priority coming from security. Exposure management introduces a cleaner ownership model by separating two distinct roles:

• Risk owner: The service owner who understands business context and decides how to respond to risk.
• Remediation owner: The technical team (cloud, server, code, etc.) that performs the actual fix.

Without this distinction, programs stall. "I come to you as the remediation owner, you crack open a spreadsheet and start arguing that your data's different than my data," Hibbert said. "That happens a lot."

How AI Fits Into the Exposure Management Stack

Security teams aren’t lacking data, they're drowning in it. Telemetry from scanners, threat intelligence feeds, asset management platforms, cloud monitoring tools… the volume of inputs has outpaced any human team's ability to process it manually.

This is where AI enters the exposure management picture. According to Hibbert, AI's primary value is in making connections across data sets that are too complex for manual analysis — correlating attacker behavior, exploit techniques, mitigating controls, and asset context to surface what actually matters.

But AI's usefulness depends entirely on the quality of the data foundation underneath it. "You want to make sure that your AI is based on a sound data foundation," Hibbert said. "If you don't believe in the data, if you're suspect of the opinions coming out of the AI, then you're not going to take action based on those outputs."

The evolution Hibbert describes is a three-stage progression:

1. Data orchestration: Aggregating, normalizing, and making sense of feeds from multiple tools and CMDBs.
2. Decision orchestration: Using AI to produce opinionated, explainable prioritization across teams; telling you what to fix, in what order, and why.
3. Action/remediation orchestration: Automating remediation for known patterns with high confidence, while keeping humans in the loop for high-risk changes.

"Automation works well for known patterns," Hibbert noted. "If the AI can look back and say it has 90% confidence this is the right thing to do, you can start to automate those. But if it's a risky change that could impact a critical service, you still might want a human to click the button."

Compliance Proves Activity. Exposure Management Proves Impact.

For organizations operating under regulatory frameworks (PCI DSS, HIPAA, SOC 2, etc.) vulnerability management has historically been compliance-driven. Close your critical vulnerabilities within 30 days. Show the auditor a report. Move on.

Hibbert's view: compliance-driven programs demonstrate activity, not impact. "Hey, I closed my critical vulnerability in 21 days, but it's not tied to the actual risk you're taking out of the environment."

Exposure management reframes the conversation for boards and executive leadership. Instead of SLA adherence metrics, security teams can show quarter-over-quarter risk reduction tied to specific business services — demonstrating not just that work was done, but that the organization's exposure to material risk has measurably decreased.

"One is focused on outcomes and impact. The other is focused on demonstrating that prescribed activity has been performed," Hibbert said.

What It Takes to Transition to Exposure Management

Moving from risk-based vulnerability management to exposure management isn't primarily a technology decision. It's an organizational one.

• Executive commitment. Exposure management needs to be treated as a discipline, not a tool deployment or side project.
• Shared understanding of risk. All teams need to agree on how risk is defined and prioritized before the program can operate effectively.
• Aligned incentives. If different teams are incented differently (e.g., one team optimizing for CVSS-based closure speed, another for uptime) friction and conflict will undermine the program.
• Clear decision authority. Risk ownership and remediation ownership need to be explicitly defined and agreed upon across teams.
• Dedicated resources. The cross-team coordination required for exposure management can't run on the side of someone's desk.

On the practical side, Hibbert recommends starting small. Pick one or two areas (external attack surface, crown jewel applications, a set of critical services) and demonstrate measurable risk reduction before expanding. "You're never going to start with perfect data or perfect systems," he said. "Focus on decisions, not scope."

Preserving Domain Knowledge While Evolving the Program

One concern Hibbert hears frequently: will moving to exposure management mean losing all the domain-specific logic teams have built into their existing tools over years?

His answer: it shouldn't. Exposure management is designed to sit above the tools, normalizing and curating insights from across teams; not to replace them. Domain knowledge that reflects genuine business context should be preserved and carried forward.

The same principle applies to workflows. Security teams don't need to force every development team into a single standardized process. "We have customers who use 20 different flavors of Jira," Hibbert said. "We can accommodate that. We're not asking them all to change the way they develop code, we're showing them where in their code to fix exposures, using a broader, business-aligned prioritization model that's explainable and defensible."

The Bottom Line

The tools have multiplied. The environments have expanded. The attack surface now spans infrastructure, cloud, code, APIs, identities, and AI systems. What hasn't kept pace, in many organizations, is the program-level thinking that ties all of it together.

Exposure management isn't a tool, it's a discipline — one that requires organizational alignment, a shared data foundation, and a shift in how security teams measure their own success. Not by how many vulnerabilities were closed, but by how much risk was actually removed from the business.

"It really wasn't about the tools," Hibbert reflected. "It was about decision clarity and moving beyond the tools."

To learn more about Brinqa's approach to enterprise exposure management, schedule a free consult with a Brinqa Expert.

FAQs