Is the classic ruleset/decoders/ruleset/rules PR process still active, or has it moved to the Engine?

[Pratik Dabhi]

Hi all,

I've built a new decoder and rule set for Sophos Firewall's Central Reporting Format syslog, which is the format current SFOS firmware emits. This is distinct from the older Device Standard Format already covered by 0510-sophos_fw_decoders.xml and 0705-sophos_fw_rules.xml.

I followed the existing contribution pattern: adding a new decoder/rule group to the vendor files along with a .ini test file, as described in ruleset/README.md.

Before opening the PR, I wanted to confirm the current contribution process, as it looks like the ruleset pipeline may be undergoing some changes:

• ruleset/decoders/ and ruleset/rules/ no longer exist on main; they were removed by the "Clear analysisd ruleset" commit in July 2025. They are still present on master, but that branch has not had a commit since April 2024.
• There are also several currently open PRs using the classic ruleset structure:
  • #36872 – new Check Point decoder, targeting main
  • #38216 – Palo Alto decoder/rules rewrite, targeting master
  • #38883 – rule compliance tags, targeting master

These have been open for roughly 1–3 months without reviews, comments, or CI runs, so I wanted to check before submitting another contribution through the same path.

Given the ongoing work on the Wazuh Engine, is the classic XML ruleset still the recommended target for a new vendor decoder/rule contribution like this? Or should new contributions now target the Engine's decoder format, another branch, or a different repository/workflow?

I'm happy to share the decoder, rules, and tests in the meantime if that would be useful.

Thanks!

[Awwal Ishiaku]

Hello Patrik,

Such PRs are usually merged to the branch of the next available release.

The master branch you are trying to merge to is obsolete and no longer used.

The next 4.x release that I'm aware of is 4.14.9.

To prevent conflicts and other potential issues with branch management, a member of the team  will review and add your commits to the correct branch.

However, the priority now is on developing 5.0.0 where the decoder and rule format is completely different. We are in beta 5 now and pushing hard to have GA in the coming weeks.

We'll review your PRs as soon as possible.

Thanks.

[Awwal Ishiaku]

You can test the beta 5 release by deploying with the documentation: https://documentation.wazuh.com/5.0-beta/index.html

Let us know if you discover any gaps. You can open an issue for this or ask in any of the community channels.

The rules and decoders for 5.0 are not managed in the Git repository.
We develop the content and publish them via the Wazuh CTI platform.

[Pratik Dabhi]

Hi Awwal,

Thanks for the clarification.

We will leave the current 4.x PR available for the team to review and move to the appropriate release branch.

We are also interested in testing the same integrations and detection use cases against Wazuh 5.0 Beta 5.

Our current work includes custom security monitoring for GitLab Community Edition, including authentication events, failed login detection, credential-spraying patterns, OAuth activity, and associated Wazuh dashboards. We are also working on additional integrations such as Sophos Firewall logging.

We will deploy Beta 5 and validate these use cases against the new architecture. If we identify parsing, detection, migration, or coverage gaps, we will document them with sanitized sample events and reproduction steps and raise issues as appropriate.

Since rules and decoders are now distributed through the Wazuh CTI platform in 5.0, is there a preferred process for community members to propose new detection content or integrations for inclusion in the CTI-managed content?

Regards,

Pratik

[Nguyen Xuan Dong]

Before counting coverage gaps on Beta 5, it is worth separating "the rule did not fire" from "no events ever reached the rule". We replayed 24 ATT&CK techniques against a default-config install and 3 alerted - that is our own claim, not reproduced outside our company. A default install also loads no audit rules, so auditd-sourced detections have nothing to match.

[Awwal Ishiaku]

Hi Nguyen, 
Note that we now separate regular events from findings (alerts).

All auditd events are logged to the events index which you can see under the discover tab. Only events with security context are then promoted to the findings index (alerts).

We don't load any auditd rules with the agent installation, so users have to configure those themselves.

However, we have rules and decoders to parse and match auditd events

Please share the ATT&CK techniques you simulated and the event logs generated from the simulation so we can investigate and develop the appropriate rules.

[Nguyen Xuan Dong]

Awwal - the technique list and the replay harness are public: https://github.com/xuxu298/siem-replay-24-techniques - each technique with the exact command used, and which 3 produced a finding on a default 4.x install.

Correction on my wording: you're right that auditd events reach the events index. What I measured was narrower - a default agent install ships no auditctl rules, so for the syscall-dependent techniques there were no auditd events to promote at all. The ruleset wasn't the gap.

For the logs, which is more useful to you: archives.json lines per technique, or the agent ossec.log plus the auditctl config I used?