The team that owns the affected code or service should fix a vulnerability, because they understand the change and carry the release. The security team's job is to set priority, give context, unblock hard cases and track progress. Security fixing everything itself does not scale and breeds hand-off delays.
The principle: owners fix, security enables
Code ownership already exists in most repositories. On GitHub, a CODEOWNERS file maps file patterns to people or teams, and owners are automatically requested for review on pull requests that touch their files. The same map can answer "who gets this finding". If a finding has no owner, assigning one is the first fix.
A routing table
| Situation | Who fixes | Security's role |
|---|---|---|
| Vulnerable dependency in a service | Owning team | Priority, upgrade guidance |
| Flaw in first party code | Owning team | Review the fix |
| Leaked secret | Owning team rotates, security guides | Check scope of exposure |
| Shared base image or library | Platform team | Prioritise across consumers |
| Vulnerable third party product, no patch | Owning team and security together | Compensating controls, exception record |
| Active exploitation of a deployed system | Joint, with incident lead | Coordinate and communicate |
| Abandoned repository, no owner | Engineering leadership assigns | Escalate, propose retirement |
What security should provide
- A priority, not a pile. Tell the team which three findings matter first and why.
- A suggested fix. An exact version to upgrade to, or a patch, saves hours.
- A deadline that matches risk. One that people can plan for.
- A named contact. Someone they can ask without opening a ticket.
What owners should expect to do
- Triage new findings for their service weekly
- Fix or schedule within the agreed time
- Record a reason when they decide not to fix
Handling the awkward cases
Shared libraries. If a platform team owns a library used by twenty services, fixing it once is cheaper than twenty separate tickets. Route the finding to the library, then track adoption.
No owner. Findings with no owner are the ones that age. Treat "unowned" as a finding in itself and report it upward.
Skills gap. Some fixes need security expertise, such as a flaw in session handling. Pair a security engineer with the owner for the first fix, then let the owner do the rest.
Where automation fits
A proposed fix, such as a dependency bump pull request, moves work from "figure out what to do" to "review a change". The owner still approves, which keeps accountability where it belongs.
Try it yourself
Open the demo and follow a finding from detection to a fix. Look for the point where the owner and priority are attached.
Click through it at your own pace, or open it full screen.
Quick check
Should security open a ticket for every finding?
No. Send owners a prioritised short list and let low priority items sit in a dashboard. Ticket floods are ignored.
Who owns a finding in a shared library?
The library's owning team fixes it once. Consumers then need to upgrade, which security can track.
Safeguard offers autonomous remediation with fix pull requests, which is off by default and starts with every category on Manual, so the owning team approves each change. A free scan shows what a first set of findings would look like.
Sources
Last reviewed: 19 October 2026.
