Use when performing container security scan — provides a structured process for scanning container images and runtime environments for security vulnerabilities, misconfigurations, and compliance violations. This template covers image scanning, Dockerfile best practices, runtime security policies, and remediation tracking.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add cloudthinker-ai/CloudSkills --skill container-security-scan --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Container Security Scan?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cloudthinker-ai-container-security-scan)More formats (shields.io, HTML) on the badges page.
---
name: container-security-scan
enabled: true
description: |
Use when performing container security scan — provides a structured process
for scanning container images and runtime environments for security
vulnerabilities, misconfigurations, and compliance violations. This template
covers image scanning, Dockerfile best practices, runtime security policies,
and remediation tracking.
required_connections:
- prefix: registry
label: "Container Registry"
- prefix: scanner
label: "Security Scanner"
config_fields:
- key: image_name
label: "Image Name"
required: true
placeholder: "e.g., myapp:latest"
- key: compliance_standard
label: "Compliance Standard"
required: false
placeholder: "e.g., CIS Docker Benchmark"
features:
- CONTAINER_SECURITY
- VULNERABILITY_SCAN
- SRE_OPS
---
# 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
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!