A fresh install exposes nothing it does not have to
FoxByte runs on infrastructure you control, and its defaults assume the network is not your friend. Here is what it does out of the box, and how to report a problem.
Secure before you touch a setting
Loopback only
The console, gateway and Agent API listen on 127.0.0.1 until you choose otherwise.
TLS, no silent fallback
A service that cannot load its certificate refuses to start rather than serve plain text off loopback.
First account needs a token
The first sign-up needs a one-time setup token, and sign-up closes after it.
Brakes on guessing
Ten failed sign-ins in 15 minutes hold further attempts; request bodies and connections are capped.
Branches belong to their maker
Other people’s branches are not listed and answer “not found”, through the gateway too.
A password per role
Each account and agent logs in to Postgres with its own password; there are no superuser switches in release builds.
Verify what you install
Every release’s SHA256SUMS is signed with the FoxByte release key. The installer checks that signature wherever OpenSSL 3 is available; macOS ships LibreSSL, which cannot, so there it checks every file against SHA256SUMS and warns. Set FOX_REQUIRE_SIGNATURE=1 to refuse instead. fox update checks the signature on every update and never installs a release that fails. Each file has a GitHub build attestation, and each release an SPDX SBOM.
$ curl -fsSL https://get.thefoxbyte.com/install.sh | FOX_REQUIRE_SIGNATURE=1 sh $ gh attestation verify fox-darwin-arm64 --repo thefoxbyte/foxbyte $ gh attestation verify oci://ghcr.io/thefoxbyte/postgres-walg:18 --repo thefoxbyte/foxbyte
Check the key, not just the signature
| What | Value |
|---|---|
| Algorithm | Ed25519 |
| Public key (base64) | aTn8b2xj53r7QjOK+K2//RBU+4OBHoxzuclxGK04WZc= |
| SHA-256 of the key | f30408e212e75bff72b715db8264c076f7765b6be121e895d8a7e7b1a20ff682 |
| SBOM | foxbyte-sbom.spdx.json, attached to every release |
The same key is built into fox and into install.sh. A release signed by any other key is refused.
Who FoxByte defends against, and where it stops
- People and agents who log in through FoxByte. None of them is a superuser: they cannot stop the Blackbox, write to it, forge who they are, or reach a branch that is not theirs.
- Someone on the network. Services listen on loopback until you open them, TLS refuses to fall back to plain text, and sign-ins are throttled.
- A database superuser can stop the Blackbox’s event triggers. Signed anchors kept off the machine prove that recorded history was not rewritten; the next release also records what the triggers missed.
- Root on the machine can read the disk and the anchor key there. Encryption at rest is not built in yet: use full-disk encryption, and server-side encryption on the backup bucket. Anchors kept elsewhere stay the proof.
- No independent penetration test has been done yet. Reports go through the private process below.
Logs you can prove
Blackbox
Every schema change, hash-chained and anchored outside the database.
Learn more →Security log
Sign-ins, keys, password changes, admin grants and refused requests, chained and anchored the same way.
Report a vulnerability privately
Please do not open a public issue for security problems. We would rather hear first, and we answer quickly.
- 1
Report
Use GitHub’s private vulnerability reporting: the repository’s Security tab, then Report a vulnerability. No GitHub account? Email info@thefoxbyte.com with Security report in the subject.
- 2
Acknowledgement
Within 3 business days.
- 3
Assessment
Severity and whether we can reproduce it, within 7 days, then updates as we fix it and credit in the release notes if you want it.
Review it like a security team would.
Read the code, verify the release, and report anything you find privately.
$ curl -fsSL https://get.thefoxbyte.com/install.sh | sh