Keep one inventory with a surface column (web, backend, mobile, internal tool) rather than three separate lists. The discovery methods differ by surface, but vendors, data and owners are shared, and a single list is the only way to see one vendor across all of them.
What differs by surface
| Surface | How integrations appear | Discovery source |
|---|---|---|
| Backend services | HTTP clients, SDKs, queues, webhooks | Dependency scans, code search, egress logs |
| Web front end | Scripts, embeds, browser SDKs, fonts | Page crawl, content policy reports, build manifests |
| Mobile apps | Embedded SDKs, platform services | App dependency manifests, store listings, network tests |
| Internal tools and no-code | Connectors, automations, shared accounts | Admin consoles, platform audit logs |
Each surface has its own review questions. A front end script runs in the user's browser with access to the page, a backend SDK runs with your credentials, and a mobile SDK ships inside a binary that users keep for a long time.
Why one list wins
Imagine a single analytics vendor present on the website, in the iOS app and in a backend job. If the lists are separate, three owners each think it is somebody else's problem. A vendor incident, a pricing change or a deprecation notice reaches one team, and the other two find out later. OWASP's guidance asks for visibility of how APIs share data with external third parties, and splitting the list by surface makes that harder.
How to structure the single list
- Shared columns. Vendor, owner, purpose, data classes, credential location, last confirmed date.
- A surface column. Allow multiple values per row, or create one row per surface linked by vendor.
- Surface specific fields. Add an optional block per surface, such as script URL and integrity setting for web, or SDK package and minimum OS version for mobile. Keep these optional so other surfaces do not carry empty columns.
- Per surface discovery. Run the right check for each surface and write results into the same list.
- Shared review. Run one quarterly review with representatives from each surface, so duplicates and conflicts are visible in the room.
When to split anyway
Separate lists make sense when different teams have strict access boundaries, when regulations or contracts require a separate record, or when a mobile program already runs a mature SDK register that you do not want to disrupt. In that case, still publish a combined vendor view that reads from each.
Common mistakes
Do not treat web scripts as someone else's job, since they run with access to the page. Do not skip internal tools: connectors in no-code platforms are integrations, and they often hold powerful credentials. Do not let mobile be the only surface with an approval process while backend integrations go in unreviewed.
Quick check
Do mobile SDK registers still make sense?
Yes, as a view or a set of extra fields. Link them to the shared vendor rows so nothing is counted twice.
Who should coordinate across surfaces?
One named owner of the inventory system, with a representative from each surface on the review.
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.
Sources
Last reviewed: 19 October 2026.
