NSAuditor AI Enterprise 0.42.0 shipped this week, and the part practitioners will touch first is small enough to fit in a shell profile: four environment variables that tell the scanner which cloud estate it is looking at. Here is what they do, what happens when you get them wrong, and what the new bill of materials actually describes.
The four variables
Sovereign Azure selection reads any of the following:
AZURE_ENVIRONMENT— the conventional selector, e.g.AzureUSGovernmentARM_ENVIRONMENT— the Terraform-style spelling, for shops that already export itAZURE_ARM_ENDPOINT— an explicit Resource Manager endpointAZURE_AUTHORITY_HOST— an explicit authority host for token acquisition
Before this release, no code in either repository read any of them. Credential objects and Resource Manager clients were constructed without an authority host, without a management endpoint and without a credential scope, which meant they resolved to the commercial defaults. In 0.42.0 all eighteen of those construction sites take their configuration from the selected estate.
What fail-closed looks like in the report
The behaviour worth rehearsing before you run it in anger is what happens on a bad selection. If you name an estate the product does not recognise, or you export two variables that disagree with each other, the scan does not guess and it does not fall back. It refuses that source and writes an evidence gap naming the variable that would resolve the disagreement.
That is a deliberate trade. A refusal is a visible, actionable outcome you can fix in one line. A silent fallback produces a report that looks entirely normal and describes the wrong subscription — and there is nothing in such a report that would tell you so.
The estate stamp
Every Azure scan now writes the estate it addressed into its own summary, which means the subject of the report travels with the report. If you run both a commercial and a government subscription under credentials that are valid in both — the ordinary shape for a firm with a federal line of business — this is the line that lets you, and your auditor, confirm at a glance which one you are holding.
The AWS side of the release follows the same principle through partition handling: resource names, severity ladders and region dispatch now follow the partition in play, so a finding in aws-us-gov, aws-cn, the intelligence-community partitions or aws-eusc carries the weight it would carry in commercial.
An SBOM that describes what you installed
The new bill of materials is generated on demand in CycloneDX or SPDX. The detail that matters is its subject: rather than describing the maintainer’s working tree, the generator builds the tarball, installs it with its declared Community Edition peer into an empty directory, and generates the document there, stamped with the tarball it describes. If the tooling underneath cannot see the complete dependency graph, it writes nothing at all — a partial bill of materials being worse than none when someone downstream will treat it as complete.
Alongside it there is now a published FIPS posture statement: the product employs FIPS-approved algorithms, and it is not, and does not contain, a FIPS 140-validated cryptographic module. Whether the runtime beneath it is one depends on your own Node and OpenSSL build, which the statement says plainly rather than leaving to inference.
Getting it
The catalog is unchanged at 29 Enterprise auditors and 56 plugins overall, and all eight coverage matrices are unchanged too — this release deepens correctness on controls already covered rather than adding new ones.
npm install -g nsauditor-ai@0.2.49 @nsasoft/nsauditor-ai-ee@0.42.0The peer floor is Community Edition 0.2.49 or newer, and order matters: install Community Edition first, because partition detection lives there. Everything runs locally on your own infrastructure, read-only. Details on the Enterprise page.
