 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Administrators and architects aren’t the only ones who feel the pinch if there’s a security issue in Kubernetes, or with a container. Today’s microservices and cloud-based distributed architectures offer the benefits of resilience and scalability, but they come with the trade-off of tremendous interdependency.
Everything is interdependent in the cloud, and building more secure software inside of Kubernetes is not just a matter of keeping an up-to-date OS image and virtual machines available. Containers are different beasts, and with the velocity they bring to the development life cycle, slowing down the flow of innovation with security constraints and processes will only anger everyone involved.
👁 Graphic on question on deployment slowdowns.
Red Hat’s state of Kubernetes security report includes responses from 600 IT professionals working at companies that use Linux containers in production. Over half of those respondents worked at companies with over 1,000 employees. Thus, the ensuing report is heavily focused on enterprise use of Kubernetes at scale for business workloads and applications.
The findings from this study show that containers present their own challenges to application developers, security professionals and IT administrators. Perhaps this is why 67% of those surveyed said that they had delayed or slowed down application deployment into production due to security issues with containers or Kubernetes.
Scary? According to those surveyed, deployment delays may be the best-case scenario. While 53% of respondents said they had to delay a project in the past 12 months due to Kubernetes and container security concerns, 46% said they lost revenue or even customers due to these concerns. Even worse, 30% of respondents had to pay fines or faced legal action due to these breaches. A further 26% had to terminate an employee.
👁 Graphic on concerns about container strategy
Why is this happening? Isn’t security a major concern for every business on the planet? Why is Kubernetes presenting a challenge here? According to 42% of those surveyed, the reason is that their companies are not sufficiently dealing with container security.
That number can be divided into two subgroups: the 23% who feel their companies do not sufficiently address container security threats with their security strategies, and the 19% who feel their employers are not investing enough in the problem.
This issue extends further into many of these organizations than simply the budget or architectures. When asked who was most responsible for Kubernetes and container security within their organizations, only 34% of respondents said it is their security teams’ responsibility — leaving over 50% to respond that it is the IT teams’ responsibility. Parsing that number more fully, only 15% of those in the survey placed the job with their DevSecOps teams. Another 16% said their developers were responsible for container and Kubernetes security inside their organizations.
👁 Graphic on question about DevSecOps initiatives
With that type of variance in how teams handle security for containers and Kubernetes, it’s unsurprising that integrating these technologies into the stack is causing delays and security concerns. Traditional IT has fairly clear lines of control for most aspects of the operation, from database admins to security people. And yet, over half of those in this survey have not yet pushed responsibility for security for containers and Kubernetes onto their security teams.
Naturally, the software supply chain is a big part of the security picture for businesses, and container and Kubernetes security play into that story as well.
Forty-four percent of respondents in this survey said software vulnerabilities are the highest-risk aspect of their software supply chains. That’s up 9 percentage points from last year’s survey, a clear sign that the software supply chain is becoming a more prominent part of the application delivery life cycle.
That view is bolstered by the fact that 57% of survey respondents who are worried about vulnerable application components said that their organizations had detected vulnerable application components in their software supply chain in the last 12 months.
One interesting finding of the report was that almost all of the concerns shown by those in the survey were based on actual experience rather than a theoretical threat. For example, though things like “lack of software bill of materials (SBOMs)” and “lack of automation” were cited as concerns by 26% and 30% of those surveyed, they were experienced by 59% and 56% of respondents, respectively.
Thus, some respondents have found ways to mitigate these risks. Forty-seven percent cite security attestations — such as image signing, deployment signing and pipeline attestation — as being the most important security aspect of a software supply chain. An additional 45% cite vulnerability scanning as the most important tool for software supply chain security.
The state of Kubernetes security report, sponsored by Red Hat Advanced Cluster Security for Kubernetes 2024, is available for free here.
