Model your SCA hierarchy around products and owning teams, with tier or criticality as an attribute, not the org chart alone. Repos belong to one owning team and can serve several products. Keep structure shallow, label everything, and make moves cheap, because reorganizations will happen.
The three ways people model it
| Axis | Good for | Weak at |
|---|---|---|
| Org chart (division, department, team) | Delegation, who gets the alert | Breaks at reorgs, hides shared code |
| Product or service | Customer impact, SBOM per release | Shared libraries serve many products |
| Tier or criticality | Setting policy strictness | Needs a human to assign and maintain |
You need all three, but they play different roles. Use the team axis for ownership, the product axis for reporting and SBOMs, and tier for policy.
A workable structure
- Organization at the top for global policy.
- Business unit for delegated admin and unit level policy.
- Team as the unit that receives and fixes findings.
- Repository assigned to exactly one owning team.
- Labels for product, tier, data sensitivity and environment.
Resist adding more levels. Each extra level multiplies the places a policy can be overridden. Labels are cheaper than hierarchy.
Why one owner per repo
A finding needs one accountable team. Backstage's catalog docs make the same point for components: owner is the singular entity, commonly a team, that bears ultimate responsibility (see Sources). If a repo has two owners, nobody owns it. Where a repo truly serves several products, tag the products as labels and keep one owning team.
Shared libraries
A shared internal library is where models often break. The library's own team owns the findings in its dependencies. Consuming services own whether they have upgraded. A good tool lets you see both: the finding at the library, and which services still pin the vulnerable version.
Mapping from existing data
Do not type this in by hand. Pull from:
- A service catalog, if you have one.
- CODEOWNERS files for path level owners.
- Your identity provider's groups for team membership.
- Repository topics or custom properties for product and tier labels.
Then compare: how many repos have no resolvable owner? That number is your first metric.
Design for change
Reorgs move repos between teams. Check that:
- Moving a repo updates its effective policy and open finding owners without a rescan.
- History stays attached to the repo, not the team.
- Teams can be merged or renamed without losing exceptions.
- Bulk moves are possible by label or API, not one repo at a time.
Related: build an alert ownership map and what happens to ownership after a reorg.
Pilot before you commit
Model one business unit with real data before rolling out. Count how many repos fit cleanly and how many are awkward. The awkward ones teach you what labels you need.
Safeguard's asset discovery helps find repositories and services you did not know about, and a free scan at gold.safeguard.sh/scan gives a starting inventory.
Quick check
How many hierarchy levels are too many?
More than four or five usually causes override confusion. Use labels for extra dimensions instead.
Can a repo belong to two teams?
Avoid it. Assign one owning team and add labels for other stakeholders.
Sources
Last reviewed: 19 October 2026.
