To build a service inventory, merge five sources: your deploy platform, your source control, your container registry, your DNS and gateway records, and your cloud accounts. Record a name, an owner, an environment, and a lifecycle state for each service. Anything that appears in only one source is your first list of gaps.
What a service inventory is
A service inventory is a list of every deployable unit you run, with enough fields to decide who fixes a finding and how urgent it is. It is not a diagram and it is not a wiki page that someone updated last spring. If vulnerability scanning is the question "what is wrong with our software", the inventory is the question "which software is that".
OWASP names the failure mode directly. In its API Security Top 10 entry on improper inventory management, it says microservices and cloud deployments make unnecessary API hosts common, and its prevention advice starts with inventorying all API hosts and noting the environment, intended audience and version.
The five sources to merge
| Source | What it tells you | What it misses |
|---|---|---|
| Deploy platform (for example the cluster API) | What is running now | Services deployed by hand elsewhere |
| Source control | What has code | Repos that never ship, and shipped code with no repo |
| Container registry | What images exist | Whether anything runs them |
| DNS and gateway config | What is reachable | Internal only services |
| Cloud account listings | Functions, queues, hosted databases | Anything outside the accounts you checked |
No single source is complete. The value is in the differences. A repo with no running deployment may be dead code. A running image with no repo is a bigger worry.
Fields to record
Keep the first version small. Five fields are enough to start.
- Name, unique and stable.
- Owner, a team and not a person.
- Environment, such as production or staging.
- Lifecycle, such as experimental, production or deprecated.
- Exposure, meaning internet facing, partner facing or internal.
Add language, base image and repository link once the first five are filled in for most services.
A one week plan
Day one, export what the deploy platform runs. Day two, export repos and registry images. Day three, pull DNS and gateway hosts. Day four, merge by name and image, and mark the mismatches. Day five, send each owning team its rows and ask for a yes, no or "do not know". Anything left as "do not know" after a week gets a named triage owner.
Do not wait for perfection. A scanner can start on the services you are sure about while the rest are chased.
Keeping it alive
Make the inventory a by-product of delivery. If a service needs a catalog entry to get a deploy slot, the list stays current without a reminder. Review the mismatch list monthly.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the dependency inventory ties each component back to the project that uses it.
Quick check
Is a service inventory the same as an SBOM?
No. The inventory lists your services. An SBOM lists the components inside one piece of software. You want both, and the inventory tells you which SBOMs you should have.
Who should own the inventory?
Platform or engineering operations usually owns the process. Each service team owns its own row.
Safeguard can discover assets and scan dependencies and SBOMs across many projects, and you can run a free scan on one repository to see the output.
Sources
Last reviewed: 19 October 2026.
