STIG Compliance Scanning

Pretorin integrates STIG (Security Technical Implementation Guide) scanning to verify technical control implementations. The scanning workflow connects NIST 800-53 controls to specific technical checks via the CCI (Control Correlation Identifier) chain.

Traceability Chain

NIST 800-53 Control → CCIs → SRGs → STIG Rules → Scanner Results

• CCI — Control Correlation Identifier: bridges a control requirement to testable items
• SRG — Security Requirements Guide: technology-neutral security requirements
• STIG Rule — Technology-specific check with detailed test and fix procedures

Browse the Chain

Find Applicable STIGs

# Show STIGs applicable to your system
pretorin stig applicable --system "My System"

# AI-infer STIGs from system profile
pretorin stig infer --system "My System"

Explore the Traceability

# Full chain from a NIST control to STIG rules
pretorin cci chain ac-2 --system "My System"

# Browse CCIs for a control
pretorin cci list --control ac-2

# See what a specific CCI requires
pretorin cci show CCI-000015

# Browse STIG rules
pretorin stig rules <stig_id> --severity cat_i

Scanning Workflow

Scanning is driven by recipes that the calling AI agent invokes through MCP. Each scanner ships as a built-in recipe (inspec-baseline, openscap-baseline, cloud-aws-baseline, cloud-azure-baseline, manual-attestation).

1. Discover Available Recipes

pretorin recipe list
pretorin recipe show inspec-baseline

2. Review Test Manifest

The agent uses get_test_manifest (MCP) to see which STIGs and rules apply to a system before running a scan. From the CLI you can browse the relationships directly:

pretorin stig applicable --system "My System"
pretorin cci chain ac-2 --system "My System"

3. Ask the Agent to Run the Scan

Inside Claude Code, Codex CLI, or pretorin agent run, ask:

“Run an inspec-baseline scan against RHEL_9_STIG on this system.”

The agent will open a recipe context, call the recipe’s run_scan script, and submit results through submit_test_results. There is no direct CLI command for executing a scan — the recipe layer is the contract surface.

4. Submit Results Manually

If you have raw scanner output and want to upload it without running through a recipe, push it directly via MCP:

submit_test_results(system_id, results)

5. Attach Evidence to a Failing Rule

When a rule fails, attach remediation proof, mitigating-control documentation, or waiver-justification artifacts to the rule’s per-system workflow row. The workflow row is lazy-created on first attachment.

# Create the evidence
pretorin evidence upsert ac-02 fedramp-moderate \
  --name "RHEL hardening playbook output" \
  --description "Ansible run output applying CAT-I remediations" \
  --artifact-content "**Evidence**\n\n- Ansible run output applying CAT-I remediations." \
  --type configuration

# Link it to the STIG rule by catalog rule UUID
pretorin evidence link-stig <evidence_id> <stig_rule_uuid>

Add --override-system-mismatch --override-reason "<why>" to permit cross-system attachment when the evidence belongs to a different system than the active context.

Full Checklists (.ckl / .cklb) and the eMASS Handoff

submit_test_results (and the recipes above) record summarized per-rule pass/fail. When you need a full-fidelity, reviewable DISA checklist — asset metadata, the four DISA statuses, finding details/comments, and severity overrides — use the STIG Checklist Workspace: import a scanner’s output into a checklist, then export a regenerated .ckl/.cklb for the air-gapped eMASS handoff. See STIG & CCI Browsing for the full command reference.

Agent/recipe flow: scan → import → export

The openscap-baseline recipe emits a native XCCDF results document. An agent lands a reviewable checklist like this:

1. Scan. The agent runs recipe_openscap_baseline__run_scan(stig_id=..., datastream=<path>, profile=<xccdf profile id>), which returns an xccdf_results_path. A datastream is required for a real scan (without one OpenSCAP has nothing to evaluate and no results path is produced), and SSG datastreams need a profile to select rules.
2. Resolve or create the checklist. list_stig_checklists(system_id, inventory_item_id=<asset>) to reuse an existing checklist for the (benchmark, asset), or create_stig_checklist(system_id, stig_benchmark_id=<stig_id>, inventory_item_id=<asset>) to create one.
3. Import the scan (test axis). import_stig_checklist_xccdf(system_id, checklist_id, file_path=<xccdf_results_path>). The test axis is system-scoped, so the response reports how many checklists on the system the scan affects.
4. Export for eMASS. export_stig_checklist(system_id, checklist_id, format="cklb", output_path=...) regenerates the reviewable .cklb (or .ckl) with derived DISA statuses — the scan round-trips back out.

The equivalent from the CLI:

pretorin stig create-checklist --benchmark RHEL_9_STIG --asset <inventory_item_id>
pretorin stig import <checklist_id> results.xml --format xccdf
pretorin stig export <checklist_id> --format cklb --output web01.cklb

To import a hand-authored or externally-produced checklist (STIG Viewer, Evaluate-STIG, SCC) rather than a raw scan, use the review axis: pretorin stig import <checklist_id> web01.cklb (format auto-detected).

MCP Tools for STIG/CCI