Blog
Security insights and product updates.
I pointed my CVE pipeline at 1,500 GitLab servers. It found 31 exploitable vulnerabilities.
Last week I wrote about building a scanner that writes its own exploits. A cron job runs Claude Code every night, it reads new CVEs, writes proof-of-concept checks, tests them against vulnerable and patched Docker instances, and opens PRs. I review and merge in the morning. That post was about how the pipeline works. This one is about what happens when you point it at 1,500 real servers. The target list I pulled 1,500 IPs from Shodan tagged as GitLab instances. Only 41% were actually runn
How I built a security scanner that writes its own exploits
Every night at 3AM, a cron job on my homelab server runs claude /cve-pipeline. By morning, there are pull requests waiting. Each one is a working exploit check for a recent CVE, tested against a vulnerable instance, tested again against a patched instance, with WAF bypass variants for the most popular WAF setups. In the morning I review the PRs, merge, deploy. Users get the new checks on their next scan. I'm a solo founder. The whole thing runs on a $200/mo Claude Max subscription. 31 expl
SOC 2 Vulnerability Scanning: What CC7.1 and CC7.2 Actually Require
Most startups hit the same wall. You're halfway through your SOC 2 audit, and the auditor asks for vulnerability scanning evidence. You've been heads-down on access controls, encryption, HR policies. Scanning? You figured the pentest covered that. It doesn't. Vulnerability scanning is its own control with its own evidence. I've watched three founders scramble to produce scan reports the week before their audit window closed. This post is what I wish I could have sent them. The two contr