Vercel Just Got Breached. How Much of Your Business Is in Your Deployment Platform?
Today, Vercel confirmed that attackers gained unauthorised access to its internal systems. An actor claiming to be ShinyHunters is selling what they describe as source code, access keys, employee accounts, API keys, NPM tokens, and GitHub tokens — asking $2 million on a breach forum.
Vercel's official bulletin is sparse: they've identified a "limited subset of customers" affected, brought in incident response specialists, and notified law enforcement. Their one concrete recommendation? Review your environment variables and use the sensitive environment variable feature.
That recommendation deserves a closer look — because it points to a problem much bigger than one platform getting breached.
The thing nobody thinks about until it happens
When you deploy on a platform like Vercel, Netlify, Railway, or any PaaS, you hand over a remarkable amount of trust. Not just your code — your secrets.
Environment variables in a typical deployment: database connection strings with credentials, payment gateway API keys (Stripe, Adyen), third-party service tokens (Twilio, SendGrid, Auth0), internal API keys for service-to-service communication, OAuth client secrets, encryption keys. This isn't hypothetical. This is what sits in the environment variables tab of most production deployments right now.
When your deployment platform gets breached, the attacker doesn't need to hack you. They already have your keys. Your Stripe API key gives them access to your payment infrastructure. Your database connection string gives them your data. Your GitHub token gives them your code repos and potentially the ability to push changes.
The Vercel breach isn't just a Vercel problem. It's a demonstration of what platform dependency risk looks like when it materialises.
This isn't unique to Vercel
We're not singling Vercel out — they disclosed the breach, which is the right thing to do. The problem is structural, and it applies to every PaaS and CI/CD platform.
If you deploy through GitHub Actions and store secrets there — same risk. If you use Netlify with environment variables — same risk. If your CI/CD pipeline in GitLab has production credentials — same risk. If your AWS credentials sit in a deployment service — same risk.
The question isn't "is Vercel secure?" The question is: what happens to your business if any platform you depend on gets compromised?
What to do right now
If you're a Vercel customer, the immediate actions are straightforward:
Rotate everything. Every API key, every database credential, every token stored in Vercel environment variables — assume it's compromised and rotate it now. Don't wait for Vercel to tell you whether you're in the "limited subset." Rotating a key costs you minutes. Not rotating one could cost you everything.
Check your access logs. Look at your databases, your payment provider dashboards, your third-party services. Any unusual access patterns? Any API calls you don't recognise? Do this today.
Review deployment and access tokens. Vercel integration tokens, GitHub connections, NPM publish tokens — revoke and reissue. If a token was connected to Vercel's internal systems, treat it as exposed.
What to do this month — regardless of which platform you use
The broader lesson applies whether you're on Vercel, Netlify, AWS, or anything else.
Audit what secrets live where. Make a list of every credential stored in your deployment platform. You'll likely be surprised how many there are and how many are more privileged than they need to be. A database connection string with full admin rights in a preview environment? That shouldn't exist.
Separate preview from production. Most platforms let you set different environment variables per environment. Your preview deployments should never have access to production databases, production payment gateways, or production API keys. If a breach exposes preview environment secrets, the blast radius should be limited to test systems — not your live infrastructure.
Use a dedicated secrets manager. AWS Secrets Manager, HashiCorp Vault, Doppler — tools built specifically for secret storage, with access logging, rotation policies, and granular permissions. Your deployment platform's environment variables weren't designed for this level of security. They're convenient, not secure.
Principle of least privilege for tokens. That GitHub token connected to your deployment platform — does it need write access to all repositories? Probably not. That database credential — does it need admin rights? Definitely not. Scope every credential to the minimum required.
Think about blast radius. If platform X is breached tomorrow, what do the attackers get? Can they access your production data? Your customers' payment information? Your source code? Draw the diagram. If the answer is "everything," your architecture has a concentration risk that should keep you up at night.
Have a credential rotation plan. Not "we'll figure it out when it happens." An actual list: these are our secrets, these are where they're stored, this is how we rotate each one, this is who's responsible. When a breach hits — and it will, eventually, somewhere — you want to execute a plan, not improvise.
The pattern: platforms are targets
Two months ago, AWS data centers were destroyed in the Middle East. Today, Vercel's internal systems were breached. Different attack vectors — physical destruction versus cyber intrusion — but the same underlying lesson: the platforms you build on are not invulnerable, and your responsibility for resilience doesn't end at the boundary of your own code.
Every layer of your stack that you don't control is a layer that can fail or be compromised. The cloud provider, the deployment platform, the CI/CD pipeline, the package registry, the DNS provider. Each one is a dependency. Each one is a potential single point of failure.
The companies that handle these incidents without damage are the ones that thought about platform dependency before it became urgent. Separated secrets. Scoped permissions. Had rotation plans ready. Designed for the scenario where a trusted platform becomes untrusted.
If you haven't done that thinking yet — today is a good day to start.
At Otocolobus, we help companies design infrastructure that limits blast radius — whether the threat is a breached platform, a compromised credential, or a destroyed data center. If you want to understand your current exposure and build a practical plan to reduce it, get in touch.