<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Security on Cliff Hults</title><link>https://www.haguest.com/categories/security/</link><description>Recent content in Security on Cliff Hults</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 Cliff Hults</copyright><lastBuildDate>Fri, 01 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.haguest.com/categories/security/index.xml" rel="self" type="application/rss+xml"/><item><title>The Paved Path: Making the Secure Choice the Easy Choice at Scale</title><link>https://www.haguest.com/posts/2026-05-01-the-paved-path/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://www.haguest.com/posts/2026-05-01-the-paved-path/</guid><description>&lt;p>&lt;em>This is the final part of a series. Start with &lt;a href="https://www.haguest.com/posts/2026-02-06-give-the-backlog-teeth/" >Part 1 — giving the backlog teeth&lt;/a>, then &lt;a href="https://www.haguest.com/posts/2026-02-13-the-waiver-trap/" >Part 2 — the waiver trap&lt;/a>.&lt;/em>&lt;/p>
&lt;p>The waiver experiment was a failure in the best possible way; it was diagnostic. It told me exactly where the real bottleneck was: &lt;strong>fixing a vulnerability was hard to &lt;em>do&lt;/em>, not hard to &lt;em>decide&lt;/em>.&lt;/strong> Teams weren&amp;rsquo;t ignoring the work because they were lazy or uncaring. The work to fix a dependency vulnerability was slow, manual, and painful. Every fix was a research project.&lt;/p>
&lt;p>So I stopped trying to apply more pressure and started asking the question that changed everything:&lt;/p>
&lt;blockquote>&lt;p>&lt;em>What if fixing a vulnerability was the easiest possible thing to do?&lt;/em>&lt;/p>&lt;/blockquote></description></item><item><title>The Waiver Trap: When Your Compliance Safety Valve Delays Real Remediation</title><link>https://www.haguest.com/posts/2026-02-13-the-waiver-trap/</link><pubDate>Fri, 13 Feb 2026 00:00:00 +0000</pubDate><guid>https://www.haguest.com/posts/2026-02-13-the-waiver-trap/</guid><description>&lt;p>Enforcement worked. Critical vulnerabilities were suddenly getting fixed on deadlines, and the backlog that had sat ignored for years started to clear. But it worked &lt;em>too well&lt;/em> in one sense: the volume of new work it created across thousands of developers turned enforcement itself into a blocker.&lt;/p>
&lt;p>This is the part of the story almost nobody writes about, because it&amp;rsquo;s the part that looks like a failure. It was the most instructive decision I made.&lt;/p></description></item><item><title>Giving the Backlog Teeth: What Enforcing Remediation SLOs Actually Requires</title><link>https://www.haguest.com/posts/2026-02-06-give-the-backlog-teeth/</link><pubDate>Fri, 06 Feb 2026 00:00:00 +0000</pubDate><guid>https://www.haguest.com/posts/2026-02-06-give-the-backlog-teeth/</guid><description>&lt;p>Every security leader has stared down a backlog of ignored vulnerabilities. You know the shape of it: thousands of open findings, tracked diligently, remediated rarely. The problem wasn&amp;rsquo;t that people didn&amp;rsquo;t care; it was that nothing was &lt;em>at stake&lt;/em> for not fixing them.&lt;/p>
&lt;p>I led a vulnerability-management program across a large engineering organization of thousands of developers and repositories. Early on I learned that you can&amp;rsquo;t improve what you don&amp;rsquo;t enforce. Here&amp;rsquo;s what actually happens when you give the backlog teeth, and the uncomfortable truth about what enforcing it really takes.&lt;/p></description></item></channel></rss>