Docker Eng

Deep Docker workflow—image design, multi-stage builds, security, runtime config, health checks, and operations. Use when containerizing apps, hardening image...

Security Scan

An instruction-only Docker guidance skill that is internally consistent with its stated purpose and does not request credentials, installs, or other privileged access.

Purpose & Capability

The name/description (deep Docker workflow, hardening, build optimizations) matches the SKILL.md content. All recommended tools and practices (multi-stage builds, .dockerignore, Trivy/Grype, SBOMs, Vault, orchestrator probes) are relevant to containerization and image hardening; nothing requested is unrelated to the stated purpose.

Instruction Scope

The SKILL.md stays inside the scope of Docker/image workflows and checklists. It recommends scanning, non-root runtimes, healthchecks, tagging with git SHAs, etc. It does not instruct the agent to read arbitrary system files, exfiltrate data, or contact unexpected endpoints. It mentions external tools and secret managers only as recommended practices, not as required accesses.

Install Mechanism

No install spec and no code files are present. Because this is instruction-only, nothing will be downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths. It references secrets management (Vault, K8s secrets) as best practice but does not request tokens or keys in the skill metadata.

Persistence & Privilege

always is false and the skill does not request permanent presence or modify other skills or system-wide settings. Autonomous model invocation is enabled by default on the platform but that is normal and not a unique risk here.

Assessment

This skill is instruction-only and appears coherent with its Docker-focused purpose. Before installing or letting an agent act on its advice: (1) remember the skill may recommend using external tools (Trivy/Grype, SBOM generators, Vault, kubectl) — only grant registry/kube/Vault credentials when strictly necessary and to trusted agents; (2) review any concrete shell commands the agent proposes before running them; (3) if you allow autonomous agent actions, limit the agent's ability to run arbitrary commands or access broad credentials; and (4) because the skill's source is unknown, prefer to use it as read-only guidance (follow recommendations manually or in a controlled CI environment) rather than giving it privileged access. If you want higher assurance, ask the publisher for provenance (homepage, source repo) or request a version that includes reproducible checks or signed release notes.

Docker Eng — Deep Workflow

Containers package applications with their dependencies. Optimize for small, reproducible images and clear runtime contracts—not “SSH into a mini VM.”

When to Offer This Workflow

Trigger conditions:

• Authoring Dockerfiles for apps or CI
• CVEs in base images; accidental secrets in layers
• Slow builds or oversized images pushing registry costs

Initial offer:

Use six stages: (1) base image & supply chain, (2) Dockerfile structure, (3) runtime config & secrets, (4) security hardening, (5) health & observability, (6) ops & debugging). Confirm registry and orchestrator (Kubernetes, ECS, etc.).

---

Stage 1: Base Image & Supply Chain

Goal: Pin tags or digests; prefer minimal bases (distroless, slim) when compatible.

Practices

• Scan images regularly (Trivy, Grype); track SBOM where required

---

Stage 2: Dockerfile Structure

Goal: Multi-stage builds: compile in builder, copy only artifacts to runtime; order layers for cache hits (dependency manifests before source).

Practices

• Maintain a robust .dockerignore (exclude secrets, build artifacts, VCS noise)

---

Stage 3: Runtime Config & Secrets

Goal: Configuration via environment variables; secrets injected at runtime (K8s secrets, IAM, vault)—never COPY real secrets into the image.

---

Stage 4: Security Hardening

Goal: Run as non-root; read-only filesystem where possible; minimal packages in final image; avoid leaking build tools in production.

---

Stage 5: Health & Observability

Goal: HEALTHCHECK or orchestrator probes match real readiness (dependencies up); logs to stdout/stderr in structured form.

---

Stage 6: Ops & Debugging

Goal: Tag images with git SHA; document how to exec/debug (or use debug sidecars for distroless).

---

Final Review Checklist

• Base image pinned and scanned
• Multi-stage build; minimal runtime layer
• No secrets in layers
• Non-root and least privilege
• Health/readiness aligned with app
• .dockerignore and reproducible builds

Tips for Effective Guidance

• Explain layer caching order—why COPY package.json before COPY . matters.
• Distroless images: no shell—use ephemeral debug containers or sidecars.

Handling Deviations

• Windows containers: different paths and base images—validate separately.