(1) Fossil is designed to run inside a minimal chroot jail. The stand-alone "fossil" binary needs its repository database file, /dev/null, and /dev/random and nothing else. It can run inside a sparse jail. So even if somebody manages to find an RCE in Fossil, the damage potential is limited. They cannot shell-out because there is no /bin/sh in the jail.

(2) Fossil processes each HTTP request in a separate process.

(3) Custom static-analysis tools run over the Fossil sources at compile-time, and abort the built if any problems are seen. The source code and docs to these tools is in the Fossil source tree.

As is stunnel, which is what the canonical fossil website uses to handle HTTPS

Fossil's been available for nearly 14 years now and we've had to make only a single security-relevant release in that time (in late Summer 2020).

Fossil's primary architect, Richard Hipp (edit: HN user "SQLite"), is no stranger to code hardening and continues to add security-related APIs to all levels of the code, from how we internally build SQL queries or encode URL arguments to the recent (late 2020) ability for the db to lock down regions of the db until/unless that protection is toggled off for the brief blocks of code which need to modify those regions, ensuring that other areas of the code cannot modify parts of the database which they aren't directly responsible for. Security against malicious inputs has never been treated as an afterthought in fossil.

If you want something more complicated (BSD jails, Docker, etc.) the same properties make it easy to box up that way instead.