3. Architecture Review
Architecture review is performed when the full system structure is defined, including frontend, backend, database, and external services. The focus is on understanding system components, trust boundaries, third-party integrations, and network communication between services. The…
Why it matters
Architecture review is performed when the full system structure is defined, including frontend, backend, database, and external services. The focus is on understanding system components, trust boundaries, third-party integrations, and network communication between services. The security goal is to identify system-wide risks and weak trust relationships. Common issues include direct database access from multiple services, lack of network segmentation, and weak internal service security. This is a big-picture review of how the entire system is connected and protected.
How we test it
Our operators follow a structured checklist for this topic, adapted to your API surface and authentication model.
Testing approach
- Structured validation of 3. Architecture Review during scoped assessment.
- Evidence captured with reproducible steps for your engineering team.
What we look for
- Misconfigurations and control gaps related to 3. Architecture Review.
- Exploitable paths that could affect confidentiality, integrity, or availability.
Related topics
| Topic | Summary |
|---|---|
| 1. DREAD (Risk Rating Model) | We validate this area during scoped assessments, documenting impact and remediation guidance. |
| 1. Idea Review (Requirement Stage) | Idea review is the earliest stage of SDLC where a product or feature is still just a concept. At this stage, the focus is on understanding what we are building, why we are building it, and what type of data will be used. The security goal is to identify basic risks before any de… |
| 2. Design Review | Design review happens when the system design starts taking shape, including APIs, database structure, and user flows. The focus is on API structure, authentication flow, data flow between components, and external integrations. The security goal is to identify design-level flaws… |
| 2. PASTA (Threat Modeling Process) | We validate this area during scoped assessments, documenting impact and remediation guidance. |
| 3. LINDDUN (Privacy Model) | We validate this area during scoped assessments, documenting impact and remediation guidance. |
| 4. Threat Modeling (Core Security Activity) | Threat modeling is a structured process used to identify, analyze, and reduce security risks in a system before it is built or released. It helps answer what can go wrong, how an attacker can exploit the system, what the impact would be, and how those risks can be fixed. It is i… |