Let's reconstruct an OAuth supply chain attack. In these attacks no one really breaks into your company. The attackers simply walk through the door, using trusted credentials you've given to one of your vendors. They are impossible to prevent. But, is there really nothing we can do about it? The best way to figure it out is to do it yourself: so, let's create 3 organisations, give them all real infrastructure, and reverse engineer a real breach to see what allows supply chain attacks to be most effective. We'll design potential attacks (incl. LLM-assisted attacks), run them against real-world infrastructure, and find out what makes breaking in easier (or, harder) when a trusted vendor is breached. This talk is based on the Vercel breach in April 2026. https://vercel.com/kb/bulletin/vercel-april-2026-security-incident --- Earlier this year we got a breach notification from Vercel. The kind I've had to write myself in the past. This time I was on the other end. "We’ve identified a security incident that involved unauthorized access to certain internal Vercel systems." The email said we're (probably) not affected. But, the public information they shared got me thinking about the blanks they left out. 1. What really happened? 2. How can the access we grant 3rd-parties as part of standard day-to-day work be abused? 3. Can an upstream breach move through our company, and propagate downstream our customers? 4. What is the real risk? 5. Can we do anything about it? I decided to figure it out. So, I built the infrastructure for 3 organisations using real services and realistic architectures. Then, experimented with designing ways to break in. The results were practical insights for defence - finding out what makes these attacks easy, and what makes them hard. That's what I'd like to share in this talk, with a (hopefully) interactive demo of a (demonstrative) OAuth supply chain attack.