To inventory applications across several cloud accounts, start from what your team builds rather than from each account console. List repositories, container images and deployed versions, join them with a stable service name, and attach an owner to each. Accounts then become a "where it runs" column, not the organising idea.
Why account by account inventories fail
An account is a billing and permission boundary. An application is not. One service can have a repository, two images, a function in another account and a database in a third. If you inventory per account, you end up with five lists that do not agree, and no one can answer "which of our services use this library?"
Application teams care about a different question from platform teams. They need to know which code they ship, which versions are live, and who fixes things. That is a software inventory, and it can be built without admin access to every account.
Definitions
Application inventory: a list of the services you own, each with a name, owner, source repository and the places it runs.
Deployed artifact: the thing actually running, such as a container image identified by digest, a function package, or a virtual machine image.
Component inventory: the packages and libraries inside each artifact, usually recorded as an SBOM.
Steps
- Pick a service name rule. One short lowercase name per service, used everywhere. Kubernetes documents a recommended label,
app.kubernetes.io/name, for exactly this, andapp.kubernetes.io/part-offor the higher level application. - Start from source. List every repository that produces something deployable. Skip libraries that never ship on their own at first.
- Record the artifacts each build produces. Image names and digests, function packages, machine images.
- Collect what is deployed. Ask each account or cluster for the images and function packages it runs, then match them to step 3 by digest. Anything running that matches nothing is your first finding.
- Generate component data per artifact. One SBOM per deployed artifact, not per repository, because a repository may build several things.
- Attach owners. Use a team name and a contact route, not a person.
- Refresh on a schedule. A quarterly spreadsheet goes stale within weeks.
What each source tells you
| Source | Answers | Misses |
|---|---|---|
| Repositories | What you build and who commits | What is actually running |
| Registries | Which images exist | Which are in use |
| Runtime listings per account | What is deployed now | Why, and who owns it |
| SBOMs | Which components are inside | Configuration and exposure |
No single source is enough. The join between them is the inventory.
Common gaps
Images pushed by hand and never built in CI. Functions deployed from a laptop. Accounts opened for a trial and forgotten. Forks of internal tools that kept the old name. Each shows up as a runtime item with no matching build, which is why step 4 matters.
Try it yourself
Open the demo and look at how a dependency inventory turns scattered components into one searchable list for a single service.
Click through it at your own pace, or open it full screen.
Quick check
Do I need access to every cloud account to start?
No. Start with repositories and registries, which you probably already read. Add read only runtime listings from each account as they become available.
Is a CMDB the same thing?
Not quite. A configuration database can hold this data, but it often tracks infrastructure. An application inventory is organised around services and their components.
Safeguard's asset discovery and SBOM and dependency scanning cover this kind of inventory, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
