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, postgresql-stig-baseline, manual-attestation).

postgresql-stig-baseline is deliberately narrow: it evaluates exactly one rule (CD_Postgres_16_STIG / SV-261860r1000977_rule, the AU-10 audit-attribution requirement) against a Docker-hosted PostgreSQL 16 instance, and it is the only built-in scanner that also ships an apply_remediation script. See Scan, Remediate, Approve below.

1. Discover Available Recipes

pretorin recipe list
pretorin recipe show inspec-baseline

# Narrow to the scanners provisioned for the active scope
pretorin recipe list --active

A recipe whose required sources are verified missing is hidden unless you pass --include-unavailable; bind the missing source with pretorin preflight before expecting the scanner to run.

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).

Scan, Remediate, Approve

Scanning by itself only records results. The full loop — scan, reconcile the failures into the POA&M, remediate, attach the resulting evidence, and approve the leaf records — ships as a workflow playbook the calling agent reads through MCP:

list_workflows()
get_workflow(workflow_id="stig-scan-remediation")

The playbook is the contract; there is no CLI command that runs it. It walks the agent through source preflight, the exact traceability chain, the scan, the Issue and human-approved plan that authorize a fix, apply_remediation, the evidence link, and finally the two leaf approvals:

• approve_cci_implementation — requires the CCI to be past not_started with a substantive committed narrative and approval-supporting scoped evidence.
• approve_stig_rule_workflow — requires the rule to be in scope through confirmed applicability or a checklist, its latest exact-rule result to pass, verified recipe remediation evidence linked to the workflow row, and every linked Issue reconciled.

Both return HTTP 409 listing the missing prerequisites when they are not met.

Neither approval touches the parent NIST/DoD control. Approving every CCI and STIG rule under a control leaves the control itself unapproved by design — a human makes that decision in the Pretorin UI. Agents take the leaf records to audit-ready and stop there.

MCP Tools for STIG/CCI