Your dependency findings route to code owners, but reorgs leave some unowned — how do you keep the program accountable?

## The pathology A finding is created and assigned to a team. The team was dissolved in a reorganisation six months ago; its distribution list still exists and nobody reads it. The finding shows as assigned, which on most dashboards renders the same as being worked. It never breaches, because nobody notices it to breach. Meanwhile the service it describes is still running, still deployed, still reachable, and still carrying the vulnerable dependency. This is a governance failure disguised as a tooling detail. It matters more than most because it is *silent by construction*: every other failure in a vulnerability program produces noise, and this one produces quiet. ## Three root causes worth separating **Ownership is stored rather than derived.** The team name is copied into the finding at creation. From that instant it is a stale snapshot. Any assignment stored at creation time is wrong as soon as the org chart moves, and org charts move constantly. **There is no rejection path.** If the only actions available are "fix" and "close", a wrongly-routed finding either becomes someone's unwanted work or gets closed to clear the queue. Neither is the truth, which is "not mine, and I do not know whose". **There is no owner of last resort.** Every finding needs a human with a name who is accountable if nobody else claims it. Without that role, unclaimed work has no destination and defaults to nothing. ## The design that holds up **Derive ownership at display time.** Resolve the owning team from a live source — the service catalogue, code ownership metadata on the declaring manifest — every time the finding is rendered or reported. Live sources are the ones maintained for other reasons, which is what keeps them true. If the catalogue is itself stale, fix that first: it is the substrate everything else depends on. **Make unowned a state, not an absence.** When resolution fails, the finding lands in an explicit unowned queue, visibly, with its remediation clock still running. The clock is the important part: pausing it while ownership is sorted out means the estate's most neglected assets record the best numbers. **Give rejection a first-class meaning.** A team can reject a routing with a reason, and rejection returns the item to the unowned queue rather than closing it. Only a team that has *accepted* ownership can suppress, defer or close. This separates "this is not my problem" from "this is not a problem", which is the confusion that puts unowned findings in the closed bucket. **Name the owner of last resort.** Someone senior enough to reassign across organisational boundaries holds the unowned queue — often the engineering leader over the affected area, with the security program driving the review. Their job is not to fix the findings; it is to produce owners for them, or to decide the service is decommissioned. **Make ownership part of the reorg and decommission checklists.** A service whose team is dissolved gets an owner or gets turned off. Treating decommissioning as a legitimate remediation is one of the highest-leverage moves available: unowned services are frequently unused ones, and turning one off closes every one of its findings permanently and at zero upgrade risk. ## What to measure - **Auto-resolution rate** — the share of findings whose owner resolves to a live team without human intervention. Falling means the catalogue is decaying. - **Time to acknowledgement** — creation until a named human accepts ownership. This is the part of the interval that unowned findings live in, and it is invisible in any metric that only counts creation-to-close. - **Unowned queue age** — the oldest item's age, not the count. A persistently empty unowned queue almost never means every service has a live owner; it usually means unresolvable ownership is being papered over by a default assignment. - **Rejection rate by team** — a spike says the routing rule for that area is wrong, which is a signal you only get if rejection is a supported action. ## The organisational tradeoff The underlying question a principal is really being asked is who pays. Two models, and the answer is usually a split: Central remediation works for shared substrate — internal libraries, shared platform templates, common base configurations — where one fix fans out across the estate and the central team has the context to test it. Distributed remediation is the only honest model for application-level direct dependencies, because upgrading them requires knowing whether the application still behaves, and a central team cannot know that. Fund the fan-out, push the long tail, and be explicit that the unowned queue is *not* the central team's backlog — it is a routing problem escalated to leadership, and treating it as work the security team absorbs is how a security team ends up owning several hundred services it cannot change. Finally, resist the instinct to report the unowned queue as an embarrassment to be minimised. It is the program's most valuable signal: it names exactly where the organisation's map of itself has stopped matching what it is running.