Inputs
Diagrams and descriptions of components, roles and integrations. Workshops fill the gaps.
Architecture review focus
Indicative view, not a measurement: 3 primary focus, 2 usual component, 1 context or scope-dependent, 0 outside normal scope.
| Area | Level |
|---|---|
| Design and trust boundaries | primary focus |
| Authentication and authorisation | primary focus |
| Inputs and data processing | limited focus |
| Business logic | part of the test |
| Secrets and cryptography | part of the test |
| Dependencies and builds | limited focus |
Some flaws begin in the design
Many weaknesses come from design decisions rather than coding mistakes. Components trust unverified input, tenant separation exists only in the interface or integrations have excessive permissions. Such flaws are costly to fix later and automated tools usually miss them.
Architecture review suits new service development, major changes, cloud migration or preparation for enterprise customer security requirements.
What we assess
- Sensitive data flows and where data is stored, processed and transferred.
- Trust boundaries between users, applications, services, integrations and administration.
- Authentication, authorisation and tenant separation design.
- Integrations, webhooks, queues and third-party service communication.
- Secrets, encryption and key management design.
- Logging, audit trails and security event traceability.
A review together with your team
We work beyond documents. Following threat modelling practice described by OWASP, we ask four questions: what are we working on, what can go wrong, what will we do about it and have we done enough?
We use STRIDE categories: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Review can fit a broader secure development programme using OWASP SAMM. These are methodologies, not certifications.
Workshop
We review data flows, trust boundaries and key scenarios with architects and developers.
Threat model
Threats, impact and likelihood in your product's context.
Controls
Prioritised recommendations with ways to verify effectiveness through testing or review.
Typical findings
Trust without verification
Services accepting identity or permissions from another component without their own checks.
Tenant separation
Data isolation relying on one layer or correct client behaviour.
Overprivileged integrations
Service accounts, tokens and webhooks with more rights than the process needs.
Secrets and keys
Unclear secret management, rotation or separation between environments.
Missing audit trail
Sensitive operations cannot be traced or attributed to a user.
Deliverables and review boundaries
The review assesses the design as described and supported by supplied information. It does not verify that implementation follows the design. Code review and application testing can be agreed separately for this purpose.
- An updated data flow diagram with trust boundaries.
- A threat model with descriptions, impact and priorities.
- Recommended controls and assigned owners in your team.
- Recommendations for areas requiring code review or penetration testing.
