Run a Safe OpenSCAP Baseline Check with oscap

You will inspect an installed SCAP benchmark, select a profile, run an XCCDF evaluation and save an HTML report plus machine-readable results. The examples use OpenSCAP 1.3.9 and the Ubuntu 24.04 CIS content installed on this machine. Allow 10 to 30 minutes: reading the content is quick, but a full profile can take 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 if the benchmark needs access to files or services your account cannot read. Evaluation is normally read-only, but do not use remediation until you have reviewed every proposed change.

Checkpoint 1: confirm the tool and content

1. Check the installed OpenSCAP version and supported interfaces.

oscap --version

On this system the package is openscap-scanner 1.3.9+dfsg-1.1ubuntu2, and the command reports SCAP 1.3, XCCDF 1.2 and OVAL 5.11.1 support. The version matters: profiles, probes and output details come from both the scanner and the content package.

2. 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 supplied by 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.

Checkpoint 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, including its prefix. A profile title is for people; --profile expects the ID.

If the file contains several XCCDF or data-stream components, inspect the complete output and use --datastream-id and --xccdf-id when needed. Without those selectors, the manual says the first applicable data stream or component is used. That default is convenient for a simple file and a poor choice when precision matters.

Checkpoint 3: run an evaluation without changing the host

1. 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 creates both files. With a data stream, --results-arf is recommended by the manual 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"

Do not add --skip-validation as a quick fix for malformed or untrusted content. It suppresses input and output validation, which removes a useful safety check.

Read the result correctly

Open the report locally in a browser or inspect its size before sharing it:

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

The exit status is not a simple success-or-failure score. OpenSCAP returns 0 when all rules pass, 1 for an evaluation error, and 2 when the evaluation completed but at least one rule failed or is unknown. In a shell script, capture the status immediately; a later command would replace $?.

# 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. Read the rule rationale, confirm that it applies to this host and check whether the benchmark expects a different service or workload.

Review narrow checks before a full run

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

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

The rule ID above is a placeholder. Copy a real ID from the benchmark or its report. --rule may be repeated, but rules required by the selected rule are not automatically evaluated. That makes a targeted check useful for diagnosis, not a replacement for the 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. Use neither on production systems until you have an approved change, a backup and a tested rollback. If you generated a fix script with oscap xccdf generate fix, review it as text and run it only through your normal change process. The scanner itself has no universal undo command; recovery is the backup or the reverse of each approved change.

Remote resources are another common trap. --fetch-remote-resources permits 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 provide local copies instead of downloading them.