Run a Safe OpenSCAP Baseline Check with oscap

Compliance wants a CIS baseline report by Friday, and oscap gets you an HTML report and machine-readable results without touching a single setting. This guide inspects an installed SCAP benchmark, selects a profile, runs an XCCDF evaluation and saves both outputs. Allow 10 to 30 minutes: reading the content is quick, a full profile run takes several minutes and may need root to inspect protected system state.

Run inspection commands as your normal account first. Use sudo only for the evaluation, and only if the benchmark needs access your account cannot read. Evaluation is normally read-only, but do not touch remediation until you have reviewed every proposed change.

1. Confirm the tool and content

Check the installed OpenSCAP version and supported interfaces:

oscap --version

This system has package openscap-scanner 1.3.9+dfsg-1.1ubuntu2, reporting SCAP 1.3, XCCDF 1.2 and OVAL 5.11.1 support. The version matters: profiles, probes and output detail come from both the scanner and the content package.

Set a shell variable to the benchmark you intend to inspect:

CONTENT=/usr/share/usg-benchmarks/ubuntu2404_CIS_1/ssg-ubuntu2404-xccdf.xml
test -r "$CONTENT" && echo "content is readable"

Replace the path with content from your operating system or security team. Treat downloaded SCAP files as security-sensitive input: do not enable remote fetching just to make an unknown file work.

2. Discover the benchmark

Use info before evaluation. It identifies the file type and shows the profiles and component IDs available inside a data stream:

oscap info --profiles "$CONTENT"

Typical output includes profile IDs such as xccdf_org.ssgproject.content_profile_cis_level1_server. Copy the exact ID, prefix included. A profile title is for people; --profile wants the ID.

If the file contains several XCCDF or data-stream components, inspect the full output and use --datastream-id and --xccdf-id when you need them. Without those selectors, the manual says the first applicable data stream or component gets used, which is fine for a simple file and a poor choice once precision matters.

3. Run an evaluation without changing the host

Choose the profile and write results into a new working directory:

mkdir -p "$HOME/oscap-results"
PROFILE=xccdf_org.ssgproject.content_profile_cis_level1_server
oscap xccdf eval \
  --profile "$PROFILE" \
  --results "$HOME/oscap-results/cis-level1-xccdf.xml" \
  --report "$HOME/oscap-results/cis-level1-report.html" \
  "$CONTENT"
status=$?
printf 'oscap exit status: %s\n' "$status"

The command validates the input by default, evaluates the selected rules, and writes both files. With a data stream, the manual recommends --results-arf for Asset Reporting Format output:

oscap xccdf eval \
  --profile "$PROFILE" \
  --results-arf "$HOME/oscap-results/cis-level1-results.arf.xml" \
  --report "$HOME/oscap-results/cis-level1-report.html" \
  "$CONTENT"

Warning: do not add --skip-validation as a quick fix for malformed or untrusted content. It removes a useful safety check on both input and output.

4. Read the result correctly

Open the report locally in a browser, or check its size first:

ls -lh "$HOME/oscap-results"
test -s "$HOME/oscap-results/cis-level1-report.html" && echo "report created"

The exit status is not a simple pass-or-fail flag. OpenSCAP returns 0 when every rule passes, 1 for an evaluation error, and 2 when the evaluation completed but at least one rule failed or is unknown. Capture the status immediately in a script; a later command would overwrite $?:

# Run this immediately after the evaluation block above.
case "$status" in
  0) echo "all evaluated rules passed" ;;
  2) echo "evaluation completed with failed or unknown rules" ;;
  1) echo "evaluation error" >&2 ;;
  *) echo "unexpected oscap status: $status" >&2 ;;
esac

A failed rule is evidence to investigate, not permission to apply a fix straight away. Read the rule rationale, confirm it actually applies to this host, and check whether the benchmark expects a different service or workload.

5. Review narrow checks before a full run

For a long profile, evaluate one rule first. This separates a content or permissions problem from a genuinely broad set of findings:

oscap xccdf eval \
  --profile "$PROFILE" \
  --rule xccdf_org.ssgproject.content_rule_example_rule \
  "$CONTENT"

That rule ID is a placeholder: copy a real one from the benchmark or its report. --rule can be repeated, but rules required by the selected rule are not automatically pulled in too, so a targeted check is useful for diagnosis, not a substitute for the full profile assessment.

Safety boundaries and recovery

--remediate executes fix elements during evaluation. The separate oscap xccdf remediate operation applies fixes from a saved result. Both can alter configuration, disable access or interrupt services.

Destructive action: do not use either on production systems without an approved change, a backup and a tested rollback. If you generated a fix script with oscap xccdf generate fix, review it as plain text and run it only through your normal change process. The scanner has no universal undo command; recovery means the backup, or reversing each approved change by hand.

Remote resources are another common trap. --fetch-remote-resources allows downloads referenced by the content. Prefer a trusted, locally mirrored content set and record its package version. If a data stream needs external components, --local-files DIRECTORY lets you supply local copies instead of downloading anything.