In 2003, running the cyber café at 16, I learned something that took me twenty years to put into words: trust without a model is negligence with good PR. We had eight machines connected through a 10/100 switch and a single internet uplink. When the connection dropped at 11pm with the place packed, I had five minutes to diagnose or my old man lost money. I learned not to trust anything I couldn't trace: not the router, not the ISP, not the cabling. Everything had to be verifiable. Everything had to have a known failure path. Twenty years later, I put critical infrastructure on Vercel and assumed the threat model came included in the Pro plan. It didn't. In April 2026, Vercel confirmed a security incident with a supply chain component. The exact technical details are still being filtered through NDAs, corporate postmortems, and Twitter speculation. There's analysis of the what everywhere. I'm not going to repeat it. What I care about is why I wasn't prepared to think about that scenario. And the answer is uncomfortable: because Vercel does such a good job of abstracting complexity that I implicitly assumed it was also abstracting risk. It doesn't. No platform does. None of them ever did. The problem wasn't the incident. The problem was my epistemic negligence: the active — though unconscious — decision not to model threats in layers I didn't directly control. Vercel is genuinely brilliant. Edge functions, ISR, atomic deployments, preview environments, GitHub integration that actually works. It's the kind of tool that lets a solo developer operate with the surface area of a mid-sized team. I get why I trusted it. But there's a dangerous cognitive pattern these platforms enable without meaning to: If I can't see the complexity, I assume the risk doesn't exist. Vercel hides Nginx, hides the routing, hides the CDN, hides the certificates, hides the build pipeline. That's real value. The problem is that when something is hidden, it's also outside your mental model of failure. I had a threat model for my code. I had one for my database on Railway. I had zero for my build pipeline on Vercel. And that's exactly the vector supply chain attacks exploit: the gap between what you control and what you assume someone else is controlling. // What I was modeling as attack surface const myThreatModel = { userInputs: 'sanitized ✓', authentication: 'JWT with rotation ✓', database: 'parameterized queries ✓', secretsEnvVars: 'Railway secrets manager ✓', // What I wasn't modeling buildPipeline: undefined, // ← here ciDependencies: undefined, // ← and here vercelInfra: undefined, // ← and especially here npmSupplyChain: 'npm audit... that\'s enough, right?' }; That undefined doesn't mean I thought about it and decided not to cover it. It means it never showed up in my head as a possible attack surface. And that's exactly the difference between accepted risk and ignored risk. Here's the part that's hardest to admit. If someone had asked me in March 2026 "did you model supply chain risk in your build pipeline?", I would have said something like: "I'm a solo developer, I don't have time for that. I use Vercel precisely so I don't have to think about those layers." That sounds reasonable. Even mature. "Know your limits, use abstractions." But it's a trap. Because there's a massive difference between: Consciously accepted risk: "I know Vercel can have incidents, I evaluated the probability and impact, and decided the value it provides outweighs the residual risk." Risk ignored for convenience: "Vercel handles that." I was doing the second and calling it the first. It's the same as blindly trusting configuration tools without understanding what they do internally. Abstraction doesn't eliminate risk — it displaces it. And if you don't know where it went, you can't respond when it shows up. Supply chain attacks are devastating precisely because they attack the transitive trust model. I trust Vercel. Vercel trusts its dependencies. Its dependencies trust others. Somewhere in that chain, someone inserts malicious code. The attack doesn't need to break my code. It just needs to compromise something I trust without verifying. # Attack surface I wasn't monitoring # Vercel's build pipeline # ↓ # Build runner dependencies # ↓ # npm packages installed in CI # ↓ # postinstall scripts (routinely ignored) # ↓ # Access to env vars during build ← the prize And here's the point that makes me most uncomfortable: my env vars — including production secrets — are available during the build. That's necessary for the build to work. But it also means any code running during the build has access to them. I knew this technically. I hadn't connected it to my threat model. That disconnection between technical knowledge and security reasoning is what I'm calling epistemic negligence. It's no different from the problem I described with agents that pass empty tests: the system signals that everything is fine, and you stop looking. I didn't leave Vercel. That would be the equivalent of throwing away your computer after a virus. The platform is still the best option for what I do. What I changed was the mental model: 1. I documented the threat model explicitly, including layers I don't control ## Attack surfaces — [project] ### Layers I control - Application code - Database queries - Authentication and authorization - Input validation ### Layers I delegate (with known risk) - Build pipeline: Vercel — risk: supply chain in CI Mitigation: env vars separated by environment, periodic rotation - CDN and routing: Vercel — risk: DDoS, content injection Mitigation: CSP headers, SRI on critical assets - Database: Railway — risk: provider breach Mitigation: own backups, verified encryption at rest ### Risks accepted without active mitigation - Total compromise of Vercel as a provider Justification: unlikely, contingency plan exists but not active This document doesn't protect me from an attack. It protects me from being surprised. 2. I separated build secrets from runtime secrets What the build needs to compile shouldn't be the same as what the application needs to run. In theory I knew this. In practice I had everything mixed together in the same .env. // Before: everything together, everything available at build time VERCEL_ENV=production DATABASE_URL=postgresql://... // ← shouldn't be in build NEXT_PUBLIC_API_URL=https://api.example.com STRIPE_SECRET_KEY=sk_live_... // ← definitely not // After: separated by actual need // BUILD variables (only what the compiler actually needs) NEXT_PUBLIC_API_URL=https://api.example.com NEXT_PUBLIC_POSTHOG_KEY=phc_... // RUNTIME variables (injected at the server, not at build) // DATABASE_URL, STRIPE_SECRET_KEY, etc. — via Railway env 3. I started auditing postinstall scripts # Check what runs during npm install npm pack --dry-run cat node_modules/[critical-package]/package.json | jq '.scripts' # See which packages have install scripts cat package-lock.json | jq '[.packages | to_entries[] | select(.value.scripts.postinstall or .value.scripts.preinstall) | .key]' It's tedious. I'm not going to do it for all 847 packages in my node_modules. But I will for critical direct dependencies. This connects to something I wrote about designing reliable systems: reliability doesn't come from having no failures, it comes from knowing how things fail and having a response ready. 4. I added SRI for external assets Not the complete solution. One more layer in the model. There's a parallel with something I analyzed about semantic prompt optimization: when you compress aggressively, you lose context that seemed redundant but wasn't. Threat models have the same problem. When you simplify them for convenience, the context you lose is exactly what gets attacked first. And on who decides what's visible or what counts as "good enough security": that's also a power decision. Those who design the abstractions decide what you get to see. Vercel decided the build pipeline would be invisible. That's a valid UX decision. It's not a security decision. What exactly happened in the Vercel April 2026 incident? Do I need to migrate away from Vercel after this incident? What is a supply chain attack and why is it different from a conventional hack? How do I know if my Vercel projects were affected? Is npm audit enough to protect me from supply chain attacks? npm audit checks for known vulnerabilities in dependencies. A supply chain attack typically uses code with no reported vulnerabilities — the problem is that the code was maliciously modified, not that it has a known bug. They're different vectors. npm audit is necessary but nowhere near sufficient. What's the minimum I should do to improve my supply chain posture on Vercel? I wouldn't stop using Vercel. But from day one of every project I'd include a threat model document with an explicit section for "layers I delegate with known risk." Not to resolve all of them, but to not be caught off guard. The cyber café taught me that systems fail in specific ways and that knowing those ways is the difference between diagnosis and panic. It took me twenty years to apply that lesson to how I use deployment platforms. The Vercel incident didn't break anything concrete for me. It broke my excuse that "using good platforms" is equivalent to "having a security model." It isn't. It never was. Abstraction is value. Blind trust in the abstraction is security technical debt that eventually comes due. Do you have a documented threat model for the platforms you use, or are you outsourcing that too? I'd genuinely like to know how other solo developers or small teams handle this.