Security you can't justify is a vicious cycle | Dependabot is...← Back<br>2026-07-02
I’ve already written about compliance<br>security – here’s the<br>adversarial round.<br>Dependabot continuously DDoSes me with a wall of pull requests. npm audit<br>always paints X high-severity vulnerabilities. And a devops engineer, now and<br>then, starts arguing that our microservices – inside one locked-down AWS VPC –<br>should really talk over TLS.<br>Different mouths, one noise: add more security, now. Not one of them showed<br>me an attacker. Not one showed me the threat.<br>That’s the tell. A vulnerability is worth acting on when you can show the code<br>that exploits it. Everything else – the red banner, the CVSS score, the “we<br>should really” – is a personal take. Mostly marketing. Adding security you<br>can’t justify isn’t rigor – it’s security theater. And it’s a vicious cycle.<br># Talk is cheap. Show me the code.1<br>A working proof of concept is proof. A severity score is a claim. A scanner<br>label is a claim. Someone’s opinion is a claim. Claims are cheap – generate a<br>thousand a day, no code required. The PoC is the tax that separates the real<br>from the loud.<br>Watch a claim meet the tax. A hyped model scanned curl and reported five<br>confirmed vulnerabilities; after the security team looked, one was<br>real.2 The label said confirmed. The code said otherwise.<br># Never update dependencies unless it breaks for your users.3<br>Brainlessly following automated-tool guidance is a security risk. Brainlessly<br>adding a dependency to your code or infra is a security risk.<br>Supply chain: attackers force-pushed malicious commits to 75 of 76 tags of the<br>official Trivy Action and turned it into a credential stealer.4 That<br>proof never came from the red banner.<br># Conclusion<br>None of this is anti-tooling; the enemy isn’t the scanner or the model. It’s<br>treating a claim as a verdict – a UI/UX problem in the tools, and blind<br>obedience to decade-old compliance checklists.<br>So I’ve started to understand the projects that refuse AI contributions.<br>Linus Torvalds, linux-kernel mailing list, 25 August 2000.<br>http://lkml.org/lkml/2000/8/25/132 ↩︎
Daniel Stenberg, “Mythos finds a curl vulnerability”, daniel.haxx.se,<br>2026-05-11.<br>https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/ ↩︎
Mitchell Hashimoto: “Fork your dependencies, trim them to only your use<br>case, never update unless it breaks for your users.”<br>https://x.com/mitchellh/status/2057171518027887035. ↩︎
Stephen Thoemmes, “Trivy GitHub Actions Supply Chain Compromise”, Snyk.<br>https://snyk.io/articles/trivy-github-actions-supply-chain-compromise/ ↩︎