Most application security problems are decided long before anyone runs a scanner. Someone chooses to trust a tenant identifier that arrived from the browser, or grants a function app the permissions that made the feature work that afternoon, and the decision looks reasonable in the pull request. It is still there two years later, and by then it is the shortest path into your customers' data.
Tools do not catch that class of problem, because there is nothing wrong with the code. The problem is in the design, and that is a judgement your engineers have to make themselves.
The class is taught by the consultants who run our application security tests, so the examples come from environments we have worked in.
What we cover
- Reasoning about your own design the way an attacker would, covering trust boundaries, what the system assumes about its callers, and where those assumptions stop being true
- Threat modeling as a working method, covering how to run it, how to keep it light enough that it actually happens, and how to document what comes out of it
- Authorization and tenant isolation, which is the bug class that causes the most damage in multi-tenant applications
- Identity integration done properly, covering OIDC and OAuth flows, token validation, scopes and claims, and the ways that integrations with Entra ID, B2C or Cognito go wrong
- The cloud resources underneath the application, covering what the application's own identity can reach, how storage, secrets and queues become exposed, and why a small application bug becomes a large one when the workload holds standing permissions
- Secrets, dependencies and pipelines, covering where credentials end up, what your build process trusts, and what an attacker gains by compromising it
How it runs
Teaching first, then a workshop on one of your own systems. Your team picks the application, we work through it together, and you keep the threat model and the findings that come out of it.
We adapt the balance to the group. A team that is already threat modeling gets less method and more depth on authorization and cloud identity, and a team that is new to it gets the opposite.
The intention is that your team can run the next one without us.