Find unofficial security tools by searching four places: CI configuration for scanner commands, installed apps and webhooks on your code host, IDE and browser extension lists, and expense or SSO records. Treat each find as information about an unmet need, then decide to adopt, replace or remove it.
Why it happens
Developers add a scanner when the official one is slow, noisy or missing a language. Intent is usually good. The risk is that code, tokens or findings flow to services nobody reviewed.
Where to look
| Place | What to search for |
|---|---|
| CI files and templates | Scanner commands, container images used in jobs, uploaded reports |
| Code host | Installed apps, OAuth grants, webhooks, deploy keys |
| Package manifests | Dev dependencies for linters and scanners |
| Extension stores and IDE lists | Security plugins in managed browsers and editors |
| Finance and SSO | Small subscriptions, sign in logs, trial accounts |
| Developer survey | A short, no blame question: what do you use that we do not know about |
Our post on browser extensions in your asset inventory covers one corner of this in more detail.
Handle finds without blame
Ask what problem the tool solves. Then sort:
- Adopt. It fills a gap and passes a vendor review. See vendor security review before you buy.
- Replace. The need is real but an approved tool can meet it. Show how.
- Remove. It duplicates something or moves data somewhere unacceptable. Revoke the access and rotate any token it held.
Check the permissions
For every unofficial tool, list what it can read and write. A scanner with write access to repositories or access to secrets is a bigger concern than a read only linter. Use least privilege as the standard.
Prevent it recurring
Give developers a fast path to request a tool, with a short review and a clear answer. A slow approval process creates the shadow tools in the first place.
What to do with the data you find
Put every discovered tool into the same inventory sheet as the approved ones, with a status of adopt, replace, remove or review. Share the summary with engineering leads without naming individuals. The pattern across teams usually points to one or two real gaps in the official tooling, and fixing those removes most of the reason for shadow tools.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and notice how components from several sources land in one list. Your tool inventory should give the same single view.
Quick check
Should we ban unapproved tools?
A ban without a fast request path pushes usage further out of sight. Pair any rule with a quick review route.
Do free tools need review too?
Yes. Free does not mean harmless. What matters is what it can access and where results are sent.
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
