Runbound Security

Status

Runbound is under active development and has not yet undergone an external, human-run security audit. That audit is planned before the v1.0 tag. Until then, Runbound is not recommended for production deployments handling sensitive traffic.

What has been done

Every release goes through internal and adversarial AI-assisted security review before shipping — concurrency, memory safety (panic/unwrap/silent error swallowing), network surface and authentication, and injection paths (SQL/command/path/template) are all in scope for each pass. Findings are tracked with an explicit severity (CRITICAL/HIGH/MEDIUM/LOW/INFO) and an explicit status — fixed, accepted, open, or disputed. A finding is never presented as fixed until it’s been re-verified, and re-verification happens in a different session or model than the one that produced the fix, specifically to avoid a reviewer confirming its own blind spot.

Verifying a release

Every published asset — each binary and SHA256SUMS — carries its own minisign signature, not just an aggregate checksum file:

minisign -Vm runbound-x86_64-linux-gnu -P RWSBM9HzDiZpfCD82uTnkeP1Ui30LfWE96C8EtFyI4/WVyLAVxpLzYy/
minisign -Vm SHA256SUMS -P RWSBM9HzDiZpfCD82uTnkeP1Ui30LfWE96C8EtFyI4/WVyLAVxpLzYy/
sha256sum -c SHA256SUMS --ignore-missing

The same key signs Runbound and RunAlexDB releases — one maintainer, two projects, one signing identity to track.

Reporting a vulnerability

Email security@runasm.com with details and, if possible, a reproduction. Please don’t open a public GitHub issue for a suspected vulnerability before it’s been triaged privately.

Roadmap to v1.0

An external, human-run security audit is the last gate before the v1.0 tag — tracked publicly as issue #170. Everything else planned for v1.0 (DNSSEC, serve-stale, the built-in web UI, automatic firewall integration) has already shipped.