Several cis_debian13.yml SCA checks appear to fail on seemingly correctly configured systems — could someone confirm?

[Toutunique]

Hi all,

While reviewing SCA results on a few Debian 13 (Trixie) hosts running the Wazuh agent (apt 4.x/stable channel), we ran into a number of checks in ruleset/sca/debian/cis_debian13.yml that report "Failed" even though the underlying system configuration looks correct to us. Before assuming our systems are wrong, we'd like to ask whether these are known issues or whether we're missing something.

We're listing everything we found in one place since they're all in the same ruleset file. Happy to split them if they appear issues

1. ID 33044 — "Ensure access to bootloader config is configured"

Rule:

c:stat -L "%n %a %u %U %g %G" /boot/grub/grub.cfg -> r:0 root 0 root && r:600

Running this stat command literally (without -c) does not produce the format string output — stat treats "%n %a %u %U %g %G" as a second filename argument, errors with "No such file or directory", and falls back to its default verbose output instead. Adding -c produces the expected 0 root 0 root / 600 substrings on a host where the file is genuinely 600 root:root.

Is -c simply missing from the command?

2. ID 33188 — "Ensure pam_pwquality module is enabled"

Rule:

f:/etc/pam.d/common-password -> r:password\s*\trequisite\s\tpam_pwquality.so\s\t*retry=(d+)

(d+) matches one or more literal letters "d" — it looks like the backslash for \d was dropped. Our common-password has password requisite pam_pwquality.so retry=3, which never contains the literal letter "d" after retry=, so the check can't pass regardless of configuration.

3. ID 33211 — "Ensure strong password hashing algorithm is configured"

Rule:

f:/etc/login.defs -> r:ENCRYPT_METHOD\s*\tSHA512 | r:ENCRYPT_METHOD\s\t*YESCRYPT

This is a single regex with a | alternation inside it, not two separate r: clauses. The right-hand side of the | still contains the literal text r: as part of the pattern (r:ENCRYPT_METHOD\s*\t*YESCRYPT), so it's actually searching for the literal substring r:ENCRYPT_METHOD...YESCRYPT, which never appears in login.defs. The SHA512 branch (left of |) has no stray r: and would work correctly. So this only manifests for hosts using ENCRYPT_METHOD YESCRYPT (which the check's own remediation text recommends as an acceptable alternative to SHA512) — which may be why it hasn't been caught: a SHA512-configured host passes fine, masking the bug.

4. ID 33216 — "Ensure group root is the only GID 0 group"

Rule:

f:/etc/group -> r:^root:x:0:0

Standard /etc/group format is name:password:GID:member-list. A normal, correct root entry is root:x:0: (empty member list) — there's no reason for a second 0 after the third colon unless a member literally named 0 exists. This looks like it may have been copied from a different check pattern.

5. ID 33217 — "Ensure root account access is controlled"

Rule:

c:passwd -S root -> r:Password is status: P | r:Password is status: L

On Debian (shadow-utils), passwd -S root outputs short fields, e.g.:

root P 2026-05-25 0 99999 7 -1

There's no "Password is status: ..." prose anywhere in the output. This pattern doesn't seem to match shadow-utils' actual format at all, on any configuration.

6. IDs 33257, 33270, 33271 — shared file-matching bug

All three checks (and possibly others) use this sub-rule to find rule files in /etc/audit/rules.d/:

d:/etc/audit/rules.d -> r:.+.rules$

.+ matches one-or-more literal dots, followed by an unescaped . (any character), followed by rules$. A normal filename like hardening.rules or audit.rules has only one dot before "rules" and never matches:

echo "hardening.rules" | grep -E '.+.rules$' # no output

This means the directory-content checks for these rules can never find any file to inspect, regardless of what's actually configured.

Additionally for 33270 specifically: the rule also expects path=/usr/bin/usermod, but on Debian usermod lives at /usr/sbin/usermod only.

And for 33271 specifically: the rule requires an audit rule referencing the syscalls create_module and query_module together with init_module/delete_module/finit_module. create_module and query_module were removed from the Linux kernel long ago and can no longer be referenced in an audit rule on any current kernel — so a rule satisfying this exact requirement can't exist on a modern system.

33257 also has what looks like a leftover copy/paste error, independent of the bug above. Its full rules: block is:

yamlrules:

• "d:/etc/audit/rules.d"
• 'd:/etc/audit/rules.d -> r:.+.rules$'
• 'd:/etc/audit/rules.d -> r:.+.rules$ -> r:^-w && r:/etc/networks && r:-p wa && r:-k system-locale|key=system-locale'
• "c:auditctl -l -> r:^-w && r:/etc/networks && r:-p wa && r:-k system-locale|key=system-locale"
• 'd:/etc/audit/rules.d -> r:.+.rules$ -> r:^-w && r:/etc/netplan && r:-p wa && r:-k system-locale|key=system-locale'
• 'c:auditctl -l -> r:.+.rules$ -> r:^-w && r:/etc/netplan && r:-p wa && r:-k system-locale|key=system-locale'
• 'c:auditctl -l -> r:^-w && r:/etc/networks && r:-p wa && r:-k system-locale|key=system-locale"s && r:-p wa && r:-k system-locale|key=system-locale'

Two things stand out here: the 4th and 7th entries both check the exact same thing (auditctl -l for /etc/networks) — the 7th appears to be a broken duplicate of the 4th, with a stray "s && r:-p wa && r:-k system-locale|key=system-locale fragment tacked onto the end that looks like a partial, unintentionally duplicated edit. Separately, the 6th entry uses a c: (command) rule with a directory-style double-arrow (-> r:.+.rules$ ->) — per the documented SCA syntax, c: rules take a single ->, so this doesn't look like valid syntax for a command check at all.

7. ID 33300 — "Ensure accounts in /etc/passwd use shadowed passwords"

Rule:

not f:/etc/passwd -> r:^\w+:x:

As far as we can tell, the not here inverts the overall match result. r:^\w+:x: matches a correctly shadowed account line (username:x:...). So: if a properly shadowed line exists, the inner match is true, and not flips it to a failing result. If no line matches (e.g. a password hash is exposed directly in /etc/passwd, which is the actually insecure state), the inner match is false, and not flips it to a passing result. That's the opposite of the intended behavior — a fully shadowed, correctly configured system fails, while an insecure one would pass.

For context: this is on Debian 13 (Trixie), Wazuh agent version 4.14.5-1, default cis_debian13.yml policy, unmodified apart from our own skip list for unrelated entries.

Could someone confirm whether these are genuine issues, or let us know if we're misreading the rule syntax somewhere? Happy to open a PR for some of these (the regex fixes look straightforward) if that's useful — just wanted to sanity-check first given how many we found in one pass.

Thanks!

[Nikhil201Gurjar]

Hi @Toutunique

I appreciate your efforts in investigating the issue in depth. Let me review the details you've shared and attempt to replicate the behaviour in my test environment. I'll share my findings with you once I complete my investigation.

Best regards,
Nikhil

[Nikhil201Gurjar]

Hi @Toutunique

I replicated the reported scenario in my local lab using an identical environment and can confirm that the majority of the SCA checks you flagged — specifically those related to regular expression issues — are valid. I verified each check individually using the corresponding CLI commands, and after applying the appropriate remediation steps, all affected checks passed successfully and were reflected as Passed on the SCA dashboard for the agent.

The one exception is SCA Check ID: 33271. During my validation, I confirmed that the create_module and query_module syscalls remain available by default in the test environment, which means the underlying logic of this check is sound. That said, I do agree that some of the regular expressions within the policy could be refined to improve both compatibility and accuracy.
Please refer to the attached document below, which includes full validation details, CLI verification steps, and the recommended remediation syntax updates for each affected SCA check:

CIS_Debian13_SCA_Validation.pdf

Additionally, I'd like to make a general recommendation for issue reports: whenever you identify a potential problem with an SCA check, please include both the reproduction steps and the proposed corrected syntax alongside your report. This allows us to reproduce and validate the behaviour more efficiently on our end, and it also serves as a strong foundation should you choose to submit a Pull Request (PR) to improve the SCA policy.

Hope this information is helpful for you. Please feel free to let us know if you have further queries or questions here.

Best regards,
Nikhil

[Toutunique]

Hi Nikhil,

Thanks for the thorough reproduction and for sharing the validation PDF — the corrected rules and reproduction steps for all 9 checks are exactly what's needed to move this into a PR.

On 33271: no real disagreement. The create_module/query_module absence I flagged isn't an x86 Debian 13 issue — it's specific to an ARM64 host in my environment, where those syscalls genuinely don't exist in the kernel. Your test on a standard x86_64 VM correctly shows them present, so the check logic itself is sound there. Might be worth a documentation note that this check can't pass on ARM64 platforms, but that's a platform caveat rather than a regex bug, so I'll leave it out of the PR.

For the other 8, I'd like to open a PR using the corrected syntax from your document. Let me know if that works for you, and if there's a preferred target branch or PR template for ruleset changes.

Thanks again for taking the time to dig into this.

Kind regards, Tout

[Nikhil201Gurjar]

Hi Tout,

Sure, you can use the attached PDF as a reference when raising a Pull Request (PR) or creating an issue here:

Create Issue: https://github.com/wazuh/wazuh/issues/new?assignees=&labels=&projects=&template=default.md&title=

When creating the issue, I recommend including the following information to help the team reproduce and validate the behaviour efficiently:

• Environment (e.g., OS version, Wazuh version, SCA policy version)
• Current behaviour (existing condition and observed result)
• Expected behaviour (the expected SCA validation result)
• Steps to reproduce the issue
• Proposed corrected syntax or configuration, where applicable

Including these details will help the team reproduce the scenario more quickly and streamline the validation process for the proposed changes.

Regards

[Toutunique]

Thanks again for the validation. I've opened a PR with the corrected syntax for the 7 confirmed checks:

#37320

Kind regards,

Tout

[Johnng007]

@Toutunique
Thanks for taking time out to point out the issues.

Albeit some of the bugs you noted are correct, the bugs you mentioned affecting some IDs (IDs 33257, 33270, 33271) are false positives.

I believe the confusion comes from misinterpreting .+ this does not mean in literal dots . dot that would be \.+.

This is correct echo "hardening.rules" | grep -E '.+\.rules$' hence the file match pattern is correct.

Fixes will be available in the next release.

[Toutunique]

@Johnng007

Thanks for the feedback — I think the grep -E test doesn't reflect how SCA actually evaluates the pattern. SCA uses OS_Regex, where . matches a literal dot and \. matches any character — the inverse of grep's ERE (see docs: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html). So .+\.rules$ can't match audit.rules under OS_Regex. This was also confirmed empirically by @Nikhil201Gurjar's own test on a live 4.14.5 agent, where the check only passed after applying \.+\.rules$.

That said, the regex point only applies to one part of 33257 and 33270. Both checks had additional, unrelated bugs: 33270's path filter pointed to /usr/bin/usermod, which doesn't exist on Debian (correct path is /usr/sbin/usermod), and 33257 had a malformed duplicate rule line plus an invalid double-arrow chain on a c: rule. Those two issues stand regardless of the regex discussion.

Kind regards, Tout