Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A critical finding on the checkout service has been open for weeks, and the only comment on it asks whose service this is. This post shows how to answer that question from the graph you already have, set deadlines by exposure, and close findings on scan evidence rather than ticket state.
Vulnerability ownership is the link between a finding and the team able to fix it. Derived from the graph that connects repository, commit, build, image and workload, using CODEOWNERS, commit authors, build metadata and namespace labels, it can stay current when those sources are maintained and refreshed.
Vulnerability ownership, not detection, is where findings stall
The scanner did its job the day it found the flaw. What decides whether the vulnerability gets closed is whether the finding reaches someone who can act on it. The checkout finding landed in a shared security queue, was triaged once and assigned to a generic bucket, and no team ever treated it as theirs. Nobody decided it was not worth fixing; nobody decided anything.
Ownership ambiguity is not a minor friction. A finding with no owner appears in no team’s sprint planning, on-call rotation or service review, so it ages quietly until a later review surfaces it as an overdue critical. The usual remedy is a spreadsheet mapping services to teams, and it rots the moment a repository is renamed, a team is reorganised or a workload moves namespace. In this case, checkout changed teams in a reorganisation and the spreadsheet still names the old one.
Derive vulnerability ownership from the graph you already have
The data needed to answer “who owns this” usually exists, just not in one place. The checkout repository has a CODEOWNERS file. The commit that last touched the vulnerable line has an author, and that author belongs to a team. The build pipeline knows which service produced the image, and the running workload sits in a Kubernetes namespace that maps to a team by label or convention.
Connect the finding to the entity graph that links repository, commit, build, image and workload, and ownership can be read from whichever node carries the strongest signal. For the checkout finding, CODEOWNERS and the namespace label agree on the new team, and the finding routes there directly. Where signals conflict, for example on a shared base image maintained by a platform team, the graph shows both candidates and the reason for each, so the choice is explicit rather than silent.
The result is more accurate than a spreadsheet for a simple reason. It is derived from the same commits, deployments and infrastructure state that change when reality changes, so a reorganisation, a repository transfer or a redeployment is reflected without anyone remembering to update a mapping. The same idea underpins an ASPM finding graph, where one model replaces several disconnected queues.
Remediation deadlines should follow exposure
Ownership says who should fix a finding. Urgency should follow a related but separate signal: exposure. The checkout service sits behind an internet-facing ingress and handles payment data, while the same library flaw in an internal reporting job with no external reachability deserves a materially longer window.
Static SLA tables that assign one deadline to every critical, wherever it lives, fail in one of two ways. Either teams spend urgency on internal, low-exposure findings or, more often, they learn the table does not reflect risk and quietly ignore it. An SLA that reads exposure from the same graph, asking whether the workload is internet-facing, handles sensitive data or is reachable from an untrusted network, gives the owning team a deadline it can trust is proportionate. Proportionate deadlines are the ones teams actually meet. For how reachability and exposure rank the queue in the first place, see risk-based vulnerability management.
One logical finding spans repo, image and workload
The checkout vulnerability did not appear once. It showed up as a taint result at a line in the repository, as a package match in the image that repository builds, and as an exposure signal on the running workload that image became. Treated as three findings, it triples the noise and invites someone to close one instance while the other two linger, unrecognised as the same problem.
Treated as one logical finding traced from the repository line through the image layer to the running workload, its status stays coherent. Fixing the source and rebuilding the image addresses all three observations together, and the finding reaches its true end state only when the workload stops showing it. That depends on knowing which image runs where, the problem image-to-workload binding addresses.
Close findings on scan evidence, not ticket state
A ticket marked resolved records a person’s belief, not the state of the system. Tickets close because someone believed a fix landed, because a sprint ended and the backlog was bulk-closed, or because a dependency bump looked as if it should have removed the CVE. None of these proves the vulnerability is gone.
The reliable signal is re-observation: a successful scan of the same scope can support a lifecycle update when it no longer detects the issue. Failed or partial scans are not proof of remediation. That criterion ignores what the ticket says, reopens automatically if a regression reintroduces the flaw, and needs nobody to remember to re-verify. The ticket still tracks the work, who is on it and what the plan is, but the next scan contributes evidence; deployment verification is still needed to establish whether checkout is fixed in production.
Key takeaways
- Replace the ownership spreadsheet with ownership read from CODEOWNERS, commit authors, build metadata and namespace labels.
- Set remediation deadlines from workload exposure rather than from severity alone.
- Track each vulnerability as one finding from repository line to running workload.
- Distinguish source remediation, verified deployment, accepted risk and scope removal in the closure record.
How SecurityVault approaches this
SecurityVault uses available repository, team and workload context to support ownership routing. Ownership sources need maintenance, and gaps or conflicts need review. Successful re-scans can update eligible finding lifecycle states within matching scope, while human-held decisions are preserved. Source remediation, deployed remediation and scope removal must remain distinct outcomes.
Test a service with a known owner, a shared base image and an asset with conflicting ownership signals. Review the proposed routing with the teams that would receive the work. Change a maintained ownership source, refresh the relevant data and inspect the result. Then compare a successful re-scan with an incomplete one. This establishes whether assignment and lifecycle changes remain explainable, and gives teams a process for resolving ambiguity before a high-priority finding spends weeks in a queue that nobody recognises as theirs.
Explore Remediation and SLAs or talk to our team about an evaluation with your engineering, security and compliance stakeholders.