Vulnerability ownership

Security vulnerabilities don’t belong to anyone — until they do.¹ They live in the gaps between bad code, flawed design, and third-party dependencies. They’re valuable to attackers, expensive for defenders, and risky for businesses. We pay bounties to find them, engineers to fix them, and incident responders when we don’t.² But internally, the hardest part isn’t detection or remediation, it’s this: who owns the fix?

Teams tend to take one of three approaches to vulnerability ownership. In the simplest approach, a team that introduces a vulnerability owns that vulnerability. They have enough knowledge on their team to fix the vulnerability, and are entirely responsible for every stage of the vulnerability lifecycle. Alternatively, security vulnerabilities are treated as a special kind of bug that a separate team should always review. Teams implement fixes, since they understand the code, but all other parts of the process are handled by a separate security group. Last, teams sometimes take a consultancy approach, where teams are responsible for their own vulnerabilities, but can request help in dealing with them. Let’s consider the outcomes of each.

Let’s take on ownership by teams first. They know their code best, so who better to fix it? Engineering teams often run like micro-economies within a larger corporation.³ They have their own incentives, resource limitations, and deliverables. So why not embed security engineers on each team?

When a team creates a new feature, their success is typically measured by the speed, efficiency, and impact of its deployment to production. Fixing security vulnerabilities along the way introduces an opportunity cost that often feels greater than addressing a typical bug—because the risk of leaving a vulnerability unfixed is rarely measured or immediately visible. The challenge of the embedded model is holding this standard against other priorities.

There’s one other problem here. Teams change. People leave. Reorgs happen. Does anyone know what team is now responsible for a bug created by a team that no longer exists? Is anyone likely to throw up their hand when they have other critical priorities? In the worst failure state, security bugs pile up in backlogs, never to be considered again.

Then, there’s the opposite approach – task a specialized team of security engineers to handle the vulnerabilities. Engineers on the product team are typically still involved with the fix, but all other elements are handled by a separate team. This approach assumes security vulnerabilities are a separate class of bug, and requires focused expertise and hands-on attention. When they are found, they go to a separate team, who analyzes them. Fixes must be approved as well. And perhaps, given the risk involved in security bugs, this level of attention is warranted.

However, here, you can easily wind up with a time-old problem at tech companies: siloing and inefficiency. Security engineers become the bottleneck, both before and after the fix. Given their involvement in approval, they also can become a convenient way to shake tickets that teams aren’t measured on and want to offload.

Worse yet, this approach can lead to a team losing ownership over the security of their own features and software.⁴ Team members may not feel responsible for introducing vulnerabilities, because most of the process is hidden from them. If no one is fully responsible for them, they may never gain the shared knowledge of how these vulnerabilities work in the first place. This can perpetuate a culture where security is an afterthought, and vulnerabilities pile up over time.

One potential solution is to think of a security team more as a consultancy. They’re not a gatekeeper, and they’re not the ones fixing everything directly. Instead, they offer expertise, context, and structured help. Security engineers are judged based on the results they deliver, but ultimately product teams themselves remain responsible for the security of their own products.

In this model, when a vulnerability is discovered, the engineering team still owns it: triage, fix, and follow-through. If the team is confident in their understanding, they proceed. But if they’re not sure about the scope, severity, or fix path, they request help from the security consultancy. That help might take the form of:

• Threat modeling or architectural guidance
• Secure code review or pairing sessions
• Remediation patterns or reusable code modules
• Risk analysis and escalation support
• Direct coding assistance

Importantly, this support is opt-in and scoped. The security team doesn’t automatically get pulled into every vulnerability, and they don’t block the path to resolution. Their involvement must be requested, and it’s their responsibility to deliver value in return.

The consultancy approach keeps ownership with the product team while still making security expertise available. It also incentivizes better security decisions. Teams are encouraged to think early and clearly about risk, knowing they’re accountable. Meanwhile, security engineers stay focused on scalable impact by building capabilities, rather than absorbing backlog.

Like the embedded model, the consultancy model’s primary challenge is maintaining high security standards on product teams. In its most scaled-up version, a consultancy could be paired with providing dedicated security engineers on each team, who rotate over time. This provides both direct security expertise for every-day issues, while still providing backup when needed.

The consultancy model isn’t without risks. If teams underestimate the severity of a vulnerability or delay requesting help, critical issues can slip through the cracks. Without clear engagement criteria or shared visibility, the security team may struggle to prioritize requests or spread themselves too thin. To succeed, the consultancy model requires strong relationships, reliable tooling, and a clear understanding of when and how to engage security, not only during emergencies but also as a proactive partner.

At its best, the consultancy model transforms security from a blocker into a trusted partner. It avoids the inefficiencies of central bottlenecks and the drift of full decentralization. And critically, it creates a culture where teams manage risk, rather than offloading it.

No matter which model your organization uses, what gets measured is what improves, and measurement is how we sustain it.⁵ Security must be treated as a core engineering value — not just an exception process.

Teams should track basic metrics like:

• Time to remediate vulnerabilities
• Percentage of vulns fixed vs. deferred
• Recurring issue rate
• Frequency of security engagements or reviews

These can be woven into sprint reporting, OKRs, or even retros. The goal is to create accountability with support, and ensure that security improvements are visible, prioritized, and celebrated.