Nobody Owns a Security Finding, Which Is Why the Backlog Never Moves

A finding that nobody owns is not a security problem. It is a routing problem, and routing problems do not resolve by being reported more often. This is why backlogs survive dashboards, escalations, monthly reviews and a rebuilt reporting stack, all of which improve visibility of work that still has no addressee.

The structural cause is simple enough to state. A scanner emits findings keyed to an artefact: an image digest, a repository path, a package coordinate. Ownership is a property of a deployment: this team runs this service in this environment and is on call when it breaks. Nothing in the toolchain maintains the mapping between those two things, so it gets reconstructed by hand, badly, once per finding.

The security team owns the number, not the code

The usual arrangement makes a security function accountable for the backlog. That function cannot merge a change to a service it does not build. What it owns is the count, and the only levers it holds over the count are reporting, escalation and asking. So the work it does is producing pressure, and pressure applied to an unrouted queue produces meetings.

This is worth separating precisely, because the two are constantly conflated. Owning the finding means deciding whether it is real and what should happen to it. Owning the fix means shipping the change. A programme where one group has both halves of the first and none of the second will stall regardless of how good its triage is. The distinction, and how to write it down so it survives a reorganisation, is the subject of our guide on who owns a security finding.

Four ways ownership dissolves in practice

Layer confusion. A container image finding against an operating system package is not fixable by the application team. They did not choose that package, they cannot patch it independently, and their only available action is rebuilding on a newer base that someone else has to publish. Routed to them, the finding sits. Routed to the platform team, it is one change that closes hundreds of findings at once. Getting that split right is most of the work in triaging container image findings.

Transitive dependencies. Nobody chose the package. The fix is either a version bump of the direct dependency that pulls it, which may not exist yet, or a resolution override, which is a decision with a compatibility cost. Assigning this to a service team without telling them which of the two you want produces a ticket that gets reopened three times.

Assignment by git blame. The heuristic of assigning to whoever last touched the file is popular because it is automatable. It routes findings to the person who most recently formatted a function, punishes contribution, and misses entirely on files nobody has edited in two years, which is where the findings concentrate.

Orphaned artefacts. Images still running, built from repositories with no active team, owned by a group that was restructured. These findings are permanent, and they distort every metric that includes them. They are also not really security findings. They are a decommissioning decision that nobody has been asked to make.

Who can actually fix what

Finding class	Who can actually fix it	What they need to act
CVE in an OS package from the base image	Base image owner, usually platform	A rebuilt image and a rollout path for consumers
CVE in a direct application dependency	The service team	A version bump and passing tests
CVE in a transitive dependency	The service team	A stated preference: wait for upstream, or override the resolution
Insecure default in a shared IaC module	The module owner	A module change plus a consumer migration plan
A credential committed to git history	Whoever can rotate that credential	Rotation authority, which the committer rarely has
Finding on an artefact no team claims	Nobody, until the catalogue is corrected	A decommissioning decision

The credential row is the one that most often goes wrong. Findings get assigned to the author of the commit, who can delete the line and cannot invalidate the key. The person who can rotate it works in a different team and does not read that queue, so the secret stays live while the finding shows as resolved. The correct sequence starts with rotation and treats history rewriting as optional cleanup, which we set out in what to do after a secret leaks in git.

Derive ownership from what is running

The fix is not a better assignment rule. It is an authoritative answer to a question the organisation currently cannot answer: for this running artefact, which team is accountable. That mapping has to be produced by the deployment process rather than maintained as a document, because a document goes stale silently and a deployment label does not.

1. Enumerate what is actually running, from the registry and the orchestrator rather than from a spreadsheet or a CMDB. The gap between the two lists is usually the interesting part.
2. Require an owning team identifier at deploy time, as a label or annotation, and reject deployments without one. Team, never an individual, with the on-call rota as the tiebreak.
3. Split findings by layer before routing anything. Base image, platform configuration, application dependency, application code. Four queues with four owners beats one queue with none.
4. Give every queue a default owner and an explicit decommissioning path. An unclaimed artefact escalates to whoever operates the platform, and the default resolution is switching it off rather than patching it. This makes ownership self-correcting, because unclaimed things stop running and stop generating findings.
5. Measure time to route separately from time to fix. They have different causes and different remedies. A long routing time is a catalogue defect. A long fix time is a capacity or prioritisation question.
6. Report the unrouted count and the aged-routed count instead of the total. Those two numbers name a responsible party; a total does not, which is the argument in why finding counts are the wrong metric.

Step two is where most attempts fail, because it requires a deployment gate and therefore agreement from teams who did not ask for one. It is also the only step that keeps working after the initial mapping exercise, and building it into pipelines rather than into a policy document is a large part of our DevSecOps implementation work.

What to do next

Take the fifty oldest items in your backlog and mark each one with the team that could actually merge the fix. Not the team it is assigned to, the team that has commit access to the thing that needs changing. Count how many you cannot fill in. That number is the real size of the problem, and it will be larger than anyone expects. It also tells you which to build first: a catalogue, or capacity.