Treat it as a discovery, not an offence. Find which tools hold repository access, review the permissions they were granted, decide whether to adopt, replace or remove them, and give developers a fast lane for the next request. Banning without an alternative just moves the tool out of sight.
Why it happens
A developer wants a dependency alert or a quick code scan. A free tier takes two minutes to connect through an OAuth prompt. No purchase happens, so procurement never sees it. The security team learns about it months later, if at all.
The risk is not that the tool is free. It is that a third party now has read access, sometimes write access, to source code and nobody assessed it.
Step 1: Find what is connected
Look at the installed apps and authorised OAuth applications in your Git hosting organisation. Most platforms list installed apps with the permissions granted and who approved them. Also check CI configuration files for third party steps, and ask in engineering channels. A short, no blame message gets better answers than an audit email.
Step 2: Triage by access, not by price
| Question | Why it matters |
|---|---|
| Read only or write access? | Write access can alter code or open pull requests |
| All repos or selected repos? | Scope sets the blast radius |
| Which data leaves your environment? | Source, manifests, or metadata only |
| Who owns the account? | A personal account leaves when the person does |
| Is there a data terms page? | You need retention and training terms in writing |
Step 3: Pick an outcome
- Adopt: the tool is useful and the terms are acceptable. Move it to a company account and a proper agreement.
- Replace: the need is real but the tool is weak on terms or control. Offer an approved alternative with a date.
- Remove: no clear need, broad permissions. Revoke access and confirm deletion in writing.
Step 4: Build the fast lane
Developers go around slow processes. Publish a one page intake: what to submit, the three questions you will ask, and a promised turnaround. Keep a short approved list for common needs. A lightweight review for low risk requests, with a deeper one for tools that need write access, is easier to defend than a single heavy process.
Link the intake to your vendor tiering so a code scanner is not treated like a note taking app. If you already tier vendors, see how to tier vendors by risk.
Step 5: Keep it from recurring
Restrict who can approve third party apps in your Git organisation, so new connections raise a request instead of a surprise. Review the list quarterly alongside access reviews.
Safeguard offers asset discovery and dependency scanning that can help you see what code and components you run, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Should we revoke every unapproved tool immediately?
Revoke anything with broad write access and no owner. For low risk read only tools, a short grace period with a decision date causes less friction.
Who should approve a code scanner connection?
Name one owner, usually the security or platform lead, and require that procurement and privacy are informed for anything that processes source code.
Last reviewed: 19 October 2026.
