Vulnerability Ownership Is the Real Remediation Bottleneck

Ask an AppSec team where their remediation time goes and the honest answer is rarely "fixing things." It is finding out who should fix them. The finding exists, the fix is often known, and the ticket sits in a shared queue, or in the wrong team's backlog, until someone works out who owns the code.

Detection got cheap. Vulnerability ownership did not. Every scanner added to the stack produces more findings, and every one of them lands on the same unsolved question: whose is this? Until that question has an answer the system can compute, adding detection only makes the queue longer.

Why vulnerability ownership is harder than it looks

On an org chart, ownership is obvious. In a real codebase, it is spread across half a dozen sources that disagree with each other.

• Repositories have a team in the SCM, often the team that created them years ago.
• Directories inside a monorepo belong to different teams, recorded in CODEOWNERS, if anywhere.
• Services have an owner in a service catalog, which may or may not match the repository team.
• Dependencies are owned, in practice, by whoever last touched the manifest, which is not the same as who should maintain them.
• People move teams, leave, and join, and the identity system learns about it on its own schedule.

Each source is partly right. None of them is complete. A remediation program that trusts one source routes a meaningful share of its work to the wrong place, and every wrong route costs a round trip: the ticket bounces, someone reassigns it, days pass.

The cost of ownership that decays

Ownership data does not fail loudly. It decays. A team is renamed and its CODEOWNERS entries stop matching anything. A directory is moved and the path in an ownership file points nowhere. A new engineer joins and cannot see their team's repositories until a nightly job runs, so they log in, see nothing, and assume the tool is broken.

Each of these is small. Together they produce the pattern every AppSec lead recognizes: tickets routed to a team that no longer owns the code, a default queue that fills with everything the router could not place, and security engineers spending their week triaging the router's mistakes instead of reducing risk.

The fix is not more diligence. It is treating ownership as data that is reconciled continuously, with drift detected and surfaced, rather than configuration that is set once and trusted forever.

What good ownership data looks like

Ownership that routes remediation work reliably has four properties.

It has an explicit precedence order

When sources disagree, the system needs a rule, not a guess. A reasonable order runs from most specific to least: an explicit per-dependency owner, then CODEOWNERS for the path, then the team that owns the repository. Whatever the order, it should be written down and visible, so anyone can predict where a finding will land.

It reaches the module, not just the repository

A monorepo with twelve teams working in it cannot route by repository. Ownership has to resolve to the directory or module where the vulnerable code or manifest lives.

It resolves to a person as well as a team

A ticket assigned to a team queue that nobody watches is a ticket nobody works. Routing to a named person, such as a team's manager or tech lead, with the team as the fallback, closes the gap between "assigned" and "someone knows."

It reports its own decay

An owner reference that matches no live team, or a path that no longer exists, should appear as a problem someone can fix, not fail silently into the default queue.

CODEOWNERS is necessary, and not sufficient

CODEOWNERS files are the closest thing most organizations have to machine-readable ownership, and they are worth investing in. They are also easy to get subtly wrong.

• In GitHub, the last matching pattern in the file wins, so a broad rule at the bottom silently overrides specific ones above it.
• Owners are referenced by team slug or group path. Rename the team and every line that references it stops resolving.
• They describe who reviews changes to a path, which is close to, but not the same as, who owns fixing a vulnerability in a dependency that path declares.

Treat CODEOWNERS as one input to ownership, keep it in review like any other code, and pair it with something that tells you when its references stop matching real teams. GitHub documents the file format and precedence rules in its code owners guide.

Ownership is also access

There is a second side to ownership that is easy to overlook: who can see what. If an engineer cannot see their team's findings the day they join, ownership data is not doing its job for them. If they can see every team's findings, including repositories they have no business in, it is doing too much.

Visibility scoped to the teams you belong to, set up the moment an account is created rather than after a batch job, makes the engineer's view match the work they own. It is also the least-privilege position, which matters when findings describe exploitable weaknesses in code.

Measuring ownership, not just findings

Most AppSec dashboards report findings: counts by severity, age, SLO compliance. Few report the thing that determines whether those numbers move. Three measures are worth adding.

• Unowned share. The percentage of open findings with no resolved owning team. This is the size of your default queue.
• Reassignment rate. How often a ticket is moved after it is created. A high rate means routing is guessing.
• Time to first owner action. The time between a finding appearing and its owner doing anything with it. This is often longer than the time to fix once someone starts.

If the unowned share is high, no amount of prioritization or auto-fixing fixes the throughput problem. The work has nowhere to go.

A vulnerability ownership checklist

• Pick a precedence order for ownership sources and document it.
• Resolve ownership to the module or directory in monorepos, not just the repository.
• Route tickets to a named person with the team as fallback.
• Reconcile ownership from your SCM, CODEOWNERS and service catalog on a schedule, removing stale links, not only adding new ones.
• Surface unresolved owner references and stale ownership paths as findings someone owns.
• Give new users their team's view at provisioning time, not the next day.
• Report unowned share and reassignment rate next to your finding metrics.

How Heeler resolves ownership

Heeler's remediation assignment can route each remediation to the team that owns the dependency, resolved in a documented order: a dependency ownership file (dependency_owners.json) first, then CODEOWNERS when you turn it on, then team-to-repository ownership as the fallback. An Ownership Source Drift view flags owner references that no longer match a live team and ownership files whose path is no longer in the scanned tree, as described in the remediation assignment and routing documentation. In a monorepo, each module can be owned by a different team.

Ownership also flows in from where you already keep it: GitHub and GitLab teams, CODEOWNERS, and Port, whose team sync reconciles changes, removing ownership links that disappear upstream rather than accumulating them. When Heeler creates a ticket, it can assign it to the team's manager from Port, with team-only assignment as the fallback. Every finding table carries a Team column, and the Repositories list has a "No team" filter that shows everything that has no owner.

New users added through SAML JIT, SCIM or manually are provisioned straight away, so the first thing they see is their team's work. Ownership then feeds Autonomous Operations, where workflows route, ticket and follow up on findings, and SCA Auto-fix, whose pull requests go to the people who own the code.

We wrote earlier about why assigning remediation ownership takes longer than fixing issues. The short version since then: ownership has to be reconciled data, not a one-time mapping.

FAQ

What is vulnerability ownership?

Vulnerability ownership is the mapping from a finding to the team and person responsible for fixing it. It depends on who owns the code, service or dependency where the finding lives.

Why do remediation tickets get routed to the wrong team?

Ownership sources such as SCM teams, CODEOWNERS and service catalogs disagree and decay over time. Renamed teams, moved directories and stale links send tickets to teams that no longer own the code.

Is CODEOWNERS enough to route security findings?

CODEOWNERS is a valuable input, but it describes code review responsibility for paths and breaks when teams are renamed. Combine it with other sources and detect references that no longer resolve.

How should ownership work in a monorepo?

Resolve ownership to the module or directory that contains the vulnerable code or manifest. Routing a monorepo's findings by repository sends every team's work to one place.

What metric shows whether ownership is working?

Track the share of open findings with no resolved owner and how often tickets are reassigned after creation. High numbers on either mean routing, not fixing, is the bottleneck.

Findings only get fixed once they reach someone who owns them. To see ownership resolved from your own sources, drift reported, and remediation routed to the right team and person, Get a demo.