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 file here — a Linux binary, a Windows .exe, a Docker container image, or any of 18 supported package formats (npm, PyPI, NuGet, …). Or pastes a URL and we fetch it. The system auto-detects what kind of thing it is by looking inside the file.
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 binary, container image, or package through the web UI. Or paste a URL — the system fetches it for you. 18 formats auto-detected: Linux ELF, Windows .exe, Docker / OCI container images, npm .tgz, PyPI sdist + wheel, NuGet .nupkg, Cargo .crate, RubyGems .gem, Composer, Maven JAR, Go modules, Helm charts, Conda packages, Hex packages, VS Code / Chrome / Firefox extensions. Detection is structural — we peek inside archives for ecosystem-specific manifest files rather than trusting filename extensions. Each format routes through the appropriate audit path: install commands run under instrumentation for npm / PyPI / Maven JAR, with broader runtime support landing per release.
Run the binary in a privileged Linux container with eBPF tracepoints on every syscall, uprobes on libssl + Go's crypto/tls (capturing plaintext before encryption), and a TLS-terminating proxy at the container egress (catches TLS libraries we don't have hooks for). 18 unique-per-run honeytokens are planted in ~/.aws/credentials, ~/.ssh/id_rsa, browser cookie stores, env vars.
The sandbox runs on an internet-isolated Docker network. iptables redirects all outbound 443 traffic to the in-sandbox proxy — so when the candidate dials a real exfil destination, we issue a leaf cert it accepts (CA injected at boot), capture the POST body in plaintext, then drop the bytes. The candidate sees a clean response and moves on; the honeytokens never leave the host.
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. Same eBPF + honeytoken + TLS-proxy instrumentation runs in the background; ffmpeg records the session as evidence. Auditor-only, never anonymous.
Every event flows through 13 streaming detectors + 3 post-enrichment detectors: HoneytokenHit (smoking gun — a planted token observed in outbound traffic), VendorDiff (unauthorized destination), SandboxDetection (probing for VM markers), HostFingerprint, TimeManipulation, Persistence (write-shape opens of cron / systemd / shell rc files), PII (Luhn-validated CC numbers, JWT, email), Beaconing (regular-interval phone-home), CryptoMining (Stratum-port connects), KnownBadASN, KnownBadDomain, GeoPolicy.
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.
Synthetic clones modeled after public disclosures. The audit pipeline positively identifies each one (43-assertion test suite passing). Click any tile to read the actual REJECT report.
2017 · Avast supply-chain trojan
HostFingerprint + VendorDiff
2020 · ~18,000 customer orgs
SandboxDetection + TimeManipulation + Beaconing
2023 · Mac + Windows info-stealer
HoneytokenHit (Chrome cookie marker)
2015 · ~4,000 iOS App Store apps
VendorDiff (typosquat) + HostFingerprint
2018 · BTC-wallet stealer
HoneytokenHit (BTC wallet marker)
2021 · CVE-2021-44228
HoneytokenHit + VendorDiff
various · DPRK actor
HoneytokenHit (SSH key marker)
2017 · pre-destructive fingerprint
HostFingerprint + SandboxDetection + TimeManipulation
2021 · RMM-agent ransomware
SensitivePath + Persistence + VendorDiff
2023 · mass-exfil exploit
HoneytokenHit (sensitive-doc marker)
2021 · env-scrape + stage-2
HoneytokenHit + VendorDiff
2021 · CI env wholesale dump
HoneytokenHit + VendorDiff
2022 · post-takeover exfil
HoneytokenHit + VendorDiff
2022 · multi-marker harvester
HoneytokenHit (multiple markers)
2014+ · travel-targeting
HostFingerprint + TimeManipulation + SandboxDetection
2018 · MSP cloud-cred pivot
HoneytokenHit (AWS) + SensitivePath
Highlighted tiles are HoneytokenHit findings — the strongest possible signal. The candidate read our planted credential and transmitted it. There's no benign interpretation.
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 sandbox while the same eBPF + honeytoken + TLS-proxy instrumentation observes 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 → sandbox container spawns with Wine + Xvfb + the candidate. ~10 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. Container tears down, ffmpeg flushes session.mp4, tracer renders the standard Markdown + HTML REJECT report — same shape as headless audits, 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 — Wine + Xvfb spin up, the candidate runs, 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:
Pick any of 16 historical supply-chain compromises (plus one clean control). When a live audit-server is reachable, this fires a real audit in an internet-isolated sandbox on our infrastructure: the candidate executes for real, we plant fresh honeytokens, the in-sandbox TLS proxy captures any plaintext exfil attempt, and the report you see is rendered from actual eBPF events (typically 10–15 seconds end-to-end). When the live server isn't reachable, the same picker replays the audit-report Markdown the production tool actually produced. The verdicts and finding counts shown are not simulated either way.
Choose a sample to audit:
Pick a candidate above to begin.
Most security tools are platform- or ecosystem-specific — a binary scanner here, an npm scanner there, a container scanner over there. swaudit is one pipeline: upload anything, get the same defensible REJECT/REVIEW/APPROVE report. Detection is structural (we peek inside archives for ecosystem manifests), not extension-based, so a mislabelled file gets routed correctly anyway.
Click any format to see exactly how we audit it — detection method, execution strategy, and the specific detectors that fire.
All formats produce the same Markdown + HTML report shape — Recommended decision, Summary, severity-grouped findings, evidence, coverage caveats. Click any tile above to see the format-specific detection methods.
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 on your own infrastructure
Best for HIPAA, PCI, FedRAMP, or other settings where binaries can't leave your network.
Get deployment instructions →Submit a binary. Get evidence. Sign off with confidence.
Thanks — we'll be in touch.
Submission failed — please email rapidvps@gmail.com directly.