Containers are your continuous integration and deployment (CI/CD) workhorse. Your software development processes could exist without them, but the question becomes, “Do you really want to though?” Typically, the answer to that question is “no.” Simultaneously, as you shift security left, your DevOps processes increasingly transform into DevSecOps, adding new responsibilities. Your container runtime is the part of the container engine that supports the containerization process by working with the operation system (OS) kernel. 

By incorporating container runtime security into your processes, you strengthen the security of your software development processes.

What is container runtime security?

Container runtime security consists of the tools and practices used to detect and prevent malicious activity while containers are running. Despite isolation, containers share the host’s kernel. The container runtime acts as a middle layer between the OS and containers so that container and application execute.  At execution, they pull all and execute all dependencies within their code, meaning that any vulnerabilities or malware become “live.” Since everything happens all at once, attackers can use various vulnerabilities hoping to escape one container as a way to compromise the other containers or the host.  

What security threats exploit container runtime?

When looking at container runtime security, many of the attacker’s usual suspects arrive on the scene. 

Compromised Container Images

Threat actors can inject malware into the container images posted on public registries, like Docker Hub. When developers use these contaminated images, they introduce the threat to the organization’s environment. 

Privilege Escalation

Attackers leverage a container vulnerability or a misconfiguration to increase their access within the container. By doing this, they can gain root access to the container or the underlying host. 

Vulnerabilities

Coding bugs that create security weaknesses give attackers a way to compromise the runtime. 

Misconfigurations

With everything delivered as code, misconfigurations or insecure configurations create an attacker gateway. For example, containers can create security risks by exposing open ports or hard coded secrets. 

Container Orchestration

The orchestrator uses runtime to manage the containers. A vulnerability in the orchestrator can undermine runtime security. 

Who is responsible for container runtime security?

Although operations and security teams traditionally managed runtime security, developers now share this responsibility as organizations shift security left. 

Developers

Developers are responsible for mitigating risks before the container runtime executes. For example, developers should:

• Follow secure software development life cycle (SDLC) best practices by writing secure code
• Identify and remediate vulnerabilities during the development phase to prevent them from undermining the runtime
• Automate review processes using tools like Static Application Security Testing (SAST) to reduce human error risk inherent in manual reviews

Operations and Security

Operations and security manage security once the application is live. For example, they should:

• Monitor application performance to detect potential security incidents
• Respond to security incidents as quickly as possible to limit damage
• Maintain infrastructure security and patch management so that the application runs in a secure environment

Container Runtime Security Best Practices

Attackers will exploit source code and organizational security vulnerabilities to gain unauthorized access to sensitive data. To mitigate risks, developers should work with their operations and security counterparts to create a comprehensive strategy. Developers should use secure coding best practices to prevent attackers from compromising applications before they execute. 

Choose Trusted Images

If you use open-source container images, you should review the author’s reputation. For example, Docker Official Images is a curated set of images across Ubuntu and Alpine operating systems. 

Change Default Configurations

By default, processes inside a container run as root, meaning that they have more access than they need. You need to set a default user so that you can limit access according to the principle of least privilege. 

Additionally, the Docker daemon uses the host’s user ID namesake as a default. You should change these configurations to prevent attackers from escaping a container to gain access to other containers or the host. 

Scan for vulnerabilities

Vulnerability scanning is critical to container security. For every layer added to your base image, you increase the security risks. You should scan the:

• Container to identify all vulnerable packages within it
• Source code to identify vulnerabilities embedded within third-party repositories, code, and their dependencies

Scan for secrets

If source code exposes a secret, attackers can undermine the application’s runtime environment. To mitigate this risk, you should scan for secrets in your source code, especially those embedded within long, random character strings and encrypted or hashed data. Some secrets you want to look for include:

• Credentials
• API keys
• Authentication tokens
• Certificates
• Private keys

Qwiet AI: Visibility into Container Security 

With Qwiet AI’s preZero platform, you can scan millions of lines of code in minutes for visibility into all containers, components, dependencies, and reachable vulnerabilities. Our platform quickly returns accurate and detailed findings while significantly reducing false positives. With our Code Property Graph (CPG), you gain a holistic view of your code, including data flows across the application, to quickly determine reachability and risk impact. 

Take our preZero platform for a free spin to see how Qwiet AI can help you scan containers to mitigate runtime security risks today.