← Penetration testing
Specialist penetration testing

Container security review

We review what goes into your images and how they're built, then test the running container inside the container engine. What would an attacker find? What could they exploit? How far could they get?

Scope your test

Delivered under Layer 7's CREST accreditation for penetration testing, by our own in-house testers. See our accreditations

Why it matters

Why containers need their own review

Containers make deployment fast and repeatable, and they repeat mistakes just as reliably. A secret baked into an image, a shell and network tools left in a production build, or a container running with too much privilege, ships to every environment that runs it.

An image scan only tells half the story. How a container behaves once it's running in its pod, with its mounts, its service account and its neighbours, is what decides whether one compromised application stays contained.

Scope

What we look at

Image contents

Base images, installed packages, known vulnerabilities, secrets left in image layers, and tooling such as shells, network utilities and SUID binaries an attacker could use.

Build hardening

Dockerfiles and build processes checked for root users, bloated base images and whether distroless or Chainguard images could be used instead.

Registry security

Who can push and pull images, whether images are signed, and whether registries are exposed.

The running container in its pod

We test from inside the running container: its security context, mounted volumes and service account token, and what it can see and reach from where it sits.

Exposed services

Ports, debug endpoints and management interfaces listening inside the container, and who can reach them.

Container escape

Privileged mode, capabilities, host mounts and runtime sockets tested for a route out to the node or into other containers.

Our approach

How we test it

  1. 01

    Review the images

    We analyse your images and build files for vulnerabilities, secrets, unnecessary tooling and hardening gaps.

  2. 02

    Get inside the pod

    Starting from a shell in a running container, we see the workload as an attacker would after compromising the application.

  3. 03

    Test the boundaries

    We test whether that foothold can escalate, escape to the node, or reach other pods, services and secrets.

What we find

Common weaknesses

Every finding comes with evidence, a risk rating and practical remediation guidance, and a free retest once it's fixed.

  • Tools left for attackers

    Shells, network utilities and SUID binaries. Attackers love living off the land: don't hand them the tools.

  • Full OS images instead of distroless

    Every package the app doesn't need is more attack surface and more to patch.

  • Outdated base images

    Images built on old base layers carrying known, exploitable vulnerabilities.

  • Exposed services

    Debug ports, admin consoles, metrics endpoints or SSH left listening in the container and reachable from other pods or the network.

  • Secrets baked into images

    Credentials and keys left in image layers, readable by anyone who can pull the image.

  • Privileged containers and mounted runtime sockets

    Root, privileged mode or a mounted Docker socket: each one turns a compromised container into a compromised node.

How it fits together

Build, package, run

Pipelines, images and clusters are one chain, and attackers move along it. Test one link, or the whole path from commit to running workload.

  1. Build

    CI/CD pipeline review

    Where code becomes an image. We check who can change what gets built, signed and pushed, and what the pipeline can reach in production.

    Learn more
  2. Package

    Container security review

    What's inside each image and how it behaves running in its pod: the tooling, privileges and exposed services an attacker would inherit.

    You're on this page
  3. Run

    Kubernetes security testing

    The cluster that schedules and connects your pods: identities, network policy, secrets and the control plane around every workload.

    Learn more
FAQ

Common questions

Do you test the running container or just the image?

Both. We review the image at rest, then test the running container from inside its pod, because privileges, mounts, tokens and network reach only show up at runtime.

How is this different from Kubernetes testing?

A container review goes deep on individual workloads: the image, and the running container in its pod. Kubernetes testing looks at the cluster around them: RBAC, network policy, secrets and the control plane.

Should we test this alongside Kubernetes and our CI/CD pipeline?

Ideally, yes. Pipelines, images and clusters are one chain, and attackers move along it: a compromised pipeline ships a backdoored image, and a weak image hands an attacker a foothold in the cluster. Testing all three together follows the whole path from commit to running workload.

Isn't an image scanner enough?

A scanner finds known vulnerable packages. It won't tell you what an attacker can do with the tooling left in the image, whether a running container can escape its pod, or how the pieces combine into an attack path.

Specialist testing

More specialist testing

Build chainCI/CD pipeline reviewLearn moreOrchestrationKubernetes security testingLearn moreDesktop appsThick client penetration testingLearn moreIdentityActive Directory security reviewLearn moreAdversary simulationOffensive security & red teamingLearn more

See all our penetration testing

Between tests: attack surface management and continuous vulnerability management.

Find out how far a compromised container could get

Tell us what you need tested and we'll give you a fixed-price quote and a clear scope, with a free retest included.

Scope your test