NSAuditor AI Enterprise 0.38.0: Sign the Chain-of-Custody Envelope — and Verify the Artifacts Too

LAS VEGAS, NV — Nsasoft US LLC has released NSAuditor AI Enterprise Edition 0.38.0, paired with Community Edition 0.2.43 and agent-skill 0.2.41. Two new commands let an approver sign the chain-of-custody envelope of a compliance evidence pack, and let anyone holding that pack establish who signed it — offline, with openssl, and with no vendor software anywhere in the loop.

For anyone who has ever handed an auditor a folder of scan output, this closes a specific and familiar gap. A hash chain proves the bytes have not changed since they were written. It says nothing about who stood behind them. As of 0.38.0, it can.

Signing happens at an approval station, not on the scanners

compliance sign-pack signs one framework’s chain-of-custody envelope with an operator-held Ed25519 key. The design decision worth noticing is where that key lives: at an approval station, deliberately away from the scanning fleet. The scanners stay keyless, so a compromised scanner cannot mint authorship. That is the difference between a signature that means something to an assessor and one that merely proves your automation ran.

The key is yours. Nsasoft never holds it, never sees it, and is never a party to what it asserts.

The verifier checks more than the signature

This is the half of the feature that matters most, and the half that is usually missing elsewhere.

compliance verify-pack establishes authorship from the signature — and then recomputes every artifact hash the envelope enumerates against the files actually on disk.

Why that second step is not optional: a verifier that checked only the signature would authenticate a set of artifact claims that nothing had ever verified, and would report the result as a pass. Drive NSAuditor’s verifier against a pack whose report has been edited — one character, length preserved, the change a directory listing cannot see — and the output is unambiguous:

signature ......... VERIFIED
approver .......... j.reyes (valid at time of signing)
artifacts ......... 4 / 4 re-hashed

ARTIFACT_HASH_MISMATCH
  soc2_report.json

The signature is genuine. The evidence is not intact. Those are two different facts, and an auditor needs both of them named separately. The verdicts never collapse into one another: signature_invalid, record_mismatch, manifest_digest_mismatch, artifact_hash_mismatch and artifact_missing are all distinct.

Two trust anchors, and the tool tells you which one it used

--registry resolves the approver through your own identity registry and checks revocation and validity as at the moment of signing, not at the moment of verification. That distinction has real consequences: a key whose authority has since lapsed does not retroactively invalidate everything it signed while it was valid. Evidence produced under a valid authority stays valid evidence.

--public-key verifies against a key you supply directly, and discloses in its own output that identity, revocation and validity checks did not run. Supplying both is refused rather than silently resolved — the tool will not guess which answer you wanted.

Your auditor needs nothing of ours

The exact bytes that were signed ship beside the signature, so there is no canonicalisation for an outside party to reproduce. An auditor reads a digest from the payload file, compares it with shasum -a 256 of the envelope, and runs openssl pkeyutl -verify. That is the whole procedure. It is published in the product’s frozen integration contract, and it is executed by the test suite in both directions — a valid signature verifying, and a one-byte change failing — rather than only written down.

No NSAuditor binary is required at any point in that chain. For a regulated buyer evaluating vendor lock-in on their own audit evidence, that is the answer they are looking for.

Three exit states, not two

Exit codes distinguish 0 verified, 1 a violation, and 2 the run could not measure. An unsigned pack, an unreadable manifest, an unsupplied key and a registry member with no key material all report the third — and none of them is a failure.

The reasoning is practical rather than pedantic. Telling an assessor that their evidence failed verification when the truth is that nothing was checked sends them hunting a forgery that never happened. Two-state verifiers manufacture that false alarm routinely. This one does not.

What a signature proves, stated precisely

A verified pack signature proves that the holder of a key asserted authorship of one framework’s chain-of-custody envelope, plus the four artifacts that envelope enumerates, at a stated time, relative to your own key custody.

It is not a vendor attestation. It is not proof the scan ran, and it is not proof the findings are true. It covers that envelope and those artifacts — not the output directory, and not the pack as a whole: a seven-framework pack holds 74 files, 28 of them named by some envelope, and no single object enumerates the set. verify-pack prints that boundary on every run, successful ones included.

Publishing the boundary alongside the capability is deliberate. An evidence tool that overstates its own guarantee is worth less to an auditor than one that states a narrower guarantee exactly.

It all rides one read-only scan

Signed packs are a layer on top of what the platform already does. One --compliance run produces seven framework-mapped evidence packs:

Underneath: 55 plugins — 27 Community network scanners plus 28 Enterprise cloud auditors across AWS, Azure and GCP. Agentless, nothing installed in your estate, credentials read-only and enforced in the product’s own code. Exploit intelligence joins CISA KEV and FIRST EPSS onto CVE matches at scan time so a KEV-listed MEDIUM outranks an unexploited HIGH. RFC 3161 trusted timestamps are available opt-in, to a Time-Stamp Authority you name. And the Zero Data Exfiltration posture is published as a positive register of 17 enumerated outbound paths rather than a bare denial, because an absence cannot be audited but a list can.

Availability

npm i -g nsauditor-ai@0.2.43 @nsasoft/nsauditor-ai-ee@0.38.0

Enterprise requires a licence. Community Edition remains MIT-licensed and fully functional on its own. Enterprise 0.38.0 requires Community 0.2.43 — both new commands are routed from the Community CLI, so the floor is a real requirement rather than a courtesy. NSAuditor AI Enterprise is also available as a container listing on AWS Marketplace for procurement-led buyers.

Full details: nsauditor.com/ai/enterprise · Step-by-step signing walkthrough: getting started