Threat Modeling and Security Architecture Review: Designing Risk Out Before Code Ships

The economics of software security favour early intervention overwhelmingly. A design-level security review that identifies an insecure architectural pattern — placing session tokens in URL parameters, allowing unauthenticated access to an internal microservice boundary, routing customer PII through a logging pipeline with insufficient access controls — costs a fraction of what it costs to re-architect that component after it has shipped, been deployed to production, and potentially been exploited. Threat modeling and security architecture review are the two disciplines that operationalise this shift-left principle: they engage with a system's design before implementation begins, or at the earliest point in development, to identify and address structural risk.

What threat modeling actually is

Threat modeling is a structured process for identifying what can go wrong with a system from a security perspective. The deliverable is not a vulnerability report — there is no running code to test yet. The deliverable is a threat model: a documented analysis of the system's assets, trust boundaries, data flows, and the threats that apply to each. STRIDE is the most widely used threat classification framework: Spoofing (impersonating another principal), Tampering (modifying data or code), Repudiation (denying actions without traceability), Information Disclosure (exposing data to unauthorised parties), Denial of Service (disrupting availability), and Elevation of Privilege (gaining capabilities beyond what was intended). Each data flow and system component is evaluated against each STRIDE category.

The threat model process typically involves structured workshops with the engineering and product teams who understand the system. The output is a prioritised threat register: identified threats, their likelihood and impact, and the controls that mitigate each. This becomes an input to the security requirements specification — developers build to mitigate the identified threats rather than discovering them later during a pentest. The security architecture review then validates that the implemented controls are correctly designed and consistently applied.

Data flow diagrams and trust boundaries

The technical centrepiece of a threat model is the data flow diagram (DFD): a visual representation of how data moves through the system, crossing trust boundaries between components. Trust boundaries are the points where the security context changes — the boundary between the public internet and a load balancer, between a load balancer and an application server, between an application server and a database, between microservices in different security zones. Every trust boundary crossing is a potential attack surface: it is the point where authentication must be enforced, where input must be validated, where data must be encrypted in transit, and where authorisation must be checked.

Drawing accurate DFDs requires access to the people who understand how the system actually works, not just how it was designed on paper. In practice, there are almost always trust boundary gaps between the design documentation and the running system — an internal microservice that was meant to be authenticated but is not in the current implementation, a logging pipeline that was meant to strip PII but does not for certain event types, a caching layer that was added for performance but inadvertently shares cache entries across tenant boundaries. The threat model process surfaces these gaps.

Security architecture review: validating the controls

A security architecture review (SAR) goes beyond threat modeling to evaluate the specific security controls implemented in the system's design. This includes authentication mechanisms (are JWTs correctly validated, are sessions correctly invalidated on logout, is the token lifetime appropriate?), authorisation model (is RBAC correctly scoped, are resource ownership checks centralised or scattered across service implementations?), data protection at rest and in transit (which data stores hold PII or sensitive data, how are they encrypted, who has access?), secrets management (how are API keys, database credentials, and certificates managed — are they hardcoded in code or config files, or managed through a secrets manager?), and third-party dependency risk (what data does each third-party SDK or library have access to?).

For systems that will undergo a CERT-In audit or regulatory IS assessment, a pre-audit security architecture review can dramatically improve the audit outcome. It identifies design-level findings that can be addressed before the active testing phase begins, reducing the remediation burden post-audit. Explore our security architecture review service for scope and methodology details.

When to conduct a security architecture review

There are four high-value trigger points for a security architecture review: before a new system is built (design review before implementation), before a significant new feature ships (particularly for features that change the system's trust model — adding a new API consumer type, integrating a new third-party payment processor, introducing a real-time data pipeline), after a significant architectural change (migration from monolith to microservices, cloud migration, multi-tenancy introduction), and before a security audit or regulatory assessment (as a pre-audit preparation exercise). Each of these represents a moment when structural security decisions are being made; review after the fact is possible but significantly more expensive.

CyVigilant's threat modeling and security architecture review practice works with engineering teams at the design stage, not just the audit stage. To discuss an engagement, visit our security architecture review page or talk to an expert.