Modelling threats to a system
- Choose a threat modeling method and turn its findings into tests
- Secure design patterns: a catalogue for insecure-design (A06)
- Review tenant boundaries before implementation
- Review a code change through its trust boundaries
- GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls
Tenancy and access control
- Review tenant boundaries before implementation
- Authorization models: RBAC, ABAC, ReBAC and policy as code you can test
- Enforce authorization for every object action
- Keep retrieval inside the user’s data boundary
- SCIM deprovisioning: make account disablement remove every usable authority
Practice: IDOR lab · RAG access control lab
Trust between services and identity providers
- Workload identity federation: short-lived, scoped identities for services and CI
- Authenticate workloads and authorize their service actions
- OAuth 2.0 and OpenID Connect login: authorization code with PKCE
- SAML single sign-on: verify signed assertions without losing the identity boundary
- Review cloud permissions and role trust together
Practice: Project: Prove deprovisioning reaches sessions and queued work
Mobile, desktop and embedded clients
- Worked threat model: a mobile banking app
- Review trust boundaries in mobile and native clients
- Harden an Android app's storage, network and entry points
- Harden an iOS app's storage, network and entry points
- Review mobile storage, links and platform permissions
- Constrain desktop IPC and privileged helpers
- Design firmware updates that can recover safely
AI and agent designs
- Worked threat model: an LLM agent with tools
- Constrain MCP and multi-agent trust boundaries
- Authorize agent tools outside the model
- Contain prompt injection at the application boundary
- Treat model releases as executable supply-chain inputs
- Protect training and retrieval data from targeted poisoning
- Secure design patterns: a catalogue for insecure-design (A06)
- Sandbox model-generated code and computer-use agents
- Defend agent memory and context against poisoning (OWASP ASI06)
Practice: Project: Enforce retrieval and tool boundaries across crashes · Project: Run model-generated Python in a locked-down container
Personal and sensitive data
- Data minimization and retention: collect less and prove that deletion works
- Tokenization, pseudonymization and privacy transformations: choose deliberately
- GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls
- Assess extraction, membership and inference risks
Writing security requirements and abuse cases
- Write testable security requirements and a security Definition of Done
- Abuse case library: tests and controls by feature
- Threat pattern library for threat modeling
- Choose a threat modeling method and turn its findings into tests
- ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat
Cloud accounts and Kubernetes clusters
- Harden managed Kubernetes on EKS, AKS and GKE
- Choose cloud security posture tools and apply zero trust
- Apply a security baseline across AWS, Azure and Google Cloud
- Run Kubernetes workloads with only the privileges they need
- Detect container and host threats at runtime with eBPF sensors and cloud services
- Harden the images you ship against CIS, STIG and SCAP benchmarks
- Case study: ingress-nginx CVE-2025-1974 and the exposed admission webhook (2025)
- Prevent subdomain takeover from dangling DNS records
Practice: Project: Verify Kubernetes admission and network boundaries · Project: Gate an image build on a CIS scan and a deviation register
- Follow identity and sensitive data across every relevant path.
- Apply STRIDE, and LINDDUN for personal data, to turn an attacker goal into a testable abuse case.
- Record an owned design decision with residual uncertainty.
A boundary diagram, a prioritized abuse-case table built with STRIDE and an owned design decision record.
- Recognize users, services, stores and queues in a simple diagram.
- Use the tenant-isolation or mobile and native guide dossier; mark assumptions when facts are unavailable.
Create a diagram plus a data-flow table for one operation. Include the ordinary API, background worker, export or cache path, administrative route and any client-side bridge, and mark where identity is authenticated and where data changes audience. This answers the first of the four threat-modeling questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job? Finish when each sensitive read or write has a caller, target and trust boundary, including paths missing from the happy-path diagram.
Walk each element and flow through STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege), and through LINDDUN where personal data is involved. Trace one tenant or account identifier from entry to the final data access, separating authenticated identity from caller-supplied fields through queues, caches and support tools. Produce one candidate bypass with a stated precondition. Finish when you can name the exact component that must reject it and the evidence still missing.
Write an abuse-case row with attacker goal, controllable input, preconditions, affected asset, expected forbidden effect and test oracle; draw an attack tree when one goal has several routes. Rank work using consequence and credible reachability, keeping uncertainty visible rather than inventing a likelihood score. Compare a partial repair with one that interrupts the actual path. Finish with a small set of material cases whose proposed controls can be falsified by specific inputs and observations.
Produce a decision record joining each selected control to an owner and acceptance evidence. Include the intended legitimate case, residual risks, unresolved dependencies and a reopening trigger such as a new queue consumer or privileged bridge method. A proposed decision remains proposed until the accountable role accepts it. Revisit the model after implementation to answer the last question: did we do a good enough job? Finish when implementation teams know what to build and reviewers know which observation would make them reject the design claim.
The steps use a connected exercise: IDOR lab: Repair an invoice authorization bug. To build the skills behind this job step by step, follow the learning path AppSec in practice.
Use the blank work product for your system. Compare its required evidence with a completed synthetic example.
Download blank work product Download completed example