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.
npx skills add UnboundCompute/security-agent-skills --skill auditing-container-image-build-hardeninggit clone --depth 1 https://github.com/UnboundCompute/security-agent-skillsWrote 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/skills/unboundcompute/security-agent-skills/auditing-container-image-build-hardening)<a href="https://agentmods.dev/skills/unboundcompute/security-agent-skills/auditing-container-image-build-hardening"><img src="https://agentmods.dev/badge/skills/unboundcompute/security-agent-skills/auditing-container-image-build-hardening/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/unboundcompute/security-agent-skills/auditing-container-image-build-hardening"><img src="https://agentmods.dev/badge/skills/unboundcompute/security-agent-skills/auditing-container-image-build-hardening.svg" alt="Reviewed on agentmods" width="80" 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.00171 | $0.01998 |
| Opus 5 | $0.00086 | $0.00999 |
| Sonnet 5 | $0.00034 | $0.00400 |
| Haiku 4.5 | $0.00017 | $0.00200 |
Grade A, and why
auditing-container-image-build-hardening scanned grade A with 1 finding 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 11d 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.
Asks for rootlowPrivilege escalation
A mod that escalates privileges can change anything on the machine, not only the project.
Dockerfile deployed under a non-root security context does not run as root. So the bug here is not an Downgraded: this mod is about security review, or the phrase is quoted, so it is likely naming the pattern rather than instructing it.
How it starts
The opening of the file, as written. The whole thing — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Auditing container image build hardening: what survives into the shipped image
A secret used in a build stage that a multi-stage build discards is not in the shipped image, and a root Dockerfile deployed under a non-root security context does not run as root. So the bug here is not an instruction in isolation; it is what survives into the final image layer and the runtime request that ships with it. This audit reads the build definition and asks, per concern, whether the image that ships runs unprivileged, carries no secret in any layer, pulls only pinned and verified content, and requests no dangerous runtime privilege. The checklist competitors flag the instruction; the finding that survives is the one a later build stage or a deploy-time override does not neutralize. Stay on the image build plane, and hand deploy-time privilege to the Kubernetes skill and cloud resources to the infrastructure skill.
When to use
- You have a Dockerfile or containerfile, or a compose or run config that sets container runtime flags.
- An instruction sets the user, copies files, fetches remote content, pins a base, or requests a privilege.
- You want to know what survives into the shipped image, not which instruction looks wrong in isolation.
Scope check
Audit only build definitions for images you own or are authorized to assess, and never push or run a built image to test a finding against shared infrastructure, adjudicate on the layers and the config. If you can't name the authorization, stop.
The loop
-
Trace what reaches the final stage first. Follow the build stages and note what the shipping stage actually contains: which stage the final image is built from, what a copy-from carries forward, and which runtime fields come from the deploy manifest rather than the build. A secret or a root default only matters if it survives into the shipped image or is not overridden at deploy; settle that first.
-
Check the run-as user. Look for no user directive, or a user set to root, so the final image defaults to the root account, then check whether the deploy-time security context or a non-root user in the base image overrides it. This is the image default; the Kubernetes skill owns the deploy-time context.
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.
- 11d ago First seen · 130 lines · 171 tokens per session scan A 558a9ebed7d3
auditing-container-image-build-hardening is a skill published in the GitHub repository UnboundCompute/security-agent-skills (5 stars, last pushed 3d ago), licensed MIT. It adds 171 tokens to every session and 1,998 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 1 finding (asks for root). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
cloud-security-engineer
Cloud Security Engineer role bundle for cloud security posture management, IaC review, container security, and identity governance across AWS, Azure, and GCP. Orchestrates cloud-specific posture reviews and zero trust program assessments. Auto-invoked when the user needs help with cloud security configuration, IaC…
container-security
Performs a container and Kubernetes security review against the CIS Docker Benchmark v1.6.0, CIS Kubernetes Benchmark v1.9.0, and NIST SP 800-190. Auto-invoked when reviewing Dockerfiles, Kubernetes manifests, Helm charts, or container orchestration configurations. Evaluates image security, runtime hardening, RBAC…
sandbox-guard
Generate Docker sandbox configurations for safely running untrusted OpenClaw skills. Isolates filesystem, network, and process access.
prodcheck-review
Review this codebase against the prodcheck pre-production checklists — security, performance, scale, integrations and post-launch readiness. Use when asked to check whether a project is ready to ship, to audit an area before launch, or to work through a specific checklist. Produces evidence with file:line citations…
dockerfile-scan
Scan a Dockerfile for insecure build patterns — running as root, unpinned or :latest base images, ADD from remote URLs, piping curl/wget into a shell, hardcoded secrets in ENV/ARG, world-writable chmod 777, and sudo usage. Use when the user asks to "review my Dockerfile", "is this container image secure", "lint my…
analyzing-kubernetes-audit-logs
Parses Kubernetes API server audit logs (JSON lines) to detect exec-into-pod, secret access, RBAC modifications, privileged pod creation, and anonymous API access. Builds threat detection rules from audit event patterns. Use when investigating Kubernetes cluster compromise or building k8s-specific SIEM detection rules.