If you’ve ever sat across a table from a CIS-CAT Pro self-attestation reviewer (or an external SOC 2 auditor doing CIS cross-validation), you know the moment when “we run hardened images” stops being a sentence and starts being a question: which images, on which assets, at which point in time, with what drift between then and now. NSAuditor AI EE 0.13.1 ships the bookkeeping that pins that conversation to evidence, across AWS, Azure, and GCP. This is the practitioner walkthrough.

Why “eligibility-only” was never going to be the finished product

EE 0.13.0 introduced CIS Critical Security Controls v8 as the sixth supported compliance framework, and it shipped a per-Safeguard cisHardenedImageCredit field. The field declared which Safeguards could earn substrate credit if the operator was actually running CIS-Hardened OS images — canonically Safeguards 4.1 (Establish and Maintain a Secure Configuration Process), 4.2 (Establish and Maintain a Secure Configuration Process for Network Infrastructure), and 4.6 (Securely Manage Enterprise Assets). What 0.13.0 explicitly deferred was the detection itself. The renderer carried a “forward capability” disclaimer.

That was the right way to ship the framework introduction — getting the per-Safeguard mapping correct first, on a 153-Safeguard universe across 18 Controls and 3 cumulative Implementation Groups, is the load-bearing work. But it also means the credit is never observed; the practitioner has to attest separately and the engine cannot cross-check. EE 0.13.1 closes that gap.

The detection plane: a pure helper plus a structured feed

The detection layer is a single pure helper at utils/cis_hardened_image.mjs. It takes a structured cisImageInventory feed that the cloud scanners produce alongside their normal findings, and decides per-cloud whether a CIS-Hardened image is in use. The architecture matters here because of a subtle invariant: positive substrate evidence cannot ride the violation channel, because harvestCloudFindings drops issue-less findings before the analysis runs. Detection runs on the rich pre-harvest source and is threaded into the analysis via opts.cisHardenedImage, the same pattern the engine already uses for opts._now.

The per-cloud signals

The classifier is intentionally conservative. A cloud Marketplace owner identifier alone never grants credit — the AWS Marketplace account 679593333241 is shared across many publishers, so a CIS-specific signal is required:

• AWS — the AMI name matches an anchored CIS-benchmark pattern, with Marketplace-owner corroboration as a secondary cross-check.
• Azure — image.publisher === center-for-internet-security-inc or the offer SKU starts with cis-.
• GCP — image.project === cis-public or a cis-* family.
• Docker — the org.cis.benchmark.profile label or a registry under cisecurity/.

Anything ambiguous yields no credit and is reported transparently. This is the discipline that keeps a “running hardened images” claim from quietly turning into a false-clean signal.

What the renderer actually says

When detection fires, the renderer flips the Safeguard from “eligible” to “observed (at scan time)” and adds three pieces of context that auditors actually use:

1. The fleet fraction. N hardened of M inspected, per cloud. If you have 200 instances and 30 use a CIS-AWS-Benchmark AMI, the report says so; it does not silently claim 100% coverage because the first instance happened to qualify.
2. The point-in-time + drift caveat. The credit is evidenced at the scan instant. It does not prove the running configuration stayed hardened across the audit period. Drift between hardened-at-launch and hardened-now is real and the report names it.
3. The operator-process-still-required caveat. Substrate credit is not operating effectiveness. The renderer says so, every time.

If detection doesn’t fire, the 0.13.0 “forward capability” disclaimer remains, telling the operator the Safeguard can earn credit but currently doesn’t.

Where the inventory feed comes from

Detection is only useful if the cloud scanners actually produce the inventory. EE 0.13.1 ships three changes there:

• NEW plugin 1210 aws-ec2-instance-auditor — the AWS producer. Multi-region by default via DescribeRegions (a single-region or zero-instance result becomes an explicit evidence-gap, never a silent compliant verdict). Alongside the AMI inventory it audits IMDSv1 (with profile-aware severity: MEDIUM with an attached IAM instance profile, LOW without), IMDSv2 hop-limit greater than one (which reopens container-credential-theft on the wire), EBS volume encryption, the account default-EBS-encryption setting, public-IP exposure including IPv6 GUA and secondary-ENI attachments, and instance-store ephemeral volumes (reported as evidence-gap because EBS encryption posture doesn’t apply).
• Azure (plugin 1022) — gains a VM-image-inventory dimension through @azure/arm-compute, soft-degrading when the optional SDK is absent.
• GCP (plugin 1021) — enumerates instances through InstancesClient.aggregatedList, then resolves each boot disk through DisksClient.get to recover the source image, since running GCP instances don’t carry the source image directly.

All three attach result.cisImageInventory. The same detection now fires on all three clouds from a single scan.

Encryption is not key access

A small but important habit plugin 1210 enforces: when an EBS volume is encrypted, the report surfaces the KMS key ID. Encryption is not key access — an encrypted volume’s confidentiality is bounded by who can kms:Decrypt its CMK. Plugin 1110 already runs effective-permission analysis on IAM identities; surfacing the key ID from 1210 lets the operator pivot rather than asserting confidentiality on Encrypted=true alone. This is the kind of detail that turns “we encrypt at rest” from a sentence into a defensible claim.

CIS density: where 9.5 Implement DMARC came from

EE 0.13.1 also moves the CIS Controls v8 matrix from 17 / 21 / 115 to 17 / 22 / 114. Plugin-1210 findings route into Safeguards 4.6 and 12.2. A separate density pass over all 115 OOS Safeguards found exactly one legitimate count-growth: Safeguard 9.5 Implement DMARC moves from OOS to partial. The evidence is the SES auditor’s DMARC posture — policy strength plus SPF and DKIM alignment for SES-managed sending identities. Candidates that would have been tempting to claim (MFA-remote, endpoint protection, remediation workflow, host-based IDS, secure SDLC) were correctly left OOS as operator-side.

The IG1 cyber-insurance baseline stays UNCHANGED at 23 of 56. The IG2 cumulative cohort moves 36 to 37 of 130, and IG3 cumulative 38 to 39 of 153. The five other framework matrices (SOC 2, HIPAA, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022) are UNCHANGED. This cycle is additive plus density-only on CIS.

The four ISO 27001:2022 deferrals close in the same cycle

EE 0.13.1 also closes the four deferrals carried from the ISO/IEC 27001:2022 introduction in 0.12.0:

• The renderer gains a Major-vs-Minor nonconformity triage matrix gated on the ISO 27001 report path, triaging Annex A findings into candidate Major, Minor, or Opportunity-for-Improvement per ISO/IEC 17021-1 — distinct from the seven systemic Clause-absence Major NCs, and with an explicit “your accredited lead auditor makes the final determination” caveat.
• A 93-control Stage-1 Statement of Applicability template ships as docs/iso-27001-soa-template.csv.
• A consolidated 93-row 2013-to-2022 migration table is appended to the ISO coverage document.
• The expectedOperatingCadence field is backfilled with a controlled vocabulary on all 31 covered and partial controls, and the documentationExpectation field completed.

What it means for the next CSAT review

If you’re heading into a CIS-CAT Pro self-attestation or a SOC 2 audit that asks for CIS cross-validation, EE 0.13.1 lets you walk in with three artefacts that didn’t exist a week ago: a per-cloud Hardened-Image fleet fraction, a multi-region EC2 posture report with per-instance evidence, and a CIS Controls v8 matrix that no longer over-claims (the conservative classifier means the credits you do show are the credits you actually have). Substrate evidence is still INPUT to self-attestation, never a “CIS certification” — and the renderer says so, every time.

npm install -g nsauditor-ai@latest @nsasoft/nsauditor-ai-ee@latest nsauditor-ai-agent-skill@latest

The CIS Controls v8 coverage matrix is at https://nsauditor.com/ai/docs/cis/ and the enterprise overview at https://nsauditor.com/ai/enterprise/.

]]>