Secure development

Six steps, in order

1. Change, with its reasoning in the commit. With one engineer, a change lands on the default branch; every push runs the pipeline below, and a branch-and-review step is the committed procedure from the day a second engineer joins.
2. Static type checking. The codebase is fully typed and a type error stops the change. This is what makes controls such as the licence classification a compile-time requirement rather than a convention.
3. Automated tests. 2,834 of them, including tests that assert security controls refuse.
4. Review against the recorded reasoning in the repository before the change lands — today by the one engineer who wrote it; by a second engineer from the day one joins.
5. Deploy as an immutable version. The platform records every deployment; nothing is edited in place.
6. Verify against the running system after deployment, rather than treating a passing test suite as confirmation that a feature works.

Version control is the audit trail

• Every change lands through version control with a full auditable history: who, when, what and why. The reasoning is recorded in the commit alongside the change.
• Database changes are versioned migrations, applied in order, recorded in a ledger and replayable from the repository. There are currently 154. An ad-hoc change to the production schema that is not written as a migration is treated as a defect, and the operations report compares what the code expects against what the database holds.
• Deployments are immutable and versioned. Rollback is redeploying a prior version rather than editing a running system.
• Schema changes are additive first, so the old and new application versions can run concurrently during a deployment.
• Secrets are never committed. Every push is scanned for credential patterns before anything else in the pipeline runs.

What each environment can reach

There is no shared staging environment holding a copy of production data. A staging copy is a second copy of the data under weaker controls and is a common source of exposure. Correctness is established by the type system, the test suite and the integrity checks; deployment safety is established by immutability and fast rollback.

The development machine reaches production and is treated as production access under access control: one holder, full-disk encrypted, its secrets in a git-ignored file that the credential scanner would refuse if it were ever staged.

The specific controls in this codebase

• Parameterised queries throughout. No string-built SQL on any path that accepts user input. Query filters are built by shared builders so that a new endpoint cannot construct its own and lose a control — the licence filter is implemented inside one of those builders for that reason.
• Fail closed. Authorisation failures deny; a refused request never reads from or writes to the shared cache; an unrecognised data source is treated as licence-restricted rather than open.
• Inputs are validated and bounded. Every list endpoint has a hard row ceiling, every request has a time budget, and every external fetch has a timeout. Bulk export is a licensing arrangement rather than a query parameter.
• Output encoding and a restrictive Content-Security-Policy on every public page, enumerating the permitted origins.
• No secret reaches a log, an error message or a response body.
• Errors are surfaced rather than swallowed. A component that cannot do its job reports that, rather than returning an empty result — an empty result and a broken component are indistinguishable downstream. This is the most consistently enforced rule in the codebase.

What governs a change at this company's size

Reviewers ask whether one person can put arbitrary code into production unnoticed. The current position:

Deployment is performed by the engineering owner. A second human approver is planned as the team grows and will be documented here when it is in place. The controls that apply today:

• Deployment runs from the pipeline, after the gates. The deploy job exists only on a run in which the credential scan, the type check and the 2,834 tests — including tests that assert the security controls refuse — have passed, and it proves what it shipped by reading the deployed commit back from the running system. The engineering owner also holds a deploy credential for emergency use; any use of it is recorded in the changelog.
• Every deployment is recorded and immutable. There is a complete, externally held record of every version that has run and when, and rollback takes about a minute.
• The database enforces its own half. Deny-by-default row-level security and zero publicly executable functions mean an application error does not become a data exposure.
• The integrity checks monitor outcomes, not intent. A change that breaks the licence filter, empties a column or stops a cursor advancing is detected regardless of who deployed it.
• Every change is recorded with its reasoning, so the history is reviewable after the fact, including by an auditor.