This tab shows what the scans can prove: ports observed listening on enclave hosts. Registration decisions — which flows cross which boundary, and what gets submitted — are an ISSM/ISSO call. Treat the export as evidence to hand up, not a finished registration. Note also that scan evidence only shows listening services; required outbound flows (NTP upstream, syslog forwarding, the vulnerability scanner reaching targets) will not appear here and still need to be accounted for.

Load last month's session file as the baseline, then load this month's scans. Everything that changed shows below — new software, removed software, hosts that appeared or dropped off, newly opened ports, and STIG applicability that shifted per host. Save this month's session at the end; next month it becomes the baseline. That sequence gives you a dated change record for sustainment without maintaining anything by hand.

One row per asset. Name, IP, MAC, OS, device type, and last scan date are pulled from scan evidence and refresh each time you load new scans. Manufacturer, model, serial, location, owner, status, and criticality can't come from a scan — fill those once and they persist in the session file.

Assets that exist but never scan (powered-off spares, standalone media stations, network gear outside scan scope) won't appear on their own. Use Add asset not detected by scan so the inventory reflects reality rather than only what the scanner can see — those entries are exactly what makes the Reconciliation tab useful.

Load a SASR-E or similar cyber-threat-intel spreadsheet (.xlsx directly, or CSV/TSV). Columns are recognized automatically through the alias table in Detection Config → intelAliases — if your feed names a column differently, add the header there and re-load; no code edits. Records are fused with the CVE-bearing findings in your scans, so remediation order follows real-world exploitation (weaponization, actor use, RF risk) rather than CVSS alone. All parsing stays in your browser.

Every severity-rated finding from the scans — including configuration findings that carry no CVE and so never appear on the Threat Intel tab. Pivot the same dataset eight ways with the view selector above: rolled up by finding, by asset (IP Summary), flat detail list, or grouped by port, plugin family, or subnet. Filters apply across every view, and findings on an IP Summary row drills into that single host.

Where threat intel is loaded, the fused priority tier and IAVM references ride along. Age is days since the vendor published a patch (falling back to plugin publication); rows past the remediation window configured in Detection Config are marked. The POA&M draft export turns open findings into line items with the decision fields left blank for the ISSM.

User accounts enumerated by credentialed scans — Windows local/domain users, group memberships, and the account-state plugin family (passwords never expire, never logged on, disabled), plus Linux user enumeration. This is scan-evidenced ground truth to reconcile against the Account Management Plan: every row here should map to an authorized account, and the flags are the exceptions worth explaining.

Scan policies must include the user-enumeration plugin families (Windows "User management" and SSH user enumeration) for this tab to populate — if it's empty on a credentialed scan, check the policy before assuming there are no findings.

Actual per-rule assessment results from SCC (SCAP Compliance Checker) XCCDF output or STIG Viewer checklists (.ckl / .cklb), including zips of either. Where the STIG Applicability tab records which baselines apply, this records which checks pass — with V-IDs, STIG IDs, CAT severities, and CCI references carried through to the exports.

Checklists also carry the manual review results that no automated scan can produce, so a host assessed by SCC alone will show those rules as Not Reviewed until the checklist is imported. The Coverage view compares what the applicability matrix claims against what was actually assessed — a STIG that applies but was never run is invisible in either artifact alone.

Every other artifact in this tool rests on the scans having actually authenticated. This tab reports what the scan says about itself: whether credentialed checks succeeded, which policy ran, how old the plugin feed was, and when it ran. An assessor asking “how do you know this inventory is complete?” is asking for this page.

A host reporting Credentialed checks : no yields OS-inference findings only. Its software inventory, account data, and STIG marks are incomplete no matter how clean they look — which is exactly the failure mode this tab exists to make visible.

One point per assessment cycle, tracking whether the posture is actually improving: findings by severity, CAT I and open STIG findings, compliance score, and sustainment exposure. This is the view leadership asks for and that no single scan can answer.

You already save a session each cycle, so history can be rebuilt retroactively — Add from prior sessions reads any number of saved session files, extracts a metrics point from each, and leaves your current dataset untouched. Setting a baseline on the Changes tab also records a point automatically.

The same evidence, cut four ways for decision-makers: Quick strikes (weaponized, confirmed on the network — act this week), Low-hanging fruit (one update clears many endpoints), Engineering campaigns (OS upgrades and fleet migrations that need planning and change control), and Modernization (unsupported components as budget-line items). Repetitive endpoint work is grouped — Windows 10 upgrade × 8 endpoints — not listed host by host.

The leadership report is a self-contained HTML file (charts included, marking-banner stamped) ready to attach to an e-mail for a commander or a COO. The AI prompt package is a ready-to-paste briefing + data digest for your approved AI assistant (NIPRGPT, Ask Sage, Claude, etc.) to draft narrative game plans — the tool itself makes no network calls, ever.

remedyWeights: how much risk one finding instance retires when its fix is applied — this is what the Remediation Plan ranks on, so an enclave tasked only on Critical/High can zero sev2/sev1 here. productAliases: merges the several ways scanners name one product (a RHEL check says firefox, the Windows plugin says Mozilla Firefox) for the Software Summary view only — the remediation plan keys on the un-aliased product, so an alias can never claim one patch covers two products that need different fixes.

catalog: master list of STIG-mapped products in export order — name, ver (STIG version shown in the header row; blank renders as ver? until you fill it from the current DISA quarterly release), active (whether it's a matrix column now), patterns (case-insensitive substrings matched against OS string + installed-software output + fired plugin names; prefix a pattern with re: to use a regular expression instead, which is how the RHEL and Windows Server entries cope with scanners reporting a version token mid-string), and optional osPatterns (OS string only). Inactive entries auto-activate the first time scan evidence hits them on any host. noisePatterns: installed-software lines to suppress from the unmapped review list. vendorRules / typeRules: first-match-wins prefill for the Software Listing's Vendor and Type columns. deviceRules: hostname-prefix → device type. listingAliases: header-name aliases for HW/SW baseline listings — add the headers your listings use and re-load, no code edits. Maintain this as STIGs release/sunset — no code changes needed.