Who owns a security finding?
Not the security team, who cannot fix code they did not write, and not whichever developer happened to be merging when the scanner fired. Both defaults produce the same outcome, which is a queue that grows until everyone agrees to ignore it. Handling a finding involves three separate roles, and most dysfunction in a DevSecOps programme comes from one group holding two of them or from nobody holding the third.
Why does putting security in charge of findings fail?
Because the security team becomes a queue rather than a decision maker. Every finding lands with a group that cannot change the code, so their only available actions are to chase, to escalate, or to fix it themselves in a codebase they do not know. The first two consume the relationship, the third produces changes nobody wants to review, and all three scale badly against a backlog that grows with every dependency update.
The opposite default fails differently. Pushing every finding to the developer who was merging asks someone in the middle of unrelated work to judge exploitability, decide severity in your environment and choose whether the release should proceed. That is not their expertise and it is not fair to ask, so it resolves into blanket suppression or blanket escalation depending on the individual's temperament.
The workable division separates three roles. The tooling decides what gets reported. Security decides what is worth acting on and by when. The team that owns the affected component does the fixing. When those three sit with three different parties the system self-corrects, because each one holds the other accountable for a decision it cannot make itself.
How does a finding get matched to a team?
Mechanically, from metadata that exists before the finding does. A container image finding is matched by tracing image to build to source repository to owning team. An infrastructure finding is matched by resource tag. A dependency finding is matched by the manifest it appears in. Every one of those chains needs to be complete, and the chain is what you build first, because a triage process with no routing is a person reading a list and guessing.
The most common break in the chain is between running workload and source repository. If your images do not carry a label recording the repository and commit they were built from, then a finding on a workload in production cannot be routed without human archaeology. Adding those labels is a small change to a build template and it is the single highest-value piece of plumbing in the whole programme.
The second most common break is a team directory that is out of date. Ownership recorded as an individual's name goes stale the moment they change roles, so record a team identifier that maps to a rota, and make the mapping a file in version control rather than a field in a tool. Then a reorganisation is a pull request rather than a data migration.
| Finding type | Owner | Why them | If unowned |
|---|---|---|---|
| Application dependency, reachable | The team that owns the service | They chose the dependency and can change the version | The service should not be in production, escalate that instead |
| Base image or operating system package | Platform team | The fix is a scheduled rebuild, not per-service work | Nominate a base image owner before enabling the scanner |
| Infrastructure misconfiguration | Whoever owns the resource by tag | The fix is a change to a definition they control | Untagged resources go to the account owner, and the missing tag is the finding |
| Secret in code or in an image layer | Security, immediately, then the owning team | The first action is rotation and it is time critical | Escalate to the credential's issuing system owner |
| Shared internal library | The library's maintaining team, then every consumer | One fix upstream saves many downstream | This is the classic orphan, assign it or fork the maintenance |
| A service nobody claims | The engineering manager for that domain | Only a manager can resolve an ownership vacuum | Treat undecided ownership as a decommissioning question |
What happens to the findings nobody owns?
They accumulate, and they are usually the ones that matter most, because unowned components are also unmaintained ones. Every estate has an internal library whose author left, a service that runs a scheduled job nobody has looked at in two years, and a base image inherited from a platform project that ended. Findings against these sit in the backlog forever, and their presence trains everyone to read the backlog as noise.
The correct response is not to assign them to security or to the platform team by default, which is how a small team ends up maintaining forty services. It is to escalate the ownership vacuum itself, as a separate item, to the manager who can resolve it. Two answers are acceptable: a team takes it on, or it gets decommissioned. Neither answer is that it stays in production unowned.
Make this visible rather than routing around it. A count of production components with no current owner is a better indicator of security posture than any finding total, it is unambiguous, and it is the kind of number that gets fixed when reported because nobody can defend it.
The interim arrangement worth naming, since the alternative is pretending otherwise, is custodianship: a platform team holds an orphaned component with an explicit remit to keep it patched and nothing more, with an end date attached. That is honest and survivable. What fails is silent custodianship, where a team acquires forty services by never objecting and then cannot maintain any of them properly.
How does an escalation ladder work in practice?
Time-based and automatic, with each step adding visibility rather than pressure. A finding past its deadline appears in the owning team's own board. Past a second threshold it appears in a weekly list their manager sees. Past a third it appears in whatever forum reviews delivery risk. Nobody sends an email, and nothing depends on a security analyst having the energy to chase.
The design rule is that escalation moves the audience, not the owner. Reassigning a finding to a more senior person because it is overdue removes the incentive to fix it and creates a route by which anything unpleasant becomes somebody else's. The team stays the owner throughout, and what changes is who can see that it is late.
Escalation only works when the deadlines are defensible, which means starting the clock at fix availability and setting the window by exposure rather than by score alone. A ladder built on deadlines the team could never have met produces contempt for the ladder, and once that has happened it cannot be restored by tightening it.
What does the security team do in this model?
Four things that nobody else can. It decides what a finding means in your environment, which requires knowing the architecture and the threat picture rather than the codebase. It sets and defends the deadlines. It owns the exception process, including saying no. And it maintains the detection tooling itself so the pipeline keeps producing accurate results.
It also owns the parts of the discipline that are not findings at all: threat modelling new designs, testing business logic no scanner understands, and running incidents. Those are the activities with the highest return per hour of specialist time, and they are exactly what gets crowded out when the team is used as a triage queue.
A useful test of whether the model is working is where the security team's hours actually go. If most of them are spent gathering information, chasing owners and re-explaining findings, the routing metadata is missing and the fix is plumbing rather than headcount. Try it this week: pick ten open findings and see how many can be routed to a current owning team from stored data alone, without asking anybody.
Common questions
- Who should own security findings in a DevSecOps model?
- Three parties, holding three separate roles. The tooling decides what is reported. The security team decides what is worth acting on and by when, and owns the exception process. The team that owns the affected component does the fixing. Problems appear when one group holds two of these roles, most commonly when security is expected both to prioritise findings and to remediate them in code it does not own.
- How do you route a security finding to the right team automatically?
- From metadata that exists before the finding does. Container findings route by tracing image to build to source repository to owning team, which requires image labels recording the repository and commit. Infrastructure findings route by resource tag. Dependency findings route by the manifest they appear in. Record ownership as a team identifier mapped to a rota in a version-controlled file, not as an individual's name in a tool.
- What do you do with findings on components nobody owns?
- Escalate the ownership vacuum as its own item to the manager who can resolve it, rather than assigning the finding to security or the platform team by default. Only two answers are acceptable: a team adopts the component, or it is decommissioned. A count of production components with no current owner is a stronger posture indicator than any finding total, because nobody can defend the number.
- Should overdue findings be reassigned to someone senior?
- No. Escalation should change who can see that a finding is late, not who owns it. Reassigning upwards removes the incentive to fix and creates a route by which anything unpleasant becomes someone else's problem. Automate the visibility instead: the team's own board, then a weekly list their manager sees, then the forum that reviews delivery risk, with no analyst having to chase.
- What should a security team spend its time on instead of triage?
- Deciding what findings mean in your specific environment, setting and defending deadlines, owning the exception process, keeping the detection tooling accurate, and the work no scanner can do: threat modelling new designs, testing business logic, and running incidents. If most of the team's hours go on gathering information and chasing owners, the routing metadata is missing and the remedy is plumbing rather than more people.
- Who owns base image and operating system vulnerabilities?
- The platform team that owns the image pipeline, because the fix is a scheduled rebuild on a current base rather than per-service work. Routing those findings to individual service teams creates the same task many times over and interrupts developers who cannot fix anything faster than the rebuild would. Nominate a base image owner before enabling the scanner, since these findings are the highest volume category by a wide margin.
