<?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/tags/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>Sun, 20 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.haguest.com/tags/security/index.xml" rel="self" type="application/rss+xml"/><item><title>Designing an Automated Artifact Factory: A Case Study in Turning Pipeline Pain Into a Platform Boundary</title><link>https://www.haguest.com/posts/2026-09-20-automated-artifact-factory/</link><pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate><guid>https://www.haguest.com/posts/2026-09-20-automated-artifact-factory/</guid><description>&lt;p>Every team wiring the same three security checks into its own pipeline isn&amp;rsquo;t really a security problem. It&amp;rsquo;s a platform problem wearing a security costume.&lt;/p>
&lt;p>This is the story of how we traced that pattern back to a structural issue, and the design we landed on to fix it: an automated artifact factory that turns signing, vulnerability scanning, and antivirus scanning from something every team bolts onto their own pipeline into something the platform just does for them.&lt;/p></description></item><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>When Your Security Tool Goes Down: Surviving an SCA Tool Outage</title><link>https://www.haguest.com/posts/2026-04-12-sca-tool-outage/</link><pubDate>Sun, 12 Apr 2026 00:00:00 +0000</pubDate><guid>https://www.haguest.com/posts/2026-04-12-sca-tool-outage/</guid><description>&lt;p>Security tooling exists to protect your organization. But what happens when the security tool itself becomes the outage?&lt;/p>
&lt;p>That&amp;rsquo;s the situation we found ourselves in when an SCA tool experienced a service disruption that lasted approximately five hours. For us, it wasn&amp;rsquo;t a degraded experience; it was a complete development freeze.&lt;/p></description></item><item><title>Supply Chain Attacks Start in Your Build Cache</title><link>https://www.haguest.com/posts/2026-04-11-axios-supply-chain/</link><pubDate>Sat, 11 Apr 2026 00:00:00 +0000</pubDate><guid>https://www.haguest.com/posts/2026-04-11-axios-supply-chain/</guid><description>&lt;p>On March 25, 2025, a malicious version of the axios npm package (version 1.14.1) was published to the npm registry. It contained a bundled dependency called &lt;code>plain-crypto-js@4.2.0&lt;/code>, which was later confirmed to be malicious. The package was identified and removed from the npm registry within roughly three hours.&lt;/p>
&lt;p>For most organizations, three hours sounds manageable. For us, it wasn&amp;rsquo;t that simple.&lt;/p></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><item><title>Log4j Scanning and Detection</title><link>https://www.haguest.com/posts/2021-12-16-log4j/</link><pubDate>Thu, 16 Dec 2021 14:59:43 -0500</pubDate><guid>https://www.haguest.com/posts/2021-12-16-log4j/</guid><description>&lt;p>Lately, everyone has been talking about Log4Shell (CVE-2021-44228) and likely, if you&amp;rsquo;re reading this, you&amp;rsquo;re looking for info for what to do. Most people attempted to utilize &lt;a href="https://log4shell.huntress.com/" target="_blank" rel="noreferrer">Huntress&amp;rsquo;s Log4Shell detection tool&lt;/a> to show connections to a LDAP server they were hosting. Some people had issues with this as it was overburdened with requests (rightfully so) or didn&amp;rsquo;t want to, or aren&amp;rsquo;t allowed to send outbound traffic to a server they didn&amp;rsquo;t own. At our organization, we were part of the latter group. In order to comply with our rules, we needed to find a reliable way to scan our devices for the vulnerability and look for requests to a domain that we owned.&lt;/p></description></item></channel></rss>