Treat it as input from whoever can write to the repository, not as truth. The Backstage catalog continuously ingests entity descriptor YAML from configured sources and stores it. If a source is writable by many people, many people can influence the catalog's owners, links and relationships that others rely on.
How the catalog gets its data
The documentation says Backstage natively imports catalog data through entity descriptor YAML files, and that the catalog backend continuously ingests data from configured sources and stores it in its database. Entities can be added in static configuration, registered through the catalog import plugin, or discovered from a GitHub organization. Larger setups sync from another system through entity providers, or enrich entities with custom processors.
That design is convenient. It also means the catalog is a downstream consumer of whatever those sources contain.
What an attacker or a careless commit can change
| Field or feature | Why it matters |
|---|---|
| Owner | Teams rely on it to route incidents and approvals |
| Links and annotations | Plugins read annotations to decide which dashboards, repos or pipelines to query |
| Relationships and dependencies | Used to understand blast radius |
| Lifecycle and type | Used to decide what is production |
| Registered locations | Can point the catalog at more files to ingest |
None of those is code execution by itself. They are trust inputs. A plugin that takes an annotation value and uses it in a request, a path or a query now has attacker-influenced data flowing through it, which is the usual reason to ask whether plugin authors validated it.
Decisions to make
- Who may add or change descriptors? In most organizations, any developer with repository write access can. If catalog ownership drives incident routing, require review on those files through code owners.
- Which locations does the catalog ingest? Prefer explicit, bounded sources. Broad organization discovery is useful and also means every repository in scope can add entities.
- Are annotations treated as untrusted by plugins? Read how each installed plugin uses them.
- Is the catalog the source of truth for anything security relevant, such as which services are internet facing? If yes, verify against a second source.
- Can you spot drift? Compare the catalog against your cloud accounts and source host periodically.
A short review routine
Once a quarter, export the catalog and sort by oldest update. Entities nobody has touched for a long time are either stable or abandoned, and you want to know which. Check for services with no owner or with an owner team that no longer exists. Look for entities whose repository link no longer resolves. These are the cases that cost time during an incident.
If you use entity providers or processors, treat them as backend code. The same review that applies to scaffolder actions applies to them: dependency list, network calls, credentials.
Why this belongs in a security review
Developer portals are used when people are under pressure. During an incident, the owner field decides who gets paged and the dependency links decide where you look. Wrong data wastes the first minutes. That is a security and resilience concern, even when nobody has attacked anything.
Where Safeguard fits
Safeguard's asset discovery and SBOM and dependency scanning give you a second view of what exists and what it depends on, which is useful when checking a catalog against reality. See gold.safeguard.sh/scan for the free scan.
Quick check
Is the catalog database the source of truth?
It is a store built from configured sources. The truth lives in those sources, so protect them accordingly.
Does a bad descriptor mean code execution?
Not by itself. The risk is that plugins and people trust its fields, so validate how plugins use annotations and who can edit descriptors.
Sources
Last reviewed: 19 October 2026.
