Ask who owns a vulnerability and you will usually get two answers at once. Security says the developers own it, because they own the code. Developers say security owns it, because security found it. Both are partly right, and the finding sits in the gap between them until it breaches its SLA, or until someone exploits it.
In short
- Ownership has to be decided before the finding exists. Map every repository, image and cloud account to a team; findings inherit the owner automatically.
- Split the work, not the accountability. Security owns the policy, the priority and the verification. The owning team owns the fix and the date.
- SLAs only work with an exception process. Every dismissal needs a reason, every snooze needs an end date, and long-term risk acceptance needs a named approver.
- Platform teams own shared fixes. A base image or a shared library should be fixed once, centrally, not by fifty product teams separately.
Three teams, one finding
Most organisations have three groups with a hand on a vulnerability. The security team (AppSec, cloud security, the CISO’s office) sets policy and runs the tooling. Product engineering teams own services and the code in them. Platform teams own the things everybody builds on: base images, CI pipelines, shared libraries, the cloud landing zone.
A vulnerable package in a base container image is a good test. Security’s scanner reports it in fifty services. Fifty product teams each get a ticket. Forty-eight of them cannot fix it, because the fix is in the base image, which a platform team owns. The right answer is one finding routed to one team, and fifty services that inherit the fix when they rebuild.
or its direct dependencies"| P["Product team
owns the fix"] Q -->|"In a base image, shared library
or pipeline template"| PL["Platform team
owns the fix"] Q -->|"In cloud configuration
or identity policy"| C["Cloud or platform team
owns the fix"] P --> S["Security verifies
on the next scan"] PL --> S C --> S
Route the finding to whoever can change the thing that fixes it, not to whoever runs the affected service.
A RACI for the vulnerability lifecycle
A RACI chart (Responsible, Accountable, Consulted, Informed) is unfashionable, but for vulnerability management it removes most of the arguments. This is a starting point; adapt the columns to your own organisation.
| Activity | Security team | Product team | Platform team | CISO |
|---|---|---|---|---|
| Set the priority model and SLAs | R | C | C | A |
| Map assets to owning teams | R | A (confirms) | C | I |
| Set business context (exposure, data, criticality) | C | A/R | C | I |
| Run scanning and correlation | A/R | I | C (CI integration) | I |
| Triage: confirm or dismiss | A/R | C | C | I |
| Fix in service code and direct dependencies | C | A/R | I | I |
| Fix in base images, shared libraries, pipelines | C | I | A/R | I |
| Verify the fix | A (automatic rescan) | I | I | I |
| Approve risk acceptance beyond SLA | R (recommends) | R (requests) | C | A |
| Report to the board | R | I | I | A |
The important line is the second one. If ownership is assigned when a finding appears, every new finding starts with an argument. If it is assigned to the asset in advance, every finding on that asset inherits an owner, and the argument happens once.
The lifecycle, step by step
Security finds, prioritises and verifies. The owning team fixes or asks for an exception. Nothing closes on someone's word alone.
Two details in that sequence matter more than they look. First, a finding is marked fixed by the next scan, not by a person. Ticket systems close when someone says the work is done; vulnerability management should close when the evidence says it is gone. Second, the exception path is part of the process, not a failure of it. Some findings genuinely cannot be fixed inside the SLA, and a process without a legitimate way to say so gets worked around.
SLAs that teams can actually meet
An SLA is a promise the organisation makes to itself about how long a known risk may stay open. It is only credible if the volume it applies to is manageable. That is why prioritisation comes first: an SLA of seven days on every “critical” is unachievable when half of everything is critical. An SLA of seven days on known-exploited, reachable findings is achievable, because there are few of them.
| Priority | Default SLA | Typical content | Escalation if missed |
|---|---|---|---|
| P1 | 7 days | Known exploited, reachable, on exposed or sensitive systems | Security lead at breach; CISO at 2× SLA |
| P2 | 30 days | High likelihood or high impact, but not both | Security lead at breach |
| P3 | 90 days | Real but limited: internal, mitigated, or low likelihood | Team review at quarterly planning |
| P4 | 180 days | Hygiene: test code, dev-only dependencies, informational | None; fix opportunistically |
These are the defaults in InsightFortify and they are deliberately conventional. You can change them per organisation. What matters more than the exact numbers is that they are written down, agreed with engineering leadership, and applied to a list short enough to meet.
Exceptions: the part most programmes get wrong
There are three legitimate reasons not to fix a finding on time, and each needs a different mechanism.
| Situation | Right mechanism | What must be recorded |
|---|---|---|
| It is not real: a false positive, or the code is never deployed | Dismiss | The reason, and who decided. Kept and auditable; never deleted. |
| It is real but cannot be fixed yet: no patch, a release freeze, a dependency upgrade that needs planning | Snooze with an end date | The reason, the date, and the plan. Once the date has passed, the next scan that still sees it reopens it. |
| It is real and the business chooses to live with it | Risk acceptance, approved by the CISO or a risk committee | The business owner, the compensating controls, the review date. |
Watch for snoozes that become permanent
A snooze renewed every quarter is a risk acceptance nobody signed. Review long-running snoozes in the quarterly cycle and either fix them or formally accept them.
Security champions
The most effective lever on ownership is not a process. It is a person in each engineering team who understands the priority model, can triage the team’s own findings, and is the first call when security needs something. Champions are usually volunteers given a small time allocation, some training and recognition. They turn “security’s tickets” into the team’s own work.
Every repository, production image and cloud account the tooling sees.
Use your service catalogue if you have one. Unowned assets are a finding in themselves.
Internet-facing, data classes, criticality, compensating controls. Thirty minutes per team, once.
Written down, signed off, published where every engineer can find it.
One person, a few hours a month, with a direct line to AppSec.
Only now do overdue numbers mean anything.
Roles in the tool
InsightFortify maps these responsibilities to four roles. Security lead manages repositories, policies, SLAs and settings. Security analyst triages: confirm, dismiss, snooze, reopen and assign. Developer reads findings and works on the ones assigned to them. Auditor has read-only access, including the audit trail of every triage decision. Each dismissal and snooze keeps who made it and why.
For the CISO
Ownership is a design decision you make once, not a negotiation you have per finding.
You are accountable for the exception process. If it is too hard to use, people will work around it.
For the AppSec lead
Route to whoever can change the thing that fixes it. Base images and shared libraries go to the platform team.
Let the next scan close the finding, not the ticket.
For the board
Ask how many findings have no owner, and how many exceptions are past their review date.
A programme with a working exception process is more trustworthy than one that claims to fix everything.
A vulnerability without an owner is a vulnerability nobody will fix.
Assign owners to assets in advance, split the work clearly, and give every exception an end date.