How do you route supply chain findings to the right owner?

Route each finding by a chain: component to repository, repository to team, team to a named person, and person to a ticket in the tool they already use. Keep a fallback owner for orphans. Most unfixed findings are not hard to fix. They are unowned.

The ownership chain

A finding names a package. Your job is to turn that into a human. Build the chain once, store it as data, and keep it current.

Handle the awkward cases

Shared dependencies. One vulnerable library used in forty repos should produce one parent issue with child tasks, not forty separate alerts to forty people. Group by component and fixed version.

Transitive dependencies. The vulnerable package may come in through a direct dependency owned by another team. Route to the owner of the direct dependency chain in your own repo, and note which parent pulls it in.

Orphans. Repos with no owner need a default. Give the platform owner a weekly orphan list and a rule: an orphan with a critical finding goes to a named engineering manager after seven days.

Vendored code. Code copied into a repo with no package record may not match any inventory entry. Flag it as a coverage gap.

Decide priority before routing

A routed finding with the wrong urgency wastes everyone's time. Use a small decision tree. CISA, working with Carnegie Mellon University's Software Engineering Institute, describes SSVC as a methodology that accounts for a vulnerability's exploitation status, impacts to safety, and prevalence of the affected product. You do not need the full method, but the idea carries over: urgency comes from exploitation, exposure, and impact, not the score alone.

Write the ticket so it can be done

• One sentence on what is wrong.
• The affected component and version, and where it appears.
• The fixed version, or the mitigation if none exists.
• Whether the code is reachable.
• A due date based on urgency.
• A link to request an exception.

If a developer needs to open three other pages to understand the ticket, it will wait.

Measure the routing itself

Track the share of open critical findings with a named person, the median time from detection to assignment, and the number of orphans. If assignment takes days, the problem is the chain, not the developers.

Keep it current

Review ownership data every quarter and whenever a team changes. A code owners file in each repository, checked by a simple CI rule, keeps the second link honest.

A worked example

Take a hypothetical advisory in a shared date handling library used in thirty repositories owned by six teams. Without a routing design, the platform creates thirty alerts. Each team sees five alerts, argues about duplicates, and nobody starts.

With the design, the platform groups findings by component and fixed version, creating one parent issue with six child tasks, one per team. Each child task goes to the named champion for that team, using the ownership chain. The ticket states what is wrong, the fixed version, whether the code is reachable, and a due date. Two repositories have no owner. The platform owner assigns them to the fallback engineering manager, who reassigns them within two days. Within a week, the parent issue shows four of six teams done and two in progress, so a single glance tells everyone where things stand.

Ownership data model

Keep it simple and stored where machines can read it.

Rules for escalation

1. A critical finding with no owner after one day goes to the fallback owner.
2. An owner who has not acknowledged a critical finding in two days is reminded, and in four days the manager is notified.
3. A finding past its due date appears in the monthly report with the owner's name.
4. A finding that is known exploited and internet facing goes to the on-call engineer immediately.

These rules should be visible to everyone, so escalation feels fair and predictable.

Reducing noise before routing

Routing noise creates noise for people. Filter before you assign. Apply reachability, collapse duplicates, and group by fixed version. A person should receive a small number of well described tasks, not a flood. After a month, ask owners how many tickets they received and how many they consider useful. If the ratio is poor, tune before you add more repositories.

Special routing cases

• Findings in vendored code. Route to the repository owner and tag as coverage gap.
• Findings in base images. Route to the team that owns the base image, not every service that uses it.
• Findings in build tooling. Route to platform engineering.
• Findings in third party SDKs. Route to the integration owner and track a vendor follow up.

Closing the loop

A finding is done when a rescan of the built artifact shows it gone. Configure the platform to close tickets on that signal, not on a manual status change.

Try it yourself

Click through it at your own pace, or open it full screen. Open the demo and follow how a finding moves through states. Imagine each state change as a point where the ticket needs a clear owner.

Safeguard offers asset discovery, SBOM and dependency scanning, and reachability analysis to scope findings, with fix pull requests off by default and every category on Manual. See an inventory with the free scan at gold.safeguard.sh/scan.

Quick check

Sources

• CISA, Stakeholder-Specific Vulnerability Categorization (SSVC)

Last reviewed: 19 October 2026.