<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Threat Modeling on CybersecurityOS</title><link>http://www.cybersecurityos.net/tags/threat-modeling/</link><description>Recent content in Threat Modeling on CybersecurityOS</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 31 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="http://www.cybersecurityos.net/tags/threat-modeling/index.xml" rel="self" type="application/rss+xml"/><item><title>Threat Modeling in Plain English: A Guide for Engineering Teams</title><link>http://www.cybersecurityos.net/posts/os-weekly/threat-modeling-plain-english-engineering-teams/</link><pubDate>Sun, 31 May 2026 00:00:00 +0000</pubDate><guid>http://www.cybersecurityos.net/posts/os-weekly/threat-modeling-plain-english-engineering-teams/</guid><description>&lt;p>Most engineering teams know they &lt;em>should&lt;/em> be doing threat modeling.&lt;/p>
&lt;p>Very few actually do it — and the ones who try often produce a document that gets filed away and never looked at again.&lt;/p>
&lt;p>The problem isn&amp;rsquo;t motivation. It&amp;rsquo;s that almost every guide to threat modeling is written for security teams, not engineering teams. The language is wrong. The framing is wrong. The process feels like a compliance exercise instead of something that makes the software actually harder to attack.&lt;/p></description></item></channel></rss>