For years, “we’re not a bank, we don’t need that level of security” was a defensible posture. Most teams ran a dep scanner, had a pen test once a year, and quietly relied on attackers not caring enough to read their code.
That posture is gone. Here’s what changed:
1) Your source code is probably already out there.
May 20, 2026: GitHub disclosed an employee device compromise via a poisoned third-party VS Code extension. ~3,800 internal repos exfiltrated. The malicious version was live in the Visual Studio Marketplace for 18 minutes. In OpenVSX, 36 minutes.
If that can happen to Microsoft-owned GitHub — with MDM, EDR, and a small army of security engineers — assume it already happened to your team. How many extensions did your devs install last week? Do you know what any of them actually do?
2) AI flipped the economics of vulnerability research.
Anthropic’s Project Glasswing reports 10,000+ high/critical vulns found in important software in the first month using Claude Mythos Preview. Cloudflare confirmed it works on real codebases — given the right harness (architecture context, narrow tasks, validation, attacker-input reachability).
The scary part isn’t the frontier model. It’s the floor. Open source historically catches up in about six months. After that, a kid in a basement with a decent OSS model can build a personalised exploit for your specific codebase, scan the entire public IPv4 internet in an afternoon, and hit every instance.
3) The supply chain is no longer trusted code.
Trivy — a security scanner — became the attack vector. March 2026: attackers force-pushed 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing malware. CanisterWorm followed shortly after — a self-propagating npm worm using postinstall hooks. Install was enough.
Zero trust now has to include code itself. Pin everything to commit SHAs, not tags. But ask the harder question: what if the platform itself is compromised, the way GitHub just was?
And the CVE model can’t keep up. VulnCheck: 32.1% of known exploited vulns in H1 2025 had exploitation evidence on or before the day the CVE was issued. NIST submissions up 263% from 2020 to 2025. The CVE is no longer the start of danger — it’s already late.
So what do you actually do?
Start with the worst case. How would you kill your own company? Authentication, authorization, tenant isolation, secrets, CI/CD, package publishing, billing — these are existential. Everything else is noise until they’re covered.
Patching faster won’t save you. If your architecture and dev flow don’t enforce security boundaries by default, no SLA gets you there. The answer is designed security, not reactive security.
Wrote the full essay on what this looks like in practice https://blog.reqproof.com/p/death-of-security-by-obscurity
Genuine question to the room: how is your team thinking about source-code-as-attack-surface? Or is everyone still on patching SLAs and hoping?
Top comments (1)
Kerckhoffs's principle finally applies to application code, not just cryptography. Source exposure used to just save attackers time — same bugs were findable with black-box testing. AI vulnerability research changes that because it maps input-reachable surface across the entire codebase at once, catching logic bugs that SAST and manual pen testing both miss. The answer isn't protecting source (that ship sailed), it's designing code that's safe when fully readable — treating your repo as public and asking "does this still hold?"