From Security Findings to Cryptographically Verifiable Evidence: The New Enterprise Security Model

For years, security and compliance teams have followed roughly the same process:

Scan → find vulnerabilities → create a report → collect screenshots → upload evidence to a GRC platform → wait for the auditor.

That model is beginning to look outdated. Modern enterprises need something more fundamental:

Can we prove what was found, when it was found, how it was prioritized, who approved an exception, and whether the evidence has changed?

That is a very different problem. And it is the direction taken by NSAuditor AI Enterprise 0.37.0 with Community Edition 0.2.42.

From scanning to proof

NSAuditor AI Enterprise is designed around a simple idea: a security finding is useful; verifiable security evidence is much more valuable.

A single read-only scan can produce evidence mapped to seven major compliance frameworks:

• SOC 2
• HIPAA Security Rule §164.312
• NIST CSF 2.0
• PCI DSS v4.0.1
• ISO/IEC 27001:2022
• CIS Controls v8
• GDPR Article 32 — as the Security of Processing infrastructure substrate only, not GDPR compliance as a whole

Across AWS · Azure · GCP, agentless and with read-only credentials. The workflow runs on the customer’s own infrastructure under a Zero Data Exfiltration architecture, which since 0.33.0 the vendor publishes as a positive register of seventeen enumerated outbound paths — each with its trigger, its default and its off switch — rather than as a blanket promise. Nothing is transmitted to Nsasoft.

But the interesting part isn’t simply the number of frameworks. It is what happens after the scanner finds something.

1. Prioritize what attackers are actually exploiting

Traditional vulnerability management often starts with severity. But severity doesn’t answer the question security teams really need to ask: what should we fix first?

NSAuditor AI adds an exploit-intelligence layer using operator-supplied CISA KEV and FIRST EPSS data. Findings carrying CVEs can be classified as:

KNOWN_EXPLOITED → ELEVATED → BASELINE

The result is exploit-first prioritization. A medium-severity vulnerability that is actively known to be exploited can therefore become more urgent than a critical vulnerability that has never been observed in exploitation.

Importantly, the existing risk score isn’t replaced — exploitability becomes another dimension of the decision, and the join runs downstream of CVE matching rather than adding detection of its own. That is a much more useful model for security operations:

Severity tells you how bad it could be. Exploit intelligence helps tell you how urgent it is.

No exploit data ships with the product. Both catalogues are the operator’s own downloads from CISA and FIRST, which is what makes the next section possible at all.

2. Exceptions become evidence, not just workflow entries

Every security organization eventually has exceptions. A vulnerability gets suppressed. An engineering team accepts the risk. A compensating control is documented.

The problem is that an exception can become one of the weakest links in an audit. Who approved it? Was the approval still valid? Was the record modified? Was the person authorized to approve it?

NSAuditor’s approval workflow introduces cryptographic controls around that decision. With an appropriate signing key, an approval can be signed using Ed25519 — a capability the vendor describes as reachable and not yet proven, and that hedge is itself worth noticing: vendors rarely qualify their own cryptographic claims. The identity registry can carry the approver’s public key material beside the fingerprint it already held, and the two must agree or the registry is refused when it loads.

Where that key material is present, the report distinguishes between two questions that are usually collapsed into one:

• verified — should this suppression stand?
• cryptoValid — did these signature bytes actually validate against the registered key?

They diverge on exactly one case — a key revoked after it signed — and separating them is what turns “this approval was signed after the approver’s credential was revoked” from a statement about an editable text field into a cryptographic finding.

That distinction matters, because security evidence should not claim something was verified when it wasn’t. NSAuditor explicitly reports “signed — not checked by this report” when the necessary key material isn’t available. In other words:

Not checked does not become “passed.”

And it does not become “failed” either. Every identity registry in the field today is fingerprint-only, so reporting those entries as failures would accuse an organization’s own approvers of forgery for not having migrated yet. A missing verdict means NOT CHECKED, and the report says so in as many words. That is exactly the kind of conservative behaviour auditors and security architects should expect from automated evidence systems.

3. Evidence needs a trustworthy time

There is another question that ordinary hash checks don’t answer: when did this evidence actually exist?

That is where RFC 3161 trusted timestamping becomes important. NSAuditor AI Enterprise supports an operator-selected Time-Stamp Authority through NSAUDITOR_TSA_URL, and it is opt-in with no vendor default. When enabled, compliance artifacts receive an RFC 3161 timestamp response (.tsr) that can be independently verified.

The important architectural decision is what is deliberately absent: there is no NSAuditor timestamp authority. The customer chooses the authority, and the timestamp can then be verified independently of NSAuditor — including by an auditor who does not trust the vendor at all, which is the point.

This changes the question from “here is a report we generated” to “here is evidence whose integrity can be checked, and whose existence can be independently timestamped.” That is a much stronger foundation for audit evidence.

4. Hash chaining provides integrity

NSAuditor evidence artifacts also carry SHA-256 chain-of-custody information. An auditor can verify the artifact bytes offline. If the report changes, verification fails.

This is important because integrity and authenticity are different things, and conflating them is how evidence models quietly overpromise:

• A SHA-256 hash helps answer: has this file changed?
• RFC 3161 helps answer: can we establish that this evidence existed at a particular time?
• An Ed25519 approval signature helps answer: did the approval signature validate against the registered key?

These mechanisms solve different trust problems, and combining them creates a far stronger evidence model than exporting a PDF.

5. Now take that model into an air-gapped environment

This is where 0.37.0 becomes particularly interesting. Air-gapped security environments have a fundamental problem: the scanner is isolated from the internet, but vulnerability intelligence normally lives on the internet. How do you keep vulnerability matching current without connecting the scanner to the outside world?

0.37.0 introduces a portable vulnerability-data workflow. A connected system downloads the required NVD data and creates a portable feed bundle with feed bundle. That bundle can optionally include the operator’s own CISA KEV catalogue and FIRST EPSS scores. It is then transferred into the isolated environment and read into the local vulnerability store with feed import, which names every record it skipped and why — withdrawn CVEs and entries with no CPE data are expected outcomes of ingest, not data loss.

Internet-connected preparation environment ↓ vulnerability intelligence bundle ↓ controlled transfer ↓ air-gapped security environment ↓ offline CVE + exploit intelligence ↓ security scan ↓ evidence generation

The bundle records a SHA-256 for each carried file that import verifies — integrity, not authenticity: the recorded hash travels inside the same archive as the data it covers, so it detects a file altered in transit but cannot establish authorship, and import treats every field it reads as untrusted input. Signing the bundle on the connected host is named as future work rather than implied as present.

Both catalogues are validated on the connected host, where a bad download can still be replaced — and the reasoning is specific rather than incidental. The parsers return an empty result for unreadable input rather than failing, and an empty catalogue at a store path makes every finding read “not known exploited”, which is indistinguishable from a genuinely clean host. A validation that fired on the isolated side would fire in the one place nothing can be done about it.

The result is that an isolated environment doesn’t have to choose between security isolation and current vulnerability intelligence.

The bigger picture

Put these capabilities together and the architecture starts looking less like a traditional vulnerability scanner and more like a security evidence engine:

1. DISCOVER — find technical security issues across AWS, Azure and GCP.
2. PRIORITIZE — use risk plus exploit intelligence to determine what matters now.
3. APPROVE — record security exceptions with accountable identities, dates and expiries.
4. VERIFY — cryptographically check applicable approval signatures, and say so when a check did not run.
5. TIMESTAMP — establish when evidence existed, using an RFC 3161 authority you choose.
6. PRESERVE — maintain SHA-256 integrity and chain-of-custody information.
7. MAP — connect findings to seven compliance frameworks.
8. PROVE — deliver auditor-ready evidence.

And all of it can operate within the customer’s own infrastructure.

This changes the role of GRC

This architecture does not compete with GRC platforms. It strengthens them.

Platforms such as Vanta, Drata and Secureframe are valuable orchestration and compliance-management layers. But a GRC platform still needs trustworthy technical evidence underneath it. That is where a technical execution engine becomes important.

GRC tells you what needs to be demonstrated. The security engine discovers what actually exists. The evidence engine establishes what was observed and preserves its integrity.

That creates a much cleaner architecture: technical execution → verifiable evidence → GRC orchestration → auditor. NSAuditor AI Enterprise is designed to operate in that technical layer, with scan-time connectors for GRC platforms that are opt-in, operator-configured and currently early-access and single-workspace — an integration, not a managed multi-tenant sync.

One scan. More than a report.

The real evolution isn’t “we built a better scanner.” It is a move from security findings to technically verifiable security evidence.

A modern enterprise security platform should be able to answer: What did we find? How dangerous is it? Is it being exploited? Who accepted the risk? Can that approval be cryptographically checked? When did this evidence exist? Has it changed? Which compliance controls does it support? Can an auditor independently verify it?

And ideally: can we do all of this without sending our infrastructure data to someone else’s cloud?

That is the direction of NSAuditor AI Enterprise 0.37.0. One read-only scan. Seven framework-mapped evidence packs. Exploit-first intelligence from your own catalogues. Approval signatures checked against recorded key material, with a missing verdict reported as not checked. RFC 3161 trusted timestamps, opt-in and vendor-neutral. SHA-256 evidence integrity. Air-gapped operation. Zero Data Exfiltration.

The future of compliance isn’t just collecting evidence. It’s proving the evidence.

Availability

@nsasoft/nsauditor-ai-ee 0.37.0 is on npm under the Enterprise licence. Community Edition nsauditor-ai 0.2.42 is MIT-licensed and free. Enterprise requires Community Edition 0.2.42 or newer — a raised floor this cycle, because the new feed commands are routed from Community Edition and an older CE would build an incomplete archive without saying so.

Further detail: NSAuditor AI Enterprise and the technical specifications.