Security is often scheduled as a gate near the end of delivery. The application is built, tested and then assessed. The findings arrive when the architecture is fixed and the release date is close, which makes remediation expensive and compromise tempting.
The expensive findings are architectural
Some vulnerabilities are implementation defects: an unescaped input, a missing authorisation check, an outdated dependency. Others are architectural: a trust boundary that does not exist, a service that has more access than it needs, a data store that mixes tenants, a logging pipeline that captures sensitive information.
Architectural findings are harder and more expensive to fix late. They are also the findings that matter most in a system that handles sensitive data or critical operations.
Start with assets, actors and trust boundaries
A threat model does not need to be a large document. It needs to identify what is valuable, who might want it, where the trust boundaries are and what happens if a boundary is crossed.
That conversation changes design decisions: where authentication happens, how service-to-service access is granted, what data is logged, how secrets are managed and how administrative access is separated from normal use.
Make the secure path the easy path
Security controls fail when they are optional or inconvenient. A platform should provide secure defaults: central identity, short-lived credentials, approved libraries, automated dependency checks and a deployment pipeline that requires review.
The goal is not to rely on every developer remembering a policy. It is to make the policy part of the environment.
Prepare for the failure, not just the breach
Incident response is part of security design. Who is called, what evidence is preserved, how access is contained and how the organisation communicates are decisions that should be made before an incident.
A system that can detect, contain and recover from a failure is more resilient than one that has passed a checklist but has never tested its response.
What we recommend
- Threat-model the system before architecture is finalised.
- Define trust boundaries and service identities explicitly.
- Use secure defaults and central identity rather than per-application credentials.
- Include dependency and secret management in the delivery pipeline.
- Test the incident response path, not just the controls.
Where we disagree
We do not believe compliance certification proves a system is secure. It proves that certain controls exist and are documented. We also do not believe security is a reason to avoid cloud or third-party services; it is a reason to design the integration, access and exit path carefully.
A practical test
Before the next architecture review, draw the trust boundaries and mark every place where data or authority crosses one. Then ask what authenticates the caller, what it is allowed to do, what evidence is recorded and what happens if the control fails. The exercise usually reveals more than a vulnerability scan, because it exposes design assumptions that no scanner can see.