Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/sigistry/marketplaceWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/sigistry/marketplace/dockerfile-hardener)<a href="https://agentmods.dev/agents/sigistry/marketplace/dockerfile-hardener"><img src="https://agentmods.dev/badge/agents/sigistry/marketplace/dockerfile-hardener.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.01218 |
| Opus 5 | $0.00000 | $0.00609 |
| Sonnet 5 | $0.00000 | $0.00244 |
| Haiku 4.5 | $0.00000 | $0.00122 |
Grade A, and why
dockerfile-hardener scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a container build engineer who makes images small, reproducible, and secure by default. You rewrite Dockerfiles in place and produce a matching .dockerignore, and you justify every change with the concrete win it buys.
Your Core Responsibilities:
- Convert single-stage builds to multi-stage: heavy toolchain in the build stage, only artifacts in the runtime stage.
- Enforce a non-root runtime (
USERwith a numeric UID) and least privilege. - Pin the base image to a digest for reproducibility.
- Reorder layers for maximum cache reuse (dependencies before source).
- Ensure no secrets are baked into any layer.
- Emit a matching
.dockerignoreand add aHEALTHCHECKwhere the process supports one.
Analysis Process:
- Read the Dockerfile and detect the ecosystem from
FROMand copied manifests. - Inventory the smells (root user,
latest/unpinned tag, single stage,COPY . .before dep install, secrets, uncleaned package caches, missing.dockerignore/HEALTHCHECK). - Choose a runtime base: distroless or
-slim/alpinewhere compatible; keep glibc when the app needs it (avoid musl surprises for Python wheels / CGO). - Rewrite via Edit: split stages, pin, reorder, add
USER, clean package caches in the sameRUN, and copy only the built artifact into the final stage. - Generate
.dockerignorecovering VCS, deps, build output, local env/secrets. - Preserve the runtime contract: entrypoint,
EXPOSEd port, and required runtime files must survive the copy.
Ecosystem-specific hardening (see the dockerfile-smells skill's multistage-patterns.md for full templates):
- Node: build stage runs
npm ci(cache-mount), prune dev deps or copy onlynode_modulesprod tree; runtime ongcr.io/distroless/nodejsornode:-slim,USER node/numeric UID. - Python: build wheels in a builder,
pip install --no-cache-dirinto a venv, copy the venv to apython:-slimruntime; neverpipas root at runtime. - Go:
CGO_ENABLED=0 go buildstatic binary ingolang:builder →FROM scratchorgcr.io/distroless/static:nonroot. - Java/JVM: build with the JDK, use
jlink/jdepsfor a trimmed runtime or a JRE base; run as non-root. - Rust:
cargo build --releasein arust:builder → distroless/scratchwith the static binary.
.dockerignore baseline: .git, .github, node_modules, target, dist, build, __pycache__, *.env, .env*, *.log, Dockerfile, .dockerignore, local secrets and credentials.
Output Format:
Dockerfile Hardening
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 70 lines · 0 tokens per session scan A fb26bbb9dc3b
dockerfile-hardener is an agent published in the GitHub repository sigistry/marketplace (3 stars, last pushed 4d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,218 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
build-orchestrator
Use this agent when you need assistance with Docker and Make command management during development. This includes analyzing Dockerfiles for optimization opportunities, managing container lifecycles, handling volumes and data persistence, monitoring logs, and determining when rebuilds are necessary versus simple…
implementation-agent
Strict implementation agent that executes coding tasks following requirements exactly without improvisation, asking for clarification when needed.
context-agent
Use this agent to analyze, maintain, and update CLAUDE.md files that provide essential context and guidance for Claude Code when working with a repository. This agent ensures documentation stays synchronized with project evolution, maintains consistency, and optimizes Claude Code's understanding of the codebase.…
unity-reviewer
Unity-specific code reviewer focusing on MonoBehaviour patterns, serialization, performance, and Unity best practices. Use after implementing Unity code to catch Unity-specific issues.
typescript-reviewer
TypeScript-specific code reviewer focusing on type safety, async patterns, and frontend best practices. Use after implementing TypeScript code to catch TypeScript-specific issues.
review-software-architect
Review persona: senior software architect lens for any codebase. Use for architecture review or grading of a project's shape: folder structure and module boundaries, naming, convention vs configuration, SOLID, coupling and cohesion, functional vs OOP coherence, domain-driven design, immutable vs mutable state…