Did we get better?
Show what changed since the last scan.

“Did we actually get better?” — answered in the report you send

Consultants hear it at the re-test. MSPs hear it at the quarterly review. A simple before-and-after diff answers fast and can cost you credibility. A finding vanishes because its host was left out of the re-test, a plugin timed out, the CVE lookup failed, or NVD stopped matching a CVE to software that never changed — and the diff shows it as fixed. That line can end up in front of a client’s board. Nobody fixed it: the scanner stopped looking, or the data moved under it.

With Pro, one command — nsauditor-ai report --from <dir> --format executive --since <runId|prior> — compares two scan runs and writes new, resolved and changed-severity findings into the print-ready executive HTML report you hand the client. No side-by-side spreadsheets, no rows copied from one report into the next.

New in 1.3.0: two kinds of narrower re-test no longer read as a fix

A re-test is rarely the same scan twice. A slow plugin gets dropped from --plugins, or the SSH probe is left out and port 22 still answers, but nothing identified what is on it. In the previous release, the rows that depended on what was left out read resolved. In the two cases below the report now sets them aside instead of crediting a fix (the two measured limits are stated further down):

• A plugin left out of the scan. Each analysis agent reads what named plugins write. When one it reads was not requested, the scan records an input gap and the agent’s earlier rows are filed NOT-COMPARABLE. (For port discovery, the port scanner (003) or Nmap (024) is enough — either one.) Measured on the release candidate: a re-test that dropped the TLS scanner (011), one of the plugins the crypto agent reads, reported 0 resolved and 4 not comparable, among them two TLS-version findings and a self-signed certificate set aside on that input gap. On the same two plugin sets, the previous release read those three as resolved.
• A port that answered unidentified. With the SSH probe left out and the port scanner (003) seeing port 22 open, an end-of-life OpenSSH row and a CVE row on port 22 were filed NOT-COMPARABLE (port-not-measured), reported neither as fixed nor as new, until a rescan can read the program and version.
• Titles that no longer move with a probe. The exposure agent’s titles now name only the port, and the service agent’s end-of-life titles name the program without the version, so one unchanged port no longer reads as one resolved row and one new one.
• A Basis cell that shows its work. Every new, resolved and changed row says what was checked for that row.

Still holding since EE 1.2.0: 22 of 22, and 5 of 5

22 UDP findings (since EE 1.2.0). We compared a real router scan with a twin of it that drops its 22 UDP rows. The release before the rule reported all 22 resolved; with the rule, the delta reported all 22 not comparable: the re-test never recorded those ports as closed or answering, so it does not get to call them fixed. That router pair was measured when the rule shipped; the 1.3.0 release test re-checked the rule on UDP rows of its own.

5 dnsmasq CVEs (since EE 1.2.0). A pre-publish test run caught this one. NVD stopped matching five CVEs to dnsmasq 2.78 on a router that was still answering with dnsmasq 2.78. The earlier delta called all five resolved, and the compliance pack counted them as closed findings with a mean time to remediate of about a day. On the same pair of scans, the delta with the rule read 0 resolved and 5 not comparable — and the 1.3.0 release test reads the same on a local dnsmasq 2.78 pair — reason vulnerability-data-changed — the vulnerability data changed, not your estate.

A resolved column that shows its work

Before a missing finding is called resolved, the comparison looks at how each run measured it. When the report can see the two runs did not measure it the same way, it files the finding under NOT-COMPARABLE, with the reason on the row. Among the reasons:

• its host was not scanned in the other run;
• it carries no producer identity to check (producer-unknown);
• the plugin that reports it did not run, errored or timed out;
• the analysis agent that reports it did not run, or a plugin it reads was left out of the scan or did not complete (evidence-gap);
• the licensed package that runs the analysis agents and CVE matching failed to load on that host — now named on stderr instead of passing in silence (evidence-gap);
• the scanner recorded an evidence gap there — an AccessDenied, or a CVE lookup that failed, for example (evidence-gap);
• the other run had a narrower scope — on Enterprise cloud scans, fewer AWS regions or a different Azure subscription or GCP project;
• the check on its port could not complete (probe-not-measured);
• its TCP port, seen open by the port scanner, stopped answering between the two scans, or answered without its service being identified (for a CVE or end-of-life row) — or its UDP port was not recorded as closed or answering by the other scan (port-not-measured);
• whatever produced it changed what identifies a finding across the upgrade — across the 1.2.0 → 1.3.0 upgrade, the exposure agent, the service agent and plugin 1160, so rescan after upgrading before you compare (identity-basis-changed);
• the vulnerability data stopped attributing its CVE while the same program and version still answer (vulnerability-data-changed).

And the report tells your client in plain words: a finding that could not be compared is not a finding that was fixed. When someone asks why a finding was set aside, the answer is on its row — along with which way it went: absent from this run, or appeared in it.

On Enterprise, the same rule reaches the compliance report. With SLA tracking on (--compliance-history <dir> or --sla-policy <file>) and a prior --compliance scan of the same host in the history, a control that failed on a finding whose port, probe, region or producer the new scan did not measure is held FAILED, with the gap leading its explanation and counted among the evidence gaps — never shown as a current finding. New in 1.3.0, that now includes the controls behind a failed CVE lookup (a LOOKUP NOT MEASURED record) and the controls behind an analysis agent’s rows when a plugin it reads was left out; and SLA age and time to remediate in the HIPAA, NIST CSF, PCI DSS, ISO 27001, CIS, GDPR and NIST SP 800-171 packs no longer reset on every scan, with a history written by any earlier release read correctly and no pack regenerated (stated limit: two findings whose prose differs only by a control id would share one identity; none does among the emitted texts, and a test holds that at zero). The second limit above reaches it too: on a scan that discovered ports with Nmap alone, a row on a port it did not measure can count as closed in MTTR and its control can read PASS.

Some pairs are refused outright, with no rows guessed: two runs at different licence tiers, or two runs on either side of a release that changed what the reported findings count means. A refused comparison exits 2, so a script cannot mistake it for a clean delta; when the executive report is still written, its body says no comparison was made.

A tamper-evident baseline, checked before anything is compared

A quarter-over-quarter story needs a baseline that is still there and still intact. Pro keeps your scan history past the Community 7-day window, and for every scan run on 1.1.0 or later, the run record and each host’s findings files are sealed with SHA-256 digests and chained to the previous run. Both runs are checked first. If a sealed findings file was corrupted, partly restored or changed by an ordinary edit, the report names it and refuses the comparison — so you find out at report time, not in front of the client.

Already scanning? Baselines written since EE 1.0.0 are compared across the upgrade; one scanned before 1.1.0 carries no integrity digest, and the report says so. From your first two scans on 1.1.0 or later, both sides of the comparison are sealed.

The --since comparison is a Pro capability, included in Enterprise; its code ships in the free Community package and your licence unlocks it. The watch-mode last-vs-current webhook alert delta stays free.

One file. No network. Hand it to the client.

A scan ends with a directory of artifacts. An engagement ends with something a client reads. nsauditor-ai report closes that gap: point it at a finished run and it renders an executive HTML report — one self-contained, print-ready file that opens with no external network reference of any kind. It survives an email attachment, a laptop with no connectivity, and a reviewer’s locked-down browser.

Add --brand when the report goes out under your own name and the cover page carries it. --format jira writes a Jira-importer CSV instead, so a findings list becomes a backlog. ⚠️ That CSV is written for Jira’s own CSV importer — the field mapping is done inside Jira, and this is not a live-instance integration we have verified.

What goes inside brand.json

Every field is optional. Omit the file and the report renders unbranded under its default title.

// brand.json — put it next to your logo
{
  "title":        "Q3 External Perimeter Review",
  "companyName":  "Acme Manufacturing GmbH",
  "preparedBy":   "J. Rivera, Security Consulting LLC",
  "contact":      "security@example.com",
  "logoPath":     "acme-logo.png"
}

title replaces the headline; companyName is who the report is for; preparedBy is who prepared it. logoPath is a local PNG or JPEG, resolved next to the brand file and embedded into the HTML as a data URI.

That logo rule is strict on purpose, and every part of it protects the same promise — that the file opens with no external network reference. A URL is refused and never fetched: a remote logo is egress at render time and a tracking pixel every time your client opens the report. SVG is refused, because SVG is markup that can carry a script and break the no-script guarantee from inside the image. The path may not escape the brand file’s own directory, checked as typed and again after symlinks resolve. The cap is 2 MB, and the format is read from the file’s magic bytes rather than its extension — renaming an SVG to .png does not get it past the check. A brand file that cannot be read, is not valid JSON, or whose logo is refused is a fatal error and no report is written: a flag you passed is never silently dropped, because that is how a report goes out unbranded without anyone noticing.

It states what it could not read

A report that quietly skips a container reads exactly like a report that had nothing to skip. So every report carries a container census: where finding-like records sit in a place the report does not read, that place is named and counted on the page. Silence is disclosed — never rendered as absence.

report is a Pro capability and is included in Enterprise. It produces no PDF: the HTML is print-ready, and your browser prints it when a PDF is what the client asked for.

Prioritize by exploitation first, not by CVSS alone

Version-based CVE matching is just the start. Every finding is scored — CVSS weighted by verification status, with an uplift for findings carrying an initial-access technique — and the queue is then ordered exploit-first. Findings are emitted unverified — you adjudicate what stays, not the scanner.

A KEV-listed MEDIUM outranks an unexploited CRITICAL

Severity ranks how bad a vulnerability would be if it were exploited. It cannot tell you whether anyone is exploiting it. Pro closes that gap at scan time: every finding carrying a CVE is joined by CVE ID against a local CISA KEV catalog and a local FIRST EPSS scores file, then banded and reordered exploit-first.

The justification travels with the finding — the KEV flag, the EPSS score with its percentile, the CVE ids that matched, and the store’s own as-of date. Your ranking is always something you can date and defend. Both catalogs are free, public and operator-supplied: point Pro at files you control and the join runs entirely on your machine.

Your existing riskScore does not move — exploitPriority is a new axis beside it. And this is enrichment, not detection: it reorders what the scanner already found.

Where Pro ends and the evidence pack begins

Pro sharpens the queue. Enterprise turns the result into something an assessor reads — 29 Enterprise plugins, 28 of them cloud auditors across AWS, Azure and GCP, and one read-only scan mapped to eight frameworks with an explicit out-of-scope column.

It is also where suppression lives — and suppression is an Enterprise capability, not a Pro one. Enterprise adds a suppression workflow for the compliance report: accepted-risk and false-positive records keyed on source and title pattern, approved with an approver’s signature, renewable on a cadence, and read by the compliance engine — which Pro does not run, so a suppression has no effect on a Pro report. The Enterprise compliance engine gives each decision an owner, a rationale, a date and an expiry inside the evidence pack — and as of EE 0.36.0 the report checks that approval’s signature against the key material the approver’s registry entry declares, rather than repeating what the record says about itself. A missing verdict reads not checked and never failed.

Isolated networks are Enterprise too: the offline install walkthrough — carry the package and the CVE data in, verify checksums, then import the feed — now lives on the Enterprise page.

None of that is part of a Pro licence. If your buyer is an auditor rather than a remediation queue, that is the tier to look at.

See NSAuditor AI Enterprise →