NSAuditor AI Enterprise 0.32.3 is a matrix-neutral depth pass on the AWS RDS auditor. It closes a cleartext false-negative that affected one common database shape, hardens how the scanner treats security parameters that are configured but not yet effective, and pairs a Community Edition change that fails fast on a bad GRC configuration. No new framework, no new plugins (still 28), and all seven coverage matrices are unchanged.

The Aurora Serverless cleartext blind spot — closed

NSAuditor checks whether an RDS database enforces SSL/TLS by reading the database’s parameter group. But an Aurora Serverless v1 cluster scales its compute up and down automatically and, between activity, may have no running database instances at all. The instance-level SSL check therefore had nothing to read — while the actual TLS-enforcement switch (rds.force_ssl for PostgreSQL, require_secure_transport for MySQL) lives on the cluster parameter group. A serverless cluster configured to accept plaintext connections produced zero transit-encryption findings: a silent clean over a real hole.

0.32.3 audits the cluster parameter group directly via DescribeDBClusterParameters. A non-enforcing cluster is now flagged; if the parameters cannot be read — a denied or throttled API call — the result degrades to an explicit evidence gap, never a silent pass. The new finding routes to exactly the same transit-encryption controls as the existing per-instance check across all seven frameworks, so no coverage number moves.

“Set” is not “in force” — staged-parameter discipline

Some database security parameters take effect only after a reboot. If an operator enables rds.force_ssl but hasn’t rebooted, the parameter reads as set while the database still accepts cleartext until the reboot lands. 0.32.3 reads the parameter’s apply status: a value that is staged (pending-reboot / applying, not in-sync) is no longer reported as an affirmative pass. It becomes a low-severity evidence gap that says plainly: configured, but not yet effective — reboot and re-scan. The same discipline covers the pgAudit audit-logging parameter and the Aurora cluster path.

Community Edition: fail fast on a bad GRC configuration

For operators who push compliance evidence to a GRC platform (Vanta, Drata, Secureframe), a typo in a token or control-map used to surface only after a full multi-region scan finished, at push time. CE 0.2.28 adds a startup preflight: when a scan requests a framework and a GRC provider, the configuration is validated up front, so a misconfiguration fails immediately with a clear message. GRC push remains a CLI feature by design.

Honest about what’s next

The cluster-SSL closure is a real new detection and was reviewed hard, including a 20-agent principal audit that confirmed the fix end-to-end and confirmed it is fail-closed — it never manufactures a false “clean.” That review flagged a follow-on being sequenced deliberately: for a provisioned Aurora cluster (one that does have instances), the new cluster-level check and the existing per-instance checks should present one coherent verdict. It is fail-closed today; the refinement needs verification against a live Aurora cluster first, so it is planned rather than force-fit into this release.

Versions

• Enterprise: @nsasoft/nsauditor-ai-ee@0.32.3
• Community: nsauditor-ai@0.2.28 (MIT — GRC-push startup preflight)
• Agent skill: nsauditor-ai-agent-skill@0.2.26

Coverage matrices unchanged: SOC 2 10/4/33 · HIPAA 7/3/45 · NIST CSF 2.0 13/10/83 · PCI DSS v4.0.1 19/9/39 · ISO 27001 17/14/62 · CIS Controls v8 17/23/113 · GDPR Art. 32 4/5/2. Full details at the NSAuditor AI Enterprise page.