Security and assurance
The security controls RJV has built and tested, what it has not yet done, how to report a vulnerability and what RJV does not claim.
On this page
The position RJV takes
RJV does not claim that its systems are unbreakable. The aim is narrower and can be tested: keep the exposed surface small, check authority at the moment of use, stop untrusted content from acquiring authority, make compromise detectable, and make recovery something that has been practised. A fault in the web process should not become control of the host, the database, the release process or another customer's data.
A statement on this page names what was checked and how. Where nothing has been checked, the page says so.
Controls in place, and how each was checked
| Control | What it does | How it was checked |
|---|---|---|
| Authority at execution | An operation runs only while a grant for that operation on that resource is current. The default answer is refusal. | Automated tests of allowed and refused callers, expired and revoked grants, and callers acting on resources that are not theirs. |
| Sign in and sessions | Passwords, authenticator codes and passkeys. Repeated failures are throttled. A session can be revoked and ends when it expires. | Automated tests, including replay and concurrency cases for passkeys. Passkeys have not been run with a physical authenticator. |
| Browser protections | A content policy forbids executable browser scripts, permits images and styles only from this site's own origin, refuses framing, and blocks other sources by default. Other controls include file type protection, a transport security header, checks of origin on state changing requests, and protected session cookies. | Automated tests of the headers on every response, including errors, and of the request checks. |
| Database privileges | The application connects as a role that does not own the tables. It cannot rewrite the evidence chain or change a ledger balance directly. | Automated tests that run as that role and expect the refusals. |
| Evidence | Each consequential change writes an entry in the same transaction. Entries are append only and linked by fingerprint, so an alteration breaks the chain. | Automated tests of the chain and of its verification. |
| Memory safety | The code forbids unsafe Rust across the whole project, and a build check fails if the setting is removed. | The build check, run before every release. |
| Dependencies | Third party licences are checked against a policy, a software bill of materials is generated, and outside services the code can reach are declared. | Build checks that fail on an undeclared service or an unapproved licence. |
| Release and rollback | A release is built from a clean source tree, installed as a numbered release and reversed by pointing back at the previous one. | Used for every release on RJV's own host. |
What has not been done
- No independent security assessment or penetration test has taken place.
- The platform has not been mapped requirement by requirement to a published verification standard, so no level of such a standard is claimed.
- A backup procedure exists, but a full restoration onto a clean machine has not yet been carried out, so recovery time and data loss are not known.
- Release provenance is not yet signed, and a software bill of materials is not yet pinned to each release.
- The reachable surface of the host and its network has not yet been reconciled against a written inventory by an independent party.
Each of these is work to be done, and the list will change as it is done. The evidence and limitations page records the claims that have been graded.
How to read a security claim from RJV
RJV works to a written security baseline adopted on 22 October 2026. It has not been independently assessed against that baseline, so this site does not claim conformance with it or with any named standard. When an assessment is done, the claim will name the baseline, the scope, the date and the exclusions, in the form "assessed against this baseline, for this scope, on this date". RJV will not describe its systems as impossible to breach, and it will not compare them with the defences of any named organisation.
Data and outside services
The privacy notice states what personal data is collected, why and for how long. The services that handle data outside the application are listed in the sub processor register, and the services the application itself can reach are set out on the deployment and ownership page.
Reporting a vulnerability
Follow the disclosure process. It names the contact address, what to include and the safe harbour that applies to good faith research.
- Published
- 24 October 2026
- Revision
- 4