Most application breaches do not come from sophisticated attackers. They come from default configurations, secrets in source control, exposed admin paths, and identity systems that were never designed to be the perimeter they ended up being.
What follows is the engineering playbook we use when we are building production software. It is not exhaustive. It is the set of practices that, in our experience, prevent the largest share of incidents per hour of effort.
Threat model on day one, not after the launch
Before any architecture is drawn, we run a threat-modeling session with the team. The output is a one-page document: trust boundaries, data flows, the assets that matter, and the top five threats the team commits to designing against.
Threat modeling that happens after the system is built is mostly archaeology. It does not change what gets shipped. Doing it at the start changes which architectures get considered in the first place.
Identity is the new perimeter — treat it that way
Every modern application is, at the architectural level, an identity boundary. Who is the caller, what are they allowed to do, and how do we know it is really them.
We default to a managed identity provider, SSO, MFA, conditional access, and short-lived tokens. We do not write authentication from scratch. We do not store passwords. And we treat the identity provider as the highest-criticality dependency in the stack, because it is.
Secrets are not source code
Secrets — API keys, database passwords, signing keys, OAuth tokens — never enter source control. We use a managed secret store, with versioning, audit logging, and break-glass procedures.
Every new engineer joining the team has to demonstrate they can rotate a secret in under five minutes. If they cannot, the rotation runbook is the problem, not the engineer.
Application security in the SDLC
Security gates that fire after the work is done are a tax on velocity that does not improve outcomes. We integrate static analysis, dependency scanning, and secret scanning into the CI pipeline so issues surface in the pull request that introduced them.
We also keep a security-focused code review cadence — not a separate review team, but rotating senior engineers reviewing for security-sensitive patterns. The goal is shared ownership, not handoff.
Operate securely, not just ship securely
Logging, monitoring, alerting, and incident response are not afterthoughts. They are part of the definition of done. A service we are about to put in production has to have its observability story written down — what we will see, what will page us, how we will know if something is wrong.
We also run game days. Simulated incidents, on a real schedule, against real production. The team that has not run a game day does not know how it will respond at 2 a.m. — and 2 a.m. is when it matters.
The discipline behind the playbook
Each of these practices is a small habit. None of them are heroic. Together, they prevent the overwhelming majority of incidents that actually take applications down.
Secure software is not built by a security team gating engineering. It is built by an engineering team that treats security as a property of good engineering — and operates accordingly.