Threat modeling is the cheapest way to fix security vulnerabilities — yet it remains underused across the industry. Done in the design phase, it costs an hour of conversation to change an architecture. Done after production deployment, it costs quarters of rework. Jeevan Singh, Director of Product Security at Twilio, has built and scaled threat modeling programs at multiple organizations. In this episode, he shares how to prioritize which systems actually need a threat model, why developers trained on threat modeling outperform security engineers at finding vulnerabilities, and how to build a security culture that works both top-down and bottom-up.
You can read the complete transcript of the episode here >
What is threat modeling and why should organizations do it?
Jeevan defines threat modeling as asset-centric: identify the assets in a feature or system, then determine what risks exist to those assets. The process should be simple, transparent, and democratized — everyone in the session should have a voice.
The critical “why”:
- It is the cheapest way to fix vulnerabilities. During the design phase, fixing a security issue means redrawing an architecture diagram. After months of development, it means rearchitecting deployed code — a cost difference measured in quarters of engineering time.
- It avoids costly reactive work. Bug bounty payouts, pen test findings, and breach response all carry real dollar costs. Threat modeling in the design phase prevents many of these from ever existing.
- It accelerates sales. Enterprise customers evaluate security posture before signing contracts. Fewer critical vulnerabilities mean faster sales cycles and more confident executive summaries.
The process in practice: review the design, gather the right subject matter experts, discover threats, prioritize them, mitigate the critical ones, and reflect as a group — does the majority feel confident enough? Not everyone needs to agree, but consensus that the job was “good enough” is the bar.
How should resource-constrained teams prioritize threat modeling?
Whether you have one security engineer or twenty, you cannot threat model everything. Jeevan’s prioritization framework:
- Focus on the paved path first: Identify the common tooling and patterns your engineers use to deploy to production. If you secure the paved path, 80% of the business is covered. Systems that follow the paved path and do not handle sensitive data may not need a full threat model.
- Ask security questions during design, even without a security team: For 10-to-50-person startups that cannot afford a security engineer, train engineers to pause during design and ask: “What are the bad things that can happen here?” Document the answers. When you eventually hire a security engineer, they will have context to prioritize immediately.
- Spend time where the impact is highest: If you have five threat models to review in a week, spend most of your time on the one or two that involve critically sensitive data (PII, payment information, authentication). A risk-based approach beats spreading effort evenly across everything.
The principle is simple: strong security is just strong engineering. Asking security questions is no different from asking reliability or performance questions — it is part of building high-quality software within a proper secure development lifecycle.
Why are developers better at threat modeling than security engineers?
Jeevan ran an experiment at Twilio: he trained 120 engineers on threat modeling. The results surprised everyone.
- Developers have deep system knowledge: Something that takes a security engineer days or weeks to discover — hidden data flows, undocumented dependencies, edge cases in business logic — developers already know. They built the system. They know it inside out.
- Security training unlocks what they already know: Once trained to think adversarially, developers spot vulnerabilities that security engineers could not even think to ask about. The combination of deep system context plus a security mindset is more powerful than either alone.
- It mirrors the TDD evolution: In the late 90s and early 2000s, developers threw code over the wall to QA. Once those silos broke down and developers owned quality, software got dramatically better. The same evolution is happening with security — engineers owning the security of their features, not delegating it to a separate team.
The key insight: engineers own the risk. Security professionals bubble up risk and advise on mitigations, but the security of the system ultimately belongs to engineering. Breaking down those silos is how security scales.
Jeevan open-sourced the training materials used for this program — searching for “Jeevan Singh Self Service threat modeling” will surface those resources.
How do you validate that a threat model was effective?
Validation happens at two levels:
- Did the security engineer make the right call? Not always — and that is acceptable. Security is about balance. The most secure system is one that is not on the internet, but businesses need to operate online. Working closely with strong engineers to evaluate feasibility of mitigations and agree on acceptable residual risk is the path forward.
- Are assumptions correct? Every threat model makes assumptions (“the attacker cannot access X,” “this network is not reachable from Y”). For critically sensitive systems — like authentication service refactors — bring in pen testing vendors specifically to validate those assumptions. Give them the threat model document and say: “prove our assumptions wrong.”
This targeted pen testing approach is far more valuable than generic full-system assessments. It focuses expensive testing effort on the exact areas where your confidence is lowest, resulting in higher-quality validation per dollar spent.
When should threat modeling happen in the SDLC?
Always is the right time — but the design phase is the best time.
- In the design phase: Changes are cheap. You are modifying diagrams and architecture decisions before any code is written. This is where the highest ROI lives.
- After production deployment: Still valuable. If you never had the opportunity to threat model during design, reviewing deployed systems can still surface issues worth fixing. But the cost of remediation is significantly higher.
- Continuously as systems evolve: Systems are not static. New features, new integrations, and new dependencies all change the threat surface. Threat modeling is not a one-time activity — it grows with the system.
The practical constraint: security teams are always under-resourced relative to engineering velocity. Prioritize design-phase threat models for new features with sensitive data, and retrofit production systems as capacity allows.
How do you sell threat modeling investment to executives?
Jeevan recommends always relating security back to business costs:
- Bug bounty and pen test costs are concrete: Critical and high vulnerabilities found externally carry real dollar values — bounty payouts, vendor engagement fees, engineering time to remediate. Threat modeling reduces those findings, which reduces those costs.
- Breach costs dwarf prevention costs: When an incident occurs, engineering resources, executive attention, legal engagement, and customer communications all get diverted from revenue-generating work. A few hours of proactive threat modeling is trivially cheap by comparison.
- Sales velocity improves with stronger posture: Enterprise customers review pen test executive summaries. Fewer critical findings mean faster deal cycles. More findings mean longer negotiations and potential deal loss.
The framing that works: an hour or two reviewing a design during the threat modeling phase can prevent quarters of rework if that vulnerability were discovered later. The ROI is not abstract — it maps directly to engineering headcount costs saved and revenue not delayed.
Should security culture be top-down or bottom-up?
Both. Neither alone is sufficient.
- Top-down is necessary for permission: Engineers are pulled in many directions — product managers, engineering managers, and customers all compete for their time. Without executive buy-in that security deserves a portion of that time, engineers will never have space to focus on it. If execs do not care about security, that is a signal about the organization itself.
- Bottom-up is necessary for execution: Executives do not write code or deploy services. Culture is built with engineers and managers who want to care about security. They need to see it as a regular engineering practice, not a special burden imposed from above.
- Wind at your back: When executives already care, everyone downstream slowly starts caring too. That executive support is the enabling condition for bottom-up security culture to take root and grow.
Building security culture is hard, but the payoff compounds: teams that internalize security thinking produce fewer vulnerabilities by default, reducing the load on constrained security resources over time.
