A software catalog is a registry of the components, APIs, systems, resources and teams in your organisation, with relationships between them. For vulnerability work it answers who owns a vulnerable service, what it depends on, and what depends on it, so a finding can go straight to the right team.
Definition and the usual entity kinds
Backstage, a widely used open source developer portal, defines its catalog with a small set of kinds. A Component is a unit of software, an API is an interface a component can expose, a Group is a team or business unit, a Resource is infrastructure such as a database or bucket, and a System is a collection of components and resources that may expose or consume APIs.
You do not need Backstage to use the idea. A spreadsheet with the same columns works at ten services. It stops working somewhere past that, mostly because nobody updates it.
Why scanners need it
A scanner produces findings about repositories and images. A finding is only useful when someone acts on it. Without a catalog, triage becomes a detective game: who wrote this, who runs it, is it still alive?
With a catalog, three things get cheap.
- Routing. The owner field names the team to notify.
- Prioritisation. Lifecycle and system fields show whether a service is in production and what it belongs to.
- Blast radius. Dependency relations show which components rely on a vulnerable one.
Catalog fields that matter for security
| Field | Why a security team cares |
|---|---|
| owner | Who gets the finding |
| lifecycle | Skip experimental noise, chase production, plan deprecated retirement |
| type | Separate services, websites and libraries, because they are fixed differently |
| system | Group findings per product |
| dependsOn | Walk from a vulnerable library to its consumers |
In Backstage, owner, lifecycle and type are required on a Component, while system and dependsOn are optional.
Where catalogs go wrong
The usual failure is stale ownership. A team is renamed, the entry stays. A service is retired, the entry stays. Counter this with two habits: a monthly check that every owner resolves to a live team, and a rule that a deprecated entry carries a retirement date.
The second failure is treating the catalog as documentation rather than data. If a pipeline cannot read it, it will drift.
A small first version
Pick one product area. Register every service in it with the five fields above. Wire your scanner output to the owner field. Measure how long a finding takes to reach a human before and after. That single number is usually enough to justify rolling it out wider.
Quick check
Do we need a developer portal to have a catalog?
No. Any structured source of truth that tooling can read will do. A portal adds browsing and plugins on top.
Should libraries be in the catalog?
Yes. A library entry with its consumers is how you answer "who is affected" when a shared dependency has an advisory.
Safeguard focuses on the scanning side, with SBOM and dependency scanning and policy gates, and offers a free scan if you want to see findings for one project.
Sources
Last reviewed: 19 October 2026.
