Which catalog-info.yaml fields should a security team require?

Require four fields beyond the name in every catalog-info.yaml: spec.owner, spec.lifecycle, spec.type, and spec.system. Add spec.dependsOn where you can. Owner routes findings, lifecycle sets urgency, type separates services from libraries, system groups products, and dependsOn gives you a map from a vulnerable component to its consumers.

The file in one example

This is a minimal Backstage style component entry.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-api
  annotations:
    example.com/repo: github.com/example/payments-api
spec:
  type: service
  lifecycle: production
  owner: group:payments-team
  system: checkout
  dependsOn:
    - component:shared-auth-lib
    - resource:payments-db

The names are made up. The structure follows the Backstage descriptor format, where apiVersion, kind, metadata and spec are the envelope and metadata.name must be unique per kind within its namespace.

What each field buys you

Backstage marks spec.owner, spec.lifecycle and spec.type as required on a Component, with system and dependsOn optional. For security work they earn their place like this.

• owner: an entity reference to the team or user ultimately responsible. Point it at a team, not a person, so it survives job changes. The docs describe it as mainly used for display, so enforcing a real team behind it is your job.
• lifecycle: well known values are experimental, production and deprecated. Use it to set severity SLAs and to flag deprecated services for retirement.
• type: service, website and library are common. Libraries get fixed by a release, services by a deploy.
• system: lets you report risk per product.
• dependsOn: the reverse relation is dependencyOf, which is the query you run when a shared library is hit.

Annotations for scanners

Annotations are a key and value map of non identifying metadata, usually links to external tools. They are a good place for a repository slug or a scanner project id. The backstage.io prefix is reserved for core, so use your own prefix.

How to enforce

1. Add a CI check that fails when owner, lifecycle or type is missing.
2. Check that owner resolves to an existing Group.
3. Reject a lifecycle value outside your agreed list.
4. Report components with no dependsOn as "unmapped", not as failures.

Start by warning, then enforce after a quarter.

Quick check

Safeguard can read dependencies and SBOMs per project, so a clean owner field turns its findings into routed work. A free scan shows the output on one repo.

Sources

• Backstage descriptor format

Last reviewed: 19 October 2026.