By Olan Johnson, Principal Solutions Architect, Ocient National Security Solutions
Most of our writing on this platform so far has been about detection and investigation: dwell time, beaconing, and scale. That emphasis was deliberate, but it also risks leaving an impression we don’t want to leave, which is that we think of ourselves as a detection company. We don’t. This post is about the other half of the problem, and why the same architecture we’ve described elsewhere applies just as directly to it.
What the industry is starting to say about itself
A recent CSO Online piece by two veteran security leaders makes an interesting argument. Their view: cybersecurity has “veered too far” toward detection, and the investment data backs it up. After watching more than 500 companies come through the RSA Conference’s Innovation Sandbox startup competition over the last three years, they estimate that more than 70% of them are shipping detection tools rather than prevention tools (CSO Online). The practical result shows up on the SOC floor as alert fatigue: more tools flagging more things, without any of them reducing the structural risk that put the alert there in the first place.
The piece’s central claim is the one worth quoting directly: “The initial problem continues to come from the usual places: known vulnerabilities, stolen credentials or misconfigurations. In other words, detection reduces impact in the short term, but it does not reduce structural risk.” They point to IBM’s Cost of a Data Breach research as supporting evidence: faster identification and containment reliably lower the cost of a breach, but the average cost stays in the millions year after year, because detection does nothing to stop the initial compromise from happening (IBM). Verizon’s 2025 Data Breach Investigations Report backs the same point about root causes from the other direction: exploitation of vulnerabilities grew 34% year over year as an initial access vector, reaching 20% of breaches, with edge-device and VPN exploitation alone jumping from 3% to 22% of that category in a single year (Verizon 2025 DBIR). The failure occurs before detection even begins: a known vulnerability that stayed exploitable for too long. We think the authors are right, and the article points to something we haven’t said clearly enough in our own writing so far: prevention has exactly the same data problem detection has, and it’s been just as underserved by the current generation of tooling.
Where the data problem shows up in prevention
Reducing structural risk (patching known vulnerabilities, retiring stale credentials, fixing misconfigurations before they’re exploited, understanding what’s actually exposed) sounds like an operations problem more than an analytics one. In practice, at the scale of a large enterprise, it is an analytics problem, and it has the same shape as everything else we’ve written about on this platform.
Vulnerability management requires joining four data sources that usually don’t live together. Knowing which of tens of thousands of scanner-reported vulnerabilities actually matter requires joining vulnerability scan results against asset inventory (what is this system, how critical is it), network topology (is it actually reachable from somewhere an attacker could start), and patch history (has this been remediated before, how long does it typically take this team to close a finding like this). Most organizations run these four things in separate systems with separate retention schedules, and reconciling them into one prioritized risk view happens manually, occasionally — usually right before an audit. This is exactly why prioritizing a scanner’s output can take days instead of minutes. The result is what security teams already know and complain about constantly: a vulnerability backlog nobody fully trusts, because nobody can see the whole picture at once.
Credential exposure is a continuous correlation problem, not a point-in-time check. Leaked-credential feeds arrive constantly. An organization’s actual population of employee and service-account credentials changes constantly too: onboarding, offboarding, password rotations, service accounts nobody remembers creating. Checking a leaked-credential feed against a snapshot of the directory once a quarter catches almost nothing; checking it continuously, against full historical identity and authentication data, catches exposure close to when it happens. That is a retention and interactive-query problem before it is anything else — the same shape as network flow, just on identity data.
Misconfiguration drift is a baseline problem. A misconfigured cloud storage bucket, an overly permissive firewall rule, an identity role with more access than it should have. These often don’t arrive misconfigured. They drift there, one small change at a time, across months. Catching that requires a long enough history of configuration state to know what “normal” actually looked like before the drift started, not just what today’s snapshot looks like against a policy checklist.
Attack surface management is only as good as how much history it’s allowed to consider. What an organization exposes to the internet changes constantly: new subdomains, forgotten test environments, third-party integrations nobody tracked centrally. A quarterly external scan is a snapshot of a moving target. Understanding the actual trend (is the exposed surface growing, where, and why) requires the scan history to be retained and queryable at full resolution over time, not just the latest pass.
Why this is the same platform argument, not a different one
Look back at what each of those four examples actually needs: multiple large, differently-shaped datasets joined together, retained at full resolution for long enough that drift and patterns become visible instead of getting lost as noise, queried interactively enough that a security or IT team can iterate on the question rather than wait for a scheduled report, on infrastructure the organization controls given how sensitive an unpatched-vulnerability inventory or a credential-exposure map actually is. We didn’t design OcientAIQ for vulnerability management or exposure management specifically. We designed a platform that solves this shape of problem, and detection turned out to be the first and most acute place large organizations felt the pain. But it does not have to be the only place.
This matters more, not less, as the threat side of the equation gets faster. The same piece from CSO Online points out that AI is lowering the barrier to attack automation and phishing at scale and raising the prospect of frontier models surfacing previously unknown vulnerability chains faster than defenders can track them. If that’s the trajectory, the defensive side needs its exposure picture to be at least as current and as complete as the offensive side’s, which means the same real-time, full-history, joined-across-everything analytics we’ve argued for on the detection side has to exist on the prevention side too, at the same scale and the same speed.
What “structural risk” actually means for a platform, not just a mission statement
The honest version of this argument is that OcientAIQ doesn’t reduce structural risk by itself. Patching a vulnerability, rotating a credential, and fixing a misconfiguration are actions a security or IT team takes, not something a query returns. What we can honestly claim is narrower but still significant: an organization cannot systematically reduce structural risk at enterprise scale without first being able to see it clearly, continuously, and completely, across vulnerability, identity, configuration, and exposure data that usually lives in separate systems with separate retention policies. That visibility is the analytics problem, and it’s the one we built the OcientAIQ Unified Data Platform to solve. Whether the mission at the other end of the query is “did an attacker touch this” or “is this exposed and for how long has it been exposed,” the requirement underneath is the same: full-resolution data, joined across sources, retained long enough to see the pattern, and queryable fast enough to act on it.