Ungoverned Usage of Third-Party Services
Third-party integrations accumulate broad, permanent access to source and pipelines, and nobody re-reviews them.
If this is new to you
Connecting a third-party service to your repository takes one click and is essentially never revisited. Over a couple of years that adds up to a set of vendors with standing access to your source and your pipelines, each with its own security posture that you do not control and cannot inspect.
The aggregate risk is not the average vendor's security. It is the union of every vendor's worst day.
What to do about it
List what currently has access — installed applications, OAuth grants, deploy keys, webhooks — along with the scopes each one holds. Anything you cannot justify in a sentence should go.
Prefer read-only wherever the integration will tolerate it, and prefer the narrowest scope that works over the scope the vendor asks for. Vendors ask for write access by default because it is easier for them.
Follow the data as well as the permissions. The integration most likely to be undocumented is the one quietly receiving user content as a side effect of a feature somebody shipped.
Going deeper
Pin external actions and images by digest, so reviewing a third party's code is a one-time act rather than a standing act of trust in whatever they publish next.
Then put integration review on a schedule. Nobody wakes up wanting to audit OAuth grants, which is exactly why it needs to be a recurring task rather than an intention.
Words used on this pagedefinitions
- OAuth scope
- The specific permissions an integration is granted. Often broader than the integration needs, because broad is easier to ask for.
- Webhook
- An outbound HTTP call your git host makes when something happens. Useful, and a data flow to an endpoint somebody has to keep owning.
Why this matters
Granting a third party access to a repository takes one click and is almost never revisited. Each integration becomes an additional path to your source and your build, with its own security posture that you do not control and cannot audit. The aggregate risk is the union of every vendor's worst day.
What it looks like in practice
If any of these sound familiar, that is the point — most of them are things somebody did for a sensible reason on a busy afternoon.
- Marketplace apps with write access, installed for a trial and never removed.
- OAuth grants held by former employees' accounts.
- Third-party actions referenced by mutable tag, so the code can change without a commit on your side.
- Webhooks delivering repository events to endpoints nobody owns.
- An analytics or AI service quietly receiving user content as a side effect of a feature.
Check your own pipeline
Questions you can actually answer, rather than a maturity score. If you cannot answer one of them, that is itself the finding — and a more useful one than a number.
What third parties can read or write your repository right now?
List installed apps and OAuth grants and their scopes. Anything you cannot justify in a sentence should go.
Are external actions and images pinned by digest?
A tag can be repointed by its owner; a digest cannot. Pinning is the difference between reviewing code once and trusting a vendor forever.
Does any integration receive user data as a side effect?
Follow the data, not the feature. This is the integration most likely to be undocumented.
How to fix it
- Review integrations on a schedule and remove anything without a current owner and purpose.
- Grant the narrowest scope the integration works with, and prefer read-only.
- Pin external code by digest and update deliberately.
- Document which third parties receive user content, and make it visible to the users concerned.
Related
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere
Risk taxonomy from OWASP Top 10 CI/CD Security Risks (Daniel Krivelevich and Omer Gil, September 2022, CC BY-SA 4.0). Explanations, checks, fixes and definitions written for this site.