Security

Real offensive depth

Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.

All security →
Compliance

Audit-ready, fixed scope

SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.

All frameworks →
Resources

Learn the space

Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.

Read the blog →
Security & Compliance Glossary

Threat Modeling

Threat modeling is a structured process for identifying potential threats, attacks, and vulnerabilities in a system early in design, then deciding how to mitigate them. It asks what you are building, what can go wrong, what you will do about it, and whether you did a good job. The output is a prioritized set of risks and countermeasures.

In practice

Done during design, threat modeling catches architectural flaws before they are written into code, when they are far cheaper to fix. Frameworks like STRIDE give teams a vocabulary for the categories of threats to consider.

It is most valuable for new features, major architecture changes, and AI systems, where the attack surface is unfamiliar. It frames the testing that follows, so testers know which threats matter most.

// how traztech helps

traztech delivers threat modeling for products and architectures for startups and growth-stage companies, led by a published security researcher.

Book a call

For a broader look at getting audit-ready, see our SOC 2 readiness work, or talk to a fractional CISO about building a program around it.

Where it comes up

Threat modelling earns its place at design time, when changing an architecture still costs a conversation rather than a quarter. It is the cheapest security activity available and the most frequently skipped.

In compliance terms it supports secure development controls, and the evidence is simply the record: what was considered, what was decided, and what changed as a result.

Threat Modeling: common questions

When should we threat model?

When designing something new that handles sensitive data, changes trust boundaries, or exposes a new interface. Doing it for every ticket is theatre.

Do we need a formal methodology?

Not necessarily. STRIDE and similar frameworks help teams new to it, but a documented conversation about what could go wrong and what you did about it is worth more than an unused template.

Track record

Who is actually doing the work

5
Published CVEs, including a CVSS 9.1
76
Controls taken from nothing to a passed SOC 2 Type II
Zero
Exceptions on that Type II report
20+
Penetration testing engagements delivered

Published vulnerability research

Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.

A SOC 2 Type II built from nothing

At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.

Before you go

Want the practical version by email?

Definitions only get you so far. I send a few short notes on how this plays out in practice. Unsubscribe in one click, and replies reach me directly.

From Jacob Masse, principal of traztech. No spam, unsubscribe in one click.