SURIQ
The single decision that shapes a security platform most is the one customers never see: what runs underneath the detection. Pick wrong and you spend the next five years writing log decoders instead of building the product people pay for. We made that call early at Suriq. We did not write our own detection engine. We built on Wazuh, and we have not regretted it once.
This post is the reasoning, not a sales pitch. If you are weighing build versus adopt for a detection core, the trade we made is worth borrowing.
What you are really choosing when you pick a detection backend
A detection engine is not one thing. It is a stack of unglamorous parts that each take years to get right: decoders that parse thousands of log formats into structured fields, a rule language expressive enough to catch real attacks without drowning analysts, a vulnerability feed that maps installed software to current CVEs, configuration scoring against hardening baselines, and an endpoint agent that has to behave identically on Windows, Linux, macOS, and a handful of Unix variants nobody admits to running anymore.
None of that is a feature a buyer will ever pay extra for. It is table stakes. A customer assumes your platform parses an sshd auth log correctly the same way they assume a car has brakes. Spend two years building it and you have shipped nothing a competitor cannot also claim. That is the trap of writing your own engine: enormous cost, zero differentiation, and a maintenance bill that never stops, because new CVEs land every day and log formats drift under you.
Why Wazuh specifically
Wazuh is an open source platform that unifies XDR and SIEM in one engine, and it is the most widely adopted one in that category. Wazuh reports more than 15 million downloads a year and runs in thousands of organizations, from small teams to large enterprises. That adoption matters for a reason that has nothing to do with marketing: a detection ruleset is only as good as the number of environments that have stress-tested it. Millions of deployments means the rules and decoders have already met the edge cases our customers will hit next week.
The capability set is the part we would have spent a decade rebuilding. Out of the box, Wazuh does rule-based log analysis through decoders, file integrity monitoring, vulnerability detection by correlating installed packages against CVE data, security configuration assessment against CIS benchmarks, and MITRE ATT&CK tagging on detections. Its architecture is three server components and a single universal agent: a manager that analyzes events, an indexer that stores and searches them, a dashboard, and the agent on each host. That design scales horizontally, which is exactly what a multi-tenant platform needs.
Then there is the part that does not show up on a feature grid. Because Wazuh is open source, the rules that judge our customers' environments are readable. Anyone can audit why a detection fired. A closed SIEM is a black box that bills you for the privilege of trusting it. We would rather build on something a customer can inspect down to the rule ID.
The economics nobody puts on the pricing page
Most proprietary SIEMs charge by data volume. The more you log, the more you pay. Sit with that incentive for a second: the pricing model rewards you for collecting less security data, which is the exact opposite of what good detection requires. Teams routinely drop log sources to stay under budget, then get breached through the gap they stopped watching.
An open detection core breaks that link. We are not paying a per-gigabyte tax to the engine vendor, so we do not pass one to customers for the act of being visible. You should be able to log the thing that matters without a finance conversation. That is a direct consequence of the backend choice, and it is one of the strongest arguments for adopting open infrastructure instead of renting closed infrastructure.
What Wazuh is not, and where Suriq starts
Here is the honest part. Raw Wazuh is a brilliant engine and a hard thing to live with. Out of the box it is a firehose of cryptic alerts, dense rule IDs, and a multi-component stack somebody has to deploy, upgrade, and keep tuned. It also watches your hosts but not the public surface an attacker actually probes first. Most teams that adopt it end up babysitting it at 3am. The engine being excellent does not make it a finished product.
That gap is the whole reason Suriq exists. We run the Wazuh core as a managed service so no one on your side patches the indexer at midnight. On top of it we built the operations layer: an alert-to-incident workflow with dedup and a full audit trail, an AI assistant that translates a dense detection into plain English and suggests how to tune the noise down, external surface monitoring that Wazuh does not do at all (BGP routes validated against RPKI, DNS and WHOIS drift, certificate expiry), and infrastructure monitoring that fails your DNS over to standby automatically when a host drops.
The line we hold is on autonomy, and it is worth stating plainly because the market lies about it constantly. Today our AI advises, it never acts. Response actions, such as restarting an agent or suppressing a noisy rule, are taken by your team and recorded against the person who took them. The one exception is DNS failover, which runs on its own because seconds matter when a host goes dark, and it reverts the moment the host recovers. Everything else is human-in-the-loop by design. We will not pretend the platform quarantines endpoints or patches packages on its own, because right now it does not, and you should not trust any vendor who says theirs does without showing you the code path.
Now the honest part about tomorrow, because where we are going matters as much as where we are. We are building an autopilot mode, a version of Suriq where the AI can take the next step itself instead of only suggesting it. The whole thing rides on the leash. Autopilot will act only inside guardrails you set: which actions it is allowed to take, on which hosts, and the exact line where it has to stop and ask a person first. Every move it makes stays logged and attributable, the same as a manual one, and you can switch it off completely whenever you want. We would rather ship this a quarter late than ship an AI that wanders outside its lane. When it lands, it will be because we can show you precisely what it is allowed to do, not because a demo looked slick. That is the bar, and we are holding ourselves to it.
What this means if you are making the same call
The pattern generalizes past us. For any layer that is mature, widely deployed, and not your actual product, adopting beats building. Detection is mature. Wazuh is widely deployed. Our product was never the engine; it was making the engine livable for a team that has a business to run. So we put our years into the workflow, the interpretation, the external eyes, and the recovery reflexes, and we let a proven engine do detection.
The same instinct shows up across our writing. When we covered the auth-stack blind spot behind the Velvet Ant intrusions, the lesson was that detection has to reach the login layer, which is precisely where Wazuh file integrity monitoring earns its place. When we wrote about how patching the Ivanti Sentry gateway still left a breach to hunt, the point was that an engine you can query after the fact is the difference between cleanup and guesswork.
The engine is Wazuh. The operations layer is ours. That split is not a compromise, it is the architecture we would choose again on day one.