swaudit runs candidate applications in an instrumented sandbox, records what they actually do, and produces a defensible report that supports your approve / reject decision. Every finding traced to evidence. Every limit stated.
Scope, up front: when the candidate is an installer, swaudit audits the installer — everything it unpacks, writes, spawns and dials, up to the point Windows requires administrator rights. That is the window a hostile installer does its damage in. What the software does after it is installed is not audited today. What that covers, and what it doesn't →
One unedited session, recorded in the product: a disposable Windows VM is provisioned, the desktop streams into the browser, a candidate exfiltrates planted credentials, and the detectors catch it while it happens. No staging — the findings and the verdict below are the ones this run actually produced.
A vendor's marketing page is not evidence. A privacy policy is not evidence. Behavior under instrumentation is evidence.
Looks at the binary on disk. Doesn't see what it does at runtime.
Insufficient
Catches known-CVE deps in the supply chain. Doesn't see what the binary actually transmits.
Insufficient
Runs the candidate. Observes every process, file, registry and network action it takes, reads its TLS payloads in plaintext, and records every destination it dials. Produces a signed report with evidence.
Defensible
The dynamic-analysis advantage
Static scanners read the bytes on disk. That's a fundamentally bounded problem: an attacker who controls the binary controls what those bytes look like. Modern malware exploits this gap by making the on-disk form deliberately innocuous and only revealing its true behavior at runtime.
.aws and .ssh directories, browser cookie and credential stores, and the registry hives that hold saved secrets.We seed a fake cloud access key into the sandbox before the candidate starts. It is minted fresh for that one run, and nobody — including us — has ever published it. There is no plausible reason that exact string should ever leave the VM. If it appears in any TLS plaintext to any destination — that's exfiltration, full stop. Not a heuristic. Not a probability. Evidence.
This is what static analysis fundamentally cannot do. You can't detect intent in bytes — you can only detect it in behavior under observation.
Other dynamic-analysis tools exist (commercial sandboxes, EDR products), but they're built for a different job: continuous monitoring after deployment, alerting on observed-bad behavior. swaudit is built for the pre-approval moment — the auditor's defensible-decision-with-evidence step that EDR doesn't address. It's the difference between "we caught the breach" and "the breach never happened because we didn't approve the binary in the first place."
How is this different from what we already have?
Static AV catches signature matches. SAST catches code patterns. EDR catches breaches that already happened. swaudit catches behavior at the moment of approval — the gap none of the others cover.
Where they're complementary: swaudit doesn't replace your AV (you still want runtime protection on every endpoint) or your EDR (you still want post-breach forensics). swaudit covers the approval moment — the question of "should we install this in the first place?" — which is the gap your other tools were never built for.
Legend: ✓ supported · ~ partial · — not the tool's job · ✗ not supported. Categories are general; individual products vary.
Upload a Windows candidate through the web UI. Format is detected structurally, not from the file extension — we look inside the file rather than trusting its name, so a mislabelled candidate still routes correctly. Six formats are launched today, each with the host program a real Windows machine would use: .exe directly, .msi via msiexec, .ps1 via PowerShell, .hta via mshta, .wsf via wscript, and .bat / .cmd via cmd.
The candidate runs in its own disposable Windows VM — created for one audit, destroyed after it, sharing no kernel, filesystem, or namespace with the audit infrastructure, and never reused between audits. It is launched as a de-privileged standard user rather than an administrator. The collector is a system-level service inside the same VM: it records every process, file, and network action the candidate takes, and a local TLS-terminating proxy reads the plaintext of encrypted traffic. Unique-per-run honeytokens are planted in credential files, browser cookie stores, and environment variables before the candidate ever starts.
Because the collector shares the guest with the candidate, every batch of evidence it sends is cryptographically authenticated with a key the candidate cannot read. If the collector is silenced, or a batch fails that check and is never redelivered, the audit is reported as inconclusive rather than clean. An audit that could not be collected properly never becomes an approval.
The VM's system proxy is pointed at the in-guest interceptor before the candidate starts, with our certificate authority trusted at boot. So when the candidate dials a real exfiltration destination, we present a leaf certificate it accepts, read the request body in plaintext, and record it as evidence. What the candidate sees is an ordinary response; what the report gets is the payload it tried to send.
For installers and apps where the malicious code only fires after a user interaction (click Install, accept the EULA, sign in), the auditor can also drive a candidate manually through a browser-based VNC view of the sandbox. The same in-guest collection, planted credentials, and TLS interception run in the background throughout. Auditor-only, never anonymous.
Every event flows through 21 streaming detectors + 3 post-enrichment detectors. The core set: HoneytokenHit (smoking gun — a planted token observed in outbound traffic), VendorDiff (unauthorized destination), SensitivePath (credential and key-file reads), SandboxDetection (probing for VM markers), HostFingerprint, TimeManipulation, Persistence (Run keys, Startup folders, services, scheduled tasks, Winlogon), PII (Luhn-validated CC numbers, JWT, email), Beaconing (regular-interval phone-home), CryptoMining (Stratum-port connects), NetworkDestination, KnownBadASN, KnownBadDomain, GeoPolicy.
A second family targets attacker tradecraft directly: DefenseEvasion (clearing the event log, disabling Defender, deleting shadow copies), CredentialAccess (LSASS / SAM / NTDS / DPAPI / browser-credential-store reads), DiscoveryRecon (system, network, and account enumeration), LOLBinAbuse (certutil / mshta / regsvr32 living-off-the-land execution), DataStaging (archiving files for exfiltration), InputCapture (keystroke capture), and DNS (algorithmically-generated lookups, DoH resolvers that route around DNS visibility, and dynamic-DNS / fast-flux domains).
Three of them exist to make blind spots visible rather than to find bad behavior, because "we observed nothing" and "we could not observe" are not the same answer. TLSCoverage reports every flow the proxy could not terminate — a certificate-pinned client's plaintext was never inspected, and the report says so instead of staying quiet. TLSReassembly catches a token or card number deliberately split across separate encrypted writes, which no single-event check can see. CloudMetadata flags reads of the cloud instance-credential endpoints that a naive link-local exemption would otherwise bury. A batch of evidence the collector abandoned rather than delivered, a collector that went silent, a candidate that never started, and a candidate that ran with administrator rights all floor the verdict too — an audit that could not see clearly never returns a clean approval.
Markdown + HTML report with a recommended decision: REJECT / REVIEW / APPROVE. Severity-grouped findings with evidence references back to the JSONL event log. Network-destinations table enriched with PTR / ASN / country. Every finding is mapped to its MITRE ATT&CK® technique and grouped by tactic, so your security team can reason about the run in the framework they already use. Reports are Ed25519-signed for tamper-evident sign-off and independently verifiable offline. The auditor signs off through the web UI — an append-only decision with rationale, and separation of duties enforced so a submitter can't approve their own audit; a baseline is saved for re-audit on the next vendor release.
Most Windows software arrives as an installer, so this is the scope statement that matters most — which is why it is here and not in a footnote. An installer is audited as an installer.
The installer's own behaviour, from the moment it starts until Windows demands administrator rights: what it unpacks and where, the files and registry values it writes, the processes it spawns, the destinations it dials, and the plaintext of the traffic the sandbox proxy can read.
A bundled third-party offer, a changed browser setting, a persistence key, a scheduled task, an undisclosed destination, a planted credential read and shipped — all of these are installed by the installer, and all of them are visible here. A hostile installer does its damage in exactly this window.
In scope
The installed product. What the software does on its second launch, after a reboot, as a background service, or through an update channel it registered is not observed today, in any run.
No verdict from swaudit speaks to it. "We did not look at that" is not "there was nothing there", and this page will not let the two be confused.
Out of scope
The candidate is deliberately run as a de-privileged standard user, never as an administrator. An administrator-level candidate shares the collector's trust domain — it could read the evidence key, forge a clean batch, or delete the record of its own behaviour — so that control is what makes a clean verdict mean anything at all.
It is not relaxed to make an installer finish. A per-machine install needs privilege the sandbox does not grant, so the audit stops where the elevation does.
By design
How to read a run that stopped at the boundary. One of two things happens, and the report says which. Either the installer never starts at all — some declare up front that they require administrator rights, and a de-privileged launch cannot grant that — or it starts, unpacks, begins installing, reaches the step that needs elevation and exits with an error. In both cases the run is reported as inconclusive and can never be filed as an approval. That is neither an endorsement nor an accusation. It does not mean the software passed: the installed product was never exercised, and not exercised is not clean. It does not mean the software failed: nothing bad was necessarily observed, and the stop is our sandbox's isolation control doing its job, not the vendor's software misbehaving. It means the audit could not be completed — and saying so plainly is the whole point, because a run like this used to render a clean "no findings" verdict over software that never installed.
Not everything hits this boundary. Software that installs per-user, and portable software that needs no install at all, runs to completion as a standard user — its full behaviour is in scope, start to finish. That is also the shape an employee downloads and runs without asking anyone, which is where the approval question is loudest. Auditing what a per-machine installer does after elevation needs a different mechanism than a de-privileged launch, and it is not built.
Evidence integrity
This is the question that decides whether any verdict means anything. The collector shares the swaudit Windows VM with the untrusted candidate — so a defensible report has to prove the candidate cannot forge a clean verdict, destroy or fabricate evidence, steal the answer key to the planted credentials, or escalate out of the sandbox into your cloud account. Not "we don't think it can." Proven, on live hardware, by a probe that runs as the candidate itself and tries every one of these.
The probe reports its own identity first, and the whole suite is thrown out as untrustworthy unless it is genuinely running as the de-privileged candidate — a control that "blocked" a privileged probe would prove nothing. Every result above was recorded in a single live run whose candidate still successfully stole and exfiltrated its planted credentials: the isolation fences the candidate without blinding the detection it protects.
In that same validation, a candidate that reads a planted credential and ships it over TLS is caught (HoneytokenHit) and the verdict is REJECT — reproduced across three independent live runs. The thing that makes the result mean something is the negative: the exact same credentials planted, a benign candidate that steals nothing, and zero hits. A positive without that negative would only prove the detector reacts to tokens existing, not to them being stolen.
Kept honest — we assert the gaps, too. A marker that is base64-encoded before it leaves, plain-http:// traffic, a client that pins its own certificate or opens a raw TLS socket that ignores the sandbox proxy, and a marker deliberately split across writes beyond the reassembly window are not claimed as caught. Each of those has a test that asserts it evades, so the coverage claim can never quietly drift into an overclaim. And every control above assumes the candidate runs de-privileged: a candidate granted administrator rights is floored to inconclusive rather than trusted, never quietly approved.
Every audit runs the candidate in a disposable Windows VM and watches what it actually does — not what its installer claims. The evidence below is what lands in the signed report.
Unique marker credentials seeded before launch
HoneytokenHit — read and transmitted
Every outbound connection, enriched with ASN and country
VendorDiff + KnownBadASN
TLS terminated in-guest, plaintext inspected
PII + honeytoken matching, reassembled across writes
Startup hooks, services, scheduled tasks
Persistence + SensitivePath
The act of checking for a sandbox is itself the signal
SandboxDetection
Every telemetry batch authenticated; a silenced or tampered collector marks the audit inconclusive rather than clean
CollectorIntegrity
Findings trace to raw evidence — the collected process, file or registry record, a decrypted payload, a timestamp. An auditor has to defend this report later, so nothing appears in it without a pointer to what produced it.
A lot of in-the-wild malware sits behind a UI gate. Headless audit boots the binary, the binary pops a "Welcome — click Install" prompt, the audit window expires, the binary exits without ever running its payload. Verdict lands at REVIEW. Real malware ships.
Interactive audit fixes this. The auditor drives the candidate manually through a browser-based VNC view of the Windows desktop while the same in-guest collection, planted credentials, and TLS interception keep recording throughout. Mouse and keyboard pass through to the candidate; the candidate sees a real human (sandbox-detection heuristics give up). The auditor captures screenshots as they go, each with a caption, and they are embedded in the rendered report so the approver can see exactly what was on screen at the moment a finding fired.
It fixes the click gate, not the elevation boundary. A human at the console can accept a licence and press Install. They cannot grant the candidate administrator rights, because running without them is the control that makes the evidence trustworthy. So on a per-machine installer, an interactive session observes the same window a headless one does — the installer's own behaviour, up to the point elevation is required. What that covers →
A single-use launch link is exchanged for a session cookie and stripped from the URL → the noVNC viewer loads → a Windows VM boots with the candidate staged and ready. Roughly four minutes from click to a usable desktop.
Click through dialogs, accept EULAs, type fake login credentials. Findings stream into a side panel as they fire — HoneytokenHit the moment the candidate exfils a planted marker, VendorDiff the moment it dials an undeclared host.
Auditor hits Stop when the demo is conclusive. The VM is destroyed and the standard Markdown + HTML report is rendered from the collected evidence — same shape as a headless audit, with the captioned screenshots attached.
Available to authenticated auditors only. Anonymous visitors and submitters never reach this surface — running real binaries interactively is bounded by an explicit role gate plus a per-server concurrency cap.
Authenticated auditors only. Clicking a button opens a fresh interactive session in a new tab — a Windows VM boots, the candidate is staged and launched, and you drive it through the noVNC viewer.
Buttons above use a session cookie set on first auth'd visit. The cookie is an opaque session ID, never the token itself, and it expires after 24 hours. Paste your bearer token here to seed the cookie without leaving the page:
Every candidate is staged into a fresh Windows VM and launched as a de-privileged standard user. What differs per format is only which program the collector is asked to start.
Every format produces the same report shape — recommended decision, summary, severity-grouped findings with raw evidence, network destinations with ASN and country, planted-credential results, and a signature an approver can verify independently. Where the candidate is an installer — an .exe setup or an .msi — what is audited is the installer's own behaviour up to the point Windows requires administrator rights, not the software once installed. Read the scope →
Most security tools call themselves "enterprise" and mean we plan to support SSO eventually. swaudit ships the full enterprise-deployment plumbing today, tested in CI — SSO behind any OAuth2/OIDC proxy you already run, three-role RBAC enforced per handler, hashed API tokens and scoped machine-to-machine service accounts, per-tenant isolation, governed approval with separation of duties, a software-request approval queue, an append-only meta-audit log, and Slack + Jira + generic webhook fanout with durable retry. Zero new third-party dependencies in the entire enterprise layer.
Sits behind any OAuth2 / OIDC reverse proxy (oauth2-proxy, Pomerium, Authentik, Keycloak). Identity is forwarded via standard X-Forwarded-Email / X-Forwarded-Groups headers. Three roles map to handler privileges: submitter, auditor, approver. Group membership at the IdP drives role assignment.
Production-ready
Issue revocable API tokens for CI/CD pipelines and dashboards, plus scoped service-account tokens (runs:read / findings:read) for machine clients. Tokens are stored hashed (SHA-256); the plaintext is shown once. A stable, versioned read API (/api/v1/runs…) returns verdicts and findings from the authoritative typed source — never by scraping a rendered report.
Production-ready
Every request through the server — submission, view, sign-off, policy view — lands in an append-only JSONL log with actor, source, roles, action, target, status, IP. Maps directly to NIST 800-53 AU-2/AU-3 audit-event controls.
Production-ready
On every REJECT verdict, post a coloured attachment to your security channel: target, decision, finding counts, link to the full report. Configurable per event type — fire on all runs, only rejected runs, or only on sign-off.
Production-ready
Auto-create a Jira issue for each REJECT verdict with the finding evidence in the description. Configurable project key, issue type, and assignee. Uses Atlassian REST API v3 — no plugin install on the Jira side.
Production-ready
Multiple destinations, per-event filters, custom headers (HMAC signing keys, auth tokens). Subscribe ServiceNow, PagerDuty, custom workflow engines, or your own SIEM intake. JSON payload includes the canonical Event shape — same data Slack and Jira receive. Delivery is durable and retried with backoff, and every attempt's outcome is observable — a failed endpoint doesn't silently drop the notification.
Production-ready
Runs, tokens, reports, and artifacts are scoped per tenant — one customer or business unit never sees another's audits. Enforced on every read and write, with a dedicated support role that can cross tenants only through an audited crossing. Per-tenant configuration (retention, allowed detectors, policy overlay) sits on top.
Production-ready
An approval is an append-only decision event with a required rationale, optional conditions and expiry — not a mutable annotation that can be quietly overwritten. Separation of duties is enforced: a submitter cannot approve their own audit. Every decision and every supersession is chained and preserved for the record.
Production-ready
A run is not a business request. Capture the requester, business owner, vendor, version, and intended use, with an immutable state history (submitted → assigned → in‑audit → closed) and the audit run linked at creation. The bridge between "someone wants to install X" and a defensible approval decision.
Production-ready
Subscribe and log in
Best for teams that want fast answers without standing up sandboxing infra.
Subscribe →Run it in your own cloud account
Best for teams that want the evidence and the audit trail to remain under their own control.
Get deployment instructions →What self-hosted does not mean. Every audit runs a real Windows VM, so the candidate binary leaves your local network for the cloud account you configure. That is a deliberate trade — a hypervisor boundary is a stronger isolation guarantee than a container — but it means fully on-premise and air-gapped operation are not supported, and neither is any deployment without cloud credentials. The supported control-plane artifact is Docker Compose; there is no Helm chart, Kubernetes manifest, Terraform module, or bare-metal installer, and no supported backup, restore, or upgrade procedure. If binaries are contractually barred from leaving your premises, swaudit is not currently a fit, and we would rather tell you here.
Submit a binary. Get evidence. Sign off with confidence.
By submitting, you agree to the swaudit Terms of Service and Privacy Policy.
Thanks — we'll be in touch.
Submission failed — please email rapidvps@gmail.com directly.