Last week, Salesforce disclosed that Heroku had suffered a significant security breach. Attackers gained access to a database containing OAuth tokens for GitHub integrations, potentially compromising thousands of repositories. Heroku has been revoking tokens, but the incident raises uncomfortable questions about the trust we place in platform services that sit at the intersection of our most sensitive assets: source code and deployment infrastructure.
For those of us who have been building on PaaS platforms since the early days, this feels like a turning point. Not because breaches are new — they’re depressingly routine — but because of where this breach sits in the software supply chain.
The Anatomy of a Platform Trust Chain#
When you connect Heroku to GitHub via OAuth, you’re granting a third party persistent access to your repositories. That token doesn’t just let Heroku pull code for deployments — depending on the scopes granted, it can read private repos, access organization data, and more. Most developers click “Authorize” without a second thought, because Heroku is a trusted name. It’s Salesforce. It’s enterprise.
But that trust is transitive. You’re not just trusting Heroku’s application security — you’re trusting their entire infrastructure stack, their employee access controls, their incident response capabilities, and every third-party service they themselves depend on. It’s turtles all the way down.
The breach reportedly originated from compromised Heroku machine accounts that had access to a database storing GitHub integration OAuth tokens. That’s a classic lateral movement pattern: compromise one component, pivot to the treasure. The tokens themselves are the treasure because they unlock access to potentially thousands of downstream repositories.
Supply Chain Security Is Not Optional Anymore#
I’ve been writing about supply chain security for a while now, and every few months we get another reminder that this problem isn’t going away. After SolarWinds, after Log4j, after the npm protestware incidents — the pattern is clear. Attackers are increasingly targeting the infrastructure and tooling that developers trust implicitly.
What makes this Heroku incident particularly concerning is the blast radius. Heroku isn’t just used by hobbyists running side projects (though it’s great for that). It’s used by startups, agencies, and enterprises for production workloads. Every one of those customers who had a GitHub integration enabled is now wondering: did someone access my code? Did they inject anything? How would I even know?
GitHub has published their own advisory and is notifying affected users. They’ve also revoked tokens proactively where they detected suspicious activity. But the fundamental problem remains: we have too many long-lived tokens floating around with broad permissions, and no good way to audit what they’ve been used for after the fact.
What You Should Do Right Now#
If you’re a Heroku user with GitHub integrations, here’s my practical advice:
1. Audit your OAuth grants. Go to GitHub → Settings → Applications → Authorized OAuth Apps. Review everything. Revoke anything you don’t actively need. This isn’t just about Heroku — do this for every integration.
2. Check your audit logs. If you’re on a GitHub organization plan, review the audit log for any suspicious activity on your repositories. Look for unexpected clones, branch creations, or webhook modifications.
3. Rotate your secrets. If your repositories contain any secrets (and they shouldn’t, but let’s be realistic), rotate them. All of them. Environment variables, API keys, database credentials — assume they’ve been read.
4. Consider your token hygiene. This is a good time to adopt short-lived tokens where possible. GitHub’s fine-grained personal access tokens (currently in beta) offer much better scoping than the classic tokens. Use them.
5. Re-evaluate your PaaS dependency. I’m not saying abandon Heroku, but think critically about what permissions you’ve granted and whether you could achieve the same deployment workflow with fewer privileges. GitHub Actions deploying to a container runtime, for instance, keeps the OAuth surface area much smaller.
The Bigger Picture: Zero Trust for Developer Tools#
The security industry has been pushing “zero trust” architecture for years, but most of that conversation focuses on network access and identity management for end users. We need to apply the same principles to our development toolchain.
Every CI/CD pipeline, every deployment platform, every code quality tool that has access to your repositories is a potential attack vector. The principle should be: minimum viable permissions, maximum viable monitoring, and regular rotation of all credentials.
I’ve spent over three decades watching the industry cycle through “trust everything” and “trust nothing” phases. The reality is somewhere in between, but right now we’re way too far on the trusting side when it comes to developer tooling. We scrutinize every dependency in our package.json but hand out OAuth tokens to platforms like candy.
My Take#
This breach is a symptom of a deeper problem in how we’ve built the modern development ecosystem. We’ve optimized relentlessly for developer experience — click a button, authorize an app, deploy in seconds — without building the corresponding security infrastructure to manage the trust relationships we’re creating.
Heroku will recover from this. They’ll improve their security posture, publish a post-mortem, and most users will reconnect their integrations. But the lesson we should take away isn’t about Heroku specifically. It’s about the web of trust we’ve woven across our toolchains and how fragile it really is.
Start auditing your OAuth grants today. You might be surprised how many services have access to your code that you’ve forgotten about entirely.