NSAuditor AI Enterprise 0.38.0 Adds Signed Evidence Packs — Verifiable Offline With openssl Alone

Nsasoft US LLC has shipped NSAuditor AI Enterprise Edition 0.38.0, alongside Community Edition 0.2.43 and agent-skill 0.2.41. The headline is a capability compliance teams have been asking for by name: an evidence pack that carries a cryptographic signature saying who approved it — and a verifier that checks a good deal more than that signature.

The gap this closes

A hash-chained evidence pack proves its bytes have not changed since the scan wrote them. Useful, and not sufficient. When an assessor asks who stood behind this exception, and can you prove they did, a hash chain has no answer. Two new commands supply one.

  • compliance sign-pack — signs one framework’s chain-of-custody envelope with an operator-held Ed25519 key.
  • compliance verify-pack — establishes authorship from that signature, and re-computes every artifact hash the envelope enumerates against the files on disk.

Keys live at an approval station, never on the scanners

Signing is deliberately separated from scanning. The scan fleet stays keyless by design, so a compromised scanner cannot mint authorship — the signature means an approver approved, not merely that automation ran. The key is operator-held throughout: Nsasoft never holds it and is never a party to what it asserts.

Why the verifier re-hashes the artifacts

A verifier that checked only the signature would authenticate artifact claims that nothing had ever verified, and report that as a pass. NSAuditor’s does not stop there. Point it at a pack whose report has been edited by a single character — length preserved, invisible to a directory listing — and it returns:

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

ARTIFACT_HASH_MISMATCH
  soc2_report.json

The signature is authentic and the evidence is not intact. Those are two separate facts, and the tool names them separately. Its verdicts never collapse: signature_invalid, record_mismatch, manifest_digest_mismatch, artifact_hash_mismatch and artifact_missing are all distinct outcomes.

Two trust anchors, and the run says which one it used

--registry resolves the approver through your identity registry and checks revocation and validity as at the moment of signing rather than at verification time — so a key whose authority has since lapsed does not retroactively invalidate what it signed while valid. --public-key verifies against a key you supply, and discloses in its own output that identity, revocation and validity checks did not run.

Verifiable with nothing of the vendor’s

The exact signed bytes ship beside the signature, so there is no canonicalisation to reproduce. An auditor reads the digest from the payload file, compares it with shasum -a 256, and runs openssl pkeyutl -verify. That is the entire procedure — published in the product’s frozen integration contract and exercised by the test suite in both directions, a valid signature verifying and a one-byte change failing.

Three exit states, not two

Exit 0 verified, 1 a violation, 2 the run could not measure. An unsigned pack, an unreadable manifest or an unsupplied key reports the third, and none of those is a failure. Telling an auditor their evidence failed verification when nothing was actually checked sends them hunting a forgery that never happened.

Scope, stated precisely

A verified pack signature proves that the holder of a key asserted authorship of one framework’s chain-of-custody envelope and the artifacts that envelope enumerates, at a stated time, relative to your own key custody. It is not a vendor attestation, not proof the scan ran, and not proof the findings are true — and it covers that envelope rather than the output directory or the pack as a whole. verify-pack prints that boundary on every run, including successful ones.

The platform underneath

One read-only scan maps to seven frameworks — SOC 2, HIPAA Security Rule §164.312, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022, CIS Controls v8, and GDPR Article 32 as security-of-processing infrastructure substrate — each producing its own framework-mapped evidence pack with a SHA-256 chain of custody.

55 plugins in total: 27 Community network scanners plus 28 Enterprise cloud auditors across AWS, Azure and GCP. Agentless, with nothing installed in the customer estate and read-only credentials enforced in the product’s own code. Exploit intelligence joins CISA KEV and FIRST EPSS at scan time so a KEV-listed MEDIUM outranks an unexploited HIGH. RFC 3161 trusted timestamping is available opt-in, against a Time-Stamp Authority you name. Cloud data never leaves the customer’s infrastructure, and the Zero Data Exfiltration posture is published as a positive register of 17 enumerated outbound paths rather than a bare denial.

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, because both new commands are routed from the Community CLI — a real requirement rather than a courtesy. Also available as a container listing on AWS Marketplace.

More: nsauditor.com/ai/enterprise · signing walkthrough