Most security problems in custom software are not discovered in code review. They are baked into the design long before the first commit: an API that trusts the client, a data model that copies sensitive fields into a logging table, a multi-tenant schema with no row-level isolation. By the time a penetration test flags them, fixing them means re-architecting.
A software threat model is how you avoid that. Run during discovery, it is a structured workshop that maps what you are building, what can go wrong, and which controls you will design in from day one. It costs a few hours and saves months.
This guide gives you a step-by-step custom software threat modeling process you can run yourself, vendor-agnostic and sized for a founder or CTO who is not a security specialist.
Key takeaways
- A threat model is a design artifact, not a compliance checkbox. Do it during discovery, before architecture is locked.
- You do not need a security team. A two-to-four hour workshop with the right people, a whiteboard, and a simple framework gets you most of the value.
- Focus on trust boundaries and data flows, not on enumerating every possible attack.
- Every accepted risk needs an owner and a decision record, or it silently becomes a production incident.
- The output should directly shape your architecture, backlog, and acceptance criteria.
Why a threat model before development beats a pen test after
A penetration test tells you what is wrong with what you built. A threat model tells you what not to build in the first place. The economics are lopsided: a design change costs a conversation, a post-launch fix costs a release cycle, a breach costs trust.
For custom software the risk is higher than for off-the-shelf products. Your system has a bespoke attack surface: custom authentication, custom integrations, custom data flows. Generic security checklists miss exactly the parts that are unique to you.
What a threat model actually produces
- A data flow diagram showing components, data stores, and trust boundaries.
- A prioritized list of threats mapped to the assets they endanger.
- A set of mitigations translated into architecture decisions and backlog items.
- A risk register with owners for anything you consciously accept.
Who to invite to the threat modeling session
The single most common failure is running the session with only engineers. Security is a product risk as much as a technical one.
- Product owner or founder: decides which risks are acceptable to the business.
- Lead engineer or architect: knows how the system will actually be built.
- Someone with security fluency: an internal specialist or a trusted external advisor; not strictly required if the facilitator is experienced.
- A facilitator: keeps the group on track and owns the write-up. This person should not also be the loudest voice in the room.
Keep it to four to six people. Larger groups produce discussion, not decisions.
The step-by-step threat modeling process
This is a lightweight, repeatable threat model before development workflow. Budget two to four hours for the first pass, then a one-hour review after architecture is drafted.
Step 1: Define scope and assets
Start by writing down what you are protecting, not what you are building. List the assets: user credentials, personal data, payment information, proprietary algorithms, admin capabilities. For each, note the impact if it were exposed, altered, or unavailable.
Then draw a clear scope line. Threat modeling an entire platform at once produces a shallow result. Pick one flow or subsystem, say, user onboarding and authentication, and model it properly.
Step 2: Draw the data flow diagram
On a whiteboard or shared canvas, sketch the system at the right altitude: external actors, your components, data stores, and the arrows between them. Mark every trust boundary: a line where data crosses from a less trusted zone to a more trusted one. Browser to API, API to database, your system to a third-party service, internal service to internal service.
Trust boundaries are where nearly all interesting threats live. If your diagram has no boundaries marked, you are not done.
Step 3: Enumerate threats per element
Walk each component and each boundary and ask structured questions. STRIDE is a reliable, vendor-neutral prompt set:
- Spoofing: can someone pretend to be another user or service?
- Tampering: can data be altered in transit or at rest?
- Repudiation: can an action be denied because it was not logged?
- Information disclosure: where could sensitive data leak, including logs and error messages?
- Denial of service: what breaks if a component is flooded or starved?
- Elevation of privilege: can a normal user reach admin functionality?
Do not try to be exhaustive. Aim for the threats that are plausible for your business, and write them down in plain language.
Step 4: Rate and prioritize
For each threat, make a quick judgment on likelihood and impact. You do not need a formal scoring model, a simple high/medium/low with a one-line rationale is enough to drive decisions. The point is to separate the two or three threats that could end the company from the twenty that are noise.
Step 5: Decide mitigations and owners
For every high-rated threat, record one of three outcomes: mitigate (design a control), transfer (push the risk to a vendor or insurer), or accept (document why). Every accepted risk needs a named owner and a review date.
Translate mitigations into concrete design decisions, for example, "all authorization checks enforced server-side," "no PII in application logs," "tenant ID enforced at the data-access layer." These become acceptance criteria, not vague intentions.
Step 6: Feed the output into architecture and backlog
A threat model that lives in a document nobody reads is worthless. Attach each mitigation to a ticket, an architecture decision record, or a test case. When the team builds the feature, the control ships with it.
How to run the session so it does not stall
Good facilitation is the difference between a useful artifact and a lost afternoon.
- Timebox each step. Twenty minutes for the diagram, forty for threat enumeration, thirty for decisions.
- Park debates. If the group argues about a specific control, note it and move on; resolve it offline.
- Write as you go. Capture threats live in a shared doc so no one has to reconstruct the session afterward.
- Separate discovery from solutioning. Enumerate threats first, then decide mitigations. Mixing them kills momentum.
If you are working with an external build partner, ask for this as part of discovery. A serious partner will treat a secure design review for custom software as a standard deliverable, not an upsell. You can see how we structure discovery and build engagements on our software development services page.
Common mistakes to avoid
- Modeling the whole system at once. Scope to one flow per session.
- Skipping the data flow diagram. Without trust boundaries, the conversation drifts into generic security advice.
- Inviting only engineers. Business context is what lets you prioritize.
- Treating the model as a one-time event. Revisit it whenever architecture changes or a new integration is added.
- No owners for accepted risks. Unowned risk is unmanaged risk.
When to revisit the threat model
A threat model is a living artifact. Refresh it when you add a new external integration, change your authentication model, introduce a new data store, or move to a new hosting environment. A short review at each major architectural change keeps it honest.
If you want a second pair of eyes on the output, or want to see how threat modeling has shaped real builds, browse our completed projects and then talk to our team about running a workshop during your discovery phase.
Avaton builds custom software, AI/ML systems, and Web3 products, and we run threat modeling as part of discovery on the engagements we ship.
Frequently Asked Questions
How long does a software threat model take?
For a focused scope such as a single user flow or subsystem, a first-pass workshop typically takes two to four hours, plus a short write-up. A follow-up review after architecture is drafted usually takes about an hour. The total effort is small compared with the cost of redesigning security controls after launch.
Do I need a security specialist to run a threat modeling session?
Not necessarily. A product owner, a lead engineer, and a capable facilitator can produce a useful threat model using a structured framework like STRIDE. A security specialist adds value for complex or regulated systems, but the biggest determinant of quality is scoping the session well and documenting decisions.
What is the difference between a threat model and a penetration test?
A threat model is a design-time activity that identifies what could go wrong and which controls to build in. A penetration test is a runtime activity that attempts to exploit a built system. They complement each other: the threat model reduces the number of issues a pen test will find and helps you interpret its results.
What should the output of a threat model look like?
A useful output includes a data flow diagram with trust boundaries, a prioritized list of threats, a set of mitigations translated into architecture decisions and backlog items, and a risk register with named owners for any accepted risks. If the output does not change your architecture or backlog, the session did not achieve its purpose.
When should we revisit the threat model?
Revisit it whenever the architecture changes materially: a new external integration, a change to authentication or authorization, a new data store, or a move to a different hosting environment. A short review at each major change keeps the model relevant and prevents design drift.
Cover: Photo by Ann H on Pexels