Member post by Rob Newsome, Head of Product Management at

Container runtime security represents the proactive measures and controls used to protect a containerized application during its runtime phase. In the contemporary world of DevOps, where rapid deployment of applications is essential, the use of containers has become increasingly prevalent. These containerized environments are designed to be lightweight, portable, and scalable. However, they also introduce new vectors for potential security vulnerabilities during runtime, hence the need for specialized measures to ensure their security.

The Importance of Container Runtime Security

Containers have a distinct lifecycle – build, ship, and run. While significant emphasis has been placed on security during the build (i.e., container image scanning) and ship (i.e., secure container orchestration) stages, runtime is often less scrutinized. Nevertheless, this stage is critical since it’s when the applications are live and processing data, making them enticing targets for potential attackers.

Containers are isolated, but they share the host’s kernel. If a malicious actor breaks out of one container, they may gain access to other containers or the host, resulting in a significant security incident. Thus, it’s paramount to have robust security measures in place during runtime.

How Does Container Runtime Security Work?

Container runtime security involves monitoring and protecting the containerized environment in real-time. This typically involves examining the system calls in the Linux kernel made by the containerized processes. Any anomalous or potentially harmful activity can be detected and alerted, or blocked.

Take Falco, an open-source project from Sysdig, as an example. It provides runtime security for containers by tapping into the Linux kernel data, using eBPF (Extended Berkeley Packet Filter) tools, and checking the system calls against a set of rules defined in a YAML file. If a system call breaks a rule, Falco sends an alert.

Here is an example of a Falco rule:

- rule: Unexpected inbound tcp connectiondesc: Detect inbound network connections to applicationscondition: >
    inbound and not trusted and container
  output: >
    Inbound connection to %container.image.repository% (command=%proc.cmdline% image=%container.image.repository%) from to %fd.dip%:%fd.dport% ( command=%proc.cmdline% image=%container.image.repository%)
  priority: WARNING

In this rule, Falco will alert if it detects any unexpected inbound TCP connections to any running containers.

Options for Implementing Container Runtime Security

Several tools are available for implementing container runtime security, each with its strengths and features.

Responding to Threats

Once a potential threat is detected, it’s crucial to respond promptly to minimize damage. This might involve killing a compromised container, isolating it for further investigation, or rolling back to a previous version. Incident response procedures should be automated as much as possible.

For example, in Falco, once a rule is breached, it can trigger an alert or an automated response. Alerts can be forwarded to a specified location, like a file, a stdout, or a webhook, which can further trigger automated responses such as Kubernetes API calls to kill the offending pod.

program_output:enabled: truekeep_alive: falseprogram: "jq '{text: .output}' | curl -d @- -X POST"

This example shows a Falco output configuration where it sends JSON formatted output to a specified webhook.


In conclusion, container runtime security is an essential facet of a comprehensive security strategy in a DevOps environment. The dynamic nature of containers necessitates real-time, automated protection measures. There are various tools available like Falco, Aqua Security, Sysdig Secure, and more that provide robust runtime security. Automated and prompt response to threats ensures the resilience and reliability of the containerized applications, protecting data and system resources while maintaining the speed and agility that make containers so attractive in the first place.