To find the same vendor used by several teams, normalize vendor names and domains in your inventory, group rows by vendor, and look for rows that differ in version, data sent or credentials. Duplicates are not always bad, but each one should be a deliberate choice.
Why duplicates appear
Teams solve problems independently. One squad adds an email provider for receipts, another adds the same provider for alerts under a different account, and a third adds a different provider for marketing. Nobody did anything wrong, yet the company now has three contracts, three credentials and three places to patch.
For security, the issue is not the count. It is that you cannot answer "who uses this vendor and in what way?" until the names are consistent.
Step by step
- Choose a canonical name. Use the vendor's legal or brand name in one spelling, plus the registrable domain. Keep a short alias table for variants.
- Add vendor as its own column. Do not rely on the free text description.
- Group and count. Sort by vendor, then by team. Flag vendors with more than one owner.
- Compare each group. Look at SDK versions, API versions, accounts, data classes sent and credential holders.
- Decide per vendor. Pick one of the outcomes in the table below.
- Record the decision. Add a note in the rows so the next reviewer does not reopen it.
Outcomes
| Finding | Reasonable outcome |
|---|---|
| Same vendor, same purpose, different accounts | Consolidate accounts and credentials |
| Same vendor, different SDK versions | Align to one supported version, keeping the newest that you have tested |
| Same vendor, one team sends personal data and the other does not | Keep separate, document the difference |
| Two vendors for the same purpose | Ask whether both are needed, and why |
| Same vendor, one team unaware of a deprecation notice | Share the notice and set a date |
Benefits beyond security
A grouped view helps other teams. Procurement sees overlapping contracts. Engineering sees one SDK to upgrade, not four. Privacy sees one processor to review instead of discovering the same one repeatedly. If you also record which integrations send personal data, a vendor-first view is a good starting point for a processor list, with review by your privacy lead.
When to leave duplicates alone
Splitting is sensible when blast radius matters. Separate accounts for a high-risk workload and a low-risk one limit what a leaked key can do. Consolidation should reduce accidental sprawl, not remove useful separation.
Try it yourself
In the demo, scan the dependency list for packages from the same publisher. That is the SDK side of this problem. Then ask which services call the same remote host.
Click through it at your own pace, or open it full screen.
Quick check
Is using one vendor from many teams a problem?
Not by itself. It becomes a problem when versions, accounts and data flows differ without anyone choosing that.
How do I normalize names automatically?
Match on the registrable domain of the API host or the publisher field of the package, and keep a small alias list for exceptions.
Safeguard offers SBOM and dependency scanning and asset discovery that can feed this kind of inventory. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
