Summary
Container vulnerability management is a critical part of wider security, ensuring that images, registries, orchestration platforms and container engines work together in a secure way to protect your organization, its customers, and its data. This article offers container security best practices, and shares the container security tools that allow developers to benefit from the consistency and portability of containers – without adding risk.
Guide to Container Security
If you’re using container technology, security should be part of your strategy from day one. Container vulnerability management is an integral part of leveraging containers, including understanding the available container security tools on the market, identifying container security best practices in your environment, and compiling a container security checklist according to your business context.
Container technology allows developers to package applications and their dependencies into self-contained units which are portable from one location to another. Developers love using containers, leaning on the consistency and portability of the technology for a wide range of use cases. However, containers have their own specific security challenges, and so getting to grips with container security is essential for anyone who is looking to make them part of a day’s work.
Luckily, this ultimate guide to container security can tell you everything you need to know!
What is Container Security?
In the IT and development world, containers are environments that provide reusable and automated systems to run a software application, often with microservice architectures. These environments contain all the applications, libraries and dependencies needed to support a software application in one neat, portable package, and allow businesses to push out new product features faster and quicken the release cycle to meet Agile methodologies and DevOps pipelines.
Container security is a catch-all term for how organizations secure their container technology. In some ways, containers can make your environment more secure, for example by isolating workloads to reduce risk, and their inherently immutable nature which means the state of a container remains constant even in runtime.
Unfortunately, in other ways, the use of container technology opens the business up to security risk, and smart organizations are getting ahead of that risk. As of 2023, the global Container and Kubernetes Security market was estimated at US$ 1219.65 million, and it’s anticipated to reach US$ 4876.63 million in 2032, with a CAGR of 25.98% during the forecast years.
Container security puts a focus on reducing any and all security risks that come with using containerized applications, from vulnerabilities found in application source code and in static container images, to container infrastructure risks in registries or the host, and runtime risks in applications in production.
Why is Container Security Important for Organizations?
Today, protecting containerized environments should be a fixed element of an organization’s overall security posture, as using containers is now part and parcel of how companies build their software applications. The container ecosystem, alongside orchestration platform Kubernetes — the leading platform for managing containers, are both extremely complex. While Kubernetes and other orchestration platforms automate a lot of the work involved in managing containerized workloads, including application development and deployment, they also have their own risks to consider.
By securing containers and Kubernetes with best practice container security, businesses are able to shift left and add security from the earliest stages in the CI/CD pipeline, which is an automated approach to software development where code changes and frequently tested and implemented. With this method of shift left, organizations can feel confident that they have a secure working environment, even when taking advantage of open-source tools and technology. Orchestration platforms including Kubernetes usually include many native security tools to make that easier, such as Role-based Access Control, network policies, and pod security policies, too.
The truth is, container security is important for many of the same reasons that all application security is important. Today’s environments are increasingly interdependent, and a vulnerability in one area can quickly spread to the whole network. The risk of a cyber attack grows all the time, including a malware injection, a ransomware threat, or even an unintended compliance breach. These can lead to data loss, financial penalties, and the erosion of customer trust. Broad application security tools are not sufficient to protect against container-specific risks.
What are Common Container Security Threats and Attacks?
The kinds of threats that organizations need to be aware of in containerized environments are different from what security teams may be used to on-premises or with virtual machines. Here are some of the top risks to stay on top of:
-
- Running containers from insecure sources: To support speed and agility, admins can pull a container from a public registry and deploy it in a matter of a few commands. However, if these images contain malware — you’ve turned a quick win into an immediate nightmare. 87% of container images running in production have either critical or high-severity vulnerabilities, an increase from 75% in 2022.
- Exposing sensitive data: In container technology, the registry itself could also open you up to vulnerabilities, if you consider it to be secure and in fact — threat actors can obtain access. If the container registry is not secured adequately, anyone could view, steal or share your sensitive information without as much as a password.
- Unusual vulnerabilities unchecked by image scanners: Many organizations lean on image scanners which compare container images against known vulnerabilities to discover security vulnerabilities. However, this doesn’t always take into consideration flaws which are not publicly known and relies on the images being structured as the tool expects.
- A broader attack surface: A containerized application relies on additional tools and more software layers than traditional architecture. You need to think further than simply the application itself and the Operating System, and consider the runtime, orchestration platform, and any and all plugins and third parties that handle tasks such as storage and networking.
-
- The risk of base images: Base images are usually a type of operating system which works alongside libraries and other resources, and can be used to create custom images as necessary for an application. However, when you bloat these base images with everything you think you may need in the future, you add the potential for vulnerabilities that open doors to attackers.
- Misconfigurations: Containers share the same kernel, so any bug or flaw in the runtime, or a wider misconfiguration in the environment, could allow one container to access resources from another — meaning you’ve lost the security benefits of rigid isolation. In a worst-case scenario, a container process could even obtain root access to the host.
- Lack of visibility: Observability is a common challenge with containerization technology, because data is spread across multiple locations, on Kubernetes worker nodes, master nodes, or inside containers themselves. If an instance shuts down, logs will disappear for good, so data isn’t even consistent in order to monitor and track information. This can leave the business open to risk.
Who is Responsible for Container Vulnerability Management?
As with any cloud security concern, when thinking about responsibility you need to remember the Shared Responsibility Model between the cloud provider and the organization. As cloud providers are responsible for the security of the cloud, this means they take responsibility over the hardware and physical infrastructure, as well as any software or networking they provide. If for example you’re using Google Kubernetes Engine, Azure AKS or Amazon ECS/EKS — your cloud provider takes responsibility for securing these.
However, users need to take responsibility over security in the cloud. That includes protecting all of their workloads, including containerized applications and all dependencies and components.
Within that scope, it’s still not always clear within the organization whose role it is to manage container security, and who should take control when it comes to implementing the right tools and security processes to keep risk to a minimum. In one recent survey, respondents couldn’t answer definitively which team should be responsible for securing container environments and Kubernetes, with 42% citing Security teams, 30% putting the onus on Development, and 28% saying it should be Operations. This confusion and disconnect can lead to friction between teams, and erode trust between DevSecOps, who in the best-case scenario, should all be working together as a functional team.
In some businesses, the responsibility for fixing security issues lies with the team that created the container or the microservice in the first place. However, this often makes things more complicated rather than less, as microservices for example often have disparate elements that rely on other microservices to complete their role. Let’s say for example a microservice is handling delivery fees for a retail website. This microservice might need to get information from another, which contains the location tracker used in order to work out where the fulfillment center is, and how that impacts the overall cost. In this case, if the problem is with the second microservice deployment, sending the task to the original development team could simply cause a bottleneck.
The right container security tools will make decisions around responsibility a lot easier, empowering developers to build secure applications faster with dev-friendly application security testing integrated into their existing workflows and available from their Integrated Development Environment (IDE). This means that development teams can take responsibility for container vulnerability management earlier in the Software Development Lifecycle (SLDC), which refers to the various stages involved in building software, from planning to deployment. Best of all, they can take this control without adding to their workload or standing in the way of innovation and agility. It also reduces the effort for Security and Operations teams, who can reserve their input for active threats.
Components of Container Security Architecture
To start securing container technology, you need to understand what there is to secure in the first place. There are a number of crucial architecture elements to consider, each of which may need its own strategy.
Firstly, think about container images. These all need to be scanned for vulnerabilities, and you should have policies in place for which images you trust and use, and from what sources developers can take images. If images are compromised, this can lead to malicious code injection or execution, and even lateral movement within the containerized environment.
Next, turn your attention to the registries themselves. Access control policies can ensure no-one can make unauthorized changes to your image repositories. On top of that, have a list of approved and verified registries to reduce overall risk of obtaining malicious images. If you use images from a compromised registry, every container that uses those images is now compromised.
Orchestrators such as Kubernetes manage how containers are used and share data. They usually have robust security controls of their own, but many organizations skip them or make changes to suit their own processes, which may not be security best practice. Remember, all containerized applications are at risk if there is a vulnerability with the orchestration platform, and threat actors could access your data, or disrupt overall business service.
Finally, the container engine is the runtime that actually runs containers. Without proper security protocols in place, you may experience unauthorized access or a lack of isolation between containers and with the host. This is the greatest risk of all, as you could experience a full system compromise, as well as data leakage and loss, and attackers gaining a foothold to launch a full-scale attack, including malware or ransomware.
The Role of Container Security Tools in the SDLC
Container security tools have a lot on their shoulders. They need to secure the use of containerized environments from the first line of code through to deployment and runtime. As images span the entire software development lifecycle, they need to be tested and monitored at every stage.
As a result, you need to consider container security tools and their capabilities in terms of preventing container image risk, including:
- Images built locally by your developers, and distributed to other members of the team or other departments.
- Images with metadata included for asset management purposes, but which may share sensitive information
- Images in registries, including both private ones and public ones where they can be shared with others to deploy.
- Images deployed to clusters, often managed by an orchestration platform, anywhere from dev to test and prod environments.
Many businesses will choose to test or scan their container images at a single stage in the SDLC. For example, they scan in the registry, and assume that the images are secure everywhere and at every time.
However, the truth is that testing and scanning needs to be done as often as possible, and at multiple stages of the process. If you test late in the SDLC, you run the risk of giving feedback too late, and slowing down new features or updates from getting to launch, as well as adding prohibitive cost to the project. However, if you test and scan too early, you may miss a risk that only becomes clear or develops closer to production, or waste time that should be spent on more urgent tasks involving applications that are live. If you ask developers to test locally in the moment, which may provide the greatest insight into the source code and version control information, this is likely to slow them down or take them out of the flow of work.
When it comes to choosing the right security tools, not all teams will need every bell and whistle or every checkbox item. Each business has their own specific demands and environments. This container security checklist can help you to understand which container security features should be included when you’re shopping around for container tools.
- Checking for code vulnerabilities: This should be done from pre-production to runtime, to give the broadest view of any issues with code.
- Access management: Staying on top of permissions, access control and roles when managing containerized environments, for example to implement least privilege.
- Developer tools: Many solutions empower developers with the right security tools to manage code vulnerabilities at the earliest stages of the SDLC.
- Network monitoring: As containers can be the target of wider threats to endpoints or networks, many container security tools include monitoring and threat detection.
- Policy creation: Who is allowed to access containers, make changes, or manage data? Tools can allow for policy enforcement and governance in a centralized way.
- Code testing: Both before and while creating source code, regular or continuous testing uncovers any vulnerabilities or misconfigurations ahead of time.
- Container scanning: Scanning of a whole container stack, uncovering any vulnerabilities in images, alongside steps for remediation.
- Incident response: Any risk to the organization or container technology needs to be fixed as well as flagged. Incident response capabilities cover triage, quarantine, and response.
- Runtime threat mitigation: Many tools go a step further from production, detecting runtime malware, insider threats, unpatched vulnerabilities, weak credentials and more.
- Reporting and analytics: Compliance is an ever-changing target, and you may need a strong audit trail, including features such as preserving container metadata for analysis.
Choosing Between Types of Container Security Tools
There are many different vendors and SaaS solutions that provide container security tools, and it can be hard to know which product will check all of your boxes, especially if they all offer a similar feature list.
In some cases, you may need a niche solution for container security scanning for example, while for another business — the right choice is a wider cloud security solution that can handle multiple security needs in one platform.
Once you know that your shortlist can manage your specific business needs, differentiators may include:
Service and Support
Consider the support function of your shortlist. Do they offer a dedicated support representative who will get to know your business context, or technical support around the clock — no matter the time zone? How does implementation and onboarding work with each vendor? In particular, do they provide managed support and advice when setting up your cloud and container security policies, so that nothing falls through the cracks?
Cloud Security Extras
Tool sprawl is a real challenge for today’s organizations, as they need a growing list of protections to keep their environments secure. Once you know container security is covered, a good idea could be to look for a vendor that can check more items off your list. Strong application security tools include Static Application Security Testing (SAST), Software Composition Analysis (SCA), supply-chain security, API security – offering tools to secure software components as they communicate with each other, IaC security, and more.
Reputation
All security vendors will call themselves the best in the business, but does your shortlist have the industry recognition to back it up? Think about industry-recognized accolades and recognition such as Gartner’s Magic Quadrant for Application Security or Forrester’s Wave Leadership. These kinds of awards and listings can help you separate experienced and proven solutions against those that are still immature in the industry.
Ease of Use
Security solutions can be fantastic as standalone tools, but how nicely does your shortlist play with the rest of your tech stack? Ideally, a container security solution will integrate with the rest of your tools and processes, seamlessly fitting into the software development lifecycle so that developers can fix code from inside their preferred integrated development environment.
6 Key Considerations for Container Security
How to Keep Container Security Knowledge Updated
Knowledge around container security best practices changes all the time, alongside the latest technology and innovation, so education needs to be part of how your organization stays up-to-date.
At Checkmarx, our customers keep container security knowledge top of mind by using tailored developer security training, known as Codebashing. It makes learning continuous, personalized, and totally aligned with your developer workflows. Personalized training journeys can be used to support development teams in building and deploying secure code, covering all aspects of the software development lifecycle.
Container Security Best Practices for 2024
To help you get started with container security, think about the following best practices:
- Secure images with good image hygiene: Container images hold everything required for the application, alongside a subset of the OS. Make sure to include the application within the container image as a statically compiled binary, including all dependencies. Remember to remove any unnecessary components, as these simply add risk. Examples could include default binaries, like “sed” which is included on UNIX. If you’re using image repositories such as Docker Hub, set policies and safeguards such as container scanning, as these can be used by anyone — threat actors included.
- Secure registries where container images are stored: For an organization’s own private registry, make sure that access controls are tight, following the principle of least privilege where possible to define who can access and publish images. Use signatures so that you can easily track images back to who created them, making it more difficult for threat actors to make substitutions. Vulnerability scanning tools are built to help find any vulnerabilities or threats in your images, and can be used continuously for ultimate peace of mind.
- Secure deployments thoroughly with key strategies: To secure the target environment, establish network segmentation rules through firewalls, VPCs or microsegmentation, or create specific admin accounts for access. Your orchestration platform will likely secure API endpoints, and offer tools like RBAC, which will help you harden security and minimize unauthorized access. In some cases, you may want to use immutable deployments, creating an instance image at the build stage, which the deployment can then use when new instances are being created.
- Secure containers in runtime: Best practices for securing containers in runtime include using the principle of least privilege so that only containers that need to interact can communicate, with implementation of separate virtual networks for containers, too. Quick wins? Only expose ports that are necessary, including SSH. Encrypting traffic is really important, so use Transport Layer Security (TLS) to secure communications.
- Monitor container activity: Workloads that run in containerized environments change all of the time. A single container image can have multiple instances, and new images and version changes are made quickly, allowing vulnerabilities to potentially move across applications. Monitoring containers, alongside remediation guidance to make quick fixes is therefore critical for both IT and Security teams. As a starting point, make sure that you can monitor master nodes on your orchestration platform, container engines, all workloads, and any containerized middleware.
As well as these best practices, it can be helpful to look at the NIST Application Container Security Guide, which publishes its own container security checklist. They start by recommending that teams are encouraged, educated and trained to rethink how they code and operate to leverage container technology. Practical tips include using container-specific host operating systems to reduce the attack surface, and only grouping containers with the same purpose, sensitivity and threat posture — to enable in-depth defense. NIST also recommends that organizations adopt specific container vulnerability management tools and processes for images, as well as container-aware runtime defense tools.
How to Prevent Container Attacks with Container Security Scanning and More
While there are certain elements of container security that you can handle in-house, or with the help of native security capabilities in container orchestration platforms, NIST is right — they aren’t enough to ensure security is robust and complete. This is especially true when it comes to third-party software components. If a container image has a vulnerability, this can be deployed in applications, and if there is an underlying issue with permissions or access control, this can propagate a risk across your environment.
Container security tools help your organization to better manage access, test your security posture, and protect the underlying infrastructure with visibility and control. This could include creating the right policies, leveraging attack simulations, or continually testing for vulnerabilities.
Container security scanning is a powerful security tool which can help you identify vulnerabilities in your containers. These tools may scan your Docker image port or wider network configuration, look at your identity and access management policies for vulnerabilities, or analyze the build process and contents of each container image. Best practices for image scanning include looking out for third-party library vulnerabilities, scanning every built image before publishing as part of the CI/CD pipeline, and using minimal base images which are as light as possible, to limit the chance of vulnerability and speed up the scan. Where possible, use distroless images, which are lightweight by design, without any additional programs, shells, or package managers.
Checkmarx One: Providing a Comprehensive Solution for Container Security
Checkmarx One secures containerized applications throughout the whole software development lifecycle, from the first line of code to deployment and runtime in the cloud. It simplifies the process of image scanning, thoroughly monitors your Docker environments, and helps to resolve any vulnerabilities in real-time. You can identify, prioritize, and address security flaws, preventing issues in production workloads while reducing alert fatigue for the development team during build and deployment.
Checkmarx’s container image scanning identifies vulnerable code in open-source software, providing the best-fix locations of where and how to solve the issue, and offering remediation guidance so that any problems are effectively handled long before deployment. Integrated with Checkmarx SCA, all layers of each public base image are extracted, with every layer inspected and packages identified.
One of the greatest challenges for developers is understanding how to prioritize their work to make an impact. Checkmarx One allows teams to correlate pre-production and runtime data, including their own source code and open-source libraries to identify exploitable vulnerabilities in running container images, so that remediation efforts can be targeted where threats are most exploitable in production. This has been shown to reduce the noise of alerts by up to 95%.
Developers can filter vulnerabilities on a single dashboard, sorting by number of vulnerabilities in container images, and their runtime usage — helping to prioritize intelligently by business impact.
As scanning and application security testing is critical across the SLDC, our partnership with Sysdig takes container security scanning a step further. While Checkmarx takes control over securing container images during development, Sysdig takes the reins in runtime. Using real-time profiling, Sysdig offers vital runtime insights into container Open Source Software (OSS), completing the picture. Checkmarx compares the OSS packages used at runtime against known vulnerabilities, and extends capabilities beyond static image analysis, ensuring full visibility and control throughout the container lifecycle.
This unified solution strengthens an organization’s ability to uncover, prioritize, and address vulnerabilities in container technology, reducing the weight of alert fatigue for developers, and fostering a shift-everywhere culture of business resilience throughout the SDLC, from code-to-cloud.
Interested in implementing container security best practices for your business, and reducing the risk of container vulnerabilities? Speak to us about scheduling a demo of Checkmarx One.