Audit - FAQ

Goss Binary Issues

Why does goss run manually fail?

Example error when running:

goss -g goss.yml validate

The audit is designed to run from the scripts, which pass discovered variables into goss or syver for metadata. Without these values being set, the run will fail. These metadata variables can be seen towards the end of the goss.yml file. Furthermore, the run_audit script shows how these variables are created and passed to the binary.

Solution: Use the provided run_audit.sh or run_audit.ps1 scripts. To run the binary directly, see “Running goss without script” in Audit.

Goss Binary Not Found

Symptom:

WARNING - The audit binary is not available at /usr/local/bin/syver
## Pre-checks failed please see output

Solution:

The roles use Syver, a fork of Goss, or on some roles its earlier release under the name krameff/goss. The role’s audit_bin_url and audit_bin_version defaults show which one and which release it pins, with checksums. Replace <release> below with that value, and check the download against the release’s SHA256SUMS file.

Download the correct binary for your architecture:

AMD64/x86_64:

curl -L https://github.com/krameff/syver/releases/download/<release>/syver-linux-amd64 \
    -o /usr/local/bin/syver
chmod +x /usr/local/bin/syver

ARM64/aarch64:

curl -L https://github.com/krameff/syver/releases/download/<release>/syver-linux-arm64 \
    -o /usr/local/bin/syver
chmod +x /usr/local/bin/syver

For roles that pin krameff/goss, use https://github.com/krameff/goss/releases/download/<release>/goss-linux-amd64 (or goss-linux-arm64) and /usr/local/bin/goss.

Or set AUDIT_BIN (in the script or as an environment variable) to point to the correct location.

Exec Format Error

Symptom:

syver: cannot execute binary file: Exec format error

Cause: Wrong architecture binary (e.g., x86_64 binary on ARM64 system).

Solution:

# Check your architecture
uname -m

# Download the matching binary (see above)

Goss Version Too Old

Symptom:

WARNING - Audit binary installed = <installed version>, does not meet minimum of <AUDIT_BIN_MIN_VER>

Older goss-based audit repos word this as WARNING - Goss installed = ....

Solution:

Install the release your role pins in audit_bin_version.release:

curl -L https://github.com/krameff/syver/releases/download/<release>/syver-linux-amd64 \
    -o /usr/local/bin/syver
chmod +x /usr/local/bin/syver
syver --version

Architecture-Specific Issues

Why do I have different results between x86_64 and ARM64/aarch64 audits?

ARM64 (aarch64) and x86_64 architectures use different system call numbers and implementations. This primarily affects auditd-related controls, as ARM64 uses different syscalls for many file operations (e.g., unlinkat instead of unlink, openat instead of open).

Common causes of ARM64 audit differences:

auditd syscall rules reference x86_64-specific syscalls
Some syscalls don’t exist on ARM64
Kernel module names may differ

What to expect:

Remediation generally works identically on both architectures
Audit results will show more failures/skips for auditd-related controls on ARM64
This is expected behavior, not a bug

For detailed information on ARM64 support, workarounds, and best practices, see the ARM64/aarch64 Architecture Guide.

Audit Results and Interpretation

How Do I Read the Audit Output?

The audit produces JSON output with the following structure:

{
  "results": [],
  "summary": {
    "failed-count": 10,
    "skipped-count": 5,
    "summary-line": "Count: 200, Failed: 10, Skipped: 5, Duration: 45.200s",
    "test-count": 200,
    "total-duration": 45200000000
  }
}

Key metrics:

test-count: Total tests (assertions) run
failed-count: Tests that failed
skipped-count: Tests skipped
total-duration: Run time in nanoseconds

Why Are So Many Controls Failing?

Common Causes:

System not yet remediated - Run audit after applying hardening
Controls disabled in remediation - Audit checks all controls by default
Architecture differences - ARM64 systems have expected auditd failures
Container environment - Many controls don’t apply to containers

Solution:

When running standalone, set the toggles in the audit vars file to match your remediation. Playbook runs generate this file from the role’s variables automatically.

# vars/CIS.yml - should match your remediation settings
rhel10cis_rule_1_1_1_1: true
rhel10cis_rule_1_1_1_2: false  # Disabled in remediation

Why Do I Have Failures After Successful Remediation?

Common Causes:

Reboot required - Some changes only take effect after reboot
Service restart needed - Configuration changes may need service restart
Time-based controls - Password aging, log rotation need time to apply
Manual controls - Some controls require manual intervention

Solution:

Reboot the system after remediation
Wait for time-based controls to take effect
Review manual control requirements in the benchmark documentation

How Do I Filter Audit Results?

Filter by status:

# Show only failures
cat audit_output.json | jq '.results[] | select(.successful == false)'

# Show only skipped
cat audit_output.json | jq '.results[] | select(.skipped == true)'

Filter by control ID:

# Find specific control
cat audit_output.json | jq '.results[] | select(.title | contains("1.1.1"))'

Performance and Resource Issues

My system is impacted when running the audit. How can I restrict its effect?

For the goss and Syver audits on Linux and Windows, you can limit the number of processes that run at the same time. The SCC scan in the Windows STIG roles has no equivalent setting.

This is set using a variable as part of the playbook:

audit_max_concurrent: 20  # Default is 50

Or if running manually using the run_audit script:

# Linux
./run_audit.sh -m 20

# Windows (current Windows CIS audit scripts)
.\run_audit.ps1 -MaxConcurrent 20

Audit Takes Too Long

Solutions:

Reduce concurrent processes:
```
./run_audit.sh -m 10
```

Skip heavy tests (filesystem scans):

# Role variable (playbook runs)
audit_run_heavy_tests: false

# Standalone: in the audit vars file
run_heavy_tests: false

Increase command timeout for slow systems:

# Role variable (playbook runs)
audit_cmd_timeout: 120000  # milliseconds

# Standalone: in the audit vars file
timeout_ms: 120000

Audit Causes High Disk I/O

Some controls scan the entire filesystem. To reduce impact:

Run during off-peak hours

Disable heavy tests if not required:

# Role variable (playbook runs); standalone uses run_heavy_tests in the vars file
audit_run_heavy_tests: false

Consider using ionice on Linux:
```
ionice -c 3 ./run_audit.sh
```

Script and Configuration Issues

Variables File Not Found

Symptom:

passed option '-v' /path/to/your/vars/CIS.yml does not exist

Solutions:

Verify the audit content is properly extracted:
```
ls -la /opt/RHEL10-CIS-Audit/vars/
```
Check the path passed to -v exists, or omit -v to use the default vars/CIS.yml in the content directory:
```
ls -la /path/to/your/vars/CIS.yml
```

Permission Denied Running Script

Symptom:

./run_audit.sh: Permission denied

Solutions:

Make script executable:
```
chmod +x run_audit.sh
```
Run with bash explicitly:
```
bash run_audit.sh
```
Run as root (the script exits if not run as root):
```
sudo ./run_audit.sh
```

Output File Not Created

Symptom: Audit runs but no output file is created.

Solutions:

Check output directory permissions:

ls -la /opt/  # or your configured output directory

Specify output file explicitly:

./run_audit.sh -o /tmp/audit_output.json

Check for errors in script execution:

./run_audit.sh 2>&1 | tee audit_debug.log

Container and Special Environments

Why Do Many Controls Fail in Containers?

Containers lack many components that benchmarks assume exist:

No systemd (typically)
No bootloader
No kernel access
Limited audit capabilities

Solution:

The role detects containers automatically and sets system_is_container: true, loading the container rule set (container_vars_file, default is_container.yml).

See Container and Docker Guide for details.