Subscribe to Email Updates

The current understanding of “container security” as a term and market is muddled, especially given containers are used by different teams in different contexts. It could mean scanning image repositories for vulnerabilities or exposed secrets, managing credentials for container deployment, or monitoring running containers for unwanted activity. 

This confusion isn’t particularly helpful to anyone — developers and operations teams are increasingly being asked about security for their deployments, while security practitioners are looking to either secure their container-based workloads themselves or partner with their DevOps colleagues to do so. Thus, my goal in this post is to help provide some clarity around the market for all involved.

To frame the container security market by use case, I’ll be using the three phases of a typical software delivery lifecycle as outlined by the Accelerate: State of DevOps report: software development, software deployment, and service operation. Others may refer to these phases as “build,” “ship,” and “run.” I’ll highlight the primary security features of each phase, the benefits and downsides, and some of the representative vendors in the space (including open source software). Naturally, not every vendor will offer all features outlined, but hopefully it can help you navigate the vendor landscape a bit more easily.

Container Development

This phase (a.k.a. the “build” phase) is about securing the container development efforts, including container image repositories and new container images being created. The main goal is to spot vulnerabilities in the container’s code early so they can be fixed during development, rather than spotted right before a release deadline or while the container is already running in production (where it could be exploited by an attacker). However, vendors in this category often look for vulnerabilities in running containers, as well, extending into the security of operating containers, too.

Primary Features:

  • Scanning for vulnerabilities, malware, or exposed sensitive information (like API keys)
  • Blocking insecure builds and images from untrusted sources
  • Validating adherence to compliance standards or custom policies 
  • Reviewing third party dependencies and matching base images to allowlists
  • Integration into CI/CD pipelines, including source code repositories (GitHub, GitLab) and build servers (Jenkins)

Benefits:

  • Integrates security assessments earlier in the CI/CD pipeline (that “shift left” thing)
  • Surfaces obvious security issues (like known CVEs) before deployment
  • Helps enforce adherence to compliance standards (like HIPAA, PCI, or CIS benchmarks) within the context of that build.
  • Tracks vulnerabilities in running containers that weren’t previously discovered or fixed (overlapping with container operation security)

Downsides:

  • Constrained to known vulnerabilities that can also be spotted with relative ease
  • Misses container security risks beyond application vulnerabilities
  • Any sort of blocking mode adds some friction to developer workflows and the dev pipeline
  • On the flip side, flagged vulnerabilities can be ignored (especially in high volumes) and remain unfixed before deployment
  • Leaves gaps if there isn’t support for all languages and frameworks used by an organization
  • Vulnerability feeds can contain incomplete or faulty information
  • Doesn’t usually take into account context under which container images will be used 

Representative Vendors:

Note: not all companies listed offer all primary features listed.

  • Startups: Aqua Security, NeuVector, Stackrox, Sysdig, Snyk
  • Large Security: Qualys, Palo Alto Networks (Twistlock acquisition), Tenable, TrendMicro
  • Ops / Platforms: Amazon ECR, Azure Security Center, Docker Enterprise, GitHub, GitLab, Google Cloud Platform, JFrog, Synopsys
  • OSS: Anchore, Clair, OpenSCAP Workbench

Container Deployment

This phase (a.k.a. the “ship” phase) secures the container deployment phase, including built containers that are deployed to image repositories but are not yet running (either in test or prod). The main goal is to audit and ensure only the right people can access and manage container repositories or orchestration layers — because otherwise attackers or accidentally-rogue developers could tamper images, jeopardizing security and stability once those images are running. 

Primary Features:

  • Define and enforce access control policies across different clusters and workloads
  • Managing credentials across different clusters and workloads
  • Performing drift detection (spotting deviations from expected configurations) and validating the integrity of clusters and image repositories 
  • Integration into orchestration tools (AKS, Kubernetes, etc.)

Benefits:

  • Minimizes misconfigured resources that could lead to security or performance issues
  • Enforces the principle of least privilege 
  • Spot vulnerabilities in image repositories that may have been publicly disclosed since the images were originally pushed to the repo
  • Facilitates adherence to compliance standards, which often require auditing of file access and modification
  • IAM capabilities are largely available natively through cloud service providers
  • Maintaining parity between prod, QA, and dev/test environments can be simplified by properly managing configuration parameters

Downsides:

  • Kubernetes-only use case addresses a limited part of the microservices threat model
  • Doesn’t apply to serverless container instances (though that’s admittedly a minor slice of the market)
  • Lack of namespace support limits per-container policy creation

Representative Vendors:

Note: not all companies listed offer all primary features listed.

  • Startups: Aqua, NeuVector, Alcide, Octarine, StackRox, Styra, Tigera
  • Large Security: HPE (Scytale acquisition), Qualys, Trend Micro, Palo Alto Networks
  • Ops / Platforms: AWS, Azure, Docker Enterprise, GCP, RedHat OpenShift
  • OSS: Kubebench, Kubehunter, Kubediff, OpenShift (RedHat), SPIRE (SPIFFE) 

Container Operation

This phase (a.k.a. the “run” phase) secures the actual instantiation and operation of containers, once they are deployed and running in enterprise environments (especially production, but let’s not forget test or QA). The main goal is to protect against unwanted activity within containers in operation, ideally detecting and responding to an incident before it results in downtime or service degradation. 

This category also covers the collection of system telemetry to facilitate post-hoc investigation of incidents. As mentioned previously, many of the container development security vendors also track vulnerabilities in running containers, but we consider that an extension of those aforementioned capabilities.

Primary Features:

  • Detection of unwanted activity (both attacker and developer), usually either deterministic or behavioral / ML-based
  • Automatically responding to unwanted activity (like shutting it down)
  • Collecting and querying system telemetry for incident investigation and auditing
  • FIM, AV, and policy enforcement for compliance requirements
  • Integration into SIEM / log management, incident response tools, and container runtimes (Docker, CRI-O, containerd) 

Benefits:

  • Preserves uptime and reduces impact by stopping unwanted activity or detecting it quickly
  • Monitors erosion of isolation boundaries between containers
  • Reduces effort required during incident response, speeding up recovery time 
  • Upholds system resilience by enforcing immutability and ephemerality
  • Exposes information about container operations that is useful to both security and operations teams
  • Creates a feedback loop to continually improve infrastructure architecture and design
  • Creates an audit log of file-related activity to meet compliance requirements

Downsides:

  • Kernel module-based agents can create reliability and stability risks in production
  • Cloud-based analysis can create network bottlenecks and increase instance costs
  • Lack of coverage for serverless instances with host-based approaches
  • Blocklist or allowlist enforcement can create performance issues when improperly defined
  • Machine learning-based tools may generate large volumes of alerts and false positives without upfront tuning
  • Network-centric tools may interfere with orchestration-based security enforcement or service meshes

Representative Vendors:

Note: not all companies listed offer all primary features listed.

  • Startups: Capsule8, CMD, Lacework, StackRox, Sysdig, ThreatStack, Uptycs
  • Larger Security Vendors: AlertLogic, TrendMicro, VMware (Carbon Black)
  • Ops / Platforms: Amazon GuardDuty, Azure Security Center
  • OSS: Falco, osquery

Parting Thoughts

I’d love to see people referring to “container development security,” “container deployment security,” and “container operation security,” but that’s a lot of syllables — probably “build,” “ship,” and “run” will ultimately reign supreme. Nevertheless, hopefully this post helps delineate the different areas of container security and why they’re each important. As a community — not just security, but also embracing our friends in DevOps — we must work to secure the containers lest we become contained by our own failures.

Yet, it’s important to remember that we don’t live in a digital shipyard filled to the brim with containers; other types of workloads are still predominant in most enterprises. Container security is generally only one component of enterprise infrastructure protection (what of your VMs, VPCs, VPSs, V*…), which is something to consider when evaluating container security tools.

If you’d like to learn more about how Capsule8 protects your containerized systems from runtime threats to security and performance, check out our Solution Brief: How Capsule8 Protects Containerized Environments.

Scroll to Top