By 2029, more than 95% of global organizations will be running containerized applications in production, according to Gartner.  This is a significant increase from less than 50% in 2023. To address these challenges, Checkmarx has developed an innovative container security solution designed to secure your applications from development to deployment.

Let’s explore the real-world impact of our solution and highlight how it helped a leading cloud-based service provider enhance their own container security.

But first…What are containers

Containers are a type of virtualization technology that packages an application and its dependencies together. This allows the application to run consistently across different computing environments, regardless of the underlying operating system.  In simpler terms, imagine a container as a shipping container – it carries everything an application needs to run (code, libraries, settings), but remains isolated from the system it runs on (like the operating system on a server). This isolation ensures portability and security for the application.

While containers provide many benefits, they also introduce unique security challenges. For example, pulling container images from public registries can expose systems to malware and vulnerabilities. Using large base images is like carrying unnecessary baggage—they slow down operations and introduce extra vulnerabilities and limited visibility in managing containerized environments can hide security threats.

Containerization is popular when developing, deploying, and running microservices-based applications.  Microservices are small, independent applications that work together to form a larger application.    Containers are ideal for this because they isolate each service and make them easy to deploy and scale. Because containers offer efficient resource utilization and faster deployment times, it is easier for developers to build, test, and deploy applications rapidly.

Why securing containers is crucial

We know that it’s convenient to pull container images from public registries. Although it saves time, this practice can expose your systems to malware and vulnerabilities, since hackers often upload malicious images to exploit unsuspecting developers. Similarly, sensitive information like passwords or API keys can inadvertently find their way into container registries, leading to data breaches. Managing these secrets is crucial.

Another pitfall is relying solely on static image scanning tools. These tools are great for detecting known vulnerabilities, but often miss emerging threats or misconfigurations. This oversight can leave your containers exposed. The inherent nature of containers increases the attack surface compared to traditional applications. Developers must secure multiple layers, including container runtimes, orchestrators, and plugins, to mitigate these risks effectively.

Adopting minimal base images, updated regularly, can significantly reduce these risks. Limited visibility makes it challenging to detect and respond to issues in real time. Robust visibility and observability tools are essential in gaining deep insights into container workloads and implementing effective threat detection and response strategies.

While containers offer immense benefits, they also require security frameworks. Addressing issues like insecure image sources, exposed secrets, incomplete static scanning, an increased attack surface, bloated base images, and limited visibility can help secure your containerized environments. Staying ahead of threats ensures that you can harness the full potential of containerization without compromising on security.

Introducing our new Container Security solution

Checkmarx provides a new powerful container security solution that enhances team efficiency across the software development lifecycle. It empowers developers and security teams with the following benefits:

Comprehensiveness:  Checkmarx goes beyond static scanning, offering a rich set of features including image scanning, package inspection, vulnerability assessment, triage, remediation, results view, scan risk report, image breakdown, and Sysdig integration for runtime coverage.

Proactive Security: Early vulnerability identification and mitigation within the development process minimizes security risks in production.

Actionable Insights: Checkmarx provides detailed information about vulnerabilities, enabling developers to prioritize remediation efforts and act.

Ease of Use: The solution integrates seamlessly with existing workflows, minimizing disruption to development processes.

Diving into key container security capabilities

Let’s dive into some of our key container security capabilities:

Checkmarx’ container security approach starts with comprehensive image scanning. It examines every layer of an image—base image, software dependencies, and application code—to uncover vulnerabilities and threats. Constant updates to vulnerability databases ensure it identifies the latest threats.

Next, the solution inspects packages within container images. It performs checks like version control to confirm the use of latest secure versions and verifies licenses to avoid potential legal issues.

Finally, it offers detailed image breakdowns. Users can drill down into each layer of a container image to view vulnerabilities and package details. This granular view enables developers to pinpoint andaddress specific security issueseffectively. 

Vulnerability Assessment:  Checkmarx prioritizes vulnerabilities based on severity and provides detailed information about each one. This includes the CVE details, potential impact, and remediation guidance.

Triage:  This allows users to manage the severity, and status, of vulnerabilities for each project or application. They can update severity levels, change status (e.g., Verify, Not Exploitable), and maintain detailed audit trails for all actions taken.

Remediation: Checkmarx identifies vulnerabilities within container images and recommends alternative base images with a lower security risk profile. This approach helps developers choose more secure foundations for their applications.

Results View: This intuitive interface provides a detailed view of container image scan results. Users can see the distribution of vulnerabilities across different severities and analyze them based on runtime status.

Scan Risk Report:  Checkmarx generates comprehensive reports summarizing scan results, including the number of vulnerabilities and their severity. These reports can be downloaded in various formats (JSON, CSV, PDF) for further analysis and compliance purposes.

Final Thoughts

Checkmarx offers a comprehensive container security solution that empowers developers and security teams throughout the development lifecycle. By identifying and mitigating vulnerabilities early, Checkmarx helps organizations build secure and compliant containerized applications. The case study demonstrated how a cloud service provider achieved a significant reduction in vulnerabilities and improved security posture with Checkmarx.

As containerization continues to reshape software development, prioritizing container security is no longer optional. By leveraging solutions like the Checkmarx One Platform, organizations can unlock the full potential of this technology while ensuring the long-term security of their applications and data.

Ready to take the next step?

Visit our website to learn more about Checkmarx’s container security solution and download our free container security Enhancement guide. You can also request a demo to experience the solution firsthand and see how it integrates seamlessly into your development workflow.

Wondering what you should consider when picking a container security solution? These are six things important things you should keep in mind. 

Glossary of terms – Container Security

Attack Surface: The sum of all potential entry points that an attacker can use to gain access to a system. A larger attack surface means more vulnerabilities attackers can exploit.

Base Image: The foundation image upon which a container is built. It typically contains the operating system and essential libraries needed for your application to run. Choosing a minimal base image reduces the attack surface.

Container: A lightweight, self-contained unit of software that packages code and all its dependencies (libraries, configuration files) for deployment and execution. Imagine a shipping container for code, allowing it to run consistently across different environments.

Container Image: A template that defines the contents and configuration of a container. It’s like a blueprint for building a container with specific functionalities.

Container Registry: A repository that stores and manages container images. Developers can pull (download) images to create containers and push (upload) new images they’ve built. Think of it as a library for container images.

Container Security: The practice of protecting containerized applications and the infrastructure they run on from vulnerabilities, malware, and unauthorized access. It’s crucial to ensure the integrity and security of your containerized environment.

DevSecOps: An approach to software development that integrates security considerations throughout the entire development lifecycle (Dev), security operations (Sec), and IT operations (Ops). Container security is a key aspect of DevSecOps.

Exploit: A piece of code or script that takes advantage of a vulnerability to gain unauthorized access or cause harm. Exploiting vulnerabilities in containers can compromise your applications and data.

Runtime: The environment where containers are executed. Container security needs to consider both the security of the image and the runtime environment.

Static Image Scanning: A security analysis technique that examines container images for known vulnerabilities without running the container. It’s like checking the ingredients list of a meal for potential allergens before cooking.

Vulnerability: A weakness or flaw in software that can be exploited by attackers to gain unauthorized access or cause harm. Vulnerabilities in container images or underlying infrastructure pose a risk to container security.

Docker, an open-source platform that automates the deployment of applications in lightweight, portable containers, has impacted application development and deployment since its launch in 2013. Containers bundle an application with its dependencies, ensuring consistent operation across different environments. This addresses the common “it works on my machine” problem, making Docker an essential tool for developers and operations teams. Docker’s rise in popularity is due to its ability to simplify the deployment process, enhance scalability, and improve resource efficiency.

According to Gartner, by 2029, more than 95% of global organizations will be running containerized applications in production, which is a significant increase from less than 50% in 2023 (source: Sysdig 2023 Cloud-Native Security and Usage Report)

The Importance of Security in Containerization

Containers, by their very nature, package not just the application but also its dependencies, which can often include outdated or vulnerable software. Why does that matter? Vulnerable software can lead to a security breach, which could result in customer attrition, as clients might lose confidence in the company’s capacity to secure their information. Ensuring that these containers are free from vulnerabilities is critical to maintaining the integrity and security of the deployed applications. According to Red Hat, State of Kubernetes Security 2023 cloud-native technologies offer agility, faster time to market, and reliability. However, 67% of enterprises face deployment delays due to security concerns. Security incidents can lead to severe impacts, including employee terminations, fines, revenue loss, and eroded customer trust.

According to the same source, in the last 12 months, 66% of enterprises have experienced software supply chain security issues due to the usage of insecure container images
and ”more than 50% of respondents are worried about misconfigurations and vulnerabilities”
Recognizing these challenges, Checkmarx aims to meet developers where they are with our extension – Docker Desktop – which  empowers them to strengthen Docker image security posture early in the development lifecycle and adopt a proactive security approach.

What is Docker Desktop

With over 3.3 million installs, Docker Desktop is one of the most popular software platforms for developers. It allows them  to work locally on their workstations, and provides out-of-the-box containerization technology for building, running, and sharing applications.

This means that developers can build an application on one computer and then run it on another, without having to worry about installing all the dependencies that the application needs. This saves developers time and effort.

Checkmarx Docker Desktop Extension Overview

The Checkmarx Docker Desktop Extension is designed to enhance the security of your Docker images by proactively identifying and mitigating vulnerabilities. This extension integrates seamlessly with Docker Desktop, providing robust features such as comprehensive image scanning, package inspection, and vulnerability assessment.

Let’s dive deeper and understand how the Checkmarx Docker Desktop Extension works

Let’s begin with a common use case.

You want to ensure your container image’s security. In that case, you should utilize a container security engine to scan it for risks.

One you scan, you discover 632 vulnerabilities. Next, you must investigate them, assess their severities, and prioritize fixes accordingly.

You can then investigate the image scan results to upgrade to safer versions, if there are nay available, or look at specific CVEs.

Alternatively, opting for a more secure base image earlier in your development cycle can reduce vulnerabilities and risks. This is where Checkmarx Docker Desktop Extension comes in.

By seamlessly integrating this capability into Docker Desktop, developers can proactively identify and mitigate security issues much earlier, significantly reducing the risk of exposure in production environments.

Once you have assessed the security posture of the image you intend to use, based on the tool recommendation, you can continue to use it or select a different base image with a stronger security posture. In our example, you can see a decrease from 591 vulnerabilities to just two.

The extension uses Checkmarx’ proprietary database and  provides insights and recommendations to protect images from security risks, preserving the integrity of your containerized environments.

The key capabilities of the Checkmarx Docker Desktop Extension include:

1. Free Tool: No cost to use, with additional premium features coming soon.
2. No Checkmarx Account Required: Accessible without needing to sign up.
3. Image Scanning: Scan local images to obtain a detailed breakdown of image layers and identify security risks associated with dependencies
4. Package Inspection: Inspect packages within Docker images to ensure compliance with security best practices (package version, license,…)
5. Vulnerability Assessment: Identify vulnerabilities associated with packages within Docker images. You will find a detailed description of the CVE and its severity.
6. Recommendations and Remediation (Premium Feature): Receive suggestions for fixing vulnerabilities (coming soon).

The Checkmarx Docker Desktop Extension is a significant advancement in container security, empowering developers to strengthen their Docker images and align with industry best practices. With the integration of security into the development workflow, our extension enables developers to build and deploy secure containerized applications with confidence.

The Checkmarx Docker Desktop Extension is an important tool for developers and DevOps  professionals. By providing detailed insights into vulnerabilities along with offering robust scanning and inspection features, this extension helps maintain the integrity and security of containerized environments.

Install Checkmarx Docker Desktop Extension: Link to download.
You can find the detailed documentation here.

Prefer not to read? You can watch a replay of our joint webinar where we go into more depth about the capabilities and demonstrate live within the Checkmarx One and Sysdig Secure products. Watch now ->

In the past several years containers have emerged as a favorable choice for deploying applications, due to their architecture they allow developers to overlook concerns about dependencies and environments. Everything essential for running an application is neatly encapsulated within the container, encompassing code, runtime, system tools, libraries, and dependencies.

In cloud-native environments, containers, when coupled with best practices and the appropriate tools, offer seamless scalability, ensuring optimal application performance and availability. This flexibility not only caters to peak demands but also frees processing power for various application components.

However, the challenge arises when cloud and application security functions operate in silos, creating fragmentation. This scenario leaves AppSec teams without the correlation or context to understand which container packages are running, which are not and prioritize associated risks effectively.

Imagine a scenario where developers, prompted by security alerts and new work items, invest their valuable time in remediation efforts, only to discover that the identified low-priority vulnerability pertains to an unused container package. Without the correlation between vulnerability and runtime data, frustration sets in for developers, and may cause alert fatigue, while AppSec teams find themselves handicapped without a comprehensive view of the critical vulnerabilities that truly matter.

The challenge for AppSec teams is not merely identifying vulnerabilities but prioritizing, and remediating the ones that pose the most risk. Establishing a connection between vulnerabilities and the running containers becomes crucial, enabling teams to prioritize critical vulnerabilities and remediating them effectively. This correlation goes beyond technical nuances; it forms the backbone for fostering trust and collaboration between developers and AppSec teams. 

Checkmarx & Sysdig; connecting the dots between pre-production and runtime

Sysdig enhances Checkmarx Container Security by providing vital runtime insights into container Open-Source Software (OSS) running within cloud-native environments. While Checkmarx excels in securing container images by detecting vulnerabilities during development, Sysdig’s real-time profiling enriches this process by analyzing containerized applications during runtime. Checkmarx crossmatches the list of OSS packages used at runtime with known vulnerable packages, enhancing the identification of security risks. By integrating with Sysdig, Checkmarx extends its container security capabilities beyond static image analysis, ensuring a comprehensive approach throughout the container lifecycle. 

The collaboration between Sysdig and Checkmarx streamlines overall security management by offering continuous runtime monitoring and analysis. Sysdig’s integration enhances Checkmarx’ ability to prioritize and address vulnerabilities effectively, delivering a unified solution covering static analysis and real-time package insights. This partnership strengthens the capability to identify and remediate security threats, fostering a resilient cloud-native environment while empowering security teams and developers with a more proactive security posture.

See the integration in action

Beginning in Checkmarx Container security, we look at the completed scans under the “Container” tab. 

Runtime insights for container packages are available at the container level and at the vulnerability level. 

Within the container level under the “Container Packages” tab, container scan results are sorted by default by the packages used at runtime, and by the packages with the most vulnerabilities.

In this view, you can easily see how easy it is to quickly jump in and tackle the container packages with the most vulnerabilities. But when users quickly cross reference the “Runtime Usage” column alongside the number of vulnerabilities found, it becomes clear which vulnerabilities should be prioritized.  

Users can also filter this view to only see the packages used at runtime. 

Runtime insights are also available at the vulnerability level. The ‘Container Vulnerabilities’ view displays vulnerabilities associated with containers and their criticality, bubbling up those vulnerabilities associated with containers found in runtime at the top of the list.  

In this view, you’ll see that the “Risk Factor” column highlights whether the vulnerability is associated with a package that is used at runtime. The results show 9 CVEs that are associated with a package used in runtime, and the last CVE was not within a package used in runtime. The risk factor of whether the vulnerability was associated with a package found in runtime is just the start; additional risk factors are coming soon. 

When users want to better understand a given vulnerability found, they can click into the CVE for more information, including the severity, CVSS Score, and attack vector. 

When users click into a given CVE, they’ll now see a new “Risk Factors” box, where they can quickly see that the vulnerability is associated with a package used in runtime.

Prioritize what’s running and reduce noise by up to 90%

Using runtime insights from Sysdig Secure, Checkmarx One or SCA standalone customers gain several benefits. 

• They can effectively prioritize remediation. Correlating pre-production and runtime surfaces the most impactful risk, dramatically reducing the time to detect and prioritize vulnerabilities associated with in-use packages first. 
• Build #DevSecTrust. Team alignment and trust are crucial for the success of an enterprise-scale AppSec program. Focusing their development team on the most critical vulnerabilities and filtering out the rest while reducing alert fatigue, builds trust with developers.  
• Improve your security posture. Runtime insights aid organizations in increasing their overall security posture, by providing the context your team needs to prioritize the most impactful vulnerabilities.  
• Reduce noise. AppSec teams can prioritize vulnerabilities based on in-use context, and eliminate 90% 

Whether you’re a CISO (Chief Information Security Officer) focused on your total application security posture, or part of an AppSec team focused on identifying and prioritizing vulnerabilities, or a developer focused on remediation and supporting the business where it matters most, Checkmarx and Sysdig help you better identify, prioritize, and remediate vulnerability risk.

The integration is available for users of both Checkmarx One or Checkmarx SCA standalone and Sysdig Secure. For current customers of both Checkmarx and Sysdig, or you wish to start gathering runtime insights Request a Demo, to get started.   

You can also watch a replay of our joint demonstration https://info.checkmarx.com/tech-partner/sysdig/bridging-code-and-cloud-security

But modern applications also present some steep challenges, not least in the realm of security. In order to thrive in the modern development landscape, developers and AppSec pros alike must be sure that their security skills can address the variety of threats that teams face today – a time when cyberattacks are growing steadily in frequency and scope.

Here’s a list of four essential security skills that anyone involved in modern application development should possess.

IaC Security

Infrastructure-as-Code (or IaC) tools have become an essential part of many modern application development workflows. Using IaC, teams can automatically provision large-scale software environments, which maximizes scalability and minimizes the risk of configuration mistakes due to human error.

But the downside of IaC is that, if the configurations applied using IaC templates contain security issues, those issues will be proliferated across your entire environment. And in most cases, the IaC tools themselves do nothing to alert you to potential security issues.

That’s why developers and AppSec teams must learn to follow security best practices when configuring IaC templates, such as:

• Secure your secrets: Don’t hard-code passwords or other secrets into IaC templates. Store them in an external secrets manager instead.
• Modularity: Keep IaC templates short and modular. Trying to cram too much configuration into a single template increases the risk of making a mistake.
• Use default settings with care: Don’t blindly trust default IaC settings. Make sure you tailor templates to your environment.

Just as important, teams should use IaC scanning tools to validate their IaC configurations prior to applying them. IaC scanners automatically check IaC templates for misconfigurations that could create security issues.

Open Source Security Risks

There are many excellent reasons for modern development teams to leverage third-party open source code. Open source saves time because it allows you to reuse code that someone already wrote rather than having to write it yourself from scratch. It is also often easy to customize. And it’s usually free of cost, which is never a bad thing.

Yet open source also poses some significant security risks when you incorporate it into your applications. You can’t guarantee that third-party open source developers adhere to the same security standards that you do when they write their code.

For that reason, it’s critical to know where in your application you incorporate open source code, and also to scan that code to identify known vulnerabilities within it.

Container Security

Modern applications are often deployed using containers. Because containers – and the orchestration platforms used to manage them (like Kubernetes) – add another layer of infrastructure and complexity to your software stack, they create a variety of potential security risks that would not be present if you were deploying applications directly on a host OS, without having a container runtime and orchestrator in the equation.

Modern developers and AppSec teams need to know what these risks are and take steps to address them. A full discussion of container security is beyond the scope of this article, but basic concepts include:

• Image security: Securing container images by ensuring that any external components on which they depend are secure, as well as using a container image scanner to check for vulnerabilities.
• Configuration security: Scanning the configuration files that are used to deploy and orchestrate containers. Like IaC templates, these files can contain configuration mistakes that enable security breaches.
• Runtime security monitoring: Using monitoring tools that can collect and analyze data from across complex containerized environments (which means collecting data from various containers, from all of the operating systems running within the cluster of servers that hosts your containers, and from the orchestration platform) to detect signs of breaches at runtime.

Microservices Security Risks

Microservices have become massively popular because they make it easy to build agile, scalable applications that lack a single point of failure, among other benefits.

But microservices also significantly increase the complexity of application architectures, which in turn increases the risks of security issues. Because microservices rely on the network to communicate with each other, there is a higher risk of sensitive data exposure. Insecure authentication and authorization controls between microservices could enable a breach to spread from one microservice to an entire app. Security problems with the tools used to help manage microservices (like service meshes) create another set of security risks to manage.

As with container security (which, by the way, is a closely related topic, because microservices are often deployed using containers), there is more to say about microservices security than we can fit into this article. But some core microservices security best practices for developers and AppSec teams to follow include:

• Microservices isolation: When designing your microservices architecture, strive to isolate each microservice as much as possible. Allow interactions between services only where strictly necessary.
• Authentication and authorization: Always require authentication and authorization for microservices to communicate with each other.
• Network isolation: Isolate the internal networks that microservices use from the public Internet, and never expose a microservice directly to the Internet unless it needs to be.

Conclusion: Modern Application Development Requires Modern Application Security

Most of the security challenges discussed above simply didn’t exist ten years ago. Back then, no one was provisioning hundreds of servers using IaC templates or deploying applications with highly complex architectures based on microservices and containers.

But those practices are the norm for modern application development. Developers and AppSec teams must respond by ensuring that they are able to leverage the tools and skills necessary to meet the modern security risks that go hand-in-hand with modern application development.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.

Click here to learn more about security in the context of Modern Application Development

At the same time, however, containers present some significant challenges, not least in the realm of security. Although the benefits of containers outweigh the security risks in most cases, it’s important to assess the security problems that containers can introduce to your software stack and take steps to remediate them.

Toward that end, this article lists the top seven security risks that containers may pose, along with tips on addressing them.

Risk 1: Running Containers from Insecure Sources

Part of the reason containers have become so popular is that admins can pull a container from a public registry and deploy it with just a few commands.

That’s great from the perspective of achieving agility and speed. But from a security point of view, it can pose problems if the container images that you pull contain malware.

This risk is not just theoretical. Hackers have actively uploaded malicious container images to Docker Hub (the most widely used public container registry) and given them names intended to trick developers into believing they are images from a trusted source. Indeed, according to one source, no fewer than half of all images on Docker Hub contain at least one vulnerability, which is an astounding figure.

The lesson here is that it’s absolutely vital to check and double-check the origins of container images that you pull, especially when dealing with public registries.

Risk 2: Exposing Sensitive Data through Container Images

The risks associated with container registries can run in the opposite direction, too: you could upload data to a private registry that you assume is secure, only to discover that your registry – and the sensitive data you stored in it – are actually accessible to the world at large.

That’s precisely what happened to Vine in 2016. The company uploaded a container image that included source code for its entire platform into a registry that was not properly secured. The registry’s URL hadn’t been publicly shared, but anyone who could guess the URL had unfettered, no-password-required access to the images in it.

Mistakes like this are easier to make than you might imagine. When you’re juggling dozens or even hundreds of container images, it’s easy to fall into the trap of accidentally placing a sensitive image in an unsecured registry, or even forgetting that an image contains sensitive data in the first place.

Risk 3: Placing Too Much Faith in Image Scanning

Image scanners, which can automatically determine whether containers contain known vulnerabilities, are a vital tool for helping to secure containers.

But scanners are only one type of tool, and they’re hardly a complete guarantee against all types of risks. They work by matching the contents of container images against lists of known vulnerabilities, which means they won’t discover security flaws that have not yet been publicly disclosed. Container scanners may also overlook vulnerabilities if container images are structured in unusual ways or their contents are not labeled in the way the scanner expects.

The takeaway: by all means, use container scanners. But never assume that an image is secure just because your scanner deems it so. Take additional steps to secure the container, such as monitoring the runtime environment for signs of security issues.

Risk 4: Broader Attack Surface

Running containers requires more tools and software layers than running a conventional application. In this respect, containers create a broader attack surface.

When you deploy containers, you have to worry about the security not just of the application and the operating system that hosts it, but also of the container runtime, the orchestrator, and possibly a variety of plugins that the orchestrator uses to manage things like networking and storage. If you run “sidecar” containers to help with tasks like logging, those become a security risk, too.

All of the above can be managed, but it requires a deeper investment in security – and a broader set of security tooling – than you’d use with a traditional, non-containerized application stack.

Risk 5: Bloated Base Images

Container base images are images that developers use as the foundation for creating custom images. Typically, a base image is some kind of operating system, along with any common libraries or other resources required to run the types of applications you are deploying.

It can be tempting to pack more than the bare minimum into base images. You never know what you may need to run your applications in the future, so you may decide to include libraries that aren’t strictly necessary for your applications today, for instance.

But the more you include in your base images, the greater the risk of a vulnerability that allows your containers or applications to be compromised. A best practice is to build base images that are as minimal as possible, even if that means updating them periodically or maintaining different base images for different applications.

Risk 6: Lack of Rigid Isolation

Containers should isolate applications at the process level. But the fact is that they don’t always do that perfectly well. At the end of the day, containers share the same kernel, and a bug in the runtime or a misconfiguration in the environment could allow a process running inside one container to access resources that live in other containers, or even gain root access to the host.

This is why it’s extra important in the case of containers to vet your configurations for security as well as monitor runtime environments for malicious activity. There is simply a greater risk of privilege escalation and similar issues with containers than there is with virtual machines.

Risk 7: Less Visibility

The harder it is to observe and monitor an environment, the harder it is to secure it. And when it comes to containers, observability and monitoring are especially difficult.

It’s not that the data you need to track containers doesn’t exist. It’s that that data is spread across multiple locations – inside containers, on Kubernetes worker nodes, on Kubernetes master nodes – and that it’s not always persistent (logs inside containers will disappear forever when the container instance shuts down, unless you move them somewhere else first).

Here again, these challenges are manageable. But they require a more sophisticated strategy for keeping track of what is happening inside your environment than you would typically have with a simpler type of application stack.

Conclusion: Containers Are Great, but They Are Harder to Secure

Again, none of the security risks described above are a reason not to use containers at all. But they are reminders that with the great agility that containers provide comes extra responsibility. Before you go pulling images from a random Docker Hub registry and calling it a day, be sure you know where your images came from, what’s in them, and which security risks may arise when they run.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.

Download our Ultimate Guide to SCA here.