If you run cloud infrastructure for a living, you have met this finding: “S3 access logging not enabled — audit trail gap.” You look at the bucket, you know a CloudTrail data-event trail has been recording every object read and write on it for two years, and you file the finding under “the scanner does not understand our estate.” NSAuditor AI Enterprise 0.44.0, released on 4 September 2026 by Nsasoft US LLC, is the release where the scanner understands your estate.
Two trails, one question
Amazon S3 offers two ways to record object-level access: the bucket’s own server access logging, and a CloudTrail trail configured with a data-event selector for the bucket. Both are legitimate, and many organisations standardise on CloudTrail because it lands in the same place as everything else they audit. Enterprise 0.44.0’s S3 auditor now asks the question the way an operator would: is this bucket’s object access being recorded by either mechanism?
Where a CloudTrail trail positively covers the bucket, the scanner emits a pass statement that names the covering trail, and the compliance report carries it as positive evidence rather than as a violation. That statement is what an assessor asks for anyway — not “is logging on?” but “show me the record of who read what.”
How strict “covered” is
This is a change that removes a finding, so the bar for removing it is deliberately high. A trail counts as covering the bucket only when the selector addresses the whole bucket rather than a prefix, records both reads and writes, the trail is running, log delivery is healthy and the region was actually reached during the scan. Anything less keeps the original finding exactly as it was. The cross-check also reports its own status once per scan, so if the credentials you gave the scanner cannot read CloudTrail, you will see “could not check” rather than a silent assumption in either direction. Fewer findings, and the ones that remain are real.
The compliance rationales that cite this control were updated in the same release — SOC 2 CC7.1, HIPAA §164.312(b) and NIST SP 800-171 3.12.3 now describe object-level access recording in either-stream terms, so the report and the finding tell the same story.
The scan you can send
The other half of 0.44.0 lives in Community Edition 0.2.51 and is aimed at the people who have to turn a scan into a deliverable. nsauditor-ai report --from <run> --format executive renders a completed run as a single print-ready HTML file with cover-page branding for the firm sending it; --format jira writes a Jira-importer CSV. The HTML has no external network reference, so it opens on an offline laptop exactly as it opens online. Both are Pro capabilities.
The cover page is the operational detail worth knowing. Each scan now maintains a per-run record — opened at start, appended per host, finalized at the end — and the cover is rendered from it: hosts requested, hosts written, hosts reached. A run that lost a host says so on the cover, and --allow-partial renders it with the caveat in the place the reader will actually look.
By the numbers
Eight compliance frameworks from one read-only scan, 29 Enterprise auditors (28 cloud auditors + 1 Zero Trust posture check), 56 plugins in total across Community and Enterprise, and every coverage matrix unchanged this cycle. Enterprise 0.44.0 pairs with Community Edition 0.2.51 and agent-skill 0.2.49, and requires Community Edition 0.2.49 or newer. Everything runs on your own infrastructure with read-only credentials enforced in code, and no scan data is collected, transmitted or stored by Nsasoft.
Details and installation: https://www.nsauditor.com/ai/enterprise/
