Security
This page is written for whoever vets a contractor before the deal. Nothing here has to be taken on trust: it is either verifiable from the outside in a minute, or produced on request. At the bottom there is a section on what we do not have.
Found a vulnerability — write to us
The machine-readable contact lives at /.well-known/security.txt per RFC 9116. Security reports go to the same address as everything else: [email protected].
- We reply within one business day and confirm receipt.
- We do not pursue researchers acting in good faith: no data exfiltration, no availability damage, no touching other people’s accounts.
- We tell you what was fixed and when. Critical issues come first, the rest as we work through them.
- We pay no bounties — we have no bug bounty programme, and promising one would be dishonest.
What is visible from outside
Everything below is verifiable without us: securityheaders.com, ssllabs.com or a plain curl. If any of it stops being true, you will see it before we manage to edit this page.
The server
- Ubuntu 24.04 LTS with automatic security updates enabled.
- Key-based access only: SSH password authentication is fully disabled.
- The firewall exposes three ports — 22, 80 and 443. Applications are reachable only through the reverse proxy, never directly from the internet.
- Secrets live in files with 600 permissions outside the repository. They are not in git and never were — the history proves it.
- The mail bridge listens on loopback only: the site is exposed, the service is not.
Visitor data
The site has no persistent store of personal data — not out of strictness, but by architecture: there is nothing to lose.
- A submitted form is delivered as a message to our working chat and is not saved in any site database.
- The IP address is used only for rate limiting — no more than five submissions per ten minutes — and is held in memory for those ten minutes.
- Analytics does not load until the visitor consents: before that there is not a single third-party script or analytics cookie on the page.
- The form is protected by a hidden honeypot field and server-side validation. There is deliberately no CAPTCHA: it filters out humans as effectively as bots.
- SPF authorises exactly one sending server; the policy is hard-fail — everything else is rejected.
- DKIM signs outgoing mail with the domain key.
- DMARC is set to quarantine: mail sent in our name from foreign servers lands in spam.
- Incoming mail is accepted without a mailbox and handed to an internal service using a shared secret compared in constant time.
Development and deployment
- Every commit passes type checking, linting, a build and a content check before it can reach the server.
- Dependency updates arrive as automated pull requests weekly and go through the same checks.
- A new version is built into a separate directory and swapped in with two renames — the site never serves broken pages mid-build.
- A health check follows every deploy. If the new version does not respond within thirty seconds, the previous one is restored automatically.
Handling your access
These are commitments, not settings: they cannot be verified from outside, but they can be written into the contract — and we agree to that.
- We work under individual accounts with the minimum sufficient rights. We do not create shared “team” passwords.
- Secrets are exchanged through a password manager or your own perimeter, not as a message in a chat.
- When the work ends we ask you to revoke access and confirm that nothing was left behind on our side.
- Production data is not copied onto working machines: debugging runs on anonymised sets.
- The NDA is signed before the first substantive call, not after.
What we do not have
The section nobody writes. We write it because a security officer will check anyway, and anything they find on their own always reads as concealment.
SOC 2 or ISO 27001 certification
None. We are a small engineering company and we are not going to buy a certificate for the sake of a line in a deck. If your procurement requires one, say so upfront so neither side wastes time.
External penetration test of this site
Not performed. The site is a showcase with no user accounts and no data store; we spend penetration testing on client systems, not on our own page.
Content-Security-Policy
Not enabled yet. The site carries inline scripts and a strict policy would break functionality silently. The correct order is report-only first, a week of observation, then enforcement — that work is not done yet.
A bounty programme
None. We accept and fix vulnerability reports, but we do not pay for them and do not promise to.
Who to write to
For security questions, a DPA, the subprocessor list or an NDA — [email protected]. The founder answers, not a support desk.