docs(import): publish the DISA STIG checklist docs on the patch line

docs/content/federal_compliance/compliance_profile.md

@@ -49,7 +49,11 @@ Two profile settings are not on the form and are set through the compliance API:
   *do* carry their own control references are mapped from those instead; see
   [Control Coverage](../control_coverage).
 * **Configuration test types** — the test types whose findings are treated as configuration items,
-  which is what drives CM-6 consolidation in the ledger.
+  which is what drives CM-6 consolidation in the ledger. Adding the **DISA STIG Checklist** test
+  type here rolls a checklist's failed items into the single consolidated CM-6 item rather than
+  filing one POA&M item per rule — see
+  [DISA STIG Checklists](/import_data/pro/specialized_import/stig_checklists/). Whether checklist
+  items are configuration items is a per-system decision, so it is not set for you.
 
 ## Auditability
 

docs/content/federal_compliance/control_coverage.md

@@ -25,17 +25,48 @@ never produces a mapping.
 Findings that carry no control references of their own are attributed to the default scan controls
 on the Compliance Profile — see [Compliance Profile](../compliance_profile).
 
+### DISA STIG checklists, through their CCIs
+
+A STIG rule does not name an 800-53 control. It cites one or more **CCIs** (Control Correlation
+Identifiers), which is DISA's own index into the control catalog — `CCI-000366`, for example, is
+the configuration-settings CCI and resolves to `CM-6`.
+
+DefectDojo crosswalks those CCIs to their controls using DISA's published CCI list, so importing a
+checklist populates control coverage with no extra configuration. See
+[DISA STIG Checklists](/import_data/pro/specialized_import/stig_checklists/) for the import itself.
+
+The crosswalk covers the NIST 800-53 Rev 5 references DISA publishes, and like reference
+extraction it is grounded in the imported catalog. Checklists assessed against a control set the
+bundled catalog does not cover produce no mappings rather than approximate ones.
+
+### When two sources disagree
+
+A finding can pick up a control mapping from more than one source. Where they disagree, the more
+authoritative one wins, in this order:
+
+1. A mapping **you set by hand**.
+2. A **CCI crosswalk** from a STIG checklist.
+3. A control reference **extracted from the finding's own text**.
+4. The profile's **default scan controls**.
+
+A CCI crosswalk outranks text extraction because the CCI is published by the same authority that
+wrote the checklist, where an extracted reference is read out of free-form scanner output.
+
 ### Backfilling existing findings
 
-Extraction runs as findings arrive. To map findings that were already imported before the feature
-was enabled, backfill them:
+Mapping runs as findings arrive. To map findings that were already imported before the feature was
+enabled, backfill them:
 
 ```
 manage.py extract_control_mappings --product <id>
 ```
 
-Use `--all` to scan every active finding instead of one Asset. The command reports how many
-mappings it created, and it leaves manual and suppressed mappings alone.
+Use `--all` to scan every active finding instead of one Asset. Both passes — reference
+extraction and the CCI crosswalk — run by default; `--skip-scanner-refs` and `--skip-crosswalk`
+run one without the other. The command reports how many mappings each pass created, and it leaves
+manual and suppressed mappings alone.
+
+Re-running it is safe: a mapping that is already correct is left untouched.
 
 ## Correcting a mapping
 

docs/content/import_data/pro/specialized_import/stig_checklists.md

@@ -0,0 +1,109 @@
+---
+title: "DISA STIG Checklists"
+description: "Import .ckl and .cklb checklists and track the open items as findings"
+weight: 4
+audience: pro
+---
+<span style="background-color:rgba(242, 86, 29, 0.3)">Note: STIG checklist import is only available in DefectDojo Pro.</span>
+
+DefectDojo Pro imports DISA STIG Viewer checklists directly, so the items an assessor marked
+**Open** become findings you can age against an SLA, assign, report on, and remediate alongside
+everything else.
+
+Choose the **DISA STIG Checklist** scan type on the Add Findings page, or pass
+`scan_type=DISA STIG Checklist` to the import API.
+
+## Supported files
+
+Both STIG Viewer formats are read by the same scan type:
+
+* **`.ckl`** — STIG Viewer 2.x, XML.
+* **`.cklb`** — STIG Viewer 3.x, JSON.
+
+The format is detected from the file's contents rather than its name, so a checklist that was
+renamed, or exported by a tool that uses a different extension, imports the same way. A checklist
+that records several STIGs against one asset is fully imported: every benchmark's items are
+included, and each finding names the STIG it came from.
+
+One checklist describes one asset. See [Importing more than one asset](#importing-more-than-one-asset)
+below for how to organize them.
+
+## How checklist statuses map to findings
+
+Every status is imported, so the finding list mirrors the checklist rather than only its failures.
+
+| Checklist status | Finding state | Meaning |
+| --- | --- | --- |
+| Open | Active, Verified | Needs remediation |
+| Not Reviewed | Active, not Verified | Still to be assessed |
+| Not A Finding | Mitigated (inactive) | Assessed as compliant |
+| Not Applicable | Out of Scope (inactive) | Does not apply to this asset |
+
+Importing **Not Reviewed** items as active-but-unverified is deliberate: on a freshly generated
+checklist most items carry that status, and they represent assessment work that has not happened
+yet. Filter the finding list on **Verified** to separate confirmed failures from items still
+awaiting review.
+
+Re-importing an updated checklist for the same asset moves findings between these states. An item
+you have since fixed (Open → Not A Finding) closes, an item that has regressed (Not A Finding →
+Open) reopens, and an item you removed from the checklist entirely is closed as no longer reported.
+
+## Severity
+
+STIG severity is the rule's DISA category, and it maps to DefectDojo severity directly:
+
+| DISA category | Severity |
+| --- | --- |
+| CAT I (high) | High |
+| CAT II (medium) | Medium |
+| CAT III (low) | Low |
+
+The category itself is recorded in the finding's **Impact** field. If an assessor overrode the
+severity in the checklist, the override is what the finding carries, the assessor's reason is kept
+in **Severity Justification**, and Impact still shows the rule's own category — so a downgrade is
+visible rather than silent.
+
+## What each finding contains
+
+| Finding field | From the checklist |
+| --- | --- |
+| Title | The V-number and the rule title |
+| Description | Group title, rule version (STIG-ID), rule ID, the STIG itself, the discussion, and any finding details or comments the assessor recorded |
+| Mitigation | The rule's fix text |
+| Steps to Reproduce | The rule's check content — how to assess the item |
+| References | The STIG and release, and every CCI the rule cites |
+| Component | The STIG and its version and release, for example `RHEL_9_STIG` `V2R3` |
+| Endpoint | The asset the checklist was run against |
+
+The asset is taken from the checklist's own target data, preferring its FQDN, then its host name,
+then its IP address. A checklist saved without any of the three still imports; its findings simply
+carry no endpoint.
+
+## Deduplication
+
+A finding is identified by its **V-number on the asset it was assessed against**. Two consequences
+worth knowing:
+
+* The same rule failing on two different assets stays **two findings**, so per-asset remediation
+  is tracked separately.
+* Upgrading to a newer release of the same STIG **keeps finding history**. The rule ID carries a
+  revision suffix that changes with every STIG release, so it is recorded for reference only and
+  never used to identify a finding.
+
+## Importing more than one asset
+
+Because closing on re-import is driven by an item's absence from the report, give **each asset its
+own test** and re-import that asset's newer checklist into it. That is the arrangement the import
+defaults assume.
+
+If you would rather collect several assets' checklists in a single test, turn **Close Old Findings**
+off when you import, otherwise each upload will close the previous asset's items.
+
+## Compliance control coverage
+
+STIG rules cite **CCIs** (Control Correlation Identifiers), DISA's index into the NIST control
+catalog, and every CCI on a rule is recorded in the finding's references. If the
+[Federal Compliance](/federal_compliance/) feature is enabled, those CCIs are crosswalked to their
+NIST 800-53 controls automatically, so a checklist import populates
+[Control Coverage](/federal_compliance/control_coverage/) and carries control attribution into the
+POA&M ledger without any further configuration.