Security is not a launch checklist

1. Model the threat before choosing tools

A threat model does not need a formal template. One hour with a whiteboard and three questions is often enough: what would hurt most if it leaked, who could reach it, and how would we know. The answers decide which controls are worth paying for.

Without that step, teams buy protection for the wrong layer. A web application firewall does not help when the real risk is an internal export tool that any staff account can call, or a database backup copied to a personal drive.

• List the assets that matter: customer records, payment data, credentials, business logic, operational availability.
• List who can reach each asset: end users, staff, partners, background jobs, third-party services.
• List the paths in: public pages, authenticated APIs, admin tools, integrations, deployment pipeline, support workflows.
• For each asset, name the worst realistic outcome and the control that would prevent or reveal it.

A useful threat model is short and revisited. It should change when the product adds a role, an integration or a new class of data.

2. Treat identity and access as the real perimeter

Once a system has staff tools, partner accounts and background jobs, the network boundary stops being the boundary. Access control becomes the control that matters, and it has to be enforced on the server for every request, not implied by a hidden menu item.

Authorisation bugs are the most common serious finding precisely because they look like working software. The page renders, the request succeeds, and the only thing wrong is whose data came back. That class of defect is invisible to a scanner and obvious to a test that asks a second user to fetch the first user's record.

• Check permission on the server for every read and write, including exports, file downloads and webhooks.
• Scope queries by the caller's organisation or unit rather than filtering results after fetching them.
• Separate roles by the decisions people make, not by job title, and keep the number of roles small enough to explain.
• Require strong second-factor authentication for administrative and financial actions.
• Review accounts on a schedule, and make offboarding remove access the same day.

3. Decide what you keep, and where secrets live

The cheapest way to protect data is to not hold it. Before adding a field, ask who needs it, for how long and what happens when it is wrong. Full identity numbers, precise locations and complete payment details are often collected because a form template included them, not because an operating step requires them.

Secrets deserve the same discipline. API keys in a repository, a shared password in a chat thread or a production connection string in a developer's local file are all the same defect: a credential with no owner, no rotation and no record of use.

• Classify data into public, internal, confidential and regulated, and let the class drive the controls.
• Set a retention period for each class, and make deletion an implemented job rather than an intention.
• Encrypt in transit everywhere, and encrypt sensitive fields at rest with keys the application does not store beside them.
• Keep secrets in a managed store, injected at runtime, rotated on a schedule and revocable in minutes.
• Hash passwords with a purpose-built algorithm, and never log credentials, tokens or full personal records.

Backups follow the same rules as production. A hardened database and an unencrypted nightly dump in shared storage give an attacker the same result.

4. Move the checks into the delivery pipeline

Reviews that depend on someone remembering do not survive a busy release week. The checks that hold are the ones that run on every change: dependency scanning, secret detection, static analysis on the paths that touch authentication and data, and a build that fails when a critical finding appears.

Dependencies need particular attention because most application code today is inherited. Pin versions, update on a rhythm rather than in a panic, and know which packages sit in the request path so an advisory can be triaged in hours instead of days.

• Block merges on secret detection and on critical dependency advisories.
• Require review from someone other than the author for changes to authentication, permissions and payment logic.
• Keep environments separate, with no production credentials reachable from a developer machine.
• Record who deployed what and when, and keep the ability to roll back quickly.
• Re-run the same checks on the release branch, not only on feature branches.

5. Plan for the day something goes wrong

Prevention fails eventually, so the second question is how quickly the team notices and how confidently it can answer what happened. That requires an audit trail designed on purpose: who acted, on which record, from where, at what time, and what changed.

It also requires a plan a stressed team can follow. Who declares an incident, who can revoke credentials or disable a feature, who talks to customers, and what evidence must be preserved before anyone starts fixing. Decided in advance, these are minutes. Decided during an incident, they are hours.

• Log authentication events, permission denials, administrative actions and data exports.
• Alert on the patterns that indicate abuse: credential stuffing, unusual export volume, privilege changes.
• Keep logs long enough to investigate, and protect them from the accounts they observe.
• Write a one-page response plan with names, contact paths and the first five actions.
• Rehearse once with a realistic scenario, then fix whatever the rehearsal exposed.

The measure of a security programme is not the absence of findings. It is how quickly a finding becomes a fix, and how rarely the same class of finding returns.