APP / APP-01
Threat modelling and secure design
Examine an application before or during design to identify sensitive assets, trust boundaries and abuse scenarios. The aim is to select appropriate controls before architectural mistakes become expensive to fix.
WHEN IT HELPS
A focused response
to a defined need.
New portal, multitenant architecture, identity-system change, payment or sensitive-data integration, or an AI project acting on information systems.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Business and architecture workshops
- data flows
- actors and privileges
- abuse scenarios
- security controls
- testable requirements
- residual risks and ownership
Deliverables
- Annotated diagrams
- threat model
- prioritised security requirements
- architectural decisions
- planned tests
- risks accepted or requiring treatment
Acceptance evidence
Main scenarios are reviewed with business teams; requirements are assigned and testable; decisions are documented; reviews are planned for major changes.
DELIVERY
How the work is structured.
Approach
Understand architecture; select risks and requirements; integrate or verify controls; test; hand over to teams and plan regression checks.
Prerequisites & responsibilities
Customer: code, architecture, developers, test environment and pipeline access. Provider: expertise and checks; code remediation only when included.
Scope factors
Applications, languages, repositories, dependencies, roles, pipelines, volume and depth. Separate tooling licenses, remediation development and maintenance.
Questions to clarify
Which actions would cause the most harm? Where are trust boundaries crossed? Which architectural decisions can still change?
IMPORTANT BOUNDARIES
Threat modelling is neither penetration testing nor proof that flaws are absent. Its value depends on information quality and updates after changes.
Controls apply to agreed versions and scope. No scanner, SBOM or framework alone guarantees the security of delivered software.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
A vendor prepares a multitenant application. Project: model customer access and exchanges before development. Target outcome: isolation requirements included in the backlog and tests rather than added after launch.
Scenario 02
A team adds an AI agent able to modify data. Project: assess tools and sensitive decisions. Target outcome: action limits and human approvals designed upfront; some tools stay outside the pilot.
Technology and reference context
References: OWASP practices and NIST SSDF; diagrams and requirements independent of any mandated tool.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.