Repositories are folders with detection rules. We encourage you to have rules with only one log source within a given Repository. This way, you ensure that a Repository is logsource-specific and all the rules it contains can be applied to a topic with logs from this source.

To view and manage your Repositories, go to Repositories. Here you can see:

The sidebar with the list of Repositories. Click on a Repository to see its content on the right
Rules in the Repository selected in the sidebar. All Repositories option is selected by default so that all available rules are displayed on the right

Repositories come in two types:

Local. For local management of detection content via the DetectFlow Admin Panel. Local Repositories only exist on the host and are not synced. E.g., you can use local Repositories in an air-gapped environment
Cloud. For the management of detection content pulled from a cloud platform. Cloud Repositories can be pulled from:
- The SOC Prime Platform (detection content is synchronized in both directions).
- Third-party open-source repositories on GitHub (detection content is only pulled to DetectFlow, no updates are pushed to the GitHub):
  - SigmaHQ
  - Splunk
  - Elastic
  - Microsoft Azure Sentinel

Note:

You cannot delete a Repository that's used in a Pipeline. To do it, first remove the Repository from all Pipelines, both enabled and disabled.

Local Repositories

To create a Local Repository:

Go to Repositories and click the plus icon.
In the modal that appears, select the Local tab, name your Repository and click Create Local Repository.
The new Repository appears in the Repositories sidebar. Click on the Repository to open it.
The new Repository is empty. Click on its name to open it and start adding rules.

There are two ways to add rules to a Repository:

Upload a set of rules, a folder, or an archive with rules (up to 5,000 rules).
1. Click the Upload or Upload Rules from File button.
2. In the modal that appears, drag and drop or select an archive, a folder, or multiple files with rules.
3. Click Upload.
Add an individual rule using the editor.
1. Click the Add Rule button.
2. On the page that appears, enter the rule's name and detection code, and then click Save.
3. The newly created rule is saved. You can find it in the Repository that was selected when you created the rule.

Cloud Repositories

SOC Prime Repositories

To synchronize custom Repositories on the SOC Prime Platform with DetectFlow, set up an integration with Threat Detection Marketplace. See the details here.

You can remove a SOC Prime Platform custom Repository from DetectFlow. To do this:

Select the Repository and click its settings icon.
In the menu, select Delete Repository.
Confirm the action

Note:
- You cannot delete a Repository that is used in a Pipeline. Remove the Repository from all the Pipelines first, and then delete it.

Also, you can turn off synchronization for a Repository. To do this:

Select the Repository and click its settings icon.
Click the Turn Sync Off option in the menu. Later, you can always turn it back on.

Third-Party GitHub Repositories

To pull content from third-party open-source repositories on GitHub, follow these steps:

On the Repositories page, click the plus icon.
In the modal that appears, go to the Third Party tab, use checkboxes to select Repositories you want to add, and click the Add button.
Turn on synchronization for each added Repository:
1. Click on its name
2. Click the settings icon
3. Click Turn Sync On in the menu that appears

You can always turn synchronization off or delete the Repository later.

Note that with the third-party GitHub repositories, you can only pull content to DetecFlow, while pushing the updates back is not supported.

Folders

Sigma rules are classified into folders based on their log source. Each rule is placed in a location in the folders based on its Sigma log source definition (the combination of product, category, and service).

The rules are organized into three main top-level folders: _product, _category, and _service.

Top Level Hierarchy

Rule placement is determined first by whether a product field in the rule is defined.

If the product field is defined, the rule is placed in the folder corresponding to the product value, for example: _product / aws.
If the product field is not defined but the category field is defined, the rule is placed in the folder corresponding to the category value, for example: _category / firewall
If neither product nor category fields are defined but the service field is defined, the rule is placed in the folder corresponding to the service value, for example: _service / apache

Second Level Hierarchy

After a rule is placed into a top-level folder (_product, _category, or _service), an additional level of classification is applied based on the remaining available Sigma log source fields.

Inside the _product folder

If a rule is placed in the _product folder (the product field is defined), it is further organized as follows:

If both product and category fields are defined, the rule is placed in the category folder corresponding to the category value, for example: _product / aws / _category / application. If the service field is also defined, no further classification is done and the rule remains in the folder corresponding to the category value.
If both product and service fields are defined, the rule is placed in the service folder corresponding to the service value, for example: _product / aws / _service / cloudtrail
If only the product field is defined (no category and no service), the rule is placed in the folder corresponding to the product value, for example: _product / aws.

Inside the _category folder

If a rule is placed in the _category folder (product is not defined but category is defined), it is further organized as follows:

If both category and service fields are defined, the rule is placed in the service folder corresponding to the service value, for example: _category / application / _service / audit
If only the category field is defined (service is not defined), the rule is placed in the folder corresponding to the category value, for example: _category / firewall

Inside the _service folder

If a rule is placed in the _service folder (product and category are not defined), no further categorization is applied:

The rule is placed in the folder corresponding to the service value, for example: _service / apache

Note: Classification of Sigma rules by log source is not applied to GitLab repositories. Sigma rules synchronized from GitLab are displayed according to the structure defined in the connected GitLab project. To learn how to synchronize Sigma rules with a GitLab project, go to this section.

Supported Detection Rules

Currently, DetectFlow supports Sigma detection rules for single-event matching. Correlation rules (aggregations, thresholds, temporal correlation) are not supported. Below are details on supported features.

Modifiers (field|modifier)

Modifiers are parsed from the detection key after the first |. Only one matching modifier per field is allowed (contains, startswith, or endswith), or none for exact match. The all modifier can be combined with any of these and does not count as a second "command"; it only switches list logic from OR to AND. The table below contains all supported modifiers.

Modifier	Effect
contains	Substring match (case-insensitive). Value can appear anywhere in the field.
startswith	Field value starts with one of the given strings (case-insensitive).
endswith	Field value ends with one of the given strings (case-insensitive).
Exact match (no modifier)	A field with no modifier is exact match (case-insensitive).
all	When combined with a command: all listed values must match (AND). Without all, any value matches (OR).

Examples:

CommandLine|contains: command line contains any of the values (OR).
CommandLine|contains|all: command line contains all of the values (AND).
Image|endswith: image path ends with any of the values.
TargetObject|startswith: target object starts with any of the values.

Unsupported modifiers (per Sigma Modifiers Appendix); any use causes the rule to be rejected:

Generic: exists, cased, neq
String: windash
Regular expression: re
Encoding: base64, base64offset, utf16, utf16le, utf16be, wide
Numeric: lt, lte, gt, gte
Time: minute, hour, day, week, month, year
IP: cidr
Specific: expand, fieldref

Condition expressions

The table below contains all supported condition expressions.

Pattern	Notes
condition: single name	e.g. `condition: selection` where `selection` is a detection identifier.
condition: A and B	Logical AND of condition names.
condition: A or B	Logical OR of condition names.
condition: not A	Negation of a condition (or group).
condition: all of selection*	All of the detection items matching the pattern (e.g. `selection_*`).
condition: 1 of selection*	At least one of the detection items matching the pattern.
condition: all of them	All detection items (except `condition` and keys starting with _).
condition: 1 of them	At least one detection item.
Nested ( … )	Parentheses for grouping (e.g. `(A and B) or C`).

Keywords search

A search-identifier whose value is a list of strings (keywords) is applied to the full log event and values are linked with OR (Sigma default behavior is case-insensitive matching).

Example:

detection:
  keywords:
    - 'keyword1'
    - 'keyword2'
  condition: keywords

The rule triggers if the full event contains keyword1 or keyword2 (case-insensitive).

Wildcards in values

Feature	Supported	Notes
Wildcards (exact match / no modifier)	Yes	Unescaped `*` (any characters) and `?` (one character) in values are converted to a full-string regex (`^...$`).
Escaped wildcards	Yes	`\*` and `\?` are treated as literal characters.
Wildcards with other modifiers	No	Wildcards are rejected when used with `contains`, `startswith`, or `endswith`.

Regex

Feature	Supported	Notes
Sigma `re` modifier	No	The Sigma `re` modifier (field\|re) is not supported. In Sigma, `re` allows values to be treated as PCRE regex and supports both single values and value lists; Detect Flow rejects any use of `re`. Use a field with no modifier and wildcards in the value for simple glob-style patterns instead.
Wildcard→regex (no modifier)	Yes	Unescaped `*`/`?` in values (field with no modifier) are converted to full-string regex (`^...$`).

Not Supported: Correlation rules, aggregations, and functions

The Sigma Correlation Rules Specification defines a separate format for meta-rules that correlate multiple events. Those rules use:

Correlation types: event_count, value_count, temporal, temporal_ordered, value_sum, value_avg, value_percentile
Aggregation conditions on counts or values: gt, gte, lt, lte, eq, neq (e.g. “≥ 100 events in 1h”)
Grouping (group-by), time window (timespan), related rules (rules), field aliases (aliases)

Detect Flow does not support Sigma Correlation rules. Only single-event Sigma (detection) rules are evaluated; no aggregations, count thresholds, or temporal correlation are applied.

Repositories and Rules