Integrator Token Blast Radius

Platforms issue tokens so that continuous-integration services, deployment tools and productivity integrations can act on a user's behalf. Those tokens are frequently long-lived, carry the user's whole reach, and are usable from any address. They are then stored by a separate company with a separate security posture.

The blast radius of that arrangement is not the integration's functionality. It is everything the granting user could reach, and it is decided at the moment the token is issued - by the scope model, the lifetime and the absence of any locality constraint - rather than by anything the integrator does afterwards.

The second half of the calculation is what the reached resources contain. For source code the answer is credentials: cloud keys in test fixtures, a database password in an old configuration file, a webhook secret in a script, a token committed in 2019 and deleted in 2020 that is still in history. So read access to code is, with high probability, write access to something else.

Why it matters

It is a risk that is invisible in the usual places. No vulnerability scan reports it, no dependency audit covers it, and the platform issuing the token is not where the breach occurs. The exposure is created by an authorisation grant - frequently made by one developer who wanted a convenient integration, silently extending organisational access to a third party.

It is also the risk that converts a disclosure incident into an infrastructure incident. A stolen read-only token sounds like the least damaging category of access until the cloned repositories are mined for secrets, after which the affected organisation faces an unbounded rotation exercise and the permanent uncertainty of not knowing which credentials were extracted.

Implementation patterns

As the platform issuing tokens:

• Prefer installation-scoped application identities to user tokens. An app installed on named repositories with named permissions, issuing short-lived tokens, gives the integrator something that expires and covers only what was granted.
• Expiry by default, with refresh - installation tokens measured in 60 minutes rather than years - so that no credential is a permanent liability.
• Fine-grained scopes with a resource allowlist, so "what can this token do" has a one-sentence answer.
• Make the grant an organisational decision: administrator approval for third-party access to organisation resources, with a reviewable list and a scheduled review.
• Alert on anomalous enumeration. An integrator token listing hundreds of organisations is not what that integrator does, and enumeration before extraction is the detectable step.
• Offer locality or audience constraints where the integrator's egress addresses are stable.

As a consumer of integrations:

• Assume code contains secrets: secret scanning with push protection, and credential rotation included in the incident plan for any code disclosure.
• Review authorised third parties on a schedule and remove those nobody can name an owner for.

Industry example

On 12 April 2022 GitHub began investigating an attacker using stolen OAuth user tokens issued to two third-party integrators, Heroku and Travis CI, to list organisations and clone private repositories from dozens of organisations including npm. GitHub stated it did not believe the tokens were obtained by compromising GitHub and that it does not store them in usable form; its security chief said the attacker's behaviour suggested mining the cloned repositories for secrets usable to pivot into other infrastructure. Heroku was subsequently reported to have reset customer account passwords and invalidated API tokens. The platform was not breached, and dozens of organisations were.

Failure scenarios

• Coarse scope. A token scoped to "all repositories" because the scope model offers nothing narrower, used for an integration that needed three.
• No expiry. The token remains valid years after the integration was abandoned, and its security is the weakest of every system that has ever stored it.
• Individual grant, organisational consequence. A developer authorises a tool and the organisation's private code becomes reachable by a third party, with no approval record.
• Secrets in history. A credential removed from the working tree but present in commits, which a clone obtains in full.
• Enumeration unnoticed. Hundreds of organisation listings from one integrator token look like normal API traffic because nothing baselines per-integration behaviour.
• Rotation without scope reduction after an incident, so the same reach is re-granted with a new value.

Trade-offs

The practical tension is adoption. Narrow scopes and expiry push work onto integrators, and a platform that makes the secure path harder will see teams fall back to personal access tokens, which are worse because they are invisible to organisational review.

When not to use it

This is not an argument against integrations. A ban drives teams to personal access tokens and unmanaged automation, which removes the review surface entirely; scoped, expiring, revocable grants with visible approval are the goal.

It is also the wrong frame for a first-party integration inside your own trust boundary, where workload identity is available and no delegated user token is needed at all - if your own services are using OAuth user tokens to call each other, the finding is the architecture, not the blast radius.

Interview question

Q: A third-party CI provider you use discloses that OAuth tokens it held for your organisation were stolen. Nothing in your own systems was compromised. What do you do in the first day, and what do you change permanently?

What a strong answer covers: revoking the integration's tokens and authorisations first, then determining reach - which repositories and organisations that token could see, not which the integrator used · treating any cloned code as a credential disclosure and scoping a rotation from secret scanning over full history, not just the working tree · reconstructing activity from platform audit logs, and being explicit about what cannot be reconstructed · permanently, moving to installation-scoped app identities with expiry and resource allowlists, administrator approval for third-party grants, scheduled review, push protection, and baselined alerting on enumeration · and the adoption trade-off, since a path that is too hard pushes teams to personal access tokens.

Quick check

Quiz: Why is a stolen read-only code token not a read-only incident? Because repositories contain credentials - in fixtures, old configuration and commit history - so read access to code converts into write access to whatever those credentials reach.

Flashcard: Which property of a delegated token decides its blast radius? - Scope coarseness, lifetime and the absence of locality constraints, all fixed at issuance; the integrator's own security posture determines only the probability of theft, not the consequence.