<?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 Rietta Cybersecurity</title>
    <link>https://rietta.com/glossary/threat-modeling/</link>
    <description>Recent content in Threat Modeling on Rietta Cybersecurity</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <copyright>1999-2026 Rietta Inc. All Rights Reserved.</copyright>
    <lastBuildDate>Sun, 27 Sep 2026 16:10:44 -0400</lastBuildDate>
    <atom:link href="https://rietta.com/glossary/threat-modeling/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Threat Modeling for ADA/WCAG Compliance</title>
      <link>https://rietta.com/blog/threat-modeling-ada-wcag-compliance/</link>
      <pubDate>Tue, 28 Jul 2026 14:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/threat-modeling-ada-wcag-compliance/</guid>
      <description>Why Accessibility Belongs in Your Threat Model Most organizations treat digital accessibility as a content problem: someone finds a missing alt tag, fixes it, and moves on. I think that&amp;rsquo;s the wrong frame entirely. Digital accessibility is an organizational risk and governance gap, and once you see it that way, the right tool for the job isn&amp;rsquo;t a content checklist. It&amp;rsquo;s the same discipline we already use for application security: threat modeling and continuous technical monitoring.</description>
    </item>
    <item>
      <title>Practical APPSEC starts with people first, processes second, and technology last</title>
      <link>https://rietta.com/blog/practical-security-people-first/</link>
      <pubDate>Thu, 04 Feb 2021 11:00:00 -0500</pubDate>
      <guid>https://rietta.com/blog/practical-security-people-first/</guid>
      <description>Application Security (APPSEC) is the subset of Information Security that is focused on hardening software to protect humans, be it customers, partners, and the public at large. The software itself must be designed to be more secure because security cannot effectively be bolted on at the end of the development process. It&amp;rsquo;s an old time idea, but security is about people, processes, and technology in that order. Let&amp;rsquo;s look at how a web application goes astray by people&amp;rsquo;s knowledge, incentives, and the working of the development process.</description>
    </item>
    <item>
      <title>What is an Abuser Story (Software)</title>
      <link>https://rietta.com/blog/what-is-an-abuser-story-software/</link>
      <pubDate>Sun, 11 Oct 2015 22:35:36 -0400</pubDate>
      <guid>https://rietta.com/blog/what-is-an-abuser-story-software/</guid>
      <description>&lt;p&gt;I publicly speaking about how development teams and those who employ them should go about using user stories with security constraints and abuser stories as a security documentation tool. At this time there is not an entry on Wikipedia about it, so I am going to take a stab at writing it up for you here.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-is-an-abuser-story-in-software-development&#34;&gt;What is an Abuser Story in Software Development?&lt;/h2&gt;&#xA;&lt;p&gt;In software development and product management, an abuser story is a user story from the point of view of a &lt;a href=&#34;https://en.wikipedia.org/wiki/Adversary_(cryptography)&#34;&gt;malicious adversary&lt;/a&gt;. Abuser stories are used with agile software development methodologies as the basis for defining the activities that should be actively blocked or mitigated by the software and proven by automated regression testing.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
