Start in a spreadsheet if you have fewer than a few dozen integrations and one coordinator. Move to a service catalog or a small database when several teams edit it, when you want automated checks, or when you need history of who changed what. The tool matters less than having owners and a review date.
What each option is good at
| Option | Strength | Weakness |
|---|---|---|
| Shared spreadsheet | Zero setup, anyone can read it | No validation, easy to break, weak history |
| Service catalog entries in each repo | Lives next to the code, reviewed in pull requests | Needs a convention and a collector to see all rows |
| Central database or internal app | Queries, validation, access control, audit trail | Someone has to build and run it |
| Ticketing system with custom fields | Fits existing workflow | Poor for browsing and joining data |
The test that decides it
Ask what you must answer under pressure. If a vendor reports a problem, can you filter by vendor in seconds? Can you list every integration whose owner has left the company? Can you see which rows were last confirmed more than a year ago? A spreadsheet can do these, until it has several editors and a few hundred rows.
A path that scales
- Pick the columns first. Use the field list from your integration record: vendor, hostnames or packages, owner, purpose, data classes, environments, last confirmed date.
- Start central. One sheet, one coordinator, locked header row, a drop-down for data classes.
- Move rows next to the code. When teams are ready, a small file in each repository that describes its integrations lets reviewers see the change in the same pull request that adds the SDK.
- Collect nightly. A job gathers those files into one view. Add a schema check so a malformed file fails the build instead of silently dropping out.
- Compare with reality. Join the inventory against dependency scan output and outbound traffic so missing rows show up as a report.
Access and sensitivity
The inventory itself is sensitive. It lists vendors, hostnames and data flows. Limit edit access to owners and a small reviewer group, and give read access to people who need it for incident response. OWASP's inventory guidance also tells teams to restrict API documentation to those authorized to use the API, and the same instinct applies here.
Try it yourself
Use the demo to see a generated inventory of dependencies. This is the kind of output you can join with your manual integration rows.
Click through it at your own pace, or open it full screen.
Quick check
Is a spreadsheet ever fine?
Yes, for a small number of integrations and a single coordinator. Plan the move before the sheet becomes the bottleneck.
Should the inventory sit in the repo?
Per-integration files in the repo are a strong option because changes get reviewed with the code. Pair them with a collector for a global view.
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.
