In my previous blog, I defined the critical capabilities of Container Native Application Protection across five key domains.  These domains were aligned to the NIST Cybersecurity Framework as an easy guide to evaluate these capabilities.  Now that the critical capabilities are defined, let’s compare and contrast them with the other approaches.  In this blog, let’s focus on the kernel plugin approach.

For this comparison, I’m going to consolidate a number of critical capabilities into the “Top 10”.  These “Top 10” address the critical runtime capabilities across all five domains.  Since the Identify domain focuses primarily on static images, I have not included it in this review.  Also, the static analysis components of the Detect domain are also not included in this review.


This domain focuses on initial deployment and supported technology requirements of the solution.  For this domain, I’ve included the following five key deployment capabilities combined into the first three of our “Top Ten” for comparison:

  • Does not require changes to container infrastructure (i.e., kernel module, host agent, etc.)
  • Supported technologies, including:
    • Support for Container as a Service (i.e., AKS, ECS, EKS, GKS, etc.),
    • Support for Function as a Services (i.e., Lambda), and
    • Support for Serverless Computing
  • Does not require root privileges/commands to run (i.e., nsenter, capsysadmin, etc.)

Since the kernel plugin requires a kernel module to be installed on the host, changes to the underlying container infrastructure is required.  This also limits such solutions portability to Container-as-a-Service, Function-as-a-Service, and Serverless Computing offerings.


Now remember, we’re skipping Identify and focusing on the runtime aspects of Detect.  This domain focuses on identifying cybersecurity events and detection processes for running containers.  For this domain, I’ve included the following four key detection capabilities combined into the fourth of our “Top Ten” for comparison:

  • Dynamic, or runtime, analysis, including:
    • Monitor system calls
    • Monitor storage activity (i.e., read, write, volume mounts)
    • Monitor network communication (i.e., ports, services, protocols)
    • Monitor application calls

Although the kernel module can monitor system, storage, and network activity, it does not natively support the ability to monitor application activity.  Additional capabilities would need to be added, specific to the application languages(s).


This domain focuses on implementing appropriate protective safeguards for containers, specifically at runtime.  For this domain, I’ve included the following nine key protection capabilities combined into the next five of out “Top Ten” for comparison:

  • Support for dynamic policy enforcement (i.e., real-time policy updates)
  • Dynamic, or runtime, protection, including:
    • Enforce system call activity/behavior
    • Enforce storage activity/behavior (i.e., read, write, volume mounts)
    • Enforce network communication (i.e., ports, services, protocols)
    • Enforce application call activity/behavior
  • Additional file/storage protection, including:
    • Enforce binary whitelist
    • Enforce file/binary integrity
  • Isolate/segment container-level communication (i.e., micro-segmentation)
  • Enforce application call path

The same limitation from above, lack of native application support, impacts the comparison here, as well.  The kernel module can support the system, storage, and network capabilities identified.


This last domain focuses on actions to address cybersecurity events, commonly known as incident response.  For this domain, I’ve included the following three key response capabilities combined into the last of our “Top Ten” for comparison:

  • Alerts and notifications, including:
    • Support allow and alert
    • Support allow, capture, and alert
    • Support block and alert

The same limitation from above, lack of native application support, impacts the comparison here, as well.  The kernel module has limited response capabilities for the application.


Although the kernel plugin covers three quarters or more of the critical capabilities across the Detect, Protect, and Respond domains, it’s deployment capabilities are lacking.  If your organization is looking to migrate to Container-as-a-Service, Function-as-a-Service, or Serverless computing options, then the kernel plugin approach will require you to re-architect your security solution.

On the other hand, a Container Native approach provides the added application protection and flexible deployment options.  You can learn more by visiting, requesting a demo here, or contacting us at [email protected].