To auto-assign vulnerability tickets, keep one source of truth that maps code locations to owning teams, let your automation read it when a finding arrives, and assign the ticket to that team's queue. Always define a fallback owner, so nothing lands unassigned.
Where ownership data can come from
You do not need a new system. Most teams already hold ownership somewhere. The question is which source is trusted and kept current.
| Source | Good for | Weakness |
|---|---|---|
| CODEOWNERS file | Repository paths and review routing | Only knows code, not deployed services |
| Service catalog | Running services and on-call teams | Often stale if nobody owns the catalog |
| Repository metadata or topics | Whole repository ownership | Coarse for monorepos |
| Manual spreadsheet | Quick start | Drifts within weeks |
GitHub documents that a CODEOWNERS file can live in the .github/, root or docs/ directory, that the last matching pattern takes precedence, and that owners are automatically requested for review when a pull request touches files they own. That makes it a decent starting point for dependency findings, because a manifest such as a lockfile has a path, and a path has an owner.
Steps
- Pick the ownership source. Prefer the one engineers already update during normal work.
- Resolve each finding to a location: repository, manifest path, or container image and its build repository.
- Look up the owner for that path. For a transitive dependency, use the manifest that pulls it in.
- Create the ticket in that team's project or queue, not in a shared security inbox.
- If no owner matches, assign to a named fallback, such as the platform team or a security triage rota.
- Report weekly on tickets that used the fallback. Each one is a gap in your ownership data.
Pitfalls to plan for
A broad pattern at the top of a CODEOWNERS file can swallow everything. Remember that a more specific line lower in the file overrides it, so check the order. Teams must also be visible and have write access, or the rule is skipped, so test with a real pull request.
Monorepos need path rules, not repository rules. A single lockfile at the root may belong to one team while service folders belong to others. Decide up front who owns the shared lockfile.
Also avoid assigning to an individual. People leave, go on holiday and change teams. Assign to a team queue, then let the team pick up the work.
Try it yourself
Open the demo and look at how findings are grouped by affected component. Think about which team each row would go to.
Click through it at your own pace, or open it full screen.
Quick check
Should I assign tickets to a person or a team?
Assign to a team queue. A person can be away or move on, and a team queue keeps the ticket visible.
What if no owner matches a finding?
Send it to a named fallback owner and review those tickets weekly. Frequent fallbacks tell you where ownership data is missing.
Safeguard can scan dependencies and open fix pull requests (off by default, every category on Manual), and you can try a free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs, About code owners
Last reviewed: 19 October 2026.
