What a real NSAuditor AI Enterprise scan actually produces — the console transcript, the findings as they are written, and the evidence artifacts — from one read-only run against fictional AWS, Azure, and GCP accounts. One scan → eight framework-mapped evidence packs: SOC 2, HIPAA Security Rule §164.312, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022, CIS Controls v8, GDPR Article 32 and NIST SP 800-171 Rev 2 — 29 Enterprise plugins, 80 evidence files per cloud, SHA-256 chain-of-custody sidecars and a cover-page Scope Attestation. No real customer data was used — every account, resource, and finding on this page is synthetic.
The transcript below was recorded on EE 0.40.1 — the same run that produced the
downloadable sample pack at the foot of this page. On the current release,
EE 0.44.0, a finished run like this one becomes something you can send:
nsauditor-ai report --from <run> --format executive
renders it into a self-contained, print-ready HTML report that opens with
no external network reference and names on the page, counted, any container of
finding-like records it did not read —
see what 0.44.0 adds.
Acme Corp's security engineer points NSAuditor at their AWS production account to get one octa-framework evidence pack covering SOC 2 Type II readiness, HIPAA Security Rule §164.312 Technical Safeguards, NIST CSF 2.0 Subcategory coverage, PCI DSS v4.0.1 sub-requirements (MVP-67 density), ISO/IEC 27001:2022 Annex A across all 93 controls, CIS Critical Security Controls v8 across all 153 Safeguards (17 covered + 23 partial + 113 OOS across 18 Controls / 3 cumulative Implementation Groups), the GDPR Article 32 Security-of-Processing substrate across 11 sub-measure units (4 covered + 5 partial + 2 OOS — an infrastructure substrate for Art. 32 only, not GDPR compliance), AND the NIST SP 800-171 Rev 2 substrate across all 110 requirements (2 covered + 49 partial + 59 OOS — an evidence substrate for CMMC Level 2 preparation, not a CMMC certification) — in a single 4-minute scan. Each plugin emits findings once; the compliance engine routes them across all eight framework control spaces.
# Regenerated from the run that produced the downloadable sample pack below, recorded as of EE 0.40.1. # Every figure is read from that run's own artifacts. Wall-clock timings are omitted: # the run records no total, and a plausible number is not a measured one. # as of EE 0.40.1 sentinel-host auto-scoping (--host aws + --plugins all) reached 20 AWS plugins. $ nsauditor-ai license --status ✓ Enterprise license active Org: audit@acmecorp.example · Seats: 5 · Expires: 2027-05-07 nsauditor-ai (CE): 0.2.45 @nsasoft/nsauditor-ai-ee (EE): 0.40.1 (loaded) $ nsauditor-ai scan --host aws \ --plugins all \ --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171 \ --out ./acme-audit-evidence [plugin] AWS IAM Deep Auditor (1030) ................. 2 findings [plugin] AWS S3 Security Auditor (1020) .............. 6 findings [plugin] AWS CloudTrail + CloudWatch (1040) .......... 20 findings [plugin] AWS DynamoDB Audit Integrity (1060) ......... 7 findings [plugin] AWS KMS Auditor (1070) ...................... 7 findings [plugin] AWS Lambda Security Auditor (1080) .......... 10 findings [plugin] AWS Secrets Exposure & Credential (1090) ... 5 findings [plugin] AWS CodePipeline + CodeBuild (1100) ......... 2 findings [plugin] AWS SQS/SNS Auditor (1150) .................. 14 findings [plugin] AWS IAM Effective Decrypt-Path Auditor (1110) ... 4 findings [plugin] AWS EC2 SG Perimeter Auditor (1170) ......... 9 findings [plugin] AWS EC2 Instance Auditor (1210) ............. 21 findings [plugin] AWS S3 Lifecycle + Cross-Region Repl (1120) ... 10 findings [plugin] AWS Backup Auditor (1130) ................... 7 findings [plugin] AWS SES Email Integrity Auditor (1190) ...... 2 findings ✓ 126 findings across 20 AWS plugins (10 CRITICAL · 19 HIGH · 42 MEDIUM · 10 LOW · 45 INFO) + 17 PASS-tier · 8 evidence-gaps (enumeration denied, not clean) · 9 coverage-boundary declarations [compliance] routing 126 findings → 8 framework control spaces… # coverage matrix (what the engine can speak to) → this scan's verdicts ✓ SOC 2 AICPA TSC 2017 · 51 controls (10 covered + 4 partial + 37 OOS) → 10 fail / 1 partial / 3 pass ✓ HIPAA §164.312 · 55 controls (7 covered + 3 partial + 45 OOS) → 6 fail / 1 partial / 3 pass ✓ NIST CSF 2.0 · 106 Subcategories (13 covered + 10 partial + 83 OOS) → 14 fail / 6 partial / 3 pass ✓ PCI DSS v4.0.1 MVP-67 · 67 sub-requirements (19 covered + 9 partial + 39 OOS) → 19 fail / 4 partial / 5 pass ✓ ISO/IEC 27001:2022 · 93 Annex A controls (17 covered + 14 partial + 62 OOS) → 21 fail / 6 partial / 4 pass ✓ CIS Controls v8 · 153 Safeguards (17 covered + 23 partial + 113 OOS) → 25 fail / 8 partial / 7 pass ✓ GDPR Article 32 · 11 sub-measure units (4 covered + 5 partial + 2 OOS) → 6 fail / 1 partial / 2 pass ✓ NIST SP 800-171 Rev 2 · 110 requirements (2 covered + 49 partial + 59 OOS) → 42 fail / 8 partial / 1 pass [evidence] writing 40 artifacts (8 frameworks × 5 surfaces) + a SHA-256 sidecar for each… ✓ ./acme-audit-evidence/aws_20260822_020259/ (80 files: 40 artifacts + 40 sidecars)
# Regenerated from the run that produced the downloadable sample pack below, recorded as of EE 0.40.1. # Every figure is read from that run's own artifacts. Wall-clock timings are omitted: # the run records no total, and a plausible number is not a measured one. # Azure: multi-purpose scanner (1022) + dedicated auditors 1220 / 1221 / 1222. $ nsauditor-ai scan --host azure \ --plugins all \ --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171 \ --out ./acme-azure-evidence [plugin] Azure Security Audit (1022) ................. 18 findings [plugin] Azure Storage Storage Data-Protection (1220) ... 9 findings [plugin] Azure NSG Perimeter Auditor (1221) .......... 4 findings [plugin] Azure Key Vault Deep Auditor (1222) ......... 5 findings ✓ 36 findings across 4 AZURE plugins (7 CRITICAL · 5 HIGH · 13 MEDIUM · 7 LOW · 4 INFO) + 12 PASS-tier · 3 evidence-gaps (enumeration denied, not clean) · 4 coverage-boundary declarations [compliance] routing 36 findings → 8 framework control spaces… # coverage matrix (what the engine can speak to) → this scan's verdicts ✓ SOC 2 AICPA TSC 2017 · 51 controls (10 covered + 4 partial + 37 OOS) → 7 fail / 2 partial / 5 pass ✓ HIPAA §164.312 · 55 controls (7 covered + 3 partial + 45 OOS) → 6 fail / 2 partial / 2 pass ✓ NIST CSF 2.0 · 106 Subcategories (13 covered + 10 partial + 83 OOS) → 8 fail / 10 partial / 5 pass ✓ PCI DSS v4.0.1 MVP-67 · 67 sub-requirements (19 covered + 9 partial + 39 OOS) → 9 fail / 7 partial / 12 pass ✓ ISO/IEC 27001:2022 · 93 Annex A controls (17 covered + 14 partial + 62 OOS) → 11 fail / 14 partial / 6 pass ✓ CIS Controls v8 · 153 Safeguards (17 covered + 23 partial + 113 OOS) → 10 fail / 21 partial / 9 pass ✓ GDPR Article 32 · 11 sub-measure units (4 covered + 5 partial + 2 OOS) → 4 fail / 4 partial / 1 pass ✓ NIST SP 800-171 Rev 2 · 110 requirements (2 covered + 49 partial + 59 OOS) → 29 fail / 21 partial / 1 pass [evidence] writing 40 artifacts (8 frameworks × 5 surfaces) + a SHA-256 sidecar for each… ✓ ./acme-azure-evidence/azure_20260822_020904/ (80 files: 40 artifacts + 40 sidecars)
Below are thirteen findings — nine from the AWS scan above plus four from the paired Azure scan:
three from the storage auditor (plugin 1220) and one from the Azure NSG perimeter auditor (plugin 1221).
The AWS set includes an object-version S3 finding — a public ACL on a
non-current (overwritten) object version with a public WRITE-class grant —
picked to span the severity range and showcase the multi-framework routing. The
CC / §164.312 / PR.DS / 3.5 control badges show
which controls each finding routes to under each framework.
acme-legacy-assets/customer-export.csv is private on its current version, but a NON-CURRENT (overwritten) version carries a public AllUsers ACL — still downloadable at ?versionId=… — and the grant includes WRITE (world-writable)
ListObjectVersions path the current-object scan
never reaches. The current version of customer-export.csv is private — a current-object-only
scanner calls it clean. But someone once published it public-read-write, then "fixed" it
with a private overwrite; S3 keeps the old version, and it still serves to the anonymous internet at
?versionId=…. The auditor samples non-current versions on versioning-Enabled
AND Suspended buckets (Suspended still retains old versions — the exact silent-overwrite case),
skips delete-markers, and reads each with GetObjectAcl({Key, VersionId}); a public
AllUsers/AuthenticatedUsers grant emits CRITICAL riding the same
"publicly accessible" anchor as the bucket/object-ACL dims — so it routes to the identical
controls with zero new framework mappings. The grant here is
WRITE-class (WRITE/WRITE_ACP/FULL_CONTROL), so the
finding adds "public WRITE-class access … – anyone can overwrite contents" — distinguishing
anyone-can-overwrite (defacement / supply-chain / malware-staging) from
anyone-can-download. Honoring the conservative-classifier principle, if the scanner role lacks
s3:ListBucketVersions or s3:GetBucketVersioning the version surface is NOT a
silent PASS — it degrades to a routed LOW evidence-gap (CC7.1 / §164.312(b)). Remediate: delete or
re-private the offending version, then enable Object Ownership BucketOwnerEnforced to make
ACL-based public access structurally impossible. All seven coverage matrices UNCHANGED.
acmeprodsa01 allows plaintext HTTP (enableHttpsTrafficOnly=false) — data in transit is not encrypted
minimumTlsVersion=TLS1_0 (downgrade-attackable — MEDIUM,
CC6.7), allowSharedKeyAccess=true (bypasses Azure AD identity — MEDIUM, CC6.1), and
no infrastructure double-encryption (LOW, C1.1). Azure field-default discipline: an absent
allowSharedKeyAccess is treated as ENABLED, never a silent PASS. Remediate with
HTTPS-only + a TLS1_2 floor + Azure AD-only authorization. This auditor spans seven dims,
including blob recoverability (soft-delete + versioning — A1.2) and per-container anonymous
public-access detection (account-toggle-aware — a public container under allowBlobPublicAccess=true
is the Azure analog of a public S3 bucket; C1.1) via the secondary blob-service / container API paths.
acmepublicsa01 has 1 blob container (public-assets) with anonymous public access AND account-level allowBlobPublicAccess=true — EFFECTIVE exposure
blobContainers.list path the
account-level checks never reach. This account is hardened on every encryption / transit / auth dim,
so an account-level scan would call it clean — but the public-assets container is set to
publicAccess=Blob while the account toggle allowBlobPublicAccess=true is on,
making its blobs anonymous-internet-readable (the Azure analog of a public S3 bucket). The dim is
account-toggle-aware: had the toggle been false, Azure would override the
container to private and the finding would downgrade to MEDIUM (latent). Remediate: set the container
to publicAccess=None (or disable allowBlobPublicAccess account-wide).
acmeprodsa01 has blob soft-delete DISABLED (deleteRetentionPolicy.enabled=false) — deleted blobs are unrecoverable
blobServices.getServiceProperties
surface: this account has no blob soft-delete window, so an accidental, ransomware, or insider
Remove-AzStorageBlob is permanent — and blob versioning is off too, so an overwrite has no
prior-version recovery. An account fully hardened on the five encryption / transit / auth dims is still
one delete from data loss. A denied getServiceProperties read degrades to a LOW evidence-gap,
never a silent recoverability PASS. Remediate: enable blob soft-delete (≥7-day retention) + versioning.
(No PCI DSS routing — PCI v4.0.1 has no covered backup/recoverability sub-requirement in the engine's scope.)
acme-app-nsg permits TCP inbound from a public source (Internet) to restricted port(s) 22 (SSH), 3389 (RDP) — EFFECTIVE exposure (attached to 1 subnet)
DenyAllInBound default at priority 65500) per restricted
management/data-tier port — so a higher-priority Deny that actually neutralizes a permissive
Allow is resolved correctly, not blindly flagged. Here acme-app-nsg allows SSH (22)
and RDP (3389) from the Internet service tag with no overriding deny, and the NSG is
attached to acme-app-subnet — so this is an EFFECTIVE exposure
(CRITICAL). Had the NSG been orphaned (attached to no subnet/NIC), the same rule would downgrade to
MEDIUM (latent) — it applies to nothing until associated. The auditor also catches the
dimensions a flat per-rule lint misses: ::/0 IPv6-wildcard sources, all-protocol (*)
rules, and the 0.0.0.0/1 split-range internet-evasion. It is non-overlapping-by-depth with the
multi-purpose scanner's coarse NSG check — distinct source, distinct control (CC6.6), no double-emission.
Remediate: scope the source to the operator's bastion / VPN CIDR.
This same plugin includes a public-internet UDP restricted-port lane (Dim 2u/3u) — so public-source UDP management/amplification services (SNMP 161, CLDAP 389, NTP 123, rpcbind 111, IPMI 623, IKE 500, Memcached 11211, RADIUS/L2TP/SIP/mDNS/RIP/XDMCP/chargen) are not silently treated as benign, not just TCP, and a restricted-port-exposure lane to the tenant-rentable AzureCloud service tags. (That work landed in EE 0.32.11 (2026-08-03) — the dependency-advisory release gate now packs the tarball, installs it the way a customer does and audits that, and refuses to report clean until an advisory database has answered: the development tree carried 25 advisories / 8 HIGH, the closure a customer installs 6 / 0 HIGH, the two lists sharing 5 of 26 packages and zero high-severity ones. SOC 2 is enumerated in full at 10 covered / 4 partial / 37 out of scope = 51 — enumeration completeness, not a coverage change: no control changed status, no routing changed, and the other six matrices are unchanged. That release carried 28 plugins and seven frameworks, unchanged. The prior EE 0.32.9 (2026-07-29) was the internal-provenance strip: 686 unexplained internal-marker occurrences went to 0 across 105 files in a rebuilt three-cloud evidence pack, with a positive control in the same run still detecting 3,572 benign matches; plus the false-clean closure, so every in-scope control of a cloud that could not be scanned carries a fail-closed evidence gap. The Vanta + Drata + Secureframe GRC connector trio shipped in 0.32.x remains available (set COMPLIANCE_GRC_PROVIDER=vanta|drata|secureframe + COMPLIANCE_GRC_TOKEN; opt-in outbound push, records model, Zero-Data-Exfiltration-redacted egress, token never serialized; suppression-aware outcomes, framework-dimensioned idempotency, rate-limit backoff, circuit breaker; single-workspace, operator-configured — not a multi-tenant sync).
acme-audit-store has neither PITR nor deletion protection enabled
DeleteTable API call vaporizes the table AND no continuous backup
exists to recover. Worst-case audit-the-auditor failure: the audit record itself is
not survivable. Enable both Point-in-Time Recovery (PI1.5 substrate) AND deletion
protection (C1.1 recoverability). Same finding routes to HIPAA §164.312(c)(1) Integrity
(ePHI must not be improperly altered or destroyed) and PCI DSS 3.5 (stored cardholder
data protection from loss).
bob (user) has effective kms:Decrypt on Resource:* via inline policy
Action:[*] on Resource:[*].
CC6.1 / C1.1 / CC6.3 blast-radius: principal can decrypt EVERY KMS key whose key policy
permits the principal — confidentiality blast-radius is account-wide for any
wildcard-permissive key policy. Replace Resource:* with specific key ARNs
+ apply a Permissions Boundary capping the effective key set. Routes to HIPAA §164.312(a)(1)
Access Control (ePHI encryption-key access boundary) and PCI DSS 7.2.1 (access control
by job function with least privilege).
acme-audit-store uses AWS-owned default encryption (no SSE-KMS customer-managed key)
acme-export-fn has public function URL with AuthType=NONE and resource-policy Principal:"*"
DB_PASSWORD and API_KEY in the runtime environment
variables, this is an exfiltration channel. CC6.6 (external-perimeter access controls)
and HIPAA §164.312(e)(1) (transmission security boundary) both fail. PCI DSS 1.4.2 (NSC
between trusted and untrusted networks) + 8.6.1 (interactive use restriction on accounts
used by systems) route the same finding. Apply IAM auth or VPC-private function URL.
aabbccdd-1111-2222-3333-444455556666 has a grant authorizing Decrypt to a principal with NO identity-policy grant for kms:Decrypt (Pacu P-16 stealth path)
arn:aws:sts::111122223333:assumed-role/acme-fixture-exec-role/acme-export-fn
— but that principal has NO identity-policy grant for kms:Decrypt. The grant
bypasses identity-policy enforcement entirely. The principal can recover plaintext from
data encrypted under this key without any IAM policy mentioning kms:Decrypt.
Pacu P-16 stealth path — auditor-detectable. Verify the grant is intentional + revoke
if the principal should not have decrypt capability on this key.
acme-db-creds has rotation DISABLED
secretsmanager:RotateSecret with a 30-day schedule.
aabbccdd-1111-2222-3333-444455556666 has automatic key rotation DISABLED
kms:EnableKeyRotation, or document the manual rotation procedure for auditor
walkthrough. PCI DSS 3.6.4 explicitly requires cryptographic key rotation at the end of
defined cryptoperiods + when key integrity is weakened — auditors require evidence of
rotation events, not just configuration.
acme-compliant-store has Point-in-Time Recovery (PITR) enabled
pass findings on COMPLIANT resources — these are the auditor's positive
evidence that the control IS operating, not just an absence of failures. A SOC 2 Type II
audit specifically requires evidence the control WAS in operation across the observation
period; pass-findings populate that evidence stream.
Each finding above appears in all eight framework reports automatically. The plugin
emits the finding once; the compliance engine routes it across SOC 2 + HIPAA +
NIST CSF 2.0 + PCI DSS + ISO/IEC 27001:2022 + CIS Controls v8 + GDPR Article 32 + NIST SP 800-171 Rev 2 control spaces in a single pass. This is the
one scan, eight frameworks contract — no double-scanning, no double-billing
for AWS API calls, no risk of cross-framework drift.
The framework-routing rules live in data/compliance/{soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171}.json
and inherit from soc2.json's grep-verified plugin-emission pattern set per
the institutional inheritance-contract discipline. A finding pattern that doesn't appear
in soc2.json cannot leak through to the other seven framework JSONs —
defended by automated anchor-drift tests at every release (including sharp doesNotMatch
cross-framework citation-leak regex defense; the CIS v8 mapping contributes 31 such tests).
NSAuditor closes five GCP false-negatives — exposures a previous build called clean. Acme's engineer
points NSAuditor at the GCP project acme-prod-3f8a1c and the same compliance engine routes
every GCP finding across all eight framework control spaces. The headline misses now caught: a GCS bucket
public via a legacy ACL while uniform bucket-level access (UBLA) is
disabled — the surface the IAM-only check never read (plugin 1024); a project-scope
roles/iam.serviceAccountKeyAdmin binding that lets a principal
mint long-lived keys for ANY service account (offline impersonation,
plugin 1025); a custom role granting iam.serviceAccounts.actAs reached through a
serviceAccountTokenCreator edge — a transitive impersonation
path (plugin 1025); and the classic 0.0.0.0/0 default-allow-ssh/rdp/icmp firewall rules
(plugin 1021).
The GCP client/auth handling lets the GCP IAM Project-Level Auditor (plugin 1025) read the
project IAM policy and run its service-account / impersonation dimensions (Dim 4-6) under
pure Application Default Credentials — no
GOOGLE_APPLICATION_CREDENTIALS key file and no
GOOGLE_IMPERSONATE_SERVICE_ACCOUNT required. A prior build failed the project-IAM read
(getIamPolicy is not a function) and silently skipped the impersonation graph; the
GCP client and ADC fixes make
that surface real, and an API denial now degrades to an explicit evidence-gap verdict — never a silent
clean. All seven coverage matrices are UNCHANGED — this is substrate-depth uplift on perimeter, access-control,
and data-protection controls already in scope.
# Regenerated from the run that produced the downloadable sample pack below, recorded as of EE 0.40.1. # Every figure is read from that run's own artifacts. Wall-clock timings are omitted: # the run records no total, and a plausible number is not a measured one. # GCP: ADC via gcloud auth application-default login; plugins 1021 + 1024 + 1025. $ nsauditor-ai scan --host gcp \ --plugins all \ --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171 \ --out ./acme-gcp-evidence [plugin] GCP Security Audit (1021) ................... 5 findings [plugin] GCP Cloud Storage Auditor (1024) ............ 4 findings [plugin] GCP IAM Project-Level Auditor (1025) ........ 12 findings ✓ 21 findings across 3 GCP plugins (5 CRITICAL · 2 HIGH · 11 MEDIUM · 3 INFO) + 11 PASS-tier · 0 evidence-gaps (enumeration denied, not clean) · 3 coverage-boundary declarations [compliance] routing 21 findings → 8 framework control spaces… # coverage matrix (what the engine can speak to) → this scan's verdicts ✓ SOC 2 AICPA TSC 2017 · 51 controls (10 covered + 4 partial + 37 OOS) → 5 fail / 4 partial / 5 pass ✓ HIPAA §164.312 · 55 controls (7 covered + 3 partial + 45 OOS) → 3 fail / 3 partial / 4 pass ✓ NIST CSF 2.0 · 106 Subcategories (13 covered + 10 partial + 83 OOS) → 1 fail / 10 partial / 12 pass ✓ PCI DSS v4.0.1 MVP-67 · 67 sub-requirements (19 covered + 9 partial + 39 OOS) → 3 fail / 9 partial / 16 pass ✓ ISO/IEC 27001:2022 · 93 Annex A controls (17 covered + 14 partial + 62 OOS) → 3 fail / 14 partial / 14 pass ✓ CIS Controls v8 · 153 Safeguards (17 covered + 23 partial + 113 OOS) → 1 fail / 23 partial / 16 pass ✓ GDPR Article 32 · 11 sub-measure units (4 covered + 5 partial + 2 OOS) → 1 fail / 5 partial / 3 pass ✓ NIST SP 800-171 Rev 2 · 110 requirements (2 covered + 49 partial + 59 OOS) → 16 fail / 33 partial / 2 pass [evidence] writing 40 artifacts (8 frameworks × 5 surfaces) + a SHA-256 sidecar for each… ✓ ./acme-gcp-evidence/gcp_20260822_021608/ (80 files: 40 artifacts + 40 sidecars)
The four GCP findings below span the severity range and showcase the GCP false-negative hardening. Each routes
across all eight frameworks; the CC / §164.312 / PR / 3.3
control badges show the per-framework destination.
acme-public-assets is public via a LEGACY object ACL (allUsers:READER) while uniform bucket-level access (UBLA) is DISABLED — anonymous-internet readable
_auditLegacyAcls dimension walks the per-object / bucket legacy-ACL
surface the IAM-only check never read. With uniform bucket-level access disabled, GCS
still honors fine-grained legacy ACLs — and this bucket carries an allUsers (and
allAuthenticatedUsers-class) READER grant, making its objects
anonymous-internet readable (the GCP analog of a public S3 bucket). A scanner that only reads the
bucket's IAM policy (which here grants nothing public) calls it clean — a false negative. The fix is
UBLA-state-aware: had UBLA been enabled, legacy ACLs would be ignored by GCS and the
finding would not fire. Remediate: remove the allUsers/allAuthenticatedUsers
ACL grants, then enable uniform bucket-level access to make ACL-based public access structurally
impossible. Routes to CC6.6 (external-perimeter access) + CC6.1 + C1.1 and HIPAA §164.312(a)(1) Access
Control. All seven coverage matrices UNCHANGED.
roles/iam.serviceAccountKeyAdmin to ci-deploy-sa — can mint long-lived keys for ANY service account in acme-prod-3f8a1c (offline impersonation)
roles/iam.serviceAccountKeyAdmin binding. That role can
create user-managed keys for every service account in the project — including the
privileged ones — and a downloaded key is a credential that works offline, indefinitely,
outside any session or Conditional-access boundary. So this binding is effectively
impersonate-anyone: the holder mints a key for a high-privilege SA and acts as it with no further
authorization step. The auditor treats project-scope key-admin as a CRITICAL privilege-escalation
primitive distinct from a direct sensitive-role grant (Dim 2). Remediate: remove the project-level
serviceAccountKeyAdmin binding, scope key administration to specific SAs only if truly
required, and prefer short-lived credentials (workload identity / impersonation with conditions) over
downloadable keys. Routes to CC6.1 + CC6.3 and HIPAA §164.312(a)(1) Access Control.
acme.batchOperator grants iam.serviceAccounts.actAs, reached by data-export-sa via a serviceAccountTokenCreator edge → impersonation PATH to backup-runner-sa
acme.batchOperator includes the bare permission
iam.serviceAccounts.actAs (not the named roles/iam.serviceAccountUser, so a
role-name-only check misses it), and data-export-sa reaches the privileged
backup-runner-sa through a roles/iam.serviceAccountTokenCreator edge — a
transitive impersonation path, not a direct grant. The finding emits the resolved path
so an auditor can trace the escalation hop-by-hop. The graph is built only because the project-IAM read
now succeeds under pure ADC (a prior build skipped it). Remediate: remove
iam.serviceAccounts.actAs from the custom role or break the
tokenCreator edge; prefer scoped, conditioned impersonation. Routes to CC6.1 + CC6.3 and
HIPAA §164.312(a)(1).
default-allow-ssh / default-allow-rdp / default-allow-icmp permit ingress from 0.0.0.0/0 to tcp:22, tcp:3389, and icmp:all
default-allow-ssh opens
tcp:22 (credential brute-force + lateral-movement pathway), default-allow-rdp
opens tcp:3389 (a primary ransomware / credential-attack vector), and
default-allow-icmp opens icmp:all (reconnaissance + DoS). Each is rated
CRITICAL. These bypass network-segmentation principles and expose management surfaces
to the entire internet. Remediate: delete the default-allow rules (or scope their source ranges to the
operator's bastion / VPN CIDR) and replace with least-privilege ingress. Routes to CC6.6
(external-perimeter access controls) + HIPAA §164.312(a)(1) + PCI DSS 1.2.1/1.3.1/1.4.1.
A false positive wastes an analyst's time; a false negative ships a "you're secure" verdict over a
live hole. The GCP cycle closes four such holes — the legacy-ACL public bucket (1024), the
project-scope key-admin impersonation primitive and the transitive actAs path (1025), and
the IAM read that previously failed shut (the GCP client and ADC fixes) — and routes each to the
producing source's own native controls, never a mirror. The one scan, eight frameworks
contract holds for GCP exactly as it does for AWS and Azure: each plugin emits once; the compliance
engine fans the finding across SOC 2 + HIPAA + NIST CSF 2.0 + PCI DSS + ISO/IEC 27001:2022 +
CIS Controls v8 + GDPR Article 32 + NIST SP 800-171 Rev 2. The seven pre-existing matrix counts are UNCHANGED.
Each framework defines its own control universe + sub-categorization + audit discipline. The matrix counts below show how the same 126 plugin-emitted AWS findings populate each framework's in-scope control set, with the remainder explicitly labeled out-of-scope (architecturally not addressable by infrastructure scanning, paired with the named non-engine evidence streams operators need).
CC6.1 · CC6.3 · CC6.6 · CC7.1 · CC7.2 · CC8.1 · C1.1 · PI1.5. OOS architectural: physical-datacenter controls, vendor management, change-management process evidence. Pair with operator-side change-management trail.
§164.312(a)(1) · §164.312(a)(2)(iv) · §164.312(b) · §164.312(c)(1) · §164.312(d) · §164.312(e)(1). 45 OOS = entire §164.308 Administrative + §164.310 Physical Safeguards (architecturally OOS for any cloud-tenant scanner). Pair with HRIS + facility access logs.
PR.AA-01 · PR.AA-05 · PR.DS-01 · PR.DS-11 · PR.IR-01 · DE.CM-01 · DE.CM-09. 83 OOS by-design: entire Govern function (policy/strategy) + entire Respond function (IR runbook execution) + Implementation Tiers 1-4 (organizational maturity). Pair with TPRM + IR platform.
1.2.1 · 3.5.1.2 · 3.6.4 · 7.2.1 · 7.2.4 · 8.3.10.1 · 8.6.1 · 10.2.1. 39 OOS: Req 3 stored-CHD attestation + Req 5 anti-malware + Req 9 physical + Req 11 ASV/pen-test + Req 12 governance. Pair with QSA-aware GRC + ASV.
A.5.15 · A.5.17 · A.5.18 · A.5.23 ⭐NEW · A.8.2 · A.8.5 · A.8.9 ⭐NEW · A.8.13 · A.8.16 ⭐NEW · A.8.20 · A.8.24. 62 OOS by-design: ISMS Clauses 4-10 entirely (7 Major Nonconformity classes — absence of Clause 9.2 internal audit or Clause 9.3 management review = auto-fail Stage 2) + Theme A.6 People (HR system) + Theme A.7 Physical (cloud-provider ISO 27001:2022 Certificate inheritance for cloud-hosted). Pair with ISO-aware GRC (Drata ISO 27001 / Vanta ISO 27001 / AuditBoard / OneTrust ISMS / Secureframe). Statement of Applicability per Clause 6.1.3.d discipline + 5-attribute taxonomy + 2013-to-2022 transition discipline (deadline October 31, 2025 passed).
2.2 · 3.3 · 3.10 · 3.11 · 4.4 · 5.1 · 5.4 · 6.3 · 6.5 · 7.5 · 8.2 · 11.2 · 11.3 · 11.4 · 12.2 · 13.1. Implementation Group cumulative discipline — engine substrate evidences IG1 23-of-56 (the cyber-insurance baseline; ~50-70% of mid-market policies require IG1 attestation) / IG2-cumulative 38-of-130 / IG3-cumulative 40-of-153; the remainder are operator-side process/endpoint artifacts. NEVER report IG2 as 74-of-74 in isolation — the IG1 base must be intact before any IG2/IG3 claim. 113 OOS by-design: Control 14 Security Awareness Training (LMS) + Control 17 Incident Response + Control 18 Penetration Testing + Control 10 Malware Defenses (endpoint EDR) entirely. No-certification-body attestation — this is INPUT to your CSAT / CIS-CAT Pro self-attestation or a SOC 2 auditor cross-validating CIS scope, never "CIS certified." Cloud Companion Guide v8 + CIS-Hardened-Image credit (4.1/4.2/4.6) + 5 Security Functions (NOT 6 — no Govern) + MS-ISAC/EI-ISAC/H-ISAC sector baselines.
Art. 32(1)(a) pseudonymisation/encryption · Art. 32(1)(b) confidentiality/integrity/availability/resilience · Art. 32(1)(d) regular testing/assessment · Art. 32(2) risk-appropriate measures. The engine produces substrate for the operator's four-factor proportionality determination (state of the art / cost of implementation / nature-scope-context-purposes / risk) — nothing is absolute pass/fail, and an unencrypted resource is only an Art. 32 finding if it holds personal data (a scope the scanner cannot know — operator-attested). 2 OOS by-design: Art. 32(1)(c) restore-availability-after-incident (backup/DR-runbook execution) + Art. 32(4) processor-instruction governance (Art. 28 agreement). The rest of GDPR (lawful basis Art. 6 / consent Art. 7 / DSARs Art. 12-23 / records Art. 30 / breach-notification Art. 33-34) is OOS-by-design — Art. 32 is the ONLY article an infrastructure scanner can substrate-evidence. Art. 83(4) lower-tier exposure (2% / €10M), NOT the 4% / €20M headline tier. Cloud-provider ISO 27001 / SOC 2 / EU Cloud CoC adherence (Art. 32(3) / Art. 42) is annual-currency demonstrable-compliance evidence. This is an infrastructure substrate for Art. 32 only — never "GDPR certified."
3.8.9 backup-media confidentiality · 3.13.16 CUI-at-rest confidentiality. Covered is rare here by construction — a requirement qualifies only when EVERY one of its SP 800-171A determination statements is a statement about technical system state the scan reads directly, and almost every requirement retains an objective about a defined procedure, an identified set, or an organization-defined parameter that configuration cannot evidence. Exactly two clear that bar. The 49 partial entries each declare WHICH shortfall applies — objective-subset, within-objective or contributory-only — because “partial” hides three genuinely different situations and an assessor needs the shape of the gap. 59 OOS by-design: families 3.2 Awareness and Training, 3.6 Incident Response, 3.7 Maintenance, 3.9 Personnel Security and 3.10 Physical Protection entirely, plus the SSP (3.12.4) and POA&M (3.12.2) — the operator artifacts an assessment is conducted against, never outputs of it — plus wireless/mobile/removable-media, endpoint malicious-code protection, and process/policy/documentation requirements. 3.3.7 clock synchronization is deliberately not claimed: this engine ships no time-source measurement. CUI scope is the operator’s assertion — the scanner cannot see CUI, cannot distinguish FCI from CUI, and cannot see an enclave boundary; running in a government region is not a boundary and inherited FedRAMP-Moderate equivalency is a Customer Responsibility Matrix question, never a transferred authorization. Rev 2 is pinned: CMMC assesses Rev 2 by rule, and Rev 3 is a different 97-requirement universe, so Rev 3 numbering in a Rev 2 citation is drift rather than currency. ⚠ The id namespace collides exactly with PCI DSS — 3.5.1 names a real requirement in both standards — so every citation must carry its qualifier. This is preparation substrate for a C3PAO assessment; deliberately not claimed, in these exact words: CMMC certified, CMMC compliant, CMMC ready, FedRAMP authorized, any MET / NOT MET verdict, or any SPRS score.
The fourth framework, joined by ISO/IEC 27001:2022 as the fifth, ships sub-requirement-level mapping per the PCI SSC RoC Reporting Template Appendix B (NOT Requirement-level, which would hide gap structure). Every covered + partial control carries four institutional schema enrichments designed to defend against the QSA-detectable overclaim patterns surfaced by an adversarial audit of the mapping from a Qualified Security Assessor's perspective.
Per Appendix E of PCI DSS v4.0.1, fifteen sub-requirements explicitly disallow the Customized
Approach. The engine carries approachEligibility: 'defined-only' +
customizedApproachObjective: null on each, with positive-defense tests asserting
every Appendix-E ID appears in the framework JSON. Misclassifying a Defined-only sub-req as
Customized-eligible is the PCI analog of HIPAA's "Addressable as Required" overclaim — block.
# 15 Defined-only sub-requirements — Customized Approach not permitted 3.2.1 PAN retention limited 3.3.1 SAD not retained after authorization (full track data) 3.3.2 SAD not retained — CAV2/CVC2/CVV2/CID 3.3.3 SAD not retained — PIN/PIN block 4.2.1.1 Trusted keys/certificates inventory 4.2.2 PAN secured via end-user messaging technologies 4.2.2.1 PAN-via-end-user-messaging policy 8.2.1 Unique user IDs 8.2.5 Terminated user access immediately revoked 11.3.2 External vulnerability scans by ASV 11.5.2 Payment-page tamper detection (Magecart) 11.6.1 Payment-page script integrity / change-detection 12.3.1 Targeted Risk Analysis methodology 12.3.2 Customized Approach Documentation 12.8.5 TPSP Responsibility Matrix 12.10.4 Incident-response personnel training
The engine cannot determine Cardholder Data Environment scope from infrastructure
scanning alone. Requirements 3 + 4 + 5 + 9 + 12 all gate on operator's CDE Data Flow
Diagram per Req 1.2.4 + Req 12.5.1. The rendered PCI DSS report surfaces this as a
cover-page disclaimer; per-control findings carry cdeScopeCaveat when the
operator has not tagged the in-scope resources.
Pair the engine with a QSA-aware GRC (Drata PCI / Vanta PCI / AuditBoard PCI / OneTrust GRC / ServiceNow IRM) that handles the CDE Data Flow Diagram, vendor TPSP Responsibility Matrices (Req 12.8.5), and the PCI DSS RoC Reporting Template assembly. The engine produces the substrate-evidence package; the GRC + QSA produce the RoC.
Every octa-framework scan emits 80 evidence files per cloud, plus the raw scan-conclusion artifacts. Each framework gets five artifact surfaces — three report formats (Markdown + HTML + JSON) plus a scope attestation and a chain-of-custody manifest — and every one of the five carries its own SHA-256 sidecar, so ten files per framework. All cryptographically bound so an auditor can verify the artifact set hasn't drifted from the scan event that produced it.
scan_compliance_{soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171}.{md,html,json} — 24 files
total. Markdown for human review + check-in to evidence repo. HTML for sharing with
auditors + executive summary. JSON for GRC ingestion + machine-readable diffing.
scan_attestation_{framework}.json — the cover-page Scope Attestation envelope
recording what was in scope, what was scanned, and the SHA-256 digest of each artifact.
(What the envelope evidences is the digest set and the scan scope. Trusted timestamping over those digests is opt-in as of EE 0.33.0 — set NSAUDITOR_TSA_URL to a Time-Stamp Authority you choose and each artifact gets an RFC 3161 .tsr sidecar your auditor verifies offline with openssl ts -verify. It is opt-in with no default ever, because a baked-in default would be third-party egress nobody asked for. Verified against a real authority on 2026-08-07: Status Granted, Verification: OK, and a one-byte change to the artifact flips it to FAILED. Signing the envelope itself is a
separate, operator-run step that landed in EE 0.38.0 as the compliance sign-pack /
verify-pack pair: CLI-only, off until you set it up, and because the Ed25519 key is
yours, a verified signature establishes authorship relative to your own key custody —
never a vendor attestation
(setup in the getting-started guide).
If you need a third-party time anchor, apply
it to the SHA-256 digests outside the tool.)
scan_chain_of_custody_{framework}.json — tamper-evident lineage from the
AWS event that produced each finding, through the scanner, to the evidence file. Each
step carries a timestamp + hash so an auditor can trace any single finding back to its
source system event.
.sha256 per evidence artifact (120 across the three cloud scans and all eight frameworks, raw conclusions included).
Allows downstream consumers to verify file integrity without re-running the scan.
scan_conclusion_raw.{json,html} — network-scan substrate.
Used by the continuous-monitoring mode (--watch) to surface only new
findings since the prior scan.
# Install the trio (CE is the free runtime; EE adds the 29 plugins + 8 frameworks) $ npm install -g nsauditor-ai@latest nsauditor-ai-agent-skill@latest \ @nsasoft/nsauditor-ai-ee@latest # Activate Enterprise license (purchase at https://www.nsauditor.com/ai/pricing/) $ nsauditor-ai license install enterprise_eyJhbGciOiJFUzI1NiIs... ✓ Enterprise license active — 5 seats — expires 2027-05-07 # Run the same octa-framework scan against your own AWS account $ nsauditor-ai scan --host aws \ --plugins 1020,1023,1030,1040,1050,1060,1070,1080,1090,1100,1110 \ --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171 \ --out ./my-audit-evidence # Or just the newest framework, if you only care about NIST SP 800-171 Rev 2 $ nsauditor-ai scan --host aws --plugins all --compliance nist-800-171 # Turn the finished run into a report you can send (Pro + Enterprise, EE 0.44.0) # Self-contained, print-ready HTML — it opens with no external network reference, # and it names on the page any container of finding-like records it did not read. $ nsauditor-ai report --from ./my-audit-evidence/aws_20260822_020259 --format executive --brand "Acme Corp Inc" # …or a Jira-importer CSV. The column-to-field mapping is done in Jira's own importer; # it is not verified against a live Jira instance. $ nsauditor-ai report --from ./my-audit-evidence/aws_20260822_020259 --format jira
--env and --aws-profile
Two CLI flags handle per-scan account selection — no shell re-export or wrapper script needed.
Pass a dotenv credentials file with --env <path>, or select a named AWS profile with
--aws-profile <name>. License is resolved independently of --env.
A missing --env file is a hard error (fail-fast, never a silent skip). Passing an INI-format
file (e.g., ~/.aws/credentials) to --env is detected and redirected to
--aws-profile with a clear diagnostic. When --host aws|gcp|azure is combined
with --plugins all, only that cloud's plugins run — other clouds are skipped and logged
(sentinel-host auto-scoping; explicit --plugins lists are unaffected).
# ── Option A: dotenv credentials file (KEY=VALUE) ────────────────────────────── # --env loads the file for this scan only; credentials are NOT written to shell env # A missing file is a hard error. INI/~/.aws/credentials format → redirected to --aws-profile $ nsauditor-ai scan --host aws \ --env ~/envs/prod.env \ --compliance soc2 # ── Option B: named AWS profile from ~/.aws/credentials ──────────────────────── # --aws-profile clears any stale explicit keys; AWS_SDK_LOAD_CONFIG=1; implies CLOUD_PROVIDER=aws $ nsauditor-ai scan --host aws \ --aws-profile prod \ --compliance soc2 # ── GCP example: ADC via dotenv (GOOGLE_APPLICATION_CREDENTIALS path) ────────── $ nsauditor-ai scan --host gcp \ --env ~/envs/gcp-prod.env \ --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171 # ── All three clouds in one run: comma-separated sentinels (CE 0.2.17+) ──────── $ nsauditor-ai scan --host aws,gcp,azure \ --env ~/envs/clouds.env \ --plugins all \ --compliance all \ --out ./prod-evidence Cloud host 'aws,gcp,azure' → scanning 3 clouds in turn; one out/ subfolder per cloud (aws_…/ azure_…/ gcp_…). # ── Sentinel-host auto-scoping: --host aws + --plugins all → AWS-only plugins ── # GCP / Azure plugins are skipped + logged; explicit --plugins lists are unaffected $ nsauditor-ai scan --host aws \ --aws-profile prod \ --plugins all \ --compliance soc2,hipaa,nist-csf,pci-dss,iso-27001,cis-v8,gdpr,nist-800-171 \ --out ./prod-evidence Cloud host 'aws' → running 20 AWS plugin(s); skipping 35 non-aws plugin(s) (other clouds + non-cloud). ✓ 20 plugins · 76 findings (4m12s) — GCP/Azure + non-cloud plugins not loaded (sentinel-host auto-scope) # ── Scope by AWS region: --aws-region <one|csv|all> ─────────────────────────── # Regional auditors fan out across every in-scope region; S3 resolves each bucket's own region. $ nsauditor-ai scan --host aws --plugins all \ --aws-region us-east-1,eu-west-1,ap-southeast-2 \ --compliance soc2 # --aws-region all = every account-enabled region. No flag = one region (unscanned regions disclosed). # Precedence: --aws-region › AWS_REGION › single-region default. Unknown region code fails fast.
Every finding in the transcript above routes to each framework whose control subject actually matches it, adjudicated per framework — a cell where no control subject matches is recorded as justified-unrouted, never silently blank. What a scan cannot measure fails closed into disclosed evidence gaps instead of a clean line, and every out-of-scope control is listed with the architectural reason it cannot be infrastructure-evidenced. The optional GRC push (opt-in, single-workspace, operator-configured) lands the same findings in your existing compliance workspace. Release-by-release history lives in the changelog, not on this page.