The Heroku OAuth token incident remains one of the most instructive supply chain events in the last several years, not because the technical mechanism was novel but because the trust topology it exposed is repeated across the industry. This post is a retrospective from the defender's seat, focused on the lessons that have aged well and the ones that have been quietly forgotten.
I am working from the public timeline, the GitHub and Heroku post-incident communications, and observations from teams I have advised who were directly affected. Specifics where they are reliably known, generalizations where they are not.
What actually happened on the public timeline?
In April 2022 GitHub detected unauthorized access to private repositories belonging to customers who had authorized certain Heroku and Travis CI OAuth applications. The threat actor obtained OAuth tokens issued to these integrations and used them to clone private repositories, ultimately exfiltrating credentials embedded in those repositories. The initial intrusion vector into Heroku's environment was not fully disclosed in the public timeline, but the consequence was clear: a third-party OAuth application became a vehicle for access to private source code at hundreds of organizations.
The technical mechanics were uncomplicated. Once attackers held a valid OAuth token with the right scopes, the GitHub API gave them legitimate-looking access. Detection on the customer side required correlating clone traffic with token identity, which most organizations were not equipped to do in 2022 and many are still not equipped to do in 2026.
What did the incident reveal about OAuth scope hygiene?
The most uncomfortable finding was the scope sprawl across authorized integrations. Many of the affected Heroku OAuth grants carried the full repo scope, which conveys read and write access to all private repositories belonging to the granting account or organization. Read access was the operationally relevant scope, but the historical norm in the OAuth ecosystem had been to request broader scopes than strictly needed, and customers had granted them.
The durable lesson is that OAuth scope is a security boundary, and the principle of least privilege applies as fiercely to third-party integrations as it does to internal IAM. Most organizations now have policies requiring explicit security review for any third-party OAuth integration requesting write or admin scopes, and several large platforms have introduced scope-narrowing flows since the incident. But scope sprawl re-accumulates over time, and a quarterly audit of authorized OAuth applications is now a baseline control I recommend to every platform team.
How did the blast radius surprise defenders?
The blast radius surprised defenders because the credentials that mattered were not the Heroku platform credentials themselves. They were the secrets embedded inside private repositories: AWS access keys, database passwords, third-party API tokens, signing keys. The attacker obtained access to source code and then performed credential mining on the code itself, finding live credentials with non-trivial frequency.
The implication is that the historic mental model of "secrets in private repos are fine because the repos are private" was retired permanently by this incident. Any organization with a meaningful population of long-lived secrets in source code was exposed regardless of their own security posture, because the trust chain ran through a third party they did not control. The post-incident reaction across the industry was the right one: aggressive adoption of secret scanning, push protection at the Git server level, and short-lived credential issuance via OIDC federation rather than static tokens.
What did remediation look like in practice?
Remediation was painful. The teams I worked with at the time spent days enumerating which secrets had been present in which repositories, which were still valid, and which dependent systems trusted those credentials. The post-mortem work surfaced a recurring pattern: organizations did not have an authoritative inventory of secrets in source code. Many discovered tokens that had been committed years earlier and forgotten, still functional, still trusted by production systems.
The teams that recovered fastest were those with strong secret inventory and rotation tooling already in place. The teams that recovered slowest were not the ones with the most repositories; they were the ones without an answer to the question "which secrets do we have, where do they live, and what do they unlock?"
Which lessons have aged well?
Three lessons have held up. First, third-party OAuth integrations need to be treated as part of your attack surface and reviewed on a recurring cadence. The list of authorized apps in your GitHub or GitLab settings is a vendor inventory, and it should be governed the same way. Second, secrets in source code are a liability regardless of repository visibility, because the trust chain reaches further than you think. Push protection, pre-commit hooks, and OIDC-based short-lived credentials are the durable controls. Third, the blast radius of any supply chain incident is determined by what the compromised channel grants access to, not by the channel itself, so investing in segmentation and least-privilege pays off across categories of incident you cannot predict.
How Safeguard Helps
Safeguard's TPRM module is designed for exactly the trust topology the Heroku incident exposed. We score third-party suppliers on their historical incident response, scope hygiene, and supply chain posture, surfacing the integrations that warrant scrutiny before they become incidents. Griffin AI ingests the OAuth and machine-identity inventory from your GitHub, GitLab, and cloud accounts, correlating it with known supplier compromises and CISA advisories so emerging threats surface within hours. Policy gates can block builds or deployments that depend on suppliers below a configured trust threshold, and the zero-CVE image and signed-SBOM workflow shrinks the credential surface inside source code. You see your third-party trust graph as a defender, not as a victim.