Feature Request: Per-rule/per-probe evaluation timeout with configurable action

[KyleMuncie]

Feature Request: Per-rule/per-probe evaluation timeout with configurable action

Problem

When evaluating heavy XCCDF profiles such as STIG (xccdf_org.ssgproject.content_profile_stig) on enterprise systems, certain OVAL checks that perform recursive filesystem scans consume excessive memory and time, often leading to OOM kills before the scan completes. Specifically, rules like:

• xccdf_org.ssgproject.content_rule_file_permissions_ungrouped
• xccdf_org.ssgproject.content_rule_no_files_unowned_by_user

These rules collect millions of file objects into memory with no upper bound on evaluation time. In our environment (RHEL 8, 64GB RAM hosts), a single rule can run for 30+ minutes, accumulate 20GB+ of memory, and eventually trigger the memory usage ratio limit or OOM kill — taking down the entire scan and losing all results.

Current Behavior

• No mechanism exists to limit evaluation time for individual rules or OVAL probes
• OSCAP_PROBE_MEMORY_USAGE_RATIO provides a memory ceiling but only terminates the scan — it does not skip the offending rule and continue
• The only workaround is to identify expensive rules after the fact and disable them via tailoring files, which means losing compliance coverage

Requested Feature

A configurable per-rule or per-probe timeout that, when exceeded, marks the rule with a configurable result and continues evaluation of the remaining rules. For example:

# Proposed environment variable or CLI flag
OSCAP_PROBE_RULE_TIMEOUT=300          # seconds per rule
OSCAP_PROBE_TIMEOUT_ACTION=notchecked # or "fail", "error", "informational"

oscap xccdf eval \
    --rule-timeout 300 \
    --rule-timeout-result notchecked \
    --profile xccdf_org.ssgproject.content_profile_stig \
    ssg-rhel8-ds.xml

When a rule exceeds the timeout, oscap would:

1. Terminate the active probe for that rule
2. Record the result as the configured action (notchecked, error, fail)
3. Free the collected objects from memory
4. Continue evaluating the next rule

Why This Matters

• Enterprise environments often have large filesystems that make recursive file checks impractical, but the non-filesystem STIG rules (SSH hardening, sysctl, audit policies, PAM, crypto policies, service configuration) are critical and should not be lost due to one expensive rule
• The current all-or-nothing behavior forces administrators to either accept incomplete scans or proactively disable rules via tailoring, which requires trial and error to identify the offenders
• A timeout mechanism would allow full-profile scans to complete with partial results rather than total failure

Environment

• OS: RHEL 8 (x86_64)
• OpenSCAP version: 1.3.13
• Content: ComplianceAsCode/SCAP Security Guide
• Profile: STIG (xccdf_org.ssgproject.content_profile_stig)
• Host memory: 64GB
• Observed: 4.3M file objects collected, 21GB+ memory consumed before hitting OSCAP_PROBE_MEMORY_USAGE_RATIO limit