Route findings to the team that owns the affected code, using a code owners file for SAST and a service to team map for DAST. Add a named fallback for orphaned code. A finding assigned to "security" usually waits; one assigned to a team with a due date gets fixed.
Why ownership is the bottleneck
Scanners are good at finding and weak at deciding who should act. If every alert lands in a central queue, a small security team becomes a bottleneck and developers never see the problem. Assigning at creation time removes a manual step and tells the right people early.
Where ownership information lives
| Source | Best for | Weakness |
|---|---|---|
| Code owners file in the repository | SAST findings tied to files | Goes stale, broad patterns catch everything |
| Repository to team mapping | Whole repository scans, dependency findings | Coarse in monorepos |
| Service catalog entries | DAST findings tied to a URL or service | Needs the catalog kept current |
| Git history of the flagged lines | Fallback when no owner is listed | The last committer may have moved on |
Steps
- For each finding, take the file path or URL.
- Look up the owner in the sources above, in the order shown.
- Assign a team, not an individual, so vacations and moves do not strand it.
- Set a due date from severity, for example by your own service level targets.
- If no owner matches, assign to a named fallback, such as the engineering manager of the nearest parent folder, and flag the gap for cleanup.
- Post the assignment where the team already works: the tracker or chat channel they use, not a separate security portal.
Handling edge cases
Shared libraries. A flaw in a shared module affects many teams. Assign one owner for the fix and link the others as affected.
DAST findings. These point at URLs, not files. Map the path prefix to a service and then to a team. Keep the mapping with the service definition so it changes with it.
Disputes. Teams will sometimes reject an assignment. Give them a short route to reassign it with a reason, and count those cases, because they show where your ownership data is wrong.
Keep the data healthy
Review the owner file quarterly alongside suppressions, see reviewing suppressions on a cycle. Track the share of findings with no owner as a metric, and drive it to zero. For the wider question of who should read alerts first, see who should triage SAST findings.
One factual note on Safeguard
Safeguard offers asset discovery and policies, which can help map what exists and who is responsible for it. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Should findings go to individuals or teams?
Teams. Individuals change roles and take leave, and a finding assigned to a person who left disappears.
What if no one owns the code?
Assign a named fallback, then fix the ownership data. Unowned code with findings is itself a finding.
Last reviewed: 19 October 2026.
