Assume the worst case and limit it ahead of time. Give the tool the narrowest scopes, grant it only the repositories it needs, prefer short lived tokens, keep write access off unless required, log its activity, and rehearse revocation. Then a vendor breach becomes a rotation task, not a crisis.
Map what the vendor can touch
List every credential and integration you gave the tool. For each one, write what an attacker holding it could do.
| Access | Worst case |
|---|---|
| Read access to all repos | Copy all source code and history |
| Write access or PR creation | Push or propose malicious changes |
| CI secrets or tokens | Run code in your pipeline, reach cloud accounts |
| Webhook endpoints | Send fake events into your systems |
| SSO and SCIM | Create or remove users if over scoped |
| Ticketing integration | Read or write tickets with sensitive detail |
Seeing it written down makes over granted access obvious.
Reduce it, step by step
- Choose repositories explicitly. Prefer selected repositories over organisation wide access.
- Use app based access, not personal tokens. GitHub's guidance says to select the minimum permissions a GitHub App needs, and that you can restrict the repositories and permissions for each installation token. It also advises never using personal access tokens for app authentication.
- Prefer expiring tokens. GitHub states that installation access tokens expire after one hour. Short lives limit what a stolen token can do.
- Keep write off by default. If the tool opens fix pull requests, scope it to that. Require your own review and branch rules so it cannot merge itself.
- Limit CI permissions. GitHub documents setting the workflow token's permissions to the least required, per workflow or per job.
- Separate environments. Do not give a scanner production cloud credentials.
Monitor it
Alert on unusual activity from the tool's identity: access to repos outside its scope, clone volume spikes, activity at odd hours. Your Git platform's audit log can show it. See quarterly git hosting access review checklist.
Rehearse revocation
Write a runbook: where each credential lives, who can revoke it, and how to rotate it. Test it once. Ask the vendor how they would notify you of an incident, and how fast. See your security vendor was breached: first 48 hours.
Put it in the contract
Ask for breach notice terms with a timeline, a right to receive indicators of compromise, and cooperation duties. See vendor breach notification clause.
Safeguard offers asset discovery, policies and guardrails, and a free scan at gold.safeguard.sh/scan.
Quick check
Is read only access safe?
It limits tampering but still exposes source and history. Treat read access to all repos as sensitive.
How often should we rotate tool credentials?
Prefer tokens that expire on their own. For longer lived credentials, rotate on a schedule you set and always after a vendor incident.
Sources
- GitHub Docs: recommended practices for creating a GitHub App
- GitHub Docs: Automatic token authentication
Last reviewed: 19 October 2026.
