Skills docker-workflow

📦

docker-workflow

Name: docker-workflow
Author: bossjones

Content revision r2 High Risk 📁 Filesystem access⚙️ External commands🌐 Network access🔑 Env variables

Build Reliable Docker Workflows With AI

Docker projects often need consistent builds, service orchestration, debugging, and production safeguards. This skill guides Claude, Codex, and Claude Code through practical container workflows.

Supports: Claude Codex Code(CC)

⚠️ 38 Poor

Stop for confirmation before installing.

Review the plan and obtain explicit user consent before changing files.

Install with my Agent

Copy this request to your Agent. It includes the canonical Skill page and manifest.

Agent request

Review the Skillstore skill "docker-workflow" from https://skillstore.io/skills/bossjones-docker-workflow.md and its manifest at https://skillstore.io/api/skills/bossjones-docker-workflow/manifest. Verify the artifact. Stop and obtain explicit user consent before installing or changing files.

Your Agent should still show its plan and request any confirmation required by the security policy.

Agent-readable resources

Use these links when an AI agent, crawler, or script needs clean context instead of reading the full page.

Markdown detail GET /skills/bossjones-docker-workflow.md Signed manifest GET /api/skills/bossjones-docker-workflow/manifest Signed lockfile GET /api/skills/bossjones-docker-workflow/lockfile

Test it

Using "docker-workflow". A Node.js API needs a smaller production image and reliable startup checks.

Expected outcome:

A staged build plan covering dependency caching, runtime-only files, a non-root user, health checks, and image size verification.

Using "docker-workflow". A local stack needs an API, PostgreSQL, Redis, and a background worker.

Expected outcome:

A service design with isolated networks, named volumes, health-based dependencies, required secrets, and limited host port exposure.

Using "docker-workflow". A container starts but remains unhealthy and cannot reach its database.

Expected outcome:

A prioritized checklist for health output, logs, service DNS, network membership, database readiness, credentials, and port configuration.

Security Audit

High Risk

v9 • 7/23/2026 Open versioned report

Most static alerts are false positives from Markdown fences, ignore rules, localhost checks, and Docker template syntax. Confirmed risks include embedded example secrets, an executable Docker helper, and its public connectivity probe. Semantic review found insecure service defaults, secret disclosure, destructive cleanup, and unpinned images; no prompt injection was found.

Files scanned

2,499

Lines analyzed

Review items

False positives ignored

Confirmed security concerns (5)

High

examples/docker-compose.yml:91-95 examples/docker-compose.yml:120 examples/docker-compose.yml:200-202 examples/docker-compose.yml:244-246 examples/docker-compose.yml:266-268

Hardcoded Service Credentials in Reusable Compose Template

The Compose template defines predictable PostgreSQL, Redis, RabbitMQ, Grafana, and pgAdmin credentials. Copying these defaults can expose data and administrative interfaces.

The credentials are directly visible in active service definitions. Several associated interfaces are published to host ports.

High

examples/docker-compose.yml:282-297

Elasticsearch Authentication Disabled on Published Port

The Compose template disables Elasticsearch security while publishing port 9200. A non-local deployment could expose indexed data without authentication.

The active service sets xpack.security.enabled=false and publishes 9200. Docker binds published ports broadly unless deployment settings restrict them.

Medium

scripts/docker_helper.sh:310-320

Container Environment Disclosure Helper

The env command prints every environment variable from a running container. Secrets can enter terminal history, recordings, or support logs.

The helper directly runs env and sorts the unredacted output. No secret-name filtering or confirmation is present.

Medium

scripts/docker_helper.sh:200-219

Forced Cleanup Can Delete Persistent Docker Data

The cleanup command force-prunes containers, images, volumes, and networks without confirmation. Unused volumes can still contain valuable application data.

The function invokes four prune commands with forced flags. The command handler runs the function without an additional confirmation step.

Medium

examples/docker-compose.yml:219-220 examples/docker-compose.yml:240-241 examples/docker-compose.yml:262-263 examples/docker-compose.yml:309-310

Unpinned Container Images in Compose Template

Several services use latest image tags. Future pulls can introduce unreviewed changes or compromised upstream releases.

Four active services explicitly use latest tags. The template provides no digest pinning or update verification workflow.

Capability review items (6)

These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.

High

examples/docker-compose.yml:53

Database connection strings

- DATABASE_URL=postgresql://postgres:password@db:5432/myapp

The example embeds a PostgreSQL password in a database URL for a production-targeted backend service. It is example code, but users could copy the hardcoded credential into real deployments.

High

examples/docker-compose.yml:175

Database connection strings

- DATABASE_URL=postgresql://postgres:password@db:5432/myapp

The worker service repeats a PostgreSQL URL with a hardcoded password. This is a real credential hygiene issue if the Compose template is reused without changes.

High

examples/docker-compose.yml:176

Database connection strings

- REDIS_URL=redis://:redispassword@redis:6379/0

The Redis URL includes a hardcoded redispassword value. Even in examples, reusable templates should avoid embedded service passwords.

High

examples/docker-compose.yml:55

Generic API/secret keys

- SECRET_KEY=${SECRET_KEY:-dev-secret-key-change-in-production}

SECRET_KEY falls back to a static development value. If copied into deployment, this can weaken signing, session, or token protections.

Medium

scripts/docker_helper.sh:1

Unix shell invocation

#!/bin/bash

The file is an executable Bash helper that runs Docker management operations such as exec, inspect, prune, and backup. It is user-triggered, but the commands can affect host and container state.

Medium

scripts/docker_helper.sh:289

Hardcoded IP address

if docker exec "$container" ping -c 1 8.8.8.8 &>/dev/null; then

The helper actively pings public IP address 8.8.8.8 from a target container during diagnostics. This is intentional, but it is real outbound network behavior.

Risk Factors

📁 Filesystem access (15)

examples/.dockerignore:124 examples/.dockerignore:125 examples/Dockerfile.multi-stage:93 examples/Dockerfile.multi-stage:99 scripts/docker_helper.sh:94 scripts/docker_helper.sh:137 scripts/docker_helper.sh:190 scripts/docker_helper.sh:192 scripts/docker_helper.sh:232 scripts/docker_helper.sh:289 scripts/docker_helper.sh:355 scripts/docker_helper.sh:428 SKILL.md:51 SKILL.md:320 SKILL.md:413

⚙️ External commands (50)

🌐 Network access (15)

examples/docker-compose.yml:23 examples/docker-compose.yml:24 examples/docker-compose.yml:31 examples/docker-compose.yml:70 examples/docker-compose.yml:158 examples/docker-compose.yml:297 examples/docker-compose.yml:314 examples/Dockerfile.multi-stage:109 examples/Dockerfile.multi-stage:48 examples/Dockerfile.multi-stage:109 examples/Dockerfile.multi-stage:165 examples/Dockerfile.multi-stage:219 examples/Dockerfile.multi-stage:279 examples/Dockerfile.multi-stage:112 scripts/docker_helper.sh:289

🔑 Env variables (7)

examples/docker-compose.yml:53 examples/docker-compose.yml:54 examples/docker-compose.yml:175 examples/docker-compose.yml:176 examples/docker-compose.yml:55 README.md:81 SKILL.md:146

Audited by: codex View Audit History →

Share & cite this report

Share the versioned assessment report, neutral badge, embed card, and citations. Skillstore reports evidence without deciding whether this Skill is safe.

Open versioned report

Copy report link

https://skillstore.io/skills/bossjones-docker-workflow/audits/9?utm_source=security_passport&utm_medium=share&utm_campaign=versioned_report

Markdown badge

[![Skillstore security assessment](https://skillstore.io/badges/skills/bossjones-docker-workflow/security.svg)](https://skillstore.io/skills/bossjones-docker-workflow?utm_source=security_passport_badge)

HTML badge

<a href="https://skillstore.io/skills/bossjones-docker-workflow?utm_source=security_passport_badge"><img src="https://skillstore.io/badges/skills/bossjones-docker-workflow/security.svg" alt="Skillstore security assessment" loading="lazy"></a>

Embed card

<iframe src="https://skillstore.io/embed/skills/bossjones-docker-workflow.html" title="Skillstore Security Assessment" sandbox="allow-popups allow-popups-to-escape-sandbox" loading="lazy" referrerpolicy="no-referrer" width="420" height="180"></iframe>

Academic citations (APA · BibTeX · CFF)

APA citation

bossjones. (2026). docker-workflow security audit report (audit version 9) [Author version unspecified]. Skillstore. https://skillstore.io/skills/bossjones-docker-workflow/audits/9

BibTeX citation

@techreport{bossjones-bossjones-docker-workflow-2026,
  author = {bossjones},
  title = {docker-workflow security audit report (audit version 9)},
  institution = {Skillstore},
  year = {2026},
  number = {9},
  url = {https://skillstore.io/skills/bossjones-docker-workflow/audits/9},
  note = {Author version unspecified}
}

CITATION.cff

cff-version: 1.2.0
message: "If you use this Skill, cite its author and this versioned security audit report."
title: "docker-workflow security audit report (audit version 9)"
version: "unspecified"
type: report
authors:
  - name: "bossjones"
date-released: "2026-07-23"
url: "https://skillstore.io/skills/bossjones-docker-workflow/audits/9"
identifiers:
  - type: other
    value: "skillstore:bossjones-docker-workflow:audit:9"
    description: "Skillstore immutable audit report identifier"

Compare variants

2 installable variants

Each author remains a separate installable skill. The recommended variant is ranked by Skillstore evidence.

Why this variant is first

Higher Skillstore usage

Author / source Skillstore Score Evidence Confidence Skillstore usage Updated

bossjones Recommended Current

bossjones-docker-workflow

Skillstore Score 38

Evidence Confidence Medium

Skillstore usage 15

Updated

2026-08-21

AutumnsGrove

autumnsgrove-docker-workflow

Skillstore Score 38

Evidence Confidence Medium

Skillstore usage 14

Updated

2026-08-21

Skillstore Score

Why this score Evidence Confidence: Medium

Architecture

Maintainability

Content

Community

Spec Compliance

What You Can Build

Containerize a New Application

Create a multi-stage Dockerfile, .dockerignore rules, and a local Compose stack for an existing project.

Optimize Container Builds

Review layers, dependency caching, base images, build contexts, and runtime users to reduce size and improve reliability.

Diagnose Container Failures

Investigate logs, health checks, ports, mounts, processes, resources, and service networking with a repeatable workflow.

Try These Prompts

Create My First Dockerfile

Review my project structure and draft a multi-stage Dockerfile. Explain each stage and identify every project-specific value I must provide.

Build a Compose Environment

Design a Docker Compose environment for my application, database, cache, and worker. Include networks, volumes, dependencies, and health checks.

Debug a Failing Container

Diagnose this container failure using logs, health status, ports, mounts, processes, and networking. Prioritize checks and explain each conclusion.

Audit Production Readiness

Audit these Dockerfile and Compose files. Review secrets, privileges, image pinning, exposed services, health checks, build size, and destructive operations.

Best Practices

Replace all example credentials and restrict published service ports before deployment.
Review helper operations before running them on shared hosts or systems with persistent volumes.
Pin image versions, run as non-root, define health checks, and scan images before release.

Avoid

Do not copy development passwords or disabled authentication settings into shared environments.
Do not print container environment values into support tickets, recordings, or shared logs.
Do not force-prune Docker volumes without confirming ownership, backups, and retention requirements.