Chips VS Threats of Containerization Technology

    The use of containers for developing and deploying software has long become standard practice. The ability to easily provide the program with a standard environment, independent of the host on which it is running, to quickly change settings, add or change some components in the container, was appreciated by many developers. But this is only a small part of all the chips that are provided by the containerization technology.

    As always, the development of technology and the growth of its popularity are accompanied by the identification of various ways of non-standard use, including malicious. In this article we will also look at the security risks of the development process associated with the use of containers, and talk about why the DevOps processes should be transformed into DevSecOps.

    Let's start with why containers win the sympathies of developers and how the use of containerization changes the development as a whole.



    Compared to virtual machines and “iron” servers, containers are completely undemanding of resources. This allows you to run significantly more containers on one machine than virtual machines. A developer can even run application components on his computer in the form of containerized microservices and he will not have to nap while waiting for the system to respond. Due to the fact that the containers share the core of the system, their start and stop occur much faster than restarting the virtual machine.


    Despite the sharing of the kernel, the application in the container runs in isolation from other parts of the system and applications. This means that an error in the application will only affect a specific container.

    The use of containers in the development allows you to escape from the eternal conflict of developers and system administrators about the privileges. The container safely separates the application from the system, so the programmer can afford any experiments without fear of destroying the OS.


    Each application runs in its own container instance with its own configuration files. This eliminates the headache associated with moving an application between hosts: everything you need to work is stored inside the container and transferred along with the rest of the application components.

    Container repositories

    The appearance of the standard Open Container Initiativeled to the fact that it became possible to create public libraries of container images and create a powerful ecosystem that combines container engines, cloud platforms and tools to manage containers, security checks and other tasks.


    The use of containers allows you to build fully automated chains of continuous integration and deployment of applications (CI / CD), in which the “manual” part will be mainly writing code. Testing, checking the quality of the code, packaging the application in a Docker image, placing the image on the Docker Hub and deploying it to the host for execution can be performed without human intervention.

    Container Threats

    Of course, with all their advantages, containers have various disadvantages. These are, for example, performance problems with resource-intensive applications and limited portability of images built for different architectures. But in addition to technological problems, containers have security problems.

    Kernel Sharing

    As always, disadvantages are the reverse side of the advantages. Kernel sharing reduces container redundancy compared to virtual machines, but the greater the number of allowed syscalls makes the security barrier more subtle, and the exploitation of kernel vulnerabilities allows you to attack all containers at once. How not to recall the specter and Meltdown sensational attacksthat allow you to read the memory of someone else's process or kernel from the user-space.

    Public repositories

    The presence of public registries with images gives a wide choice of "wrappers" for containers, but creates additional threats, since the registry server is trusted by default. If attackers succeed in modifying the base images with malicious libraries, the changes will automatically spread across all the servers in which this base image is stored in the cache, and all containers that use the library will automatically acquire malicious functionality.


    Thus, one malicious library is enough to compromise the application. Of course, vulnerabilities and malicious functions in popular libraries are not a problem of containers as such, but of technology that ensures the rapid spread of changes in images.


    Obviously, the current development process requires a new approach, an approach in which security will be integrated into the CI / CD chain, turning DevOps into DevSecOps.

    According to Gartner, in 2019
    • More than 70% of corporate development processes will contain automated checks for vulnerabilities and configurations of open-source components and commercial packages.
    • more than 50% of the CI / CD processes will contain mandatory built-in code security checks;
    • more than 60% of companies will use in the development of tools for version control and infrastructure automation management.

    Consider some of the components that must be present in the process, so that the word “Sec” in its name would not be an empty sound.

    Integration of checks into all processes

    Security checks should be present at all stages of the development process, from code generation to containerization and deployment.

    Automation of security checks

    Needed for two reasons:

    1. This will reduce the number of administration errors and misconfiguration.
    2. Security professionals will not have to manually check the code and change the settings.

    API for security functions

    Implementing this functionality requires that the security system provides an API for accessing all features. So developers can not only use the system to check, but also embed the appropriate calls in the code.

    Role-based access control

    Different security professionals need different levels of access to the check mechanisms depending on their role, since it is necessary that developers do not have the ability to change security settings, but they are not responsible for the penetrating threats.

    Compatibility with the Docker Registry API

    Ideally, protection should support scanning Docker images in any registry that supports the Docker Registry V2 API to ensure compatibility with all popular registries.

    Migration protection

    For corporate users, the dangerous point is the transition from a monolithic to microservice architecture. It is important that the security features are built into the integration processes, providing protection in automatic mode.

    An example of a security solution is the Trend Micro Deep Security Smart Check, which continuously scans images in automatic mode, detects vulnerabilities and malware. Smart Check supports Docker Trusted Registry, Amazon Elastic Container Registry, Azure Container Registry and Google Container Registry container platforms. In addition, Trend Micro integrates with leading SIEM systems and such orchestration tools as Jenkins, Kubernetes, SumoLogic, Splunk.

    An important feature of Smart Check is compliance with all requirements of regulators in terms of checking critical vulnerabilities and event logging.

    Embedding container security into DevOps processes in the early stages of development before launching applications will allow developing more reliable and productive software, as well as
    • Detect malware and libraries.
    • Identify vulnerabilities.
    • Correct errors before images are transferred to orchestration tools (for example, Kubernetes).
    • Prevent the execution of malicious code and the deployment of vulnerable software.

    Also popular now: