Security operations teams running Wazuh face a familiar problem: the platform generates alerts faster than analysts can meaningfully respond to them. Without additional tooling, analysts must manually correlate raw alert data against threat intelligence, assess severity, and decide on a response — repeatedly, under time pressure, for every significant event.
triaged sits between your Wazuh installation and your team's issue tracker, automating that triage layer. When Wazuh fires an alert, triaged's pipeline ingests it, enriches it with MITRE ATT&CK® context using an LLM, correlates it against active incidents, and opens a structured, actionable issue in GitLab — complete with a recommended response plan. Your analysts receive a prioritized, pre-contextualized workload instead of a raw event feed.
It deploys as a set of lightweight services alongside your existing Wazuh stack. Nothing about your current Wazuh configuration needs to change, and triaged does not sit in the detection path — it has no ability to suppress or alter alerts. Your existing workflows remain intact; triaged adds a layer on top of them.
Docker images are available on Docker Hub.
- NATS Server >= 2.6.0
- Anthropic API key
- GitLab instance (self-hosted or gitlab.com)
Note: Option A (Docker Compose) includes a NATS container with JetStream enabled. Option B (Manual Deployment) requires a separate NATS Server >= 2.6.0 installation with JetStream enabled (see the official installation docs).
The triaged server is developed and tested on Linux (x86_64 and aarch64). It should compile and run on macOS and other Unix-like systems, but these are not officially supported. For development and testing on Windows, Docker Desktop or WSL2 are suitable options; neither is recommended for production deployment.
Note: The triaged server exposes an HTTPS endpoint secured with mutual TLS. Network placement is at your organization's discretion; the mTLS requirement ensures that only clients presenting a valid certificate signed by your CA can connect.
Download and extract the release archive, then run the configuration installer:
tar -xzf triaged-server-v1.0.0-<arch>-unknown-linux-gnu.tar.gz
cd triaged-server-v1.0.0-<arch>-unknown-linux-gnu
sudo ./install.shThis creates the triaged system user and group, installs example configuration files to /etc/triaged/<service>/config.yaml, and sets up the TLS directory structure.
sudo vim /etc/triaged/envSet values for the following fields:
ANTHROPIC_API_KEY=<your-api-key>
GITLAB_ACCESS_TOKEN=<your-access-token>Working default values will be used for all commented/blank fields. These fields can be overridden to support custom deployment environments.
Two fields require manual configuration:
-
sink.project_idGitLab requires that issues are associated with a project. A GitLab project may be owned by an individual user or a group. A typical project name for triaged issues may be something like
triaged-alertsorsoc-alerts.Once you have created a GitLab project, you will be able to view the project's ID under Settings → General on the project's homepage.
Note: GitLab project IDs are numeric, however, for forward extensibility the
project_idtype expects a string, and must be enclosed in "quotes".
-
provider.*For production deployment, you may want to tweak the Anthropic API parameters to match your specific Anthropic setup. The default example configuration uses
claude-sonnet-4-5withmax_tokens: 20000andtemperature: 1.0. For more information on the Anthropic API, see the official docs.
sudo ./install.sh --with-pkiFor full details on PKI structure and production considerations, see the PKI docs.
To run the server in the background:
docker compose pull
docker compose up -d
# To view logs
docker compose logs -fFollow steps 1-2 from Option A.
sudo ./install.sh --with-pkiFor full details on PKI structure and production considerations, see the PKI docs.
sudo install -o root -g root -m 0755 \
alert-ingestd \
llm-gatewayd \
response-correlatord \
issue-sinkd \
/usr/local/bin/sudo install -o root -g root -m 0644 \
systemd/alert-ingestd.service \
systemd/llm-gatewayd.service \
systemd/response-correlatord.service \
systemd/issue-sinkd.service \
/etc/systemd/system/
sudo systemctl daemon-reloadsudo systemctl enable --now \
alert-ingestd.service \
llm-gatewayd.service \
response-correlatord.service \
issue-sinkd.service- Wazuh Manager >= 4.0
- A running triaged server deployment
triaged-clientd runs on the same host as the Wazuh manager, and therefore inherits Wazuh's platform requirements: 64-bit Linux only. Official release binaries are provided for x86_64 and aarch64.
The archive contains the following files required for installation:
triaged-clientd-v1.0.0-<arch>-unknown-linux-gnu.tar.gz
├── triaged-clientd # long-running service
├── triaged-hook # wazuh integration
├── config.example.yaml # example config template
├── triaged-clientd.service # systemd manifest
└── install.sh # installer script
tar -xzf triaged-clientd-v1.0.0-<arch>-unknown-linux-gnu.tar.gz
sudo ./install.shThe install script creates the triaged user and adds it to the wazuh group, installs triaged-hook to /var/ossec/integrations/ and triaged-clientd to /usr/local/bin/ and adds its systemd manifest. It initializes the /etc/triaged-clientd directory with a default config.yaml file and empty tls/ca and tls/client directories, setting the ownership and permissions for each file that it creates.
If you used the PKI helper scripts during server setup, copy the ca.pem file from the pki/ca/ directory of the extracted server release archive to the client host.
sudo install -o triaged -g triaged -m 0600 ca.pem /etc/triaged-clientd/tls/ca/To generate the client certificate and key, run pki/scripts/issue-client.sh from the extracted server release archive directory. This ensures the script can reach the existing CA files for signing. Once generated, copy the certificate and key to the client host.
sudo install -o triaged -g triaged -m 0600 /path/to/client.key /etc/triaged-clientd/tls/client/
sudo install -o triaged -g triaged -m 0600 /path/to/client.pem /etc/triaged-clientd/tls/client/Open /etc/triaged-clientd/config.yaml and set server.endpoint to your triaged server address, e.g. https://<triaged-server>/wazuh-events. All other fields have working defaults.
Note: By default, the PKI helper script generates a server certificate with the SAN
triaged.internal. For testing purposes, rather than modifying the script, the simplest approach is to simply add an entry to/etc/hostson your client machine mapping your server's IP address totriaged.internal. Yourserver.endpointwould then behttps://triaged.internal/wazuh-events.
sudo vim /var/ossec/etc/ossec.confOpen the Wazuh configuration file at the above path. Add the following block inside the <ossec_config> tags:
<integration>
<name>custom-triaged-hook</name>
<alert_format>json</alert_format>
</integration>Additional parameters can be added to this block which filter the types of events that Wazuh will forward to triaged. This step should not be necessary if you are filtering events using the triaged server rulesets.
For more information on installing and configuring custom wazuh-manager integrations, see the Wazuh server integration docs.
Start triaged-clientd:
sudo systemctl start triaged-clientd.serviceRestart wazuh-manager to load the integration. Note that restarting wazuh-manager will briefly interrupt active response processing on a live system.
sudo systemctl restart wazuh-manager.serviceBug reports and issues are welcome via GitHub Issues. Please include your platform, deployment method, and relevant log output where applicable.
triaged is source-available software. See LICENSE for terms.
Olen Systems 2026 · olensystems.com
