swaudit runs candidate applications in an instrumented sandbox, watches everything they do, and produces a defensible report that supports your approve / reject decision. Zero unknowns. All evidence.
15 seconds, no edits. Below the video: a step indicator + plain-English caption that updates as it plays, so you can follow along even if you've never seen the tool before.
What you're looking at: the auditor's homepage. Every row is one audit they've run. The big red boxes are REJECT verdicts — the binary tried to do something malicious. Numbers are how many findings of each severity (high / medium / low / info).
What you're looking at: the submit page. The auditor drops a Windows candidate here — an .exe, an .msi installer, or a PowerShell, HTA, WSF, or batch script. The system works out what kind of thing it is by looking inside the file rather than trusting its name, then launches it the way a real Windows machine would.
What you're looking at: the verdict. Big red banner: REJECT, 8 high-severity findings. Below that: every suspicious thing the binary actually did, with proof. The first finding here is "sandbox-detection" — the binary read /proc/cpuinfo looking for hypervisor brands (real apps don't need to know whether they're in a VM; malware does, so it can hide).
What you're looking at: a SHA-256 verification page. Every report is cryptographically signed. Months later, a vendor / regulator / board member can re-upload the report file and its signature here, and we'll tell them whether the report is the exact one we produced or if anyone has edited it.
What you're looking at: a policy that overlays on every audit. Acme Corp here has set: only allow vendors hosted in 9 countries, block 4 specific ASNs, and auto-REJECT on anything matching honeytoken hits, crypto mining, known-bad ASNs, or known-bad domains — no exceptions, regardless of what the vendor's manifest claims.
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 syscall, every TLS payload (decrypted), every network destination. 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/credentials, ~/.ssh/, browser cookie stores, password registry hives.We seed a fake AWS access key into the sandbox before the candidate starts. We've never told anyone what it is. There's no plausible reason that exact 24-character 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 14 streaming detectors + 3 post-enrichment detectors: 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.
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. Dropped kernel events, a collector that went silent, and a candidate that never started 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. SHA-256 sidecar for tamper-evident sign-off. Auditor signs off through the web UI; baseline saved for re-audit on the next vendor release.
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 — a syscall 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 observe everything. Mouse and keyboard pass through to the candidate; the candidate sees a real human (sandbox-detection heuristics give up). The session recorder writes an mp4 alongside the report so the approver can replay exactly what the auditor saw and clicked.
Token in the URL → browser cookie set → noVNC viewer loads → a Windows VM boots with the candidate staged and ready. ~4 min seconds from click to first paint.
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, the screen recording is flushed, and the standard Markdown + HTML report is rendered from the collected evidence — same shape as a headless audit, with the recording 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. Cookie persists 7 days. 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.
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, append-only meta-audit log, Slack + Jira + generic webhook fanout. 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. Tokens are stored hashed (SHA-256); the plaintext is shown once. Manage with audit-token create / list / revoke. Use as Authorization: Bearer aat_… against the JSON API.
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.
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.