# Prime Detect puts Sigma rule matching on the Kafka stream, before the SIEM

> DetectFlow, now renamed Prime Detect, is a SOC Prime product that applies Sigma rules to events as they pass through Kafka, so filtering and enrichment happen before ingestion rather than in the SIEM. The repository holds the documentation and Kubernetes configuration files, while the backend, UI, match node and schema parser live in separate repositories.

**socprime/detectflow-main** — Detection intelligence turbocharged with Al.

- Repository: https://github.com/socprime/detectflow-main
- Website: https://primedetect.live
- Stars: 547 · Forks: 79
- Language: Unknown
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/socprime-detectflow-main

## This repository holds the documentation, not the code

The first thing to understand is what sits in this repository. The top-level entries are FULL_DEPLOYMENT.md, GETTING_STARTED.md, LICENSE, README.md, a detectflow_kubernetes_config_files directory and a static directory holding images. There is no source code here. The README explains that Prime Detect consists of several projects, each in a separate repository, and lists them: the Prime Detect Backend, the Prime Detect UI, the Prime Detect MatchNode, the Prime Detect Schema Parser and a one-click local deployment project. The reader is told to consult each project for more details. So this repository is the landing page for the product, the place where the deployment steps and the Kubernetes manifests live, and the entry point for the licence terms. The product name changed underneath it too. The README opens by saying DetectFlow is being renamed to Prime Detect, with the new name to be reflected across all resources and assets in the next release, and the repository name still carries the old one. The project has no GitHub releases, and the last push to it was on 2026-08-20.

## The architectural bet: match rules before the data lands

The pitch in the README is that the product turns daily SIEM work into detection orchestration across data pipelines, AIDR, EDR, data lake and SIEM. The mechanism behind that claim is placement. Prime Detect consumes events from Kafka topics, applies Sigma rules to the stream, and tags and enriches events in flight, before SIEM ingestion. The README lists the claimed results in a block of bullet points: sub-second mean time to detect at 0.005 to 0.01 seconds against 15 minutes or more for a SIEM, tens of thousands of Sigma rules applied on streaming events, no changes required to the SIEM because it works with existing ingestion architecture, and scaling with your infrastructure without vendor-imposed caps. It also states the result as 10x rule capacity on existing infrastructure. Those are the vendor's own figures rather than measurements you can verify from the repository, and the README gives no benchmark methodology, so treat them as claims. The design assumption is worth taking seriously on its own terms. If the SIEM is where rules are evaluated today, then every rule you write is bounded by what the SIEM can ingest and correlate. Moving evaluation upstream of ingestion changes that boundary, and the cost is that you now own a stream processing pipeline that the SIEM team did not have to run.

## What ships now and what is still in progress

The README splits the feature set into two lists, and the split is the honest assessment of maturity. In the current release there is a real-time dashboard for live visualisation of pipeline performance and metrics, pipeline management to create, configure and monitor Flink-based ETL pipelines, log source configuration for parsing scripts and field mappings, rule management for Sigma rules from cloud sources such as the SOC Prime Platform or the SigmaHQ GitHub repository as well as local repositories, filter configuration for pre-filters to reduce false positives, topic synchronisation to discover and manage Kafka topics, and hot reload support so rules, filters and parsers update without a pipeline restart. In progress are the integrations with SIEMs, EDRs and data lakes, naming Splunk, Microsoft Sentinel, Elasticsearch and OpenSearch, the integration with the LLM Firewall AIDR Bastion, detection rules staging, and AI-powered data schema validation and remapping. For a buyer, the second list matters as much as the first. The specific integrations to the SIEM products most detection teams already run are listed as forthcoming.

## Infrastructure requirements and the two deployment paths

The technology stack is Apache Kafka 3.8 or later, Kubernetes 1.28 or later, PostgreSQL 14 or later, and Apache Flink 1.13 or later, which the README notes can be deployed together with Prime Detect. The standard deployment needs internal access to the deployed resources, network connectivity between them, and a Kubernetes cluster with at least three worker nodes of 8 vCPUs and 32 GiB RAM each. Outbound internet access is allowed to *.socprime.com for API access to the SOC Prime Platform to synchronise detections, which is optional and needs an API key, and to *.github.com for pulling open-source detections using the GitHub integration with public repositories including SigmaHQ, Microsoft, Splunk and Elastic, also optional. The resource arithmetic is spelled out per component: the User Interface Node, the admin panel that controls event matching processes, needs at least 2 CPUs and 4 GB RAM, the Task Manager Node, which controls the operation of the pipelines, needs at least 1 CPU and 4 GB RAM, and the Match Node, which matches detection rules to Kafka topic events, is a pipeline you create as many of as you need, so the cluster size follows from the number of pipelines you plan to run.

## Minikube evaluation path and the one-click deployment

For evaluation and testing, or where a full cluster is not available, there is a lightweight path on Minikube on a single machine. The prerequisites are macOS with Homebrew, Docker Desktop installed and running with at least 8 GB of memory allocated in its Resources settings, at least 4 CPU cores, and at least 40 GB of disk space, plus the same optional outbound access to *.socprime.com and *.github.com. The deployment section names two options. The one-click deployment sets up the entire ecosystem locally with Docker and Kubernetes through Minikube, with macOS and Docker Desktop as the only prerequisites, and its details live in the separate one-click local deployment repository. The full deployment covers the core components as separate steps and requires an existing Kubernetes instance, with the procedure in FULL_DEPLOYMENT.md. The Minikube route is the one to take first. It exists so that an evaluation does not need a cluster sized for production, and the honest observation is that a Flink and Kafka pipeline on a laptop is a different exercise from the same pipeline across three worker nodes.

## Licensing, alternatives and where this does not fit

The licence is worth reading carefully and it is not a standard open source grant. The README states that the software is made available under a dual licensing model, the European Union Public License version 1.2 and a SOC Prime Commercial License, and that depending on your intended use you must choose one of the two, with details in the LICENSE file. GitHub records the licence identifier as one it cannot classify. The practical point is that the EUPL is a copyleft licence with strong reciprocal obligations, and the alternative is a commercial licence with its own terms, so the choice is not a formality and a commercial deployment should be reviewed before it is assumed to be free. As for alternatives, the honest comparison is with doing nothing and with building your own. Doing nothing means rules keep being evaluated in the SIEM, with the throughput ceiling that implies. Building your own means a Flink job that reads Kafka topics, compiles Sigma rules and emits tagged events, which is a well-understood exercise that several open source streaming projects already do, and the difference is that you would own the rule synchronisation, the schema validation and the dashboard that the product ships as features. Where this does not fit is the case where you have no Kafka, no Kubernetes and no appetite for either, since the detection logic lives upstream of the SIEM by design. It also does not fit if you need those SIEM integrations on day one, and it does not fit if you want a tool you can read, fork and host entirely yourself without a vendor relationship.

## Conclusion

Adopt Prime Detect if your SIEM is the bottleneck for detection throughput and you already run Kafka, since the tool's value is doing rule matching upstream of ingestion. Skip it if you have no Kafka or Kubernetes, since both are hard requirements in the standard path, and skip it if you need the SIEM integrations today, because those are listed as in progress. Before you commit, read the LICENSE file, because the product is dual licensed under the EUPL 1.2 and a SOC Prime commercial licence and you must choose one.

## FAQ

### What is Prime Detect, formerly DetectFlow?

It is a SOC Prime product for detection intelligence that applies Sigma rules to events on a Kafka stream and tags and enriches them in flight, before SIEM ingestion. The README states that DetectFlow is being renamed to Prime Detect, with the new name to be reflected across all resources and assets in the next release.

### What infrastructure does Prime Detect require?

The standard path needs Apache Kafka 3.8 or later, Kubernetes 1.28 or later, PostgreSQL 14 or later and Apache Flink 1.13 or later, on a cluster with at least three worker nodes of 8 vCPUs and 32 GiB RAM each. A Minikube single-machine evaluation path needs macOS with Homebrew, Docker Desktop with 8 GB or more memory, 4 CPU cores and 40 GB of disk.

### Which SIEM and EDR integrations does Prime Detect support today?

The README lists integration with Splunk, Microsoft Sentinel, Elasticsearch and OpenSearch, plus LLM Firewall AIDR Bastion integration, detection rules staging and AI-powered schema validation, under features in progress rather than the current release. The current release covers the dashboard, pipeline management, log source configuration, rule management, filters, topic synchronisation and hot reload.

### How is Prime Detect licensed?

Under a dual licensing model of the European Union Public License version 1.2 and a SOC Prime Commercial License. The README states that depending on your intended use you must choose one of the two, with the details in the LICENSE file.

## Sources

- [Issues](https://github.com/socprime/detectflow-main/issues)
- [Project website](https://primedetect.live)
- [README](https://github.com/socprime/detectflow-main/blob/main/README.md)
- [socprime/detectflow-main on GitHub](https://github.com/socprime/detectflow-main)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/socprime-detectflow-main