The microsandbox team welcomes security reports and is committed to addressing security issues promptly. microsandbox is an isolation primitive, so security issues in it affect everyone who builds on it. We treat reports as a high priority.

The preferred channel is GitHub's private vulnerability reporting. It gives us a private channel to discuss the issue and coordinate a fix, and it integrates cleanly with CVE assignment when warranted.

If GitHub isn't an option, email security@superrad.company.

Security issues should not be reported via the public GitHub issue tracker, in Discord, or on social media before we've shipped a fix.

To help us triage quickly:

• A description of the issue and its impact
• A minimal reproduction (PoC code, sandbox config, or commands)
• The microsandbox version (microsandbox --version) or commit SHA
• Host platform (Linux distro and kernel, or macOS version and chip)
• Any logs, traces, or screenshots that help

In scope:

• microsandbox core (github.com/superradcompany/microsandbox)
• microsandbox SDKs (Python and Node)
• microsandbox managed cloud and its control plane (when generally available)
• Build, signing, and release infrastructure (binaries, package registries)

Vulnerability classes we're particularly interested in:

• Sandbox escape (guest workload to host)
• Isolation bypass between sandboxes
• Network policy or egress-filter bypass
• Host privilege escalation
• Secret or credential leakage outside the intended boundary
• Snapshot or restore paths leaking data across sandboxes
• Authentication or authorization bugs in the control plane
• Supply-chain issues (compromised builds, malicious dependencies)

Out of scope:

• Issues requiring physical access to the host
• Self-DoS (e.g. crashing your own sandbox with adversarial input)
• Theoretical issues without a working PoC
• Already-known issues in upstream dependencies (please report those to the upstream project)
• Best-practice or hardening suggestions that aren't exploitable

We're a small team and we're honest about our response capacity. Our targets:

We'll keep you informed throughout: when we've triaged, when a fix is in progress, when it ships, and when an advisory is published.

We're committed to transparency in security disclosure. We publish advisories through our GitHub repository's security advisories portal and the RustSec advisory database.

We follow coordinated disclosure with a default 90-day embargo from the date of initial acknowledgment. We may publish sooner if a fix ships earlier, or extend the timeline (in discussion with the reporter) for genuinely complex fixes.

If a vulnerability is being actively exploited in the wild, we'll prioritize the fix and shorten the embargo as needed.

We credit reporters in our security advisories unless you'd prefer to remain anonymous. Include your preferred name and a link (GitHub, X, personal site) in your report if you'd like to be credited.

We don't currently run a paid bug bounty program. We may introduce one as the company grows.

If anything here is unclear, email security@superrad.company.