RunAlexDB Security

Status

RunAlexDB is under active development and has not yet undergone an external, human-run security audit. It is also not yet public. Until an external audit has happened, RunAlexDB is not recommended for production deployments handling sensitive traffic.

What has been done

RunAlexDB has been through repeated rounds of internal and adversarial AI-assisted security review, covering MVCC/concurrency correctness, WAL durability and crash-safety, replication and HA (semisynchronous replication, two-phase commit, leader election and lease fencing), and the network/authentication/injection surface. Every finding from those rounds is tracked with an explicit severity and status — fixed, accepted, open, or disputed — never silently dropped. Examples of what that process has actually caught and fixed: an authorization bypass on a general code path, prepared statements that weren’t reaching the WAL, a missing self-fencing check during peer-to-peer leader election, a silent durability loss during two-phase-commit finalization, and an AUTO_INCREMENT collision under row-grain concurrency. Re-verification of a fix happens in a different session or model than the one that produced it.

Verifying a release

Signed the same way as Runbound, with the same key:

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

Reporting a vulnerability

Email security@runasm.com with details and, if possible, a reproduction, rather than opening a public issue first.