Skip to content
Back to skills

Container Security Scan

ASecurity

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.

  • 6 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 8, 2026
securityrustgorailsdockersecurity

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add cloudthinker-ai/CloudSkills --skill container-security-scan --agent claude-code

Installs 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 with every re-scan.

Security grade badge for Container Security Scan
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/cloudthinker-ai-container-security-scan/badge)](https://www.skillsdirectory.com/skills/cloudthinker-ai-container-security-scan)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…