What the Vercel Hack Taught Us About Chains of Trust

The recent compromise of a major deployment platform did not begin in the platform’s core infrastructure. The breach originated in a third-party integration that held an access token into the platform. Through that token, some customer environments were reached.

We spent years building zero-trust networks. We put identity proxies in front of internal applications and forced multi-factor authentication on every connection. Then we gave our deployment vendors standing read access to the entire codebase, authorized by a single click on an OAuth consent screen. Every consent screen is a firewall rule you will never review again. An engineer clicks “Allow” on a Friday afternoon because a preview deployment plugin needs to be live by Monday. The scope list scrolls off the bottom of the dialog. The platform decides what “Allow” means. The token is minted, stored on the vendor’s infrastructure, and outlives the employee who created it.

Build and deploy platforms are not just tools. They are identity providers with production rights. They sit outside the production network but hold absolute authority inside it. The environment variables in a build platform are the union of every secret the application needs. A single read-scoped token reaches all of them. Deploy access is code execution by another name. A token that can deploy can run anything on the target.

Procurement gates the platform. The vendor risk management process revolves around SOC 2 reports, data residency, and a long spreadsheet about encryption at rest. It does not ask how the vendor isolates customer integration tokens in memory. More importantly, procurement gates the platform, but nobody gates what gets installed on it. The approved vendor list and the integration marketplace rarely overlap. An integration is a vendor you did not procure. The marketplace is curated by the platform vendor to reduce friction and increase developer velocity, not to gate security.

When an attacker compromises that third-party integration, they extract the tokens. The breach happens on the integration vendor’s network, but the exfiltration happens on yours. The token does not care whose IP address is using it.

This creates a mismatch in incident response. Your runbook assumes the failure is in your systems. Sometimes you are a bystander to someone else’s incident. The platform vendor says it was a third party. The third party says it notified the platform. The customer is left on a bridge call asking who is going to tell them what to rotate. The breach notification arrives long after the attacker has used the token, and it rarely tells you exactly which of your environments were touched.

The immediate recovery step is to rotate credentials. But rotation assumes inventory. If you cannot list the secrets, you cannot rotate them. Prevention hides the inventory gap; recovery exposes it. A security engineer opens the platform’s admin console to look at the installed integrations. There are dozens of authorized applications: CI/CD runners, code quality scanners, dependency updaters, and deprecated preview environments. Half of them have broad read and write access. No one owns the inventory. No one knows which pipelines will break if a token is revoked.

A team rotates a deployment token. An hour later, an engineer finds the old credential in a scheduled job owned by another team. The job has been failing since the rotation, but no one included it in the incident call because it was not part of the main deployment pipeline. The integration you can see today is not a record of the access it had yesterday.

We talk about the chain of trust, but a chain implies direction and order. The actual shape is a graph. There are many integrations, many vendors, many tokens, and sometimes cycles. Your vendor’s vendor is your vendor. You cannot inherit your vendor’s security posture, but you can inherit their breach.

The useful boundary is what a platform can reach, not where its contract sits. When a vendor’s status page updates six hours after an incident begins, and that is your first notification, the only defense is the inventory you built before the event. Open the platform admin console and look at the list of authorized integrations. The console will tell you what has access today, but it will not tell you who granted it, what dependent jobs will break if you revoke it, or whether the scope was broader last year.