Security and governance
What is built in, how it is checked, and what it does not tell you.
Open source earns the name by showing its work. We do not certify our own code and we do not say “our code is secure”. This page lists the controls a security officer asks for, says what we check and why, what the checks cannot tell you, and where every result is published. It carries no version numbers and no counts, because those change with every release: the current ones are in the published results.
What is built in
The question
In Whoobe
Documented
Who did what, and from where?
An append-only audit log of administrative actions: who, from which address, what, on which target, the fields before and after. Secrets are recorded as “changed”, never as a value. Filters and CSV export. The database refuses to update or truncate it.
Is a second factor required?
An administrator chooses the roles that must use two-factor authentication. A user of such a role with no second factor is led to enrolment and gets no session until it is done. A password policy applies where a password is set.
Can staff sign in with our identity provider?
OpenID Connect single sign-on (authorization code with PKCE), roles taken from a claim at each sign-in, provisioning by a verified e-mail only, a local break-glass for administrators.
Where do the credentials of integrations live?
Encrypted at rest, decrypted only inside the gateway, never sent to a browser. Keys come from the environment; the procedure to rotate each secret is written down (it is manual).
Can we answer a data subject request?
Find, export and erase what is held about one person by one value (an e-mail), with a dry run first and the action audited without the value. Retention per data class.
Does it run on a closed network?
A profile with no outside request: fonts and icons are bundled, no CDN, no outside image service. It was run on a Docker network with no route out.
Can we monitor it?
A readiness and a liveness endpoint, Prometheus metrics behind a token, structured logs with a switch for the level.
Can we recover?
Encrypted database backups and restore scripts, and a rehearsal script that restores a backup into a throwaway stack and checks it.
Is the supply chain looked at?
Service images signed and published per release, with build provenance and a software bill of materials; the CI runs a dependency audit, a secret scan, static analysis and container scans.
Has it been tested?
Automated API, browser, isolation and DAST suites run in CI on a disposable stack. The findings, open and closed, are published.
What we tested, and with what objective
We do not say “our code is secure”, and we do not certify it ourselves. We say what we set out to check, and how.
The objective
How it is checked
Sessions, lockout, password reset, the second factor and single sign-on behave as designed
API test suites; the OpenID Connect sign-in against a mock and a real Keycloak
Every route is guarded as intended
Every route is classified (public, signed in, or by permission) in a checked-in contract, and each guarded route is called as five different identities. A new route with no classification fails the run.
One workspace cannot reach another
Two workspaces are started side by side and one tries to reach the other
Visitors cannot read what is not public
Tests of drafts, preview tokens, private files and the public search
Uploads and outbound requests cannot be abused
Upload tests (type, content, size, tickets) and a guard against requests to internal addresses, tested
Stored text and pages do not run injected code
Browser tests that feed hostile markup to the editor, the published pages and the lists of the dashboard
No secret in the code or its history, no known vulnerable dependency or image
Secret scan of the tree and of the whole git history, dependency audit, static analysis and container and configuration scans
The running stack answers safely to a standard scan
An OWASP ZAP baseline scan of the running stack, and a scan of the proxy template's TLS policy
What each suite asserts, and what it does not: the test suite document.
What the tests do not tell you
A green run means that these checks passed on this code, at this commit. It does not mean that there are no vulnerabilities. It is not an audit, a penetration test or a certification.
The coverage has holes, and they are listed with the results of each release and in the status summary, not left out.
Where the results are, and they stay public
Open source earns the name by showing its work. The tests, the findings, the results of every release and the plans are in the repository or in its public history. The failures are published too: a run that failed before the green one stays in the record.
What
What it is
Where
The tests
In the repository (scripts/security): anyone can run them against a disposable stack.
What each suite asserts, and what it does not
Written for reviewers, with the plan and a manual checklist.
Every finding, open or closed
A register with severity and state, published when a finding is made, not when it is fixed.
The result of each release
One record per release: the run, the commit, every job, the runs that failed first, what changed after the test, what was not covered.
If a claim on this site is not backed by something you can open, ask in GitHub Discussions. A vulnerability goes the other way, privately: see the security policy and the disclosure policy, never a public discussion.
What is not there
Two-factor authentication, the password policy and retention are off until you set them. An upgrade changes nothing by itself.
No high availability. One installation, one database; recovery is by backup and restore.
No third-party certification (ISO 27001, SOC 2) is claimed here. Any outside audit would be linked from the results.
It is a 0. series: behaviour can change between minor releases. The release notes list what.
Check it yourself
The sandbox is the real product with the risky features switched off, and the tests and their results are public.