Sample scan output — one scan, seven frameworks

Each finding above appears in all seven 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 control spaces in a single pass. This is the one scan, seven 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}.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 six 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).

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.

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, seven 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. All seven matrix counts are UNCHANGED.

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.

1 · A compliance report now cryptographically checks the suppression signatures it renders, for approvers whose registry entry carries key material, and the verdict names the exact signature bytes it checked, pairing positionally with the record it came from so it cannot be aliased onto a different record that happens to share an id.

2 · Two axes, not one. verified answers whether the suppression should stand; cryptoValid answers whether those bytes came from the named key. They diverge on exactly the revoked case — a revoked key's bytes still get checked — which is what makes signing after revocation a cryptographic finding rather than a statement about an operator-editable string. A tampered record renders "signature FAILED verification".

3 · The condition is not decoration. Every identity registry in the field today is fingerprint-only, so a missing verdict means NOT CHECKED and never FAILED: the report says "signed — not checked by this report", and a report advisory names how many registered approvers are still awaiting material and what to paste. Separately, an engine fault in the identity phase now fails that framework's report loudly instead of rendering a degraded section that told the auditor to restore a registry that was fine; the scan, the other frameworks and the findings artifacts are untouched.

This release is matrix-neutral: all seven coverage matrices are UNCHANGED and the plugin count is UNCHANGED at 28 Enterprise plugins, 55 overall. It needs CE ≥ 0.2.42, raised this cycle, because the new hand-carry entry points live in Community Edition — they move the NVD feeds you downloaded, and are distributed restricted. Paired CE 0.2.42 + agent-skill 0.2.40.

1 · Eleven compliance options that nothing shipped could populate now receive values. Each one was reachable only in theory — the option was declared, the engine read it, and no shipped entry point ever wrote to it, so a documented knob did nothing no matter how it was set. They are now fed from a real entry point. Those entry points live in Community Edition, so EE 0.33.0 requires CE ≥ 0.2.37; pair it with an older CE and the options stay unfed.

2 · Zero Data Exfiltration, rebuilt as a positive register. The claim used to be a denial, and a denial is unfalsifiable by inspection. It is now an enumeration of 17 outbound paths, each named with what triggers it and how to switch it off — the form a reviewer can check rather than accept. RFC 3161 trusted timestamping is now opt-in via NSAUDITOR_TSA_URL and was verified against a real timestamp authority on 2026-08-07; it is opt-in, not a default, and it is itself one of those 17 paths, so enabling it is a deliberate decision. Ed25519 suppression signing was NOT reachable from any shipped entry point at that release — no shipped path signed a suppression record. It shipped in EE 0.35.0, and EE 0.36.0 checks the signatures a compliance report renders, for approvers whose registry entry carries key material. Signature records now carry algorithm and backend frozen at the moment of signing, rather than re-derived later from whatever configuration happens to be current.

That release was matrix-neutral: all seven coverage matrices are UNCHANGED and the plugin count is UNCHANGED at 28 Enterprise plugins (27 cloud auditors plus 1023 Zero Trust Assessment, which scores a network-host scan), 55 overall. Paired CE 0.2.37 + agent-skill 0.2.35.

1 · The dependency-advisory gate had been auditing the maintainer's development tree and calling it the production closure. It now builds its subject: pack the tarball, install it into an empty directory the way a customer does, and audit that. The working-tree reading survives as an explicitly-labelled secondary that never decides the verdict. Taken with both controls in place, the development tree carried 25 advisories, 8 of them HIGH; the closure a customer installs carried 6, none HIGH. The two lists share 5 of 26 advisory packages and zero high-severity ones — every one of the eight highs was development-only. Both subjects had previously been read as "8 HIGH" over lists that overlap in a single package: a matching total is exactly what makes a wrong list read as right, which is why the two are now reconciled as sets, with a package-for-package divergence block printed on every run.

2 · Nothing was checking that an advisory database had answered. With the audit taken offline the gate produced a well-formed zero — dependency counts non-zero, the summary reconciling against its own list, no divergence because both subjects read zero — and printed a pass over a closure that really carried six. A registry mirror with no security endpoint reproduces it identically. The gate now installs a pinned canary carrying a permanently published advisory and requires that advisory back; silence is an untrustworthy run, not a pass. It also prints which registry answered, because a canary proves liveness, not freshness — a stale mirror answers it and still misses everything published since.

3 · SOC 2, enumerated in full: 10 covered / 4 partial / 37 out of scope = 51. Four AICPA criteria — CC7.4, CC7.5, A1.1 and A1.3 — appeared nowhere in the mapping data. Not out of scope with a reason; simply absent, which is assessor-visible: the covered row lists CC7.1–CC7.3, so a reader who knows the criteria asks where 7.4 and 7.5 went. Each is now enumerated with an architectural reason and the operator-side evidence that closes it, and each renders into the report as a documented gap. This is enumeration completeness, not a coverage change — no control changed status, no routing changed, covered stays 10, partial stays 4, every existing control-id membership is identical, and the other six matrices are unchanged. SOC 2 was the one framework with no universe pin, and that is exactly where the omission lived; all seven are now pinned against a universe constant held independently of the data. Separately, the Type II tables now state which mechanisms are reachable from a shipped entry point rather than presenting all of them as supported. 28 Enterprise plugins — 27 of them cloud auditors — 55 overall, seven frameworks — unchanged. Live-verified on the published bytes: 28 of 28 Enterprise plugins active, and a three-cloud scan wrote a 76-file evidence pack per cloud.

1 · A compliance report is a document a customer hands their auditor. Ours carried internal engineering identifiers — roadmap ids, internal release stamps, the name of an internal audit review — in finding titles, on the attestation cover page and inside the chain-of-custody record. None of that belongs in front of an assessor. Measured on a rebuilt three-cloud evidence pack, 686 unexplained internal-marker occurrences went to 0 across 105 files. The number that makes that zero mean something is the other one: a positive control in the same run still detected 3,572 benign matches, so the zero is a measurement rather than an absence of looking. The instrument itself is new and fails closed when its own positive control comes back empty — an empty detector can no longer report a clean sweep.

2 · A false clean, closed. When a cloud plugin could not start — its optional SDK absent, its credentials unusable — it correctly refused to report. That refusal then evaporated one layer up: the compliance report came out byte-identical to one where the scanner ran and found nothing. Ten controls read PASS. No violation, no warning. The dangerous shape is entirely ordinary — AWS and GCP scan for real, Azure's SDK is absent, and the combined pack reads as a clean three-cloud audit that nobody has any reason to question. Now every in-scope control of a cloud that could not be scanned carries a fail-closed evidence gap, and an archived scan re-processed by the new build warns instead of failing clean. Two consequences for operators: the evidence-gap finding title changed, so suppression rules matching the old text stop matching — the safe direction, findings resurface rather than hide, but silent; and you should re-scan rather than re-process any scan captured before 0.32.9.

Also in this release: four report surfaces that contradicted each other on trusted timestamping — which was still on the roadmap at that release, and became opt-in via NSAUDITOR_TSA_URL as of EE 0.33.0 — now say the same verifiable thing. On the Community Edition side, --out <dir> no longer writes into the parent directory when the directory name contains a dot; the MCP scan_cloud summary handles both spellings of the evidence-gap prefix; and validate no longer misreports where plugins came from. This release is matrix-neutral: 28 Enterprise plugins (not 27, not 29 — 27 of them cloud auditors, plus 1023 Zero Trust Assessment, which scores a network-host scan) and all seven coverage matrices unchanged — identical counts and identical control-id membership to 0.32.8.

A compliance report is only as trustworthy as the frameworks a real exposure reaches. Last cycle the analysis-agent (network-scan) path stopped waving through three real exposures — but those findings routed to SOC 2 only, so a host serving cleartext transport or exposing SMB alone failed the SOC 2 report and read perfectly clean in HIPAA / CIS / NIST CSF / PCI / ISO 27001 / GDPR off the very same scan. This release closes that split. The network-scan findings — cleartext transport (SOC 2 CC6.7 and the transport-encryption controls across the set), SMB-alone (SOC 2 CC6.6 and its cross-framework counterparts), and the new exposure signals WinRM 5985/5986, Elasticsearch transport 9300, MSRPC 135, and an aggregate open-port-count rule — now route across all seven compliance frameworks. 48 mapping rules carry each finding to the frameworks that map it, adjudicated per framework (with 24 cells justified-unrouted where no control subject matches), behind a mutation-proven guard. This release also lands a capability-claim honesty pass. Regression 9,280 pass / 0 fail. The Vanta + Drata + Secureframe GRC connector trio shipped in 0.32.x remains fully available — set COMPLIANCE_GRC_PROVIDER=vanta (or drata / secureframe) and COMPLIANCE_GRC_TOKEN and the compliance phase maps each finding to your GRC platform's evidence/test records and pushes them at scan time: opt-in, Zero-Data-Exfiltration-redacted egress, the token is never serialized into any evidence artifact, with suppression-aware outcomes, deterministic framework-dimensioned idempotency, rate-limit backoff, and a circuit breaker (records model; single-workspace, operator-configured — not a multi-tenant sync). Each finding routes to the frameworks whose control subject actually matches it — no mirror, no overclaim. This release is matrix-neutral: it routes existing network-scan findings across the frameworks that already map them, not a new framework or plugin — the plugin count is UNCHANGED at 28 and all seven coverage matrices were UNCHANGED at the count level (SOC 2 10/4/37 as re-enumerated in 0.32.10 · 7/3/45 HIPAA · 13/10/83 NIST CSF · 19/9/39 PCI DSS · 17/14/62 ISO 27001 · 17/23/113 CIS v8 · 4/5/2 GDPR Art. 32 — Security-of-Processing infrastructure substrate, Art. 32 only). It builds on the retained GCP false-negative hardening depth pass, whose fixes are still live: plugin 1024 _auditLegacyAcls reads the GCS legacy-ACL public surface a UBLA-disabled bucket still honors; plugin 1025's service-account key-admin and impersonation-path dimensions flag the project-scope roles/iam.serviceAccountKeyAdmin offline-impersonation primitive and transitive iam.serviceAccounts.actAs paths via serviceAccountTokenCreator edges; and the GCP client/ADC handling keeps GCP IAM auditing running under pure ADC with a denial degrading to an explicit evidence-gap verdict, never a silent clean.