Feature/agent update#224
Conversation
📝 WalkthroughWalkthroughThis PR adds Dockerfile support for SCA ruleset management and introduces 17 new Security Configuration Assessment policy files covering multiple operating systems and applications (Apache, macOS, IIS, MongoDB, MySQL, NGINX, PostgreSQL, SLES, SQL Server, and web vulnerabilities) with comprehensive compliance checks. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Actionable comments posted: 8
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
🤖 Fix all issues with AI agents
In @sca/cis_apache_24.yml:
- Around line 366-380: The rule string under id 10020 has a duplicated logical
operator ("&& &&") causing a syntax error; update the rules entry to remove the
extra "&&" so the expression reads something like "!r:^# && r:timeout|Timeout &&
n:\\s+(\\d+) compare <= 10" (i.e., keep the negation check for commented lines,
the presence check for timeout/Timeout, and the numeric capture/compare) so the
parser can evaluate the rule correctly.
In @sca/cis_apple_macOS_11.1.yml:
- Around line 879-890: The regex in the rules entry for id 18055 contains an
extra leading "S" ("r:^SAuthenticated Root status: enabled") which will never
match the actual csrutil output; update the rule string to remove the stray "S"
and use the correct pattern (e.g., "r:^Authenticated Root status: enabled" or a
more permissive pattern like "Authenticated Root status: enabled") so the check
matches the real command output from /usr/bin/csrutil authenticated-root status.
- Around line 301-312: The check for id 18019 ("Disable File Sharing") uses
condition: none which makes the rule pass only when the rule does NOT match, but
the rule 'c:sh -c "launchctl print-disabled system | grep -c
''\"com.apple.smbd\" => true''" -> 1' matches when SMB is correctly disabled;
fix by either changing condition: none to condition: any (so a matching rule
means pass) or invert the rule to expect zero (e.g. change the rule to check for
-> 0 instead of -> 1) so semantics align; update the rule or the condition
accordingly (referencing the exact rule string and the condition: none in this
entry).
In @sca/cis_mongodb_36.yml:
- Around line 82-84: One of the YAML rule command strings has mismatched quoting
causing a parse error: the line containing 'c:sh -c "cat /etc/mongod.conf | grep
\\-A12 "ssl:\"" -> r:clusterFile' should match the quoting style used on the
other two rules; fix it by escaping the inner double quotes around ssl: (i.e.,
use \"ssl:\") so the command becomes consistent with the 'r:PEMKeyFile' and
'r:CAFile' entries.
In @sca/cis_nginx_1.yml:
- Around line 227-258: The checks for id 23011 (keepalive_timeout) and id 23012
(send_timeout) currently use condition: any and a rule that treats a missing
directive as passing; change each check to require the directive explicitly and
validate its numeric range by setting condition: all (or removing the rule that
allows empty) and replace the rules so the first rule ensures the directive is
present (e.g., grep for the directive name must match) and the second rule
enforces r:^\s*\t*keepalive_timeout\s+(\d+) compare <= 10 &&
r:^\s*\t*keepalive_timeout\s+(\d+) compare > 0 (and similarly for send_timeout)
so the check only passes when the directive exists and its value is >0 and ≤10.
In @sca/cis_postgre-sql-13.yml:
- Around line 759-826: The rule is checking the wrong setting and has a typo:
update the command string that currently calls SHOW log_disconnections to
instead call SHOW log_line_prefix (change the rule that contains c:psql -U $user
-h $host $db -c "SHOW log_disconnections"), and fix the expected regex from
r:\sdll to r:\sddl so it matches the remediation/control which sets
log_statement='ddl'.
🟠 Major comments (37)
sca/cis_mysql5-6_community.yml-99-111 (1)
99-111: Revisit “skip-grant-tables” check logic (requiring= FALSEis brittle and may never be set explicitly).If
skip-grant-tablesis absent (normal case), this should pass, butcondition: all+ grep forskip-grant-tables = FALSEwill fail. Consider switching tocondition: noneand flagging presence ofskip-grant-tables(any value).sca/cis_apple_macOS_10.14.yml-394-405 (1)
394-405: Typo breaks Power Nap audit (pwernap→powernap).Proposed diff
- - 'c:pmset -g -> n:pwernap\s*\t*(\d) compare == 0' + - 'c:pmset -g -> n:powernap\s*\t*(\d) compare == 0'sca/cis_sles12_linux.yml-700-715 (1)
700-715: Check 3.2.5 is validating the wrong sysctl key (mismatch between title/description vs rules).The check is titled “Ensure broadcast ICMP requests are ignored” (which is
net.ipv4.icmp_echo_ignore_broadcasts), but the rules validatenet.ipv4.icmp_ignore_bogus_error_responses.Proposed diff
- id: 7545 title: "Ensure broadcast ICMP requests are ignored" @@ rules: - - 'c:sysctl net.ipv4.icmp_ignore_bogus_error_responses -> r:^net\.ipv4\.icmp_ignore_bogus_error_responses\s*=\s*1$' - - 'c:grep -Rh net\.ipv4\.icmp_ignore_bogus_error_responses /etc/sysctl.conf /etc/sysctl.d -> r:^net\.ipv4\.icmp_ignore_bogus_error_responses\s*=\s*1$' + - 'c:sysctl net.ipv4.icmp_echo_ignore_broadcasts -> r:^net\.ipv4\.icmp_echo_ignore_broadcasts\s*=\s*1$' + - 'c:grep -Rh net\.ipv4\.icmp_echo_ignore_broadcasts /etc/sysctl.conf /etc/sysctl.d -> r:^net\.ipv4\.icmp_echo_ignore_broadcasts\s*=\s*1$'sca/cis_apple_macOS_10.14.yml-178-189 (1)
178-189: Fix inverted “Disable Internet Sharing” logic (currently passes when sharing is enabled).Rule matches
Enabled = 1withcondition: all, which makes the check pass when Internet Sharing is ON. This should becondition: none(or matchEnabled = 0).Proposed diff
- id: 17013 title: "Disable Internet Sharing" @@ - condition: all + condition: none rules: - 'c:defaults read /Library/Preferences/SystemConfiguration/com.apple.nat -> r:Enabled\s*\t*=\s*\t*1'sca/cis_mysql5-6_community.yml-57-69 (1)
57-69: 10502 likely searches for the wrong pattern ($MYSQL_PWDvsMYSQL_PWD=).Grepping
MYSQL_PWDand then matching$MYSQL_PWDwill usually miss real exports likeMYSQL_PWD=secret/export MYSQL_PWD=secret.Proposed diff
- - "c:find /home -maxdepth 2 -type f -exec grep MYSQL_PWD {} + -> r:\\.profile|\\.bashrc|\\.bash_profile && r:$MYSQL_PWD" + - "c:find /home -maxdepth 2 -type f -exec grep -H MYSQL_PWD {} + -> r:\\.profile|\\.bashrc|\\.bash_profile && r:(^|\\s)(export\\s+)?MYSQL_PWD\\s*="sca/cis_apple_macOS_10.14.yml-202-215 (1)
202-215: Fix inverted “Disable Printer Sharing” logic (currently passes when sharing is enabled).Rule matches “System Printer Sharing: … Yes” with
condition: all. Should becondition: none(or matchNo).Proposed diff
- id: 17015 title: "Disable Printer Sharing" @@ - condition: all + condition: none rules: - 'c:sudo system_profiler SPPrintersDataType | grep -e Sharing -> r:System Printer Sharing:\s*\t*Yes'sca/cis_apple_macOS_10.14.yml-444-455 (1)
444-455: Fix TTL parsing and threshold (365 days should be>= 365, regex likely won’t capture correctly).Proposed diff
- - 'c:grep -i ttl /etc/asl/com.apple.install -> n:ttl[\w@-]+(\d+) compare > 365' + - 'c:grep -i ttl /etc/asl/com.apple.install -> n:ttl\s*=\s*(\d+)\s*$ compare >= 365'sca/cis_mysql5-6_community.yml-31-45 (1)
31-45: Fix SCA rule syntax for.mysql_history(missingr:and dot should be escaped).Proposed diff
rules: - - "d:/home -> ^.mysql_history$" - - "d:/root -> ^.mysql_history$" + - "d:/home -> r:^\\.mysql_history$" + - "d:/root -> r:^\\.mysql_history$"sca/cis_mysql5-6_community.yml-164-177 (1)
164-177: Fix malformedlog_binpath regex (current pattern looks invalid and won’t match real configs).Proposed diff
- - 'c:grep -Rh log_bin /etc/mysql/my.cnf /etc/mysql/mariadb.cnf /etc/mysql/conf.d /etc/mysql/mariadb.conf.d -> r:log_bin\s*\t*/\+$|log_bin\s*\t*/\+var/\*$|log_bin\s*\t*/\+usr/\*$' + - 'c:grep -Rh "^[[:space:]]*log_bin[[:space:]]*=" /etc/mysql/my.cnf /etc/mysql/mariadb.cnf /etc/mysql/conf.d /etc/mysql/mariadb.conf.d -> r:^[[:space:]]*log_bin[[:space:]]*=[[:space:]]*/($|var/|usr/)'sca/cis_sles12_linux.yml-205-218 (1)
205-218: Fix thelimits.confgrep regex (currently looks malformed and likely won’t match).
c:grep -Rh ^*[[:space:]]*hard...uses^*which is not a meaningful anchor in regex; it likely should be matching a literal*(all users) at line start.Proposed diff
- - 'c:grep -Rh ^*[[:space:]]*hard[[:space:]][[:space:]]*core[[:space:]][[:space:]]* /etc/security/limits.conf /etc/security/limits.d -> r:\s*\t*0$' + - 'c:grep -Rh "^[[:space:]]*\\*[[:space:]]+hard[[:space:]]+core[[:space:]]+0[[:space:]]*$" /etc/security/limits.conf /etc/security/limits.d -> r:.*'sca/cis_sles12_linux.yml-240-380 (1)
240-380: Fix rule/remediation command mismatches in rules 7522–7523.Rules 7522 (tftp) and 7523 (rsync) have inconsistent service-management commands: remediations specify
systemctl disable atftpd/rsyncd, but the audit rules still check viachkconfig --listfortftp/rsync. On SLES12, this will cause audit failures—the remediation disables the service via systemctl, but the rule continues to query chkconfig, resulting in false negatives.Additionally, rules 7514–7521 (inetd services) consistently use
chkconfig --list, while rule 7524 (xinetd) correctly usessystemctl is-enabled. Align all rules within this section to use the same service-management backend appropriate for SLES12.Affected rules
- Rule 7522: Remediation
systemctl disable atftpdvs. rulechkconfig --list -> r:tftp- Rule 7523: Remediation
systemctl disable rsyncdvs. rulechkconfig --list -> r:rsync- Rule 7524: Correctly uses
systemctl is-enabled xinetdandsystemctl disable xinetdsca/cis_postgre-sql-13.yml-466-527 (1)
466-527:log_min_error_statementaccepted-values regex omitserror.
If you intenderror(as the text suggests), the rule currently doesn’t allow it.sca/cis_apple_macOS_10.15.yml-181-192 (1)
181-192: Several “Disable X” checks appear inverted (they match the enabled state).
Examples:
- Internet Sharing rule matches
Enabled = 1under a “Disable Internet Sharing” control.- Printer Sharing rule matches
System Printer Sharing: Yesunder “Disable Printer Sharing”.Also applies to: 205-218
sca/cis_apache_24.yml-168-186 (1)
168-186: AllowOverrideList logic is inverted /not d:usage looks incorrect.
- You appear to want “AllowOverride None” and “no AllowOverrideList”, but one rule requires
AllowOverrideListto appear (Line 185-186) and another usesnot d:$conf-dirswhich doesn’t actually assert absence inside existing dirs.sca/cis_apple_macOS_10.15.yml-140-151 (1)
140-151: Screen-saver timeout check doesn’t enforce the “20 minutes or less” requirement.
It only checks “does not exist”, which can pass even when set too high.sca/cis_sqlserver_2019.yml-12-29 (1)
12-29:policy.fileis inconsistent/missing extension, and requirements don’t actually detect SQL Server 2019.
file: "cis_sqlserver_2019"should likely becis_sqlserver_2019.yml(and match how other policies declarefile).- Requirements only confirm Windows, not that SQL Server 2019 is installed/running.
sca/cis_apple_macOS_10.15.yml-429-440 (1)
429-440: Typo breaks Power Nap check (pwernapvspowernap).
This will never matchpmset -goutput.Proposed fix
- - 'c:pmset -g -> n:pwernap\s*\t*(\d) compare == 0' + - 'c:pmset -g -> n:powernap\s*(\d) compare == 0'sca/cis_postgre-sql-13.yml-49-71 (1)
49-71: Rule 24000:systemctlpipeline is invalid.
systemctl get-default | systemctl list-dependencieswon’t pass the default target correctly.Proposed fix
- - c:sh -c "systemctl get-default | systemctl list-dependencies | grep postgres" -> r:postgres + - c:sh -c 'systemctl list-dependencies "$(systemctl get-default)" | grep -i postgres' -> r:postgressca/cis_mysql5-6_enterprise.yml-57-69 (1)
57-69:MYSQL_PWDcheck likely won’t match real-world profile lines.
Line 68 searches forr:$MYSQL_PWD(literal “$MYSQL_PWD”), but typical exports look likeMYSQL_PWD=.../export MYSQL_PWD=....Proposed fix
- - "c:find /home -maxdepth 2 -type f -exec grep MYSQL_PWD {} + -> r:\\.profile|\\.bashrc|\\.bash_profile && r:$MYSQL_PWD" + - "c:find /home -maxdepth 2 -type f -exec grep -nH MYSQL_PWD {} + -> r:\\.profile|\\.bashrc|\\.bash_profile && r:\\bMYSQL_PWD\\b\\s*="sca/cis_mysql5-6_enterprise.yml-164-177 (1)
164-177: Check 11010 regex looks broken and likely won’t detect system-partition paths.
The rule mixes\t*and\+sequences in a way that doesn’t look like valid intent (and may never match reallog_binlines).Suggested direction (simplify path detection)
- - 'c:grep -Rh log_bin /etc/mysql/my.cnf /etc/mysql/mariadb.cnf /etc/mysql/conf.d /etc/mysql/mariadb.conf.d -> r:log_bin\s*\t*/\+$|log_bin\s*\t*/\+var/\*$|log_bin\s*\t*/\+usr/\*$' + - 'c:grep -Rh "^[[:space:]]*log[_-]bin" /etc/mysql/my.cnf /etc/mysql/mariadb.cnf /etc/mysql/conf.d /etc/mysql/mariadb.conf.d -> r:^[[:space:]]*log[_-]bin[[:space:]]*=[[:space:]]*/(var|usr)(/|$)|^[[:space:]]*log[_-]bin[[:space:]]*=[[:space:]]*/$'sca/web_vulnerabilities.yml-108-159 (1)
108-159: Outdated-app and backdoor patterns have a couple of “looks-like-a-typo” regexes.
- WordPress:
^.wp_versionis probably meant to match$wp_version(escape$), not “any char + wp_version”.- PHP scan:
.php$should be\.php$if this is a regex.\S_POSTlikely meant\$_POST.Proposed fix
- - 'd:$web_dirs -> ^version.php$ -> r:^.wp_version && r:4\.4\.2' + - 'd:$web_dirs -> ^version.php$ -> r:^\$wp_version\b && r:4\.4\.2' ... - - 'd:$web_dirs -> .php$ -> r:eval\(base64_decode\([*!+-]aWYo' + - 'd:$web_dirs -> \.php$ -> r:eval\(base64_decode\([*!+\-]aWYo' ... - - 'd:$web_dirs -> .php$ -> r:eval\(base64_decode\(\S_POST' + - 'd:$web_dirs -> \.php$ -> r:eval\(base64_decode\(\$_POST'sca/cis_apple_macOS_10.15.yml-21-29 (1)
21-29: macOS version regex looks wrong (10[*!+.-]15).
This doesn’t read like a safe way to match10.15and will likely match unintended strings.Proposed fix
- - 'c:sw_vers -> r:^ProductVersion:\t*\s*10[*!+.-]15' - - 'c:system_profiler SPSoftwareDataType -> r:System Version:.*10[*!+.-]15' - - 'c:defaults read loginwindow SystemVersionStampAsString -> r:^\t*\s*10[*!+.-]15' + - 'c:sw_vers -> r:^ProductVersion:\s*10\.15(\.\d+)?$' + - 'c:system_profiler SPSoftwareDataType -> r:System Version:.*10\.15(\.\d+)?' + - 'c:defaults read loginwindow SystemVersionStampAsString -> r:^10\.15(\.\d+)?$'sca/web_vulnerabilities.yml-57-107 (1)
57-107: Dotfile checks are using unescaped.so they match unintended filenames.
Examples:^.yop$,^.ssh$,^.shell$treat.as “any char”. Also^...$matches any 3-char filename, not literal....Proposed fix
- - "d:$web_dirs -> ^.yop$" + - "d:$web_dirs -> ^\\.yop$" ... - - "d:$web_dirs -> ^.ssh$" + - "d:$web_dirs -> ^\\.ssh$" ... - - "d:$web_dirs -> ^...$" + - "d:$web_dirs -> ^\\.\\.\\.$" ... - - "d:$web_dirs -> ^.shell$" + - "d:$web_dirs -> ^\\.shell$"sca/web_vulnerabilities.yml-160-182 (1)
160-182:.htaccessfilename regex should be escaped.
^.htaccess$matchesXhtaccesstoo.Proposed fix
- - 'd:$web_dirs -> ^.htaccess$ -> r:RewriteCond\s+\S+HTTP_REFERERS\s+\S+google' + - 'd:$web_dirs -> ^\.htaccess$ -> r:RewriteCond\s+\S+HTTP_REFERER\S*\s+\S+google'sca/cis_mysql5-6_enterprise.yml-293-315 (1)
293-315: Enterprise audit checks have “empty value” regexes that don’t matchkey=value.
E.g.,audit_log_connection_policy\s*=\s* && r:none|NONE(Line 303) / similar patterns for include/exclude/policy/strategy: the=\s* &&part matches an empty RHS, not= NONE.Proposed fix pattern
- - 'c:grep -Rh audit_log_connection_policy /etc/mysql/my.cnf /etc/mysql/mariadb.cnf /etc/mysql/conf.d /etc/mysql/mariadb.conf.d -> !r:^\s*\t*# && r:audit_log_connection_policy\s*=\s* && r:none|NONE' + - 'c:grep -Rh audit_log_connection_policy /etc/mysql/my.cnf /etc/mysql/mariadb.cnf /etc/mysql/conf.d /etc/mysql/mariadb.conf.d -> !r:^\s*# && r:\baudit_log_connection_policy\s*=\s*(none)\b'sca/cis_mysql5-6_enterprise.yml-99-125 (1)
99-125: MySQL boolean options accept multiple formats; current rules will false-fail for valid configurations.The rules for
skip-grant-tables(id: 11005) andskip_symbolic_links(id: 11006) only match= FALSE/falseand= YES/yesrespectively. MySQL 5.6 accepts equivalent formats that these rules miss:
- Rule 11005 will not catch:
skip-grant-tables=0,skip-grant-tables=OFF, or bareskip-grant-tables- Rule 11006 will not catch:
skip_symbolic_links=1,skip_symbolic_links=ON, or bareskip_symbolic_linksUpdate both rules to match these valid formats using case-insensitive patterns:
- For 11005 (skip-grant-tables must be disabled):
skip-grant-tables\s*=\s*(?:0|OFF|FALSE|false)|^\s*skip-grant-tables\s*$(reject if matched alone; accept if =OFF/=0/=FALSE)- For 11006 (skip_symbolic_links must be enabled):
skip_symbolic_links\s*=\s*(?:1|ON|YES|yes)|skip-symbolic-links\s*=\s*(?:1|ON|YES|yes)sca/cis_apache_24.yml-111-125 (1)
111-125: Fix malformed rule: add regex prefix to userdir check.The rule
"c:$enabled-modules -> userdir_"is missing ther:prefix. All other enabled-modules checks in this file use the regex prefix (e.g.,r:proxy_,r:status_module,r:info_module,r:autoindex_module,r:dav_.+module). This should be"c:$enabled-modules -> r:userdir_"for consistency and to match Wazuh SCA rule syntax.sca/cis_iis_10.yml-507-523 (1)
507-523: HSTSmax-agenumeric capture is single-digit.n:max-age=(\d)should be(\d+)or you’ll only compare the first digit.Proposed fix
- - 'c:%systemroot%\system32\inetsrv\appcmd.exe list config -section:system.webServer/httpProtocol -> r:name="Strict-Transport-Security" && n:max-age=(\d) compare > 0' + - 'c:%systemroot%\system32\inetsrv\appcmd.exe list config -section:system.webServer/httpProtocol -> r:name="Strict-Transport-Security" && n:max-age=(\d+) compare > 0'sca/cis_apple_macOS_12.0.yml-134-147 (1)
134-147: Rule regex typo likely breaks the check.r:^1$8(Line 145) is almost certainly meant to validate a numeric value (likely18).Proposed fix
- - "c:defaults -currentHost read com.apple.controlcenter.plist Bluetooth -> r:^1$8" + - "c:defaults -currentHost read com.apple.controlcenter.plist Bluetooth -> r:^18$"sca/cis_apple_macOS_12.0.yml-647-662 (1)
647-662: Command typo:defaults read read. This will fail at runtime and make the check unreliable.Proposed fix
- - "c:defaults read read /Library/Preferences/com.apple.alf.plist loggingoption -> r:^2$" + - "c:defaults read /Library/Preferences/com.apple.alf.plist loggingoption -> r:^2$"sca/cis_iis_10.yml-290-335 (1)
290-335: Numeric compare regex captures only one digit.(\d)will parse30000000as3,4096as4, etc., breaking the check. Use(\d+).Proposed fix
- - 'c:%systemroot%\system32\inetsrv\appcmd list config /section:requestfiltering -> n:maxAllowedContentLength="(\d)" compare <= 30000000' + - 'c:%systemroot%\system32\inetsrv\appcmd list config /section:requestfiltering -> n:maxAllowedContentLength="(\d+)" compare <= 30000000' @@ - - 'c:%systemroot%\system32\inetsrv\appcmd list config /section:requestfiltering -> n:maxUrl="(\d)" compare <= 4096' + - 'c:%systemroot%\system32\inetsrv\appcmd list config /section:requestfiltering -> n:maxUrl="(\d+)" compare <= 4096' @@ - - 'c:%systemroot%\system32\inetsrv\appcmd list config /section:requestfiltering -> n:maxQueryString="(\d)" compare <= 2048' + - 'c:%systemroot%\system32\inetsrv\appcmd list config /section:requestfiltering -> n:maxQueryString="(\d+)" compare <= 2048'sca/cis_iis_10.yml-367-396 (1)
367-396:appcmd listconfigtypo. Multiple rules useappcmd listconfig(no space). If that’s not accepted byappcmd.exe, these checks will always fail.Example fix
- - 'c:%systemroot%\system32\inetsrv\appcmd listconfig /section:requestfiltering -> r:verb="TRACE" allowed="false"' + - 'c:%systemroot%\system32\inetsrv\appcmd list config /section:requestfiltering -> r:verb="TRACE" allowed="false"'sca/cis_nginx_1.yml-153-165 (1)
153-165: Fix malformed regex for ownership check. Thestatrule has unbalanced parentheses in the regex pattern (r:Access:\s*(") and doesn't match actualstatoutput format. The rule will fail to parse correctly or always fail to match. Use the documentedstat -Lcformat with simpler regex, consistent with similar checks elsewhere in the codebase (e.g.,cis_alma_linux_10.yml).Proposed fix
- - 'c:stat -L /etc/nginx -> r:Access:\s*(" && r:Uid:\s+\(.+root\)\s+Gid:\s+\(.+root\)$' + - 'c:stat -Lc "%U %G" /etc/nginx -> r:^root root$'sca/cis_nginx_1.yml-13-17 (1)
13-17:policy.filefilename mismatch. Thepolicy.filevalue is"cis_nginx1.yml"but the actual filename iscis_nginx_1.yml. Wazuh SCA documentation indicates thepolicy.filefield should conventionally match the YAML filename. This mismatch violates that convention and may cause configuration confusion or issues.Proposed fix
policy: id: "cis_nginx1" - file: "cis_nginx1.yml" + file: "cis_nginx_1.yml"sca/cis_sqlserver_2014.yml-12-26 (1)
12-26: Fix metadata inconsistency and strengthen requirements gating.policy.fileis missing.ymlextension (inconsistent withcis_sqlserver_2012.yml,2016.yml,2017.ymland other policies), andrequirementsonly asserts "Windows", not "SQL Server 2014 present + sqlcmd available", allowing scans to fail noisily on non-SQL hosts.Proposed fixes
policy: id: "cis_sqlserver_2014" - file: "cis_sqlserver_2014" + file: "cis_sqlserver_2014.yml" requirements: condition: all rules: - 'r:HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion -> ProductName -> r:^Windows' + - 'c:where sqlcmd -> r:sqlcmd\.exe' + - 'c:sqlcmd -Q "SELECT @@VERSION;" -> r:Microsoft SQL Server 2014'sca/cis_sqlserver_2017.yml-12-26 (1)
12-26: Strengthen SQL Server 2017 version gating in requirements. The current check only verifies a generic Windows platform, allowing the policy to run on any Windows system (desktop, Server 2012, etc.) without confirming SQL Server 2017 presence or version. Add a registry check for SQL Server 2017 installation to match the pattern used in Windows Server policies that check for specific versions.Suggested approach
Instead of command execution checks (not used in requirements elsewhere), use registry detection for SQL Server 2017:
requirements: title: "Check that the Windows platform has Microsoft SQL Server 2017" description: "Requirements for running the CIS Microsoft SQL Server 2017 Benchmark" condition: all rules: - 'r:HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion -> ProductName -> r:^Windows' + - 'r:HKLM\SOFTWARE\Microsoft\Microsoft SQL Server -> Instance Names -> r:MSSQLSERVER'This follows the registry-based pattern used throughout the SCA framework.
sca/cis_mongodb_36.yml-267-269 (1)
267-269: Regex pattern may not match as intended due to missing grouping.The pattern
r:javascriptEnabled: 0|falsewill match either "javascriptEnabled: 0" OR the literal string "false" anywhere in the line. To correctly match either value after the key, use parentheses for grouping like other checks in this file.🐛 Proposed fix
- - 'c:sh -c "cat /etc/mongod.conf | grep \\-A10 \"security\"" -> r:javascriptEnabled: 0|false' + - 'c:sh -c "cat /etc/mongod.conf | grep \\-A10 \"security\"" -> r:javascriptEnabled: \(0|false\)'
🟡 Minor comments (17)
sca/cis_sqlserver_2016.yml-640-667 (1)
640-667: Fix terminology: SQL Server permission set isSAFE, notSAFE_ACCESS.The title says “SAFE_ACCESS”, but SQL Server’s assembly permission sets are
SAFE,EXTERNAL_ACCESS,UNSAFE; remediation already usesPERMISSION_SET = SAFE.Proposed diff
- - id: 13022 - title: Ensure 'CLR Assembly Permission Set' is set to 'SAFE_ACCESS' for All CLR Assemblies + - id: 13022 + title: Ensure 'CLR Assembly Permission Set' is set to 'SAFE' for All CLR Assembliessca/cis_sqlserver_2019.yml-27-29 (1)
27-29:$User:is declared but unset.
If unused, drop it; if intended, set a placeholder value + document how it’s used.sca/cis_mysql5-6_enterprise.yml-1-12 (1)
1-12: Fix typos in benchmark header (“Entreprise” → “Enterprise”).
Minor, but this is user-facing and repeated in multiple places (comment + “Based on” line).sca/cis_sqlserver_2012.yml-324-335 (1)
324-335: Duplicatecis_cscentry in compliance list.
Not functionally harmful, but noisy for downstream tooling.sca/cis_nginx_1.yml-182-187 (1)
182-187: Typo in remediation command (chownvschmod).chown 644 /var/run/nginx.pidshould bechmod 644 ....Proposed fix
- remediation: "If the PID file is not owned by root, issue this command: 'chown root:root /var/run/nginx.pid'. If the PID file has permissions greater than 644, issue this command: 'chown 644 /var/run/nginx.pid'" + remediation: "If the PID file is not owned by root, issue this command: 'chown root:root /var/run/nginx.pid'. If the PID file has permissions greater than 644, issue this command: 'chmod 644 /var/run/nginx.pid'"sca/cis_iis_10.yml-678-711 (1)
678-711: AES remediation typo references wrong cipher. Check 22039 is “AES 256/256 Enabled” but remediation says setAES 128/128:Enabled.Proposed fix
- remediation: "Set the following key to 1: HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Ciphers\\AES 128/128:Enabled" + remediation: "Set the following key to 1: HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Ciphers\\AES 256/256:Enabled"sca/cis_apple_macOS_12.0.yml-1-16 (1)
1-16: Header OS version mismatch. Comment says “macOS 11.x” while this policy is for macOS 12.0/12.x; please align to reduce confusion when triaging scan output.Proposed fix
-# CIS Checks for macOS 11.x +# CIS Checks for macOS 12.xsca/cis_sqlserver_2017.yml-433-454 (1)
433-454: Correct CLR permission set naming toSAFE. Title and description incorrectly reference "SAFE_ACCESS"; the correct SQL Server CLR Assembly permission set name isSAFE. Update lines to useSAFEinstead ofSAFE_ACCESS(remediation is already correct).sca/cis_sqlserver_2014.yml-436-457 (1)
436-457: CLR permission set naming mismatch. SQL Server usesSAFE,EXTERNAL_ACCESS, andUNSAFEas permission set names. The title incorrectly references "SAFE_ACCESS" when it should referenceSAFE. The remediation is correct ("PERMISSION_SET = SAFE"). Update the title to match the correct SQL Server terminology.sca/cis_nginx_1.yml-261-273 (1)
261-273: Add timeouts to the curl command to prevent hanging on unresponsive local services. The curl call lacks timeout specifications, which can cause the check to block indefinitely if the NGINX service is unresponsive or the local port is unreachable.Proposed fix
- - 'c:curl -I 127.0.0.1 -> r:^.*Server:\s+nginx/.+' + - 'c:curl --max-time 2 --connect-timeout 2 -I 127.0.0.1 -> r:^.*Server:\s+nginx/.+'sca/cis_apple_macOS_10.12.yml-33-47 (1)
33-47: Inconsistent rule match style (-> 1vs-> r:^1$|^2$). The file mixes bare value matches (-> 1,-> 0) with regex patterns (-> r:...). For consistency and clarity, normalize all similar checks to use regex patterns like-> r:^1$or-> r:^0$.sca/cis_apple_macOS_12.0.yml-20-28 (1)
20-28: Use\pinstead of[*!+.-]for consistency with the newer macOS 26.x file. The pattern12[*!+.-]technically matches version strings like "12.0" (since period is in the character class), but using\p(the Wazuh OS_Regex punctuation character class) is more semantically correct and aligns with the updated 26.x policy. This also prevents false matches on invalid version strings like "12*" or "12-".Suggested changes for lines 25–27:
rules: - 'c:sw_vers -> r:^ProductVersion:\t*\s*12\p' - 'c:system_profiler SPSoftwareDataType -> r:System Version:.*12\p' - 'c:defaults read loginwindow SystemVersionStampAsString -> r:^\t*\s*12\p'sca/cis_apple_macOS_12.0.yml-574-589 (1)
574-589: Add explicitr:regex prefix to non-conformant rules on lines 585-586. These rules omit the documentedr:prefix and include leading spaces in the expected output, deviating from Wazuh SCA standard format (as shown in rules on lines 587-588 and throughout the file). According to Wazuh documentation, the correct format isc:command -> r:REGEX_PATTERN. Update to:
c:/usr/libexec/firmwarecheckers/eficheck/eficheck --integrity-check -> r:No changes detected in primary hashesc:/usr/libexec/firmwarecheckers/eficheck/eficheck --integrity-check -> r:MBP133\.sca/cis_mongodb_36.yml-206-219 (1)
206-219: Title does not match the check's actual purpose.The title states "Ensure that audit filters are configured properly" but the description, remediation, and rule all pertain to disabling
SystemLog.quiet. This check (CIS 5.3) is about ensuring quiet mode is disabled, not about configuring audit filters. Consider updating the title to accurately reflect the control, e.g., "Ensure that SystemLog.quiet is disabled."sca/cis_mongodb_36.yml-36-50 (1)
36-50: CIS reference mismatch: compliance shows "1.2" but section comment indicates "2.1".The comment on line 37 says
#2.1(under#2 Authentication), but the compliance mapping on line 44 referencescis: ["1.2"]. This appears to be inconsistent with the section organization. Please verify the correct CIS control number.sca/cis_apple_macOS_11.1.yml-585-597 (1)
585-597: Comparison should use>=to match description "365 or more days".Line 596 uses
compare > 365but the title and description specify "365 or more days". A TTL value of exactly 365 would fail this check.🐛 Proposed fix
- - 'c:grep -i ttl /etc/asl/com.apple.install -> n:ttl[\w@-]+(\d+) compare > 365' + - 'c:grep -i ttl /etc/asl/com.apple.install -> n:ttl[\w@-]+(\d+) compare >= 365'sca/cis_apple_macOS_11.1.yml-13-19 (1)
13-19: Description references incorrect macOS version.The description on line 17 mentions "macOS 10.15" twice, but this policy is for macOS 11.0 Big Sur. This appears to be a copy-paste error from an earlier macOS policy file.
📝 Proposed fix
- description: "CIS Apple macOS 11.0 Big Sur Benchmark v2.1.0, provides prescriptive guidance for establishing a secure configuration posture for Apple macOS 10.15. This guide was tested against Apple macOS 10.15." + description: "CIS Apple macOS 11.0 Big Sur Benchmark v2.1.0, provides prescriptive guidance for establishing a secure configuration posture for Apple macOS 11.0. This guide was tested against Apple macOS 11.0."
🧹 Nitpick comments (7)
Dockerfile (1)
39-49: Consider collapsing the new SCA steps into a single RUN layer (smaller image + fewer layers).Not blocking, but you can do the mkdir/chown/chmod in one RUN to reduce layers and keep it easier to maintain.
Proposed diff
-# Ensure SCA ruleset directory exists -RUN mkdir -p /var/ossec/ruleset/sca - -# Copy SCA policies into agent ruleset -COPY sca/*.yml /var/ossec/ruleset/sca/ - -# Permissions -RUN chown -R root:wazuh /var/ossec/ruleset/sca && \ - chmod 750 /var/ossec/ruleset/sca && \ - chmod 640 /var/ossec/ruleset/sca/*.yml +# Ensure SCA ruleset directory exists, copy policies, and set permissions +RUN mkdir -p /var/ossec/ruleset/sca +COPY sca/*.yml /var/ossec/ruleset/sca/ +RUN chown -R root:wazuh /var/ossec/ruleset/sca && \ + chmod 750 /var/ossec/ruleset/sca && \ + chmod 640 /var/ossec/ruleset/sca/*.ymlsca/web_vulnerabilities.yml (1)
16-30: Consider broadening defaults/requirements to common distro paths.
Default$php.ini: /etc/php.iniwill miss many modern installs (e.g.,/etc/php/*/apache2/php.ini,/etc/php/*/fpm/php.ini). Not a blocker, but it will surprise users.sca/cis_postgre-sql-13.yml (2)
35-42: Requirements are very environment-specific (will fail by default).
Hard-coded$user: test_userplus reliance on.pgpass/ privileges is fine, but consider making it explicit in the description that users must set variables before enabling the policy.
1073-1140: pgBackRest presence check relies on shell-specific “command not found” text.
Consider usingcommand -v pgbackrestorpgbackrest --versionfor portability.sca/cis_sqlserver_2012.yml (1)
20-29: Requirements don’t validate SQL Server 2012 presence—only Windows.
Suggest adding a SQL Server–specific detection (registry/service/sqlcmd version) to avoid running lots ofsqlcmdchecks on non-SQL hosts.sca/cis_apple_macOS_11.1.yml (2)
25-28: Unusual regex character class in version detection rules.The pattern
11[*!+.-]includes*,!,+characters which are unlikely to appear in macOS version strings. While this will still match valid versions due to.being included, consider simplifying to match expected separators only.♻️ Suggested simplification
rules: - - 'c:sw_vers -> r:^ProductVersion:\t*\s*11[*!+.-]' - - 'c:system_profiler SPSoftwareDataType -> r:System Version:.*11[*!+.-]' - - 'c:defaults read loginwindow SystemVersionStampAsString -> r:^\t*\s*11[*!+.-]' + - 'c:sw_vers -> r:^ProductVersion:\t*\s*11\.' + - 'c:system_profiler SPSoftwareDataType -> r:System Version:.*11\.' + - 'c:defaults read loginwindow SystemVersionStampAsString -> r:^\t*\s*11\.'
879-884: Minor typo in description.Line 882 has "SThe seal" which should be "The seal".
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (71)
Dockerfilesca/cis_alma_linux_10.ymlsca/cis_alma_linux_8.ymlsca/cis_alma_linux_9.ymlsca/cis_amazon_linux_1.ymlsca/cis_amazon_linux_2.ymlsca/cis_amazon_linux_2023.ymlsca/cis_apache_24.ymlsca/cis_apple_macOS_10.11.ymlsca/cis_apple_macOS_10.12.ymlsca/cis_apple_macOS_10.13.ymlsca/cis_apple_macOS_10.14.ymlsca/cis_apple_macOS_10.15.ymlsca/cis_apple_macOS_11.1.ymlsca/cis_apple_macOS_12.0.ymlsca/cis_apple_macOS_13.x.ymlsca/cis_apple_macOS_14.x.ymlsca/cis_apple_macOS_15.x.ymlsca/cis_apple_macOS_26.x.ymlsca/cis_centos10_linux.ymlsca/cis_centos6_linux.ymlsca/cis_centos7_linux.ymlsca/cis_centos8_linux.ymlsca/cis_centos9_linux.ymlsca/cis_debian10.ymlsca/cis_debian11.ymlsca/cis_debian12.ymlsca/cis_debian13.ymlsca/cis_debian7.ymlsca/cis_debian8.ymlsca/cis_debian9.ymlsca/cis_iis_10.ymlsca/cis_mongodb_36.ymlsca/cis_mysql5-6_community.ymlsca/cis_mysql5-6_enterprise.ymlsca/cis_nginx_1.ymlsca/cis_oracle_database_19c.ymlsca/cis_oracle_linux_10.ymlsca/cis_oracle_linux_9.ymlsca/cis_postgre-sql-13.ymlsca/cis_rhel10_linux.ymlsca/cis_rhel6_linux.ymlsca/cis_rhel7_linux.ymlsca/cis_rhel8_linux.ymlsca/cis_rhel9_linux.ymlsca/cis_rocky_linux_10.ymlsca/cis_rocky_linux_8.ymlsca/cis_rocky_linux_9.ymlsca/cis_sles12_linux.ymlsca/cis_sles15_linux.ymlsca/cis_sqlserver_2012.ymlsca/cis_sqlserver_2014.ymlsca/cis_sqlserver_2016.ymlsca/cis_sqlserver_2017.ymlsca/cis_sqlserver_2019.ymlsca/cis_ubuntu14-04.ymlsca/cis_ubuntu16-04.ymlsca/cis_ubuntu18-04.ymlsca/cis_ubuntu20-04.ymlsca/cis_ubuntu22-04.ymlsca/cis_ubuntu24-04.ymlsca/cis_win10_enterprise.ymlsca/cis_win11_enterprise.ymlsca/cis_win2012_non_r2.ymlsca/cis_win2012r2.ymlsca/cis_win2016.ymlsca/cis_win2019.ymlsca/cis_win2022.ymlsca/cis_win2025.ymlsca/sca_distro_independent_linux.ymlsca/web_vulnerabilities.yml
🔇 Additional comments (9)
sca/cis_apple_macOS_10.13.yml (1)
21-29: Requirements block looks reasonable (multiple version-detection strategies).sca/cis_apple_macOS_10.11.yml (1)
21-29: Requirements block looks consistent with other macOS policies.sca/cis_iis_10.yml (1)
107-118: The rule logic is correct. When WebDAV is disabled viaRemove-WindowsFeature Web-DAV-Publishing,Get-WindowsFeature Web-DAV-PublishingreturnsInstallState = Available, indicating the feature is not installed. The ruler:availablecorrectly validates this disabled state. No changes needed.sca/cis_apple_macOS_10.12.yml (1)
21-29: The macOS version detection regex is actually functional, contrary to the original concern. The pattern10[*!+.-]12successfully matches10.12.6and other patch versions because the character class[*!+.-]includes a literal dot, and Wazuh SCA rules use substring matching. Testing confirms the original pattern correctly identifies all 10.12.x versions.That said, the pattern is unnecessarily permissive—it allows invalid separators like
10*12or10!12that would never appear in actual output—and reads unclearly. Improving to10\.12(\.|$)makes the intent explicit and is worth adopting for maintainability.Likely an incorrect or invalid review comment.
sca/cis_mongodb_36.yml (2)
1-31: LGTM on policy metadata and requirements block.The policy header, metadata, requirements, and variable definitions are well-structured and follow standard Wazuh SCA conventions.
176-204: LGTM for auditing checks.Checks 22507-22508 for system activity auditing are correctly structured with appropriate CIS references and rule patterns.
sca/cis_apple_macOS_11.1.yml (3)
663-676: Complex but correct logic for NFS server check.The combination of
condition: nonewith thenotmodifier creates correct logic: the check passes when/etc/exportsdoesn't exist ANDcom.apple.nfsdis in the disabled list.
30-107: LGTM on software update checks (1.2-1.6).The auto-update configuration checks are well-structured with correct command syntax and appropriate CIS mappings.
909-995: LGTM on user accounts and environment checks (Section 6).The user account configuration checks for login window settings, guest accounts, and Safari settings are correctly implemented.
| #9.1:Set TimeOut to 10 or less | ||
| - id: 10020 | ||
| title: "Ensure the TimeOut Is Set to 10 or Less" | ||
| description: "Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality. Although there is no 100% solution for preventing DoS attacks, the following recommendation uses the Timeout directive to mitigate some of the risk, by requiring more effort for a successful DoS attack. Of course, DoS attacks can happen in rather unintentional ways as well as intentional and these directives will help in many of those situations as well." | ||
| rationale: "One common technique for DoS is to initiate many connections to the server. By decreasing the timeout for old connections and we allow the server to free up resources more quickly and be more responsive. By making the server more efficient, it will be more resilient to DoS conditions. The Timeout directive affects several timeout values for Apache, so review the Apache document carefully." | ||
| remediation: "Perform the following to implement the recommended state: Add or modify the Timeout directive in the Apache configuration to have a value of 10 seconds or shorter. Timeout 10" | ||
| compliance: | ||
| - cis: ["9.1"] | ||
| - cis_csc: ["9", "5.1"] | ||
| references: | ||
| - https://httpd.apache.org/docs/2.4/mod/core.html#timeout | ||
| condition: all | ||
| rules: | ||
| - 'f:$main-conf -> !r:^# && && r:timeout|Timeout && n:\s+(\d+) compare <= 10' | ||
|
|
There was a problem hiding this comment.
Rule has a syntax error (&& &&) and will likely fail parsing.
Line 379: !r:^# && && r:timeout|Timeout ...
Proposed fix
- - 'f:$main-conf -> !r:^# && && r:timeout|Timeout && n:\s+(\d+) compare <= 10'
+ - 'f:$main-conf -> !r:^# && r:timeout|Timeout && n:\s+(\d+) compare <= 10'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #9.1:Set TimeOut to 10 or less | |
| - id: 10020 | |
| title: "Ensure the TimeOut Is Set to 10 or Less" | |
| description: "Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality. Although there is no 100% solution for preventing DoS attacks, the following recommendation uses the Timeout directive to mitigate some of the risk, by requiring more effort for a successful DoS attack. Of course, DoS attacks can happen in rather unintentional ways as well as intentional and these directives will help in many of those situations as well." | |
| rationale: "One common technique for DoS is to initiate many connections to the server. By decreasing the timeout for old connections and we allow the server to free up resources more quickly and be more responsive. By making the server more efficient, it will be more resilient to DoS conditions. The Timeout directive affects several timeout values for Apache, so review the Apache document carefully." | |
| remediation: "Perform the following to implement the recommended state: Add or modify the Timeout directive in the Apache configuration to have a value of 10 seconds or shorter. Timeout 10" | |
| compliance: | |
| - cis: ["9.1"] | |
| - cis_csc: ["9", "5.1"] | |
| references: | |
| - https://httpd.apache.org/docs/2.4/mod/core.html#timeout | |
| condition: all | |
| rules: | |
| - 'f:$main-conf -> !r:^# && && r:timeout|Timeout && n:\s+(\d+) compare <= 10' | |
| #9.1:Set TimeOut to 10 or less | |
| - id: 10020 | |
| title: "Ensure the TimeOut Is Set to 10 or Less" | |
| description: "Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality. Although there is no 100% solution for preventing DoS attacks, the following recommendation uses the Timeout directive to mitigate some of the risk, by requiring more effort for a successful DoS attack. Of course, DoS attacks can happen in rather unintentional ways as well as intentional and these directives will help in many of those situations as well." | |
| rationale: "One common technique for DoS is to initiate many connections to the server. By decreasing the timeout for old connections and we allow the server to free up resources more quickly and be more responsive. By making the server more efficient, it will be more resilient to DoS conditions. The Timeout directive affects several timeout values for Apache, so review the Apache document carefully." | |
| remediation: "Perform the following to implement the recommended state: Add or modify the Timeout directive in the Apache configuration to have a value of 10 seconds or shorter. Timeout 10" | |
| compliance: | |
| - cis: ["9.1"] | |
| - cis_csc: ["9", "5.1"] | |
| references: | |
| - https://httpd.apache.org/docs/2.4/mod/core.html#timeout | |
| condition: all | |
| rules: | |
| - 'f:$main-conf -> !r:^# && r:timeout|Timeout && n:\s+(\d+) compare <= 10' |
🤖 Prompt for AI Agents
In @sca/cis_apache_24.yml around lines 366 - 380, The rule string under id 10020
has a duplicated logical operator ("&& &&") causing a syntax error; update the
rules entry to remove the extra "&&" so the expression reads something like
"!r:^# && r:timeout|Timeout && n:\\s+(\\d+) compare <= 10" (i.e., keep the
negation check for commented lines, the presence check for timeout/Timeout, and
the numeric capture/compare) so the parser can evaluate the rule correctly.
| # 2.4.3 Disable Screen Sharing (Automated) | ||
| - id: 17514 | ||
| title: "Disable Screen Sharing" | ||
| description: "Screen sharing allows a computer to connect to another computer on a network and display the computer’s screen. While sharing the computer’s screen, the user can control what happens on that computer, such as opening documents or applications, opening, moving, or closing windows, and even shutting down the computer." | ||
| rationale: "Disabling screen sharing mitigates the risk of remote connections being made without the user of the console knowing that they are sharing the computer." | ||
| remediation: "Run the following command to turn off Screen Sharing: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.screensharing.plist" | ||
| compliance: | ||
| - cis: ["2.4.3"] | ||
| condition: all | ||
| rules: | ||
| - "c:launchctl load /System/Library/LaunchDaemons/com.apple.screensharing.plist -> r:Service is disabled" | ||
|
|
||
| # 2.4.4 Disable Printer Sharing (Automated) |
There was a problem hiding this comment.
Critical: checks must not run state-changing commands (launchctl load).
- Line 203 runs
launchctl load ...screensharing...(can enable services). - Line 381 runs
launchctl load ...locationd...(can change system state).
SCA checks should be read-only probes.
Suggested approach
- - "c:launchctl load /System/Library/LaunchDaemons/com.apple.screensharing.plist -> r:Service is disabled"
+ - "c:launchctl print-disabled system -> r:com\.apple\.screensharing\s*=>\s*true"
...
- - "c:launchctl load /System/Library/LaunchDaemons/com.apple.locationd.plist -> r:service already loaded"
+ - "c:launchctl list -> r:com\.apple\.locationd"Also applies to: 369-382
| # 2.4.8 Disable File Sharing (Automated) | ||
| - id: 18019 | ||
| title: "Disable File Sharing." | ||
| description: "Apple's File Sharing uses a combination of SMB (Windows sharing) and AFP (Mac sharing)" | ||
| rationale: "By disabling file sharing, the remote attack surface and risk of unauthorized access to files stored on the system is reduced." | ||
| remediation: "Run the following command in Terminal to turn off AFP and SMB file sharing from the command line: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.smbd.plist" | ||
| compliance: | ||
| - cis: ["2.4.8"] | ||
| - cis_level: ["1"] | ||
| condition: none | ||
| rules: | ||
| - 'c:sh -c "launchctl print-disabled system | grep -c ''\"com.apple.smbd\" => true''" -> 1' |
There was a problem hiding this comment.
Inverted logic: check will fail when file sharing is correctly disabled.
The condition: none means the check passes only if the rule does NOT match. However, the rule looks for "com.apple.smbd" => true in the disabled list — finding it means sharing IS disabled (correct state). With current logic, the check fails when file sharing is properly disabled.
🐛 Proposed fix
Either change the condition or invert the rule:
condition: none
rules:
- - 'c:sh -c "launchctl print-disabled system | grep -c ''\"com.apple.smbd\" => true''" -> 1'
+ - 'c:sh -c "launchctl print-disabled system | grep -c ''\"com.apple.smbd\" => false''" -> 1'Or alternatively:
- condition: none
+ condition: all
rules:
- 'c:sh -c "launchctl print-disabled system | grep -c ''\"com.apple.smbd\" => true''" -> 1'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # 2.4.8 Disable File Sharing (Automated) | |
| - id: 18019 | |
| title: "Disable File Sharing." | |
| description: "Apple's File Sharing uses a combination of SMB (Windows sharing) and AFP (Mac sharing)" | |
| rationale: "By disabling file sharing, the remote attack surface and risk of unauthorized access to files stored on the system is reduced." | |
| remediation: "Run the following command in Terminal to turn off AFP and SMB file sharing from the command line: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.smbd.plist" | |
| compliance: | |
| - cis: ["2.4.8"] | |
| - cis_level: ["1"] | |
| condition: none | |
| rules: | |
| - 'c:sh -c "launchctl print-disabled system | grep -c ''\"com.apple.smbd\" => true''" -> 1' | |
| # 2.4.8 Disable File Sharing (Automated) | |
| - id: 18019 | |
| title: "Disable File Sharing." | |
| description: "Apple's File Sharing uses a combination of SMB (Windows sharing) and AFP (Mac sharing)" | |
| rationale: "By disabling file sharing, the remote attack surface and risk of unauthorized access to files stored on the system is reduced." | |
| remediation: "Run the following command in Terminal to turn off AFP and SMB file sharing from the command line: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.smbd.plist" | |
| compliance: | |
| - cis: ["2.4.8"] | |
| - cis_level: ["1"] | |
| condition: all | |
| rules: | |
| - 'c:sh -c "launchctl print-disabled system | grep -c ''\"com.apple.smbd\" => true''" -> 1' |
🤖 Prompt for AI Agents
In @sca/cis_apple_macOS_11.1.yml around lines 301 - 312, The check for id 18019
("Disable File Sharing") uses condition: none which makes the rule pass only
when the rule does NOT match, but the rule 'c:sh -c "launchctl print-disabled
system | grep -c ''\"com.apple.smbd\" => true''" -> 1' matches when SMB is
correctly disabled; fix by either changing condition: none to condition: any (so
a matching rule means pass) or invert the rule to expect zero (e.g. change the
rule to check for -> 0 instead of -> 1) so semantics align; update the rule or
the condition accordingly (referencing the exact rule string and the condition:
none in this entry).
| # 2.5.6 Limit Ad tracking and personalized Ads (Automated) | ||
| - id: 18029 | ||
| title: "Limit Ad tracking and personalized Ads." | ||
| description: "Apple provides a framework that allows advertisers to target Apple users and end-users with advertisements. While many people prefer that when they see advertising it is relevant to them and their interests, the detailed information that is data mining collected, correlated, and available to advertisers in repositories is often disconcerting. This information is valuable to both advertisers and attackers and has been used with other metadata to reveal users' identities" | ||
| rationale: "Organizations should manage user privacy settings on managed devices to align with organizational policies and user data protection requirements." | ||
| remediation: "Run the following command in Terminal: sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.auditd.plist" | ||
| compliance: | ||
| - cis: ["2.5.6"] | ||
| - cis_level: ["1"] | ||
| condition: all | ||
| rules: | ||
| - "c:defaults -currentHost read /Users/<username>/Library/Preferences/com.apple.AdLib.plist allowApplePersonalizedAdvertising -> 0" |
There was a problem hiding this comment.
Rule contains literal <username> placeholder that won't be expanded.
The rule on line 482 contains <username> as a literal string in the command path. This placeholder won't be replaced at runtime, causing the check to fail. The command needs to either iterate over users or use a different approach (e.g., check current user with $USER or use a glob pattern).
🐛 Suggested fix example
Consider using current user expansion or a shell command that iterates users:
- - "c:defaults -currentHost read /Users/<username>/Library/Preferences/com.apple.AdLib.plist allowApplePersonalizedAdvertising -> 0"
+ - "c:defaults -currentHost read com.apple.AdLib.plist allowApplePersonalizedAdvertising -> 0"Or use the -currentHost flag which reads from the current user's context.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # 2.5.6 Limit Ad tracking and personalized Ads (Automated) | |
| - id: 18029 | |
| title: "Limit Ad tracking and personalized Ads." | |
| description: "Apple provides a framework that allows advertisers to target Apple users and end-users with advertisements. While many people prefer that when they see advertising it is relevant to them and their interests, the detailed information that is data mining collected, correlated, and available to advertisers in repositories is often disconcerting. This information is valuable to both advertisers and attackers and has been used with other metadata to reveal users' identities" | |
| rationale: "Organizations should manage user privacy settings on managed devices to align with organizational policies and user data protection requirements." | |
| remediation: "Run the following command in Terminal: sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.auditd.plist" | |
| compliance: | |
| - cis: ["2.5.6"] | |
| - cis_level: ["1"] | |
| condition: all | |
| rules: | |
| - "c:defaults -currentHost read /Users/<username>/Library/Preferences/com.apple.AdLib.plist allowApplePersonalizedAdvertising -> 0" | |
| # 2.5.6 Limit Ad tracking and personalized Ads (Automated) | |
| - id: 18029 | |
| title: "Limit Ad tracking and personalized Ads." | |
| description: "Apple provides a framework that allows advertisers to target Apple users and end-users with advertisements. While many people prefer that when they see advertising it is relevant to them and their interests, the detailed information that is data mining collected, correlated, and available to advertisers in repositories is often disconcerting. This information is valuable to both advertisers and attackers and has been used with other metadata to reveal users' identities" | |
| rationale: "Organizations should manage user privacy settings on managed devices to align with organizational policies and user data protection requirements." | |
| remediation: "Run the following command in Terminal: sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.auditd.plist" | |
| compliance: | |
| - cis: ["2.5.6"] | |
| - cis_level: ["1"] | |
| condition: all | |
| rules: | |
| - "c:defaults -currentHost read com.apple.AdLib.plist allowApplePersonalizedAdvertising -> 0" |
| # 5.19 Enable Sealed System Volume (SSV) (Automated) | ||
| - id: 18055 | ||
| title: "Enable Sealed System Volume (SSV)." | ||
| description: "SThe seal is verified by the boot loader at startup. macOS will not boot if system files have been tampered with. If validation fails, the user will be instructed to reinstall the operating system. During read operations for files located in the Sealed System Volume, a hash is calculated and compared to the value stored in the Merkle tree." | ||
| rationale: "Running without Sealed System Volume on a production system could run the risk of Apple software, that integrates directly with macOS, being modified. " | ||
| remediation: "Perform the following while booted in macOS Recovery Partition. 1. Select Terminal from the Utilities menu 2. Run the following command in Terminal: /usr/bin/csrutil enable authenticated-root 3. The output should be: Successfully enabled System authenticated root. Please restart the machine for the changes to take effect. 4. Reboot." | ||
| compliance: | ||
| - cis: ["5.19"] | ||
| - cis_level: ["1"] | ||
| condition: all | ||
| rules: | ||
| - "c:/usr/bin/csrutil authenticated-root status -> r:^SAuthenticated Root status: enabled" |
There was a problem hiding this comment.
Typo in regex pattern will cause check to always fail.
Line 890 has r:^SAuthenticated Root status: enabled — the leading "S" appears to be a typo (possibly carried over from line 882's "SThe seal"). The actual command output would start with "Authenticated Root status:".
🐛 Proposed fix
- - "c:/usr/bin/csrutil authenticated-root status -> r:^SAuthenticated Root status: enabled"
+ - "c:/usr/bin/csrutil authenticated-root status -> r:^Authenticated Root status: enabled"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # 5.19 Enable Sealed System Volume (SSV) (Automated) | |
| - id: 18055 | |
| title: "Enable Sealed System Volume (SSV)." | |
| description: "SThe seal is verified by the boot loader at startup. macOS will not boot if system files have been tampered with. If validation fails, the user will be instructed to reinstall the operating system. During read operations for files located in the Sealed System Volume, a hash is calculated and compared to the value stored in the Merkle tree." | |
| rationale: "Running without Sealed System Volume on a production system could run the risk of Apple software, that integrates directly with macOS, being modified. " | |
| remediation: "Perform the following while booted in macOS Recovery Partition. 1. Select Terminal from the Utilities menu 2. Run the following command in Terminal: /usr/bin/csrutil enable authenticated-root 3. The output should be: Successfully enabled System authenticated root. Please restart the machine for the changes to take effect. 4. Reboot." | |
| compliance: | |
| - cis: ["5.19"] | |
| - cis_level: ["1"] | |
| condition: all | |
| rules: | |
| - "c:/usr/bin/csrutil authenticated-root status -> r:^SAuthenticated Root status: enabled" | |
| # 5.19 Enable Sealed System Volume (SSV) (Automated) | |
| - id: 18055 | |
| title: "Enable Sealed System Volume (SSV)." | |
| description: "SThe seal is verified by the boot loader at startup. macOS will not boot if system files have been tampered with. If validation fails, the user will be instructed to reinstall the operating system. During read operations for files located in the Sealed System Volume, a hash is calculated and compared to the value stored in the Merkle tree." | |
| rationale: "Running without Sealed System Volume on a production system could run the risk of Apple software, that integrates directly with macOS, being modified. " | |
| remediation: "Perform the following while booted in macOS Recovery Partition. 1. Select Terminal from the Utilities menu 2. Run the following command in Terminal: /usr/bin/csrutil enable authenticated-root 3. The output should be: Successfully enabled System authenticated root. Please restart the machine for the changes to take effect. 4. Reboot." | |
| compliance: | |
| - cis: ["5.19"] | |
| - cis_level: ["1"] | |
| condition: all | |
| rules: | |
| - "c:/usr/bin/csrutil authenticated-root status -> r:^Authenticated Root status: enabled" |
🤖 Prompt for AI Agents
In @sca/cis_apple_macOS_11.1.yml around lines 879 - 890, The regex in the rules
entry for id 18055 contains an extra leading "S" ("r:^SAuthenticated Root
status: enabled") which will never match the actual csrutil output; update the
rule string to remove the stray "S" and use the correct pattern (e.g.,
"r:^Authenticated Root status: enabled" or a more permissive pattern like
"Authenticated Root status: enabled") so the check matches the real command
output from /usr/bin/csrutil authenticated-root status.
| - 'c:sh -c "cat /etc/mongod.conf | grep \\-A12 \"ssl:\"" -> r:PEMKeyFile' | ||
| - 'c:sh -c "cat /etc/mongod.conf | grep \\-A12 "ssl:\"" -> r:clusterFile' | ||
| - 'c:sh -c "cat /etc/mongod.conf | grep \\-A12 \"ssl:\"" -> r:CAFile' |
There was a problem hiding this comment.
Quoting error in rule command will cause check to fail.
Line 83 has mismatched quotes: "ssl:\" — the opening quote is not escaped but the closing one is. Compare with lines 82 and 84 which correctly use \"ssl:\".
🐛 Proposed fix
- - 'c:sh -c "cat /etc/mongod.conf | grep \\-A12 "ssl:\"" -> r:clusterFile'
+ - 'c:sh -c "cat /etc/mongod.conf | grep \\-A12 \"ssl:\"" -> r:clusterFile'🤖 Prompt for AI Agents
In @sca/cis_mongodb_36.yml around lines 82 - 84, One of the YAML rule command
strings has mismatched quoting causing a parse error: the line containing 'c:sh
-c "cat /etc/mongod.conf | grep \\-A12 "ssl:\"" -> r:clusterFile' should match
the quoting style used on the other two rules; fix it by escaping the inner
double quotes around ssl: (i.e., use \"ssl:\") so the command becomes consistent
with the 'r:PEMKeyFile' and 'r:CAFile' entries.
| # 2.4.3 Ensure keepalive_timeout is 10 seconds or less, but not 0 (Scored) | ||
| - id: 23011 | ||
| title: "Ensure keepalive_timeout is 10 seconds or less, but not 0" | ||
| description: "Persistent connections are leveraged by all modern browsers to facilitate greater web performance. The keep-alive timeout limits the time a persistent connection may remain open. Setting the keep-alive timeout allows this timeout to be controlled on the server side." | ||
| rationale: "Setting a keep-alive timeout on the server side helps mitigate denial of service attacks that establish too many persistent connections, exhausting server resources." | ||
| remediation: "Find the HTTP or server block of your nginx configuration, and add the keepalive_timeout directive. Set it to 10 seconds or less, but not 0. This example command sets it to 10 seconds: 'keepalive_timeout 10;'" | ||
| compliance: | ||
| - cis: ["2.4.3"] | ||
| - cis_csc: ["5.1"] | ||
| references: | ||
| - http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout | ||
| condition: any | ||
| rules: | ||
| - "c:grep -ir keepalive_timeout /etc/nginx -> r:^$" | ||
| - 'c:grep -ir keepalive_timeout /etc/nginx -> r:^\s*\t*keepalive_timeout\s+(\d+) compare <= 10 && r:^\s*\t*keepalive_timeout\s+(\d+) compare > 0;' | ||
|
|
||
| # 2.4.4 Ensure send_timeout is set to 10 seconds or less, but not 0 (Scored) | ||
| - id: 23012 | ||
| title: "Ensure send_timeout is set to 10 seconds or less, but not 0" | ||
| description: "The send_timeout directive sets a timeout for transmitting a response to the client between two successive write operations." | ||
| rationale: "Setting the send_timeout directive on the server side helps mitigate slow HTTP denial of service attacks by ensuring write operations taking up large amounts of time are closed." | ||
| remediation: "Find the HTTP or server block of your nginx configuration, and add the send_timeout directive. Set it to 10 seconds or less, but not 0. 'send_timeout 10;'" | ||
| compliance: | ||
| - cis: ["2.4.4"] | ||
| references: | ||
| - https://www.owasp.org/index.php/SCG_WS_nginx | ||
| - http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout | ||
| condition: any | ||
| rules: | ||
| - "c:grep -ir send_timeout /etc/nginx -> r:^$" | ||
| - 'c:grep -ir send_timeout /etc/nginx -> r:^\s*\t*send_timeout\s+(\d+) compare <= 10 && r:^\s*\t*send_timeout\s+(\d+) compare > 0;' | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
CIS nginx benchmark 2.4.3 keepalive_timeout requirement
💡 Result:
Requirement: set keepalive_timeout to 10 seconds or less, but not 0.
Example: add to http/server block:
keepalive_timeout 10;
Source: CIS NGINX Benchmark (item 2.4.3). [1][2]
References
[1] Tenable — CIS NGINX Benchmark v2.1.0 L1 Webserver (2.4.3).
[2] Tenable — CIS NGINX Benchmark v2.1.0 L1 Proxy (2.4.3).
🌐 Web query:
nginx keepalive_timeout default value
💡 Result:
The default keepalive_timeout for client connections is 75s. [1]
(For upstream keepalive_timeout the default is 60s.) [2]
Sources: NGINX documentation. [1] https://nginx.org/en/docs/http/ngx_http_core_module.html [2] https://nginx.org/r/keepalive
🌐 Web query:
nginx send_timeout default value
💡 Result:
Default is 60 seconds (send_timeout 60s). [1][2]
Sources:
[1] nginx.org — ngx_http_core_module (send_timeout default).
[2] freenginx.org — ngx_http_core_module (send_timeout 60s).
🌐 Web query:
CIS nginx benchmark 2.4.4 send_timeout requirement
💡 Result:
CIS requirement: set nginx send_timeout to 10 seconds or less (but not 0). Example: add "send_timeout 10;" in the http/server context. Default is 60s. [1][2]
Sources:
[1] CIS NGINX Benchmark (Tenable summary).
[2] CIS NGINX Benchmark (Tenable audit page showing 2.4.4).
keepalive_timeout / send_timeout checks are inverted. Both directives default to 75s and 60s respectively (non-compliant per CIS), yet the rules use condition: any with a first rule that passes when the directive is missing. This allows the check to pass incorrectly when the non-compliant default is in effect.
Both checks must require the directive to be explicitly present and within the valid range (>0 and ≤10 seconds):
Correct fix for both checks
Replace rules and change condition for both checks 23011 and 23012:
- id: 23011
@@
- condition: any
+ condition: all
rules:
- - "c:grep -ir keepalive_timeout /etc/nginx -> r:^$"
- - 'c:grep -ir keepalive_timeout /etc/nginx -> r:^\s*\t*keepalive_timeout\s+(\d+) compare <= 10 && r:^\s*\t*keepalive_timeout\s+(\d+) compare > 0;'
+ - 'c:grep -ir keepalive_timeout /etc/nginx -> r:^\s*keepalive_timeout\s+(\d+) compare <= 10 && r:^\s*keepalive_timeout\s+(\d+) compare > 0;'Apply the same fix to check 23012 (send_timeout).
🤖 Prompt for AI Agents
In @sca/cis_nginx_1.yml around lines 227 - 258, The checks for id 23011
(keepalive_timeout) and id 23012 (send_timeout) currently use condition: any and
a rule that treats a missing directive as passing; change each check to require
the directive explicitly and validate its numeric range by setting condition:
all (or removing the rule that allows empty) and replace the rules so the first
rule ensures the directive is present (e.g., grep for the directive name must
match) and the second rule enforces r:^\s*\t*keepalive_timeout\s+(\d+) compare
<= 10 && r:^\s*\t*keepalive_timeout\s+(\d+) compare > 0 (and similarly for
send_timeout) so the check only passes when the directive exists and its value
is >0 and ≤10.
| ## 3.1.22 Ensure 'log_line_prefix' is set correctly (Automated) | ||
| - id: 24021 | ||
| title: Ensure 'log_line_prefix' is set correctly | ||
| description: > | ||
| The log_line_prefix setting specifies a printf-style string that is prefixed to each log line. | ||
| If blank, no prefix is used. You should configure this as recommended by the pgBadger | ||
| development team unless directed otherwise by your organization's logging policy. | ||
|
|
||
| % characters begin "escape sequences" that are replaced with status information as | ||
| outlined below. Unrecognized escapes are ignored. Other characters are copied straight to | ||
| the log line. Some escapes are only recognized by session processes and will be treated as | ||
| empty by background processes such as the main server process. Status information may | ||
| be aligned either left or right by specifying a numeric literal after the % and before the | ||
| option. A negative value will cause the status information to be padded on the right with | ||
| spaces to give it a minimum width, whereas a positive value will pad on the left. Padding | ||
| can be useful to aid human readability in log files. | ||
| rationale: > | ||
| Properly setting log_line_prefix allows for adding additional information to each log | ||
| entry (such as the user, or the database). Said information may then be of use in auditing or | ||
| security reviews. | ||
| remediation: | | ||
| Execute the following SQL statement(s) to remediate this setting: | ||
| postgres=# alter system set log_line_prefix = '%m [%p]: [%l-1] | ||
| db=%d,user=%u,app=%a,client=%h'; | ||
| ALTER SYSTEM | ||
| postgres=# select pg_reload_conf(); | ||
| pg_reload_conf | ||
| ---------------- | ||
| t | ||
| (1 row) | ||
| compliance: | ||
| - cis: ["3.1.22"] | ||
| - cis_csc: ["6", "6.3"] | ||
| references: | ||
| - https://pgbadger.darold.net/ | ||
| - https://www.postgresql.org/docs/current/static/runtime-config-logging.html | ||
| condition: all | ||
| rules: | ||
| - 'c:psql -U $user -h $host $db -c "SHOW log_disconnections" -> r:%m\s\[%p\]:\s\[%l-1\]\sdb=%d,user=%u,app=%a,client=%h' | ||
|
|
||
| ## 3.1.23 Ensure 'log_statement' is set correctly (Automated) | ||
| - id: 24022 | ||
| title: Ensure 'log_statement' is set correctly | ||
| description: > | ||
| The log_statement setting specifies the types of SQL statements that are logged. | ||
| It is recommended this be set to ddl unless otherwise directed by your organization's | ||
| logging policy. | ||
| rationale: > | ||
| Setting log_statement to align with your organization's security and logging policies | ||
| facilitates later auditing and review of database activities. | ||
| remediation: | | ||
| Execute the following SQL statement(s) as superuser to remediate this setting: | ||
| postgres=# alter system set log_statement='ddl'; | ||
| ALTER SYSTEM | ||
| postgres=# select pg_reload_conf(); | ||
| pg_reload_conf | ||
| ---------------- | ||
| t | ||
| (1 row) | ||
| compliance: | ||
| - cis: ["3.1.23"] | ||
| - cis_csc: ["6", "6.3"] | ||
| references: | ||
| - https://www.postgresql.org/docs/current/static/runtime-config-logging.html | ||
| condition: all | ||
| rules: | ||
| - 'c:psql -U $user -h $host $db -c "SHOW log_statement" -> r:\sdll' | ||
|
|
There was a problem hiding this comment.
Two correctness bugs: wrong SHOW target + typo ddl vs dll.
- Line 797: check for
log_line_prefixrunsSHOW log_disconnections. - Line 825: regex expects
dllbut control/remediation isddl.
Proposed fix
- - 'c:psql -U $user -h $host $db -c "SHOW log_disconnections" -> r:%m\s\[%p\]:\s\[%l-1\]\sdb=%d,user=%u,app=%a,client=%h'
+ - 'c:psql -U $user -h $host $db -c "SHOW log_line_prefix" -> r:%m\s\[%p\]:\s\[%l-1\]\sdb=%d,user=%u,app=%a,client=%h'
...
- - 'c:psql -U $user -h $host $db -c "SHOW log_statement" -> r:\sdll'
+ - 'c:psql -U $user -h $host $db -c "SHOW log_statement" -> r:\sddl'🤖 Prompt for AI Agents
In @sca/cis_postgre-sql-13.yml around lines 759 - 826, The rule is checking the
wrong setting and has a typo: update the command string that currently calls
SHOW log_disconnections to instead call SHOW log_line_prefix (change the rule
that contains c:psql -U $user -h $host $db -c "SHOW log_disconnections"), and
fix the expected regex from r:\sdll to r:\sddl so it matches the
remediation/control which sets log_statement='ddl'.


Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.