Container Security
Also Known As
Docker security
container hardening
image scanning
TL;DR
Security practices for building and running containers — minimal base images, non-root users, read-only filesystems, image scanning, and runtime security controls.
Explanation
Container security spans the full lifecycle: build (minimal base images, no secrets in layers, multi-stage builds), ship (image scanning for CVEs, signed images), run (non-root user, read-only filesystem, dropped capabilities, seccomp profiles, network policies). Containers share the host kernel — a container escape gives access to the host. PHP containers should run as a non-root user, have no write access to the application directory, and have sensitive directories mounted read-only.
Diagram
flowchart TD
subgraph Attack Surface
IMG[Base image<br/>CVEs in OS packages]
ROOT[Running as root<br/>container escape]
SECRETS[Secrets in ENV<br/>or image layers]
NETWORK[No network policy<br/>lateral movement]
end
subgraph Hardening
SCAN[Scan image: Trivy Snyk]
NONROOT[USER nonroot<br/>in Dockerfile]
VAULT[Secrets from Vault<br/>or K8s secrets]
NETPOL[NetworkPolicy<br/>deny by default]
end
IMG --> SCAN
ROOT --> NONROOT
SECRETS --> VAULT
NETWORK --> NETPOL
style IMG fill:#f85149,color:#fff
style ROOT fill:#f85149,color:#fff
style SCAN fill:#238636,color:#fff
style NONROOT fill:#238636,color:#fff
Common Misconception
✗ Containers provide strong isolation from the host — containers share the kernel; a kernel exploit or misconfigured container can escape to the host; containers are not VMs.
Why It Matters
A PHP application compromise in a misconfigured container gives the attacker root inside the container and potentially on the host — container security limits the blast radius.
Common Mistakes
- Running containers as root — if the container is compromised, the attacker has root inside it.
- Secrets in Dockerfile ENV or image layers — image history exposes them; use secrets management or runtime injection.
- Using :latest tags — unpredictable base image changes break reproducibility and introduce unknown vulnerabilities.
- Not scanning images for CVEs — vulnerable base images are used in production without awareness.
Code Examples
✗ Vulnerable
# Insecure Dockerfile:
FROM php:latest # Unpinned, unknown contents
RUN apt-get install -y curl # Extra attack surface
COPY . /app
COPY .env /app/.env # Secrets in image layer!
USER root # Running as root
EXPOSE 80
✓ Fixed
# Hardened Dockerfile:
FROM php:8.3.4-fpm-alpine AS runtime # Pinned, minimal
RUN addgroup -g 1001 app && adduser -D -u 1001 -G app app
WORKDIR /app
# Copy only production files, no secrets:
COPY --chown=app:app src/ ./src/
COPY --chown=app:app vendor/ ./vendor/
USER app # Non-root
EXPOSE 9000
# Secrets injected at runtime via env vars or secrets manager
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
40
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 14
Perplexity 9
Google 5
SEMrush 3
Ahrefs 2
Unknown AI 2
Also referenced
How they use it
crawler 34
pre-tracking 1
Related categories
⚡
DEV INTEL
Tools & Severity
🟠 High
⚙ Fix effort: Medium
⚡ Quick Fix
Run PHP-FPM as a non-root user (USER www-data), use read-only filesystem, drop all capabilities except NET_BIND_SERVICE, and scan images weekly with Trivy
📦 Applies To
PHP 5.0+
web
cli
🔗 Prerequisites
🔍 Detection Hints
PHP container running as root; no USER directive in Dockerfile; privileged container; no image vulnerability scanning
Auto-detectable:
✓ Yes
trivy
grype
hadolint
checkov
docker-bench
⚠ Related Problems
🤖 AI Agent
Confidence: High
False Positives: Medium
✗ Manual fix
Fix: Medium
Context: File
CWE-250
CWE-272