Container Security Scan
Phase 1: Image Analysis
Analyze the container image composition.
- Base image: ___
- Base image age (days since last update): ___
- Total layers: ___
- Image size: ___
- OS packages installed: ___
- Application dependencies: ___
- Run as root: Y/N
- Exposed ports: ___
Phase 2: Vulnerability Scan
Run vulnerability scanner and catalog findings.
| CVE ID | Package | Severity | CVSS Score | Fixed Version | Exploitable | Status |
|---|---|---|---|---|---|---|
Severity Summary:
| Severity | Count | With Fix Available | Without Fix |
|---|---|---|---|
| Critical | |||
| High | |||
| Medium | |||
| Low |
Phase 3: Dockerfile Best Practices
Evaluate against Dockerfile security checklist.
- Uses specific base image tag (not
latest) - Base image is from a trusted registry
- Multi-stage build used to minimize final image
- Runs as non-root user
- No secrets or credentials in image layers
- COPY preferred over ADD
- Health check defined
- Minimal packages installed (no unnecessary tools)
- .dockerignore file present and comprehensive
- Image is signed / verified
Phase 4: Runtime Security Assessment
- Read-only root filesystem enforced
- Resource limits (CPU, memory) defined
- Security context configured (no privilege escalation)
- Network policies restrict unnecessary connectivity
- Seccomp or AppArmor profile applied
- No host namespace sharing (PID, network, IPC)
- No host path mounts to sensitive directories
Phase 5: Remediation Priority
Decision Matrix:
| Priority | Criteria | SLA |
|---|---|---|
| P0 | Critical CVE with known exploit, fix available | 24 hours |
| P1 | Critical/High CVE, fix available | 7 days |
| P2 | Medium CVE or best practice violation | 30 days |
| P3 | Low CVE or informational finding | Next release cycle |
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Summary
- Image: ___
- Scan date: ___
- Critical vulnerabilities: ___
- High vulnerabilities: ___
- Dockerfile compliance: ___% of checks passed
- Runtime security: ___% of checks passed
Action Items
- Patch all Critical/High CVEs with available fixes
- Update base image to latest patched version
- Fix Dockerfile best practice violations
- Apply runtime security policies
- Schedule rescan after remediation
- Add image to continuous scanning pipeline