Who would be fired if a CVE in their container was exploited?
The increase in the use of containers and the consequent challenge of managing vulnerabilities (CVEs).
CEO
Diogo Goebel
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 uncomfortable as it is, has the power to instantly point out one of the biggest security issues in companies today: the uncertainty about who manages CVEs in containers.
There is a "passing the buck" of container vulnerabilities within companies. The responsibility for the security of container images often divides between security, developers, and operations teams, each assuming that 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 in containerized environments, where the absence of a clear responsible party results in prolonged exposure to known risks.
The lack of specific metrics to remediate container vulnerabilities exacerbates the problem: teams are evaluated by delivery speed, system availability, or overall compliance, but rarely by CVEs resolution time. This dissociation between responsibility and performance measurement results in systematic negligence, 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 nobody's.
In managing CVEs in containers, the myth of shared responsibility creates an operational limbo. Security, DevOps, and infrastructure know that vulnerabilities need to be fixed, but each team assumes that the other is taking care of the problem. Meanwhile, the dispute for priorities in the backlogs delays critical fixes, prolonging the aging of vulnerabilities and widening the window of exposure to attacks. Without a clear responsible party, CVEs remain unfixed 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 clarify who leads, who executes, and which metrics ensure that CVEs do not remain forgotten.
A realistic DevSecOps model
DevSecOps needs to be more than a theoretical ideal; it must work in practice, without overburdening 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 generating unnecessary friction. Secure base images (near-zero CVEs) and pre-approved images eliminate vulnerabilities even before the code is 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.
The shift-left plays an important role, but 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: Who is responsible for CVEs, after all?
Like many things in IT, the answer may vary depending on the culture and structure of each company. But one thing is non-negotiable: there must be a clear responsible party. When no one formally assumes this role, vulnerabilities remain unaddressed, increasing risks to 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 overburdening teams or creating operational bottlenecks.
Recommended Contents
With Quor, security becomes your competitive edge. See how in a personalized demo.