A service catalog is a list of the services your organisation runs, each with an owner, source repository, importance tier and the places it runs. Vulnerability management needs one because a finding about a component is useless until you can say which service it belongs to and who fixes it.
Definition
Service catalog: one record per service, kept current, readable by engineers and security.
Service record: the row for one service with a short set of fields.
It is not a document library or a diagram collection. It is a table that tools can read.
The fields that matter for security
| Field | Use in vulnerability work |
|---|---|
| Service name | The key joining everything else |
| Owner team and contact route | Where findings go |
| Source repositories | Where code changes happen |
| Tier | Sets the fix deadline |
| Environments and locations | Where the fix must roll out |
| Artifacts | Image names, function packages, machine images |
| Data classes handled | Raises priority when sensitive |
| Dependencies on other services | Shows blast radius |
Kubernetes recommends labels such as app.kubernetes.io/name, app.kubernetes.io/part-of and app.kubernetes.io/component, which map neatly onto service, application and part. Using those names in the catalog lets runtime data join cleanly.
How it changes daily work
Without a catalog, a new advisory triggers a search in chat for who owns what. With one, the matching component list resolves to services, services resolve to teams, and tickets go out the same day.
Build it small
- Start from what runs. Take the list of deployed artifacts and group them into services.
- Add owners. Put a team on every service. Services with no owner go on a visible list.
- Link repositories. Use source annotations on images where available. The OCI spec defines
org.opencontainers.image.sourcefor this. - Assign tiers. Three levels are enough.
- Keep it near the code. A small metadata file in each repository, collected by a job, goes stale less often than a spreadsheet.
- Review each quarter. Remove retired services and check owners still exist.
Pitfalls
- Catalogs that need manual updates after every deploy. Let automation fill in locations and versions.
- Owner fields that name people. Use teams.
- Too many fields. Each field needs a user and a refresh process.
An example record
Service: checkout-api. Owner: payments-platform, with a channel alias. Repository: one source URL. Tier: high. Environments: production in two accounts and one data centre, staging in one account. Artifacts: one image and one scheduled function. Data classes: payment references. Depends on: the identity service. With that record, an advisory about a library in the image resolves in minutes to a team, a deadline and a three place rollout list.
Quick check
Is a CMDB the same thing?
It can serve the purpose, but many are built around infrastructure. What you need is a record per service with software details.
Who should maintain the catalog?
Service teams own their records, and a platform or security group owns the structure and checks for gaps.
Safeguard's asset discovery and compliance and evidence automation help keep inventory and ownership current. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
