Secure Software Development

Most software gets its security at the end: a scan before release, a list of findings and an argument about which ones can wait. Fixing a design mistake at that stage is slow and expensive, and some never get fixed at all.

We build the other way round. We decide how the system could be attacked before we decide how to build it, and every later choice answers to that.

What we build

• Security-focused products, where protecting data is the whole point of the software.
• Web applications and APIs that handle accounts, money or personal data.
• Backend systems and internal tools that need to be fast and need to stay up.
• Replacements for risky systems, when patching something old has stopped making sense.

How security shapes the work

A threat model, before any code

We write down what you are protecting, who would want it and how they would try to get it. Just as useful, we write down what the system will not defend against, so nobody assumes otherwise.

Boring, proven cryptography

We use standard primitives from well-tested libraries and never invent our own. Pass1, our open-source password manager, shows how we approach this in public.

Authorization you can test

Access rules live in one place and are denied by default. Each rule has a test, so a later change can’t quietly remove it.

Attacking our own work

Before release we review the code the way an attacker would: we try to break it, fix what we find and write down the risks that remain.

What you receive

• Working software, with its source code and the right to keep it
• Tests, including tests for the security rules
• The threat model and a security review of the final system
• Documentation your own team can run it from, without depending on us

Good fit

This suits you if you are building something where a breach would be a serious problem for your business, or if you have a working prototype that now needs to be safe for real customers.