<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Recent Writings — Loren Kohnfelder on Designing Secure Software</title>
    <link>https://designingsecuresoftware.com/writings/</link>
    <description>Recent content in Recent Writings — Loren Kohnfelder on Designing Secure Software</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Wed, 01 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://designingsecuresoftware.com/writings/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>March 2026 Link dump</title>
      <link>https://designingsecuresoftware.com/writings/2026mar/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/2026mar/</guid>
      <description>&lt;ul&gt;&#xA;&lt;li&gt;Google security methodology compendium&lt;/li&gt;&#xA;&lt;li&gt;Threat modeling&lt;/li&gt;&#xA;&lt;li&gt;Are attacks the only threat?&lt;/li&gt;&#xA;&lt;li&gt;Why is threat modeling ignored?&lt;/li&gt;&#xA;&lt;li&gt;Miscellaneous&lt;/li&gt;&#xA;&lt;li&gt;e16n next Stage 4&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Google is sharing a lot of their impressive security methodology in a recent collection of articles: &lt;a href=&#34;https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/how-google-does-it-security-series/&#34;&gt;How Google Does It: An inside look at cybersecurity&lt;/a&gt;. Of special interest to me: &lt;a href=&#34;https://cloud.google.com/transform/how-google-does-it-threat-modeling-from-basics-to-ai&#34;&gt;Threat modeling, from basics to AI&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>February 2026 Link dump</title>
      <link>https://designingsecuresoftware.com/writings/2026feb/</link>
      <pubDate>Sun, 01 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/2026feb/</guid>
      <description>&lt;ul&gt;&#xA;&lt;li&gt;On &amp;ldquo;the end of security bugs&amp;rdquo;&lt;/li&gt;&#xA;&lt;li&gt;STRIPPED&lt;/li&gt;&#xA;&lt;li&gt;Incident response threat modeling?&lt;/li&gt;&#xA;&lt;li&gt;Using CSS and PDF as emulators running code&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://www.anthropic.com/news/claude-code-security&#34;&gt;Claude Code Security has people predicting the end of security bugs as we know them&lt;/a&gt;&#xA;I can&amp;rsquo;t imagine &lt;em&gt;anything&lt;/em&gt; in the forseeable future doing that&#xA;because all software has bugs, and vulnerabilities are by definition&#xA;a subset of all the bugs (in a properly designed system).&#xA;Bug-free code seems computationally infeasible for large systems,&#xA;if only for the amount of testing required to confirm there are no bugs.&#xA;What am I missing, or is it AI hype?&lt;/p&gt;</description>
    </item>
    <item>
      <title>January 2026 Link dump</title>
      <link>https://designingsecuresoftware.com/writings/2026jan/</link>
      <pubDate>Sun, 01 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/2026jan/</guid>
      <description>&lt;ul&gt;&#xA;&lt;li&gt;on &amp;ldquo;Bitlocker, the FBI, and Risk&amp;rdquo;&lt;/li&gt;&#xA;&lt;li&gt;threat models to address hacklore&lt;/li&gt;&#xA;&lt;li&gt;software bloat&lt;/li&gt;&#xA;&lt;li&gt;software update release quality&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
    </item>
    <item>
      <title>Transparent AI use</title>
      <link>https://designingsecuresoftware.com/writings/ai_use/</link>
      <pubDate>Sat, 31 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/ai_use/</guid>
      <description>&lt;p&gt;How much AI use is acceptable for writing? It&amp;rsquo;s a hard question because it depends greatly on context, the reader&amp;rsquo;s expectations, and the fact that it&amp;rsquo;s difficult to usefully measure &amp;ldquo;how much&amp;rdquo;. How we address this matters for several reasons, including but not limited to: creator&amp;rsquo;s responsibility and originality, honest disclosure about research effort and sources, respecting the broad spectrum of opinion about ethical use of AI.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Risk Perspective</title>
      <link>https://designingsecuresoftware.com/writings/risk-perspective/</link>
      <pubDate>Sat, 24 Jan 2026 08:42:18 -1000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/risk-perspective/</guid>
      <description>&lt;p&gt;Writing in response to Adam Shostack&amp;rsquo;s excellent post&#xA;&lt;a href=&#34;https://shostack.org/blog/bitlocker-the-fbi-and-risk/&#34;&gt;&amp;ldquo;Bitlocker, the FBI, and Risk&amp;rdquo;&lt;/a&gt;.&#xA;He nicely highlights the fundamental risk trade-off in data protection,&#xA;and so long as we (often very rightly) prioritize availability&#xA;we need measures that may compromise confidentiality.&#xA;Also I especially liked the touch of a risk analysis &lt;em&gt;not&lt;/em&gt; using numbers&#xA;&lt;em&gt;and&lt;/em&gt; explicitly pointing that out.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dusting off</title>
      <link>https://designingsecuresoftware.com/writings/dusting/</link>
      <pubDate>Sat, 24 Jan 2026 08:28:56 -1000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/dusting/</guid>
      <description>&lt;p&gt;Dusting off this venue for writing at the suggestion of a friend&#xA;in the interest of more discussion online because it&amp;rsquo;s&#xA;&amp;ldquo;better if we move commentary off social media.&amp;rdquo;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Flaunt your Threat Models!</title>
      <link>https://designingsecuresoftware.com/writings/flaunt/</link>
      <pubDate>Thu, 14 Nov 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/flaunt/</guid>
      <description>&lt;p&gt;Threat modeling is the most powerful, underutilized, easy-to-do security methodology we have: why isn&amp;rsquo;t everybody doing it already, or why do those who are keep their work secret? If you already threat model your digital systems and products, and are doing the work already then you are doing security right so you should share it with pride. Publishing threat models may be the best evidence of excellent security work that customers and users can appreciate the value of, short of a rigorous detailed design and code review. You&amp;rsquo;ve already done the work — or if not you really should — and making it public not only is great promotion but it also helps all stakeholders understand their respective roles and responsibilities in securing larger systems.&#xA;&lt;em&gt;(about 4600 words)&lt;/em&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Demand more</title>
      <link>https://designingsecuresoftware.com/writings/demand_more/</link>
      <pubDate>Fri, 20 Sep 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/demand_more/</guid>
      <description>&lt;h3 id=&#34;demand-more&#34;&gt;Demand more&lt;/h3&gt;&#xA;&lt;p&gt;I applaud CISA leadership speaking out aggressively at the&#xA;&lt;a href=&#34;https://mwise.mandiant.com/conf24/keynotes&#34;&gt;mWISE Conference 2024&lt;/a&gt;&#xA;about the dismal state of software security&#xA;(based on &lt;a href=&#34;https://www.theregister.com/2024/09/20/cisa_sloppy_vendors_cybercrime_villains/&#34;&gt;reporting in The Register&lt;/a&gt;,&#xA;but it would be nice for&#xA;&lt;a href=&#34;http://www.cisa.gov&#34;&gt;www.cisa.gov&lt;/a&gt; to publish transcripts&#xA;in order to ensure we are interpreting remarks with full context,&#xA;given that the videos are paywalled).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Threat Modeling threat modeling</title>
      <link>https://designingsecuresoftware.com/writings/threat_modeling_itself/</link>
      <pubDate>Sun, 11 Aug 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/threat_modeling_itself/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;(2300 words) Threat modeling isn&amp;rsquo;t just for software security;&#xA;you can even threat model threat modeling.&#xA;When a major software incident occurs, the first thing we should be asking&#xA;is &amp;ldquo;show us the threat model&amp;rdquo;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Crowdstrike further revelations</title>
      <link>https://designingsecuresoftware.com/writings/crowdstrike_corrects/</link>
      <pubDate>Fri, 09 Aug 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/crowdstrike_corrects/</guid>
      <description>&lt;p&gt;In a debunking blog post, Crowdstrike finally starts to describe that content files are digitally signed for deployment. The initial report oddly referenced file timestamps instead of hashes to designate the bad and good versions of the infamous Channel File 291, but now we know these were signed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Crowdstrike External Technical Root Cause Analysis</title>
      <link>https://designingsecuresoftware.com/writings/crowdstrike_rca/</link>
      <pubDate>Tue, 06 Aug 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/crowdstrike_rca/</guid>
      <description>&lt;p&gt;The &lt;a href=&#34;https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf&#34;&gt;Crowdstrike July incident root cause analysis report&lt;/a&gt;&#xA;provides new detail and requires reading between the lines to interpret&#xA;(I welcome corrections with references if I got it wrong).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why tamper LLMs with guardrails?</title>
      <link>https://designingsecuresoftware.com/writings/ai_guardrails/</link>
      <pubDate>Mon, 05 Aug 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/ai_guardrails/</guid>
      <description>&lt;p&gt;Say what you will about LLM technology, it&amp;rsquo;s remarkable that we can do computations on the scale of billions of parameters training on large chunks of humanity&amp;rsquo;s collective text and media at all — and then it&amp;rsquo;s remarkable how you can talk to &amp;ldquo;it&amp;rdquo; in everyday language and get any kind of recognizable response out of it all, often (but not always) a pretty good one, and this is all based on the simple but powerful &amp;ldquo;select the best next token&amp;rdquo; algorithm run in a loop. The concept would have made a terrific sci-fi series, and here we are with it working in our cloud at scale.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Incoming message mess</title>
      <link>https://designingsecuresoftware.com/writings/incoming_mess/</link>
      <pubDate>Tue, 30 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/incoming_mess/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;July 30, 2024 — When will we address the unacceptable status quo of scam phone calls, SMS text, and email?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Crowdstrike threat Q&amp;A</title>
      <link>https://designingsecuresoftware.com/writings/threats_qna/</link>
      <pubDate>Thu, 25 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/threats_qna/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;Threat-based questions to understand the Crowdstrike incident&#xA;(1081 words)&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Every chance I get I&amp;rsquo;ve been offering this guidance: We understand software&#xA;security best through specific threats and mitigations, articulated by threat&#xA;models shared openly. While I doubt the folks at Crowdstrike are interested in&#xA;my help, this is a great opportunity to test how this works in practice.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CSRC NIST glossary</title>
      <link>https://designingsecuresoftware.com/writings/standard_terminology/</link>
      <pubDate>Thu, 25 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/standard_terminology/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;In search of standard terminology to talk about software security&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Someone referred to Crowdstrike as not being a &amp;ldquo;security incident&amp;rdquo; to which&#xA;someone else responded that according to NIST it is. I&amp;rsquo;d like to think that the&#xA;US National Institute of Standards and Technology (NIST) would provide standard&#xA;definitions of technical terms for the software community which is awash in&#xA;vague nomenclature that leads to much confusion, however, I see that the&#xA;situation is unexpectedly complicated. According&#xA;&lt;a href=&#34;https://csrc.nist.gov/glossary/term/security_incident&#34;&gt;https://csrc.nist.gov/glossary/term/security_incident&lt;/a&gt;&#xA;there are eight different definitions of &amp;ldquo;security incident&amp;rdquo;. This strikes me&#xA;as fundamentally unhelpful: if we are having a discussion and referencing the&#xA;NIST definition, we can disagree about the meaning and both be completely&#xA;accurate. If there is some rule to determine which of the definitions to apply&#xA;in different contexts the webpage appears to be silent on what that is.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Crowdstrike and the threat of friendly fire</title>
      <link>https://designingsecuresoftware.com/writings/friendly/</link>
      <pubDate>Tue, 23 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/friendly/</guid>
      <description>&lt;p&gt;Threat modeling methodology centers on asking, &amp;ldquo;What could go wrong?&amp;rdquo; and then considering mitigations to address such an eventuality. The unending calamities of history vividly demonstrate how human intuition repeatedly fails to foresee many such events until after they happen, and even then we sometimes fail to learn and act. For example, consider the 2008 financial crisis: after all the bailout money was handed out around Wall Street, Congress never confronted the glaringly obvious problem of &amp;ldquo;too big to fail&amp;rdquo; institutions. As a result, large firms continued to consolidate, concentrating power and risk in still fewer institutions, creating conditions for a repetition that appears to be a matter of &amp;ldquo;when&amp;rdquo; rather than &amp;ldquo;if&amp;rdquo;. Traditionally threat modeling has been deployed exclusively within the context of secure software engineering, but I posit that it is just as effective and important a tool for anticipating potential harms of all kinds — not just malicious exploitations.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Secret Questions for password reset</title>
      <link>https://designingsecuresoftware.com/writings/against_secret_questions/</link>
      <pubDate>Thu, 11 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/against_secret_questions/</guid>
      <description>&lt;p&gt;Secret questions as credentials for online account authentication are&#xA;simply a bad idea in my view: I have never seen them done well, often&#xA;seem them done atrociously, and my most generous assessment would be&#xA;that they are extremely hard to do well. But keeping an open mind,&#xA;here&#39;s a brief reasoning why these are problematic, and I invite anyone&#xA;interested to do a brilliant design and prove me wrong.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Learning from Solar Winds</title>
      <link>https://designingsecuresoftware.com/writings/learning_from_solar_winds/</link>
      <pubDate>Wed, 10 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/learning_from_solar_winds/</guid>
      <description>&lt;p&gt;ProPublica is a national journalistic treasure, and recent reporting on&#xA;the software industry is a terrific impetus to drive much needed change.&#xA;I sat in on many bug triage discussions over twenty years ago working at&#xA;Microsoft, and despite great technology advances, the way these&#xA;decisions are made appears to be little evolved. My purpose here is not&#xA;to judge what transpired and who is at fault, but to glean from the&#xA;reporting better software practices so we can at least learn from these&#xA;events.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Trusting AI</title>
      <link>https://designingsecuresoftware.com/writings/trusting_ai/</link>
      <pubDate>Mon, 03 Jun 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/trusting_ai/</guid>
      <description>&lt;ul&gt;&#xA;&lt;li&gt;&lt;em&gt;(220 words)&lt;/em&gt; June 2024 &amp;ndash; Loren Kohnfelder&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Whether or not&#xA;&lt;a href=&#34;https://boingboing.net/2024/06/03/google-ai-just-might-kill-you-it-misidentified-a-destroying-angel-mushroom-as-an-ediblebutton-mushroom.html&#34;&gt;this unscientific test&lt;/a&gt;&#xA;is reliable, asking generative AI if a mushroom is safe to eat —&#xA;it misclassified a highly toxic variety that looks like a common edible one —&#xA;is a terrible idea if you are prepared to eat according to what it says.&#xA;This illustrates my rule of thumb:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Further security discussions</title>
      <link>https://designingsecuresoftware.com/writings/further/</link>
      <pubDate>Thu, 30 May 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/further/</guid>
      <description>&lt;ul&gt;&#xA;&lt;li&gt;&lt;em&gt;(500 words)&lt;/em&gt; May 2024 &amp;ndash; Loren Kohnfelder&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;This article is a continuation of &lt;a href=&#34;../better&#34;&gt;Better Security Discussions&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;This analysis can be extended by considering potential mitigations for additional threats.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Better security discussions</title>
      <link>https://designingsecuresoftware.com/writings/better/</link>
      <pubDate>Sun, 26 May 2024 00:00:00 +0000</pubDate>
      <guid>https://designingsecuresoftware.com/writings/better/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;(900 words)&lt;/em&gt; May 2024 &amp;ndash; Loren Kohnfelder&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;em&gt;We understand software security best through specific threats and&#xA;mitigations, articulated by threat models shared openly. Without this&#xA;context we avoid much needed meaningful security discussions.&lt;/em&gt;&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
