You containerized. But is your container running as root?
Containerization and container security are not the same thing. The deployment problem is solved. The security model did not come along for the ride.
The base image comes from Docker Hub, last updated 18 months ago, 47 known CVEs. No Seccomp profile. No SBOM. Capabilities not reduced. This is the new legacy, just one that grew faster than the old one. Secure Container Platform Automation addresses what container runtimes do not automatically deliver.
The Container Hardening Gap
Containerization solves a deployment problem. It does not solve a security problem. The two are conflated too often, and that is where attack surface grows unnoticed.
- Reproducible deployments across environments
- Isolation of runtime dependencies
- Scalability and faster rollouts
- Uniform packaging format per OCI standard
- Portability across Docker, Podman, and Kubernetes
- Rootless configuration: container runs as root by default
- Seccomp profile: all kernel syscalls permitted, not only the required ones
- Linux capability drops: CAP_SYS_ADMIN and CAP_NET_ADMIN remain active
- SBOM: no visibility into which packages and versions are in the image
- Image policy: Docker Hub without CVE tracking or lifecycle management
What a secure container baseline contains
Five technical layers that together form a solid security model for container environments. Each layer addresses a specific attack surface.
Containers run without root privileges on the host system. Docker and Podman both support rootless operation. A compromised container cannot gain privileged host access.
Kernel syscall filtering: only the system calls the container actually needs are permitted. All others are blocked. This significantly reduces attack surface at the kernel level.
CAP_NET_ADMIN, CAP_SYS_ADMIN, and CAP_SYS_PTRACE are removed. The container receives only the permissions its function actually requires.
Software Bill of Materials for every image: complete package list, versions, and CVE mapping. During an incident the team knows immediately which packages were in the image and which are affected.
Only internally validated images reach production. No unvetted base images from public registries. Base image lifecycle with a defined update cadence and CVE tracking.
Where container security projects start today
VM to container: security model left behind
The migration is complete, the application runs in a container. The security model from the VM world was carried forward to the new deployment format, but container-specific hardening is missing entirely. Rootless was "too complex." Seccomp is unknown.
Docker Hub as the primary image source
Base images come directly from Docker Hub, some last updated many months ago. No internal registry, no CVE tracking, no policy defining which images are production-ready. The actual CVE exposure is unknown.
CI/CD pushes directly from a public base image
The build pipeline pulls the base image from a public registry and deploys it to production without a gate. No scan, no SBOM. What actually lands in production is not fully known.
OCI images from the policy model
GIaaS (Golden Image as a Service) can produce container images as a delivery format. The hardening policy is defined once, the build process is automated, and the result is an OCI-compliant image pushed versioned with metadata into the internal registry.
Hardening requirements, capability drops, Seccomp profile, and permitted packages are expressed as code and versioned.
The image is built automatically and checked against the policy. A CVE match stops the build. The result is traceable and reproducible.
The hardened image is pushed versioned with SBOM and metadata into the internal registry, or made available as a direct download.
Container hardening today. Kubernetes-ready tomorrow.
Container is the first step in the SPAS module path. What is built here as rootless containers, Seccomp profiles, and OCI images is the direct foundation for secure Kubernetes deployments. No restart, no break in the security architecture.
Secure Kubernetes Platform AutomationConcept, not a waiting list
This module is in the concept phase. The logic and target architecture are clear. Technical implementation is developed along concrete customer requirements.
What is possible today: container security architecture advisory via EaaS, assessment of the existing container landscape, and planning the hardening path.
- EaaS for container security projects
- Architecture advisory for container hardening
- Assessment of existing image policy and registry situation
- Planning the migration path from VM to hardened container
- NIS2, CIS Docker Benchmark, and ISO 27001 as reference frameworks
This Module is in Concept Development
The target architecture is defined. Implementation follows real requirements. If container security is on your roadmap, reach out. We prioritize based on concrete need.
→ GIaaS: Golden Image as a ServiceContainer security on your roadmap? Let us map out what is possible today.
No commitment · No sales pitch · Confidential
