The problem with single-vendor consolidation
The dominant pitch in security for a decade has been consolidation: buy one vendor's platform and retire the rest. It is appealing on a slide, but in practice most enterprises run a heterogeneous stack for good reasons — an EDR they trust, a cloud security tool their engineers chose, scanners tied to compliance mandates, and firewalls with years of tuned policy. Ripping that out is expensive, slow, and risky, and it re-locks the organisation into a new single vendor.
Meanwhile the actual pain is rarely 'too many tools' — it is that the tools do not talk to each other. Each has its own console, its own asset list, its own severity scale and its own idea of what an 'alert' is. Analysts swivel-chair between them, exposure data never meets detection data, and no one can answer a simple board question like 'which of our exploitable weaknesses could actually reach a crown-jewel system?'
What 'vendor-neutral' actually means
A vendor-neutral platform inverts the model. Instead of being another tool that wants to own the data, it is a control layer that connects to whatever you already run and treats their outputs as inputs. Certified connectors pull from each source over its API — usually OAuth, with credentials held in an encrypted vault — and write into a shared schema.
The critical piece is normalisation. An endpoint alert from one vendor, a cloud misconfiguration from another, and a CVE from a scanner have nothing in common until they are mapped onto a common model of assets, identities, events and findings. Aligning that model to an open standard such as OCSF means a detection rule or an exposure query is written once and runs across every connected source — and swapping a tool later does not break the analytics built on top.
Provenance: knowing what is real
A neutral platform ingests data of very different maturity — live production telemetry from one connector, a sample export from another, simulated data during a proof of concept. Conflating them is dangerous. The disciplined approach is to label every ingested record with its provenance (live, sample or simulated) and surface that label in the UI, so an analyst or auditor always knows whether a finding reflects real customer telemetry or demo data.
This provenance discipline is what makes a neutral platform trustworthy in a regulated environment: the same normalised record can carry both its source system and its data mode, so lineage is never ambiguous.
From telemetry to business risk
Once data is normalised, the higher-value layers become possible. Detections run over connector-fed events into SLA-tracked cases with context-aware scoring — an alert on a crown-jewel asset or a privileged identity is ranked above the same alert on a test box. An exposure graph ranks attack paths from internet-facing entry points to critical assets, weighted by real-world exploitability signals like CISA KEV and EPSS. And FAIR quantification turns all of that into annualised loss expectancy — cyber risk expressed in the same financial language as every other enterprise risk.
None of those layers care which vendor produced the underlying data. That is the point: the platform's intelligence compounds on top of the stack you already trust, and it keeps working as that stack evolves.
Where open-source fits
Vendor-neutrality also opens a low-cost path. A team without budget for premium EDR and SIEM can assemble telemetry from Wazuh and findings from open scanners like Nuclei, Trivy and Semgrep, feed them into the same normalised model, and get a real SOC and exposure programme without premium licensing. The platform does not care whether a finding came from a six-figure commercial scanner or an open-source one — it correlates and prioritises them the same way.
The lesson is that consolidation and choice are not opposites. The right architecture consolidates the intelligence — one model, one case queue, one risk picture — while leaving the choice of underlying tools open.