Who would get fired if a CVE in their container were exploited?

In a world where 87% of container images in production contain critical or high vulnerabilities, an uncomfortable question emerges: who would be held accountable, or even fired, if one of these flaws were exploited in an attack? This question, as unsettling as it may be, has the power to instantly point out one of the biggest security problems in companies today: the lack of definition regarding who manages CVEs in containers.

There is a "passing the buck" game regarding container vulnerabilities in companies. Responsibility for container image security is frequently split among security, development, and operations teams, each assuming the other is taking care of the problem. 

This fragmentation creates a perfect environment for critical vulnerabilities to remain unaddressed; after all, when everyone is partially responsible, no one is truly responsible. In conversations with clients and partners, we consistently observe this division as a significant challenge in security within containerized environments, where the absence of a clear owner results in prolonged exposure to known risks.

The lack of specific metrics for remediating container vulnerabilities worsens the problem: teams are evaluated on delivery speed, system availability, or overall compliance, but rarely on CVE resolution time. This decoupling of responsibility from performance measurement results in systematic neglect, where known vulnerabilities persist indefinitely in production environments.

The myth of shared responsibility in vulnerability management

The concept that “security is everyone's responsibility” sounds inspiring. But in practice, without well-defined roles and effective governance mechanisms, this belief becomes a problem: when something is everyone's responsibility, it often ends up being no one's responsibility.

In container CVE management, the myth of shared responsibility creates an operational limbo. Security, DevOps, and infrastructure know that vulnerabilities need to be patched, but each team assumes the other is taking care of the problem. Meanwhile, the dispute over priorities in backlogs postpones critical fixes, prolonging vulnerability aging and widening the window of exposure to attacks. Without a clear owner, CVEs remain unpatched for weeks or months, increasing risks, operational costs, and even regulatory penalties.

Security can be shared, but responsibility cannot be diffuse. Companies that handle this problem well do not eliminate collaboration, but they make it clear who leads, who executes, and what metrics ensure that CVEs are not forgotten.

A realistic DevSecOps model

DevSecOps needs to be more than a theoretical ideal; it must work in practice, without overloading teams or creating barriers to development. Security cannot simply be pushed onto developers as an extra responsibility, but rather integrated into the workflow efficiently.

A realistic model structures security as part of the development process without creating unnecessary friction. Secure and pre-approved base images (near-zero CVEs) eliminate vulnerabilities before code is even written. Automation in CI/CD allows vulnerabilities to be identified and addressed without impacting delivery speed. Centralized policies and automated enforcement ensure that security requirements are applied consistently, without relying on individual decisions or causing operational delays.

Shift-left plays an important role, but it should be used as a strategic complement—allowing developers to have more visibility into security without compromising delivery or requiring advanced expertise in the area.

Conclusion: Whose responsibility are CVEs, anyway?

As with many things in IT, the answer may vary depending on each company's culture and structure. But one thing is non-negotiable: there must be a clear owner. When no one formally assumes this role, vulnerabilities remain unpatched, widening the risks for the business.

The most resilient companies adopt a hybrid model: security is shared, but with well-defined roles and processes. This means combining automation, policy enforcement, and structured practices to integrate security into the software lifecycle, without overloading teams or creating operational bottlenecks.

Recommended content

• The Challenge of Vulnerability Management [CVEs]: Insights from Getup Customers.

• Up to 90% reduction in CVEs - early access.