Fetches docker-security-guide from josiahsiegel/claude-plugin-marketplace and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/docker-security-guide
Restart Cursor to activate docker-security-guide. Access via /docker-security-guide in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
# Use official images onlyFROM node:20.11.0-alpine3.19 # Official, specific version# NOTFROM randomuser/node # Unverified sourceFROM node:latest # Unpredictable, can break
# Build stage with build toolsFROM golang:1.21 AS builderWORKDIR /appCOPY . .RUN go build -o app# Final stage - minimal, no build toolsFROM gcr.io/distroless/base-debian11COPY--from=builder /app/app /USER nonroot:nonrootENTRYPOINT ["/app"]
Benefits:
No compiler/build tools in production image
Secrets used in build don't persist
Smaller, more secure final image
Build-Time Security
Secrets Management
NEVER:
# BAD - Secret in layer historyENV API_KEY=abc123RUN git clone https://user:[email protected]/repo.gitCOPY .env /app/.env
DO:
# Use BuildKit secrets# syntax=docker/dockerfile:1FROM alpineRUN--mount=type=secret,id=github_token\ git clone https://$(cat /run/secrets/github_token)@github.com/repo.git
# Build with secret (not in image)docker build --secretid=github_token,src=./token.txt .
BuildKit Frontend Security (2025)
Threat: Malicious or compromised BuildKit frontends can execute arbitrary code during build
🚨 2025 CRITICAL WARNING: BuildKit supports custom frontends (parsers) via # syntax= directive. Untrusted frontends have FULL BUILD-TIME code execution and can:
Steal secrets from build context
Modify build outputs
Exfiltrate data
Compromise the build environment
Risk Example:
# 🔴 DANGER - Untrusted frontend (code execution risk!)# syntax=docker/dockerfile:1@sha256:abc123...untrustedFROM alpineRUN echo "This frontend could do anything during build"
Mitigation:
Only use official Docker frontends:
# ✅ Safe - Official Docker frontend# syntax=docker/dockerfile:1# ✅ Safe - Specific version# syntax=docker/dockerfile:1.5# ✅ Safe - Pinned with digest (verify from docker.com)# syntax=docker/dockerfile:1@sha256:ac85f380a63b13dfcefa89046420e1781752bab202122f8f50032edf31be0021
Verify frontend sources:
Use ONLY docker/dockerfile:* frontends
Pin to specific versions with SHA256 digest
Verify digests from official Docker documentation
Never use third-party frontends without thorough vetting
Audit all Dockerfiles for unsafe syntax directives:
# Check all Dockerfiles for potentially malicious syntax directivesgrep-r"^# syntax=".--include="Dockerfile*"# Verify all frontends are official Docker imagesgrep-r"^# syntax=".--include="Dockerfile*"|grep-v"docker/dockerfile"
BuildKit security configuration (defense in depth):
# Restrict frontend sources in BuildKit config# /etc/buildkit/buildkitd.toml[frontend."dockerfile.v0"]# Only allow official Docker frontends allowedImages =["docker.io/docker/dockerfile:*"]
Supply Chain Protection:
Treat custom frontends as HIGH RISK code execution vectors
Review ALL # syntax= directives in Dockerfiles before builds
Use content trust for frontend images
Monitor for frontend vulnerabilities
Include frontend verification in CI/CD security gates
SBOM (Software Bill of Materials) Generation (2025)
Critical 2025 Requirement: Document origin and history of all components for supply chain transparency and compliance.
Why SBOM is Mandatory:
Supply chain security visibility
Vulnerability tracking and response
Compliance requirements (Executive Order 14028, etc.)
License compliance
Incident response readiness
Generate SBOM with Docker Scout:
# Generate SBOM for imagedocker scout sbom IMAGE_NAME
# Export SBOM in different formatsdocker scout sbom --format spdx IMAGE_NAME > sbom.spdx.json
docker scout sbom --format cyclonedx IMAGE_NAME > sbom.cyclonedx.json
# Include SBOM attestation during build# ⚠️ WARNING: BuildKit attestations are NOT cryptographically signed!docker buildx build \--sbom=true \--provenance=true \--tag my-image:latest \.# View SBOM attestations (unsigned metadata only)docker buildx imagetools inspect my-image:latest --format"{{ json .SBOM }}"
🚨 CRITICAL SECURITY LIMITATION:
BuildKit attestations (--sbom=true, --provenance=true) are NOT cryptographically signed. This means:
Anyone with push access can create tampered attestations
SBOMs can be incomplete or falsified
Provenance data cannot be trusted without external verification
For production: Use external signing tools (cosign, Notary) and Syft for SBOM generation
Generate SBOM with Syft:
# Install Syftcurl-sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh |sh# Generate SBOM from imagesyft my-image:latest
# Generate in specific formatsyft my-image:latest -o spdx-json > sbom.spdx.json
syft my-image:latest -o cyclonedx-json > sbom.cyclonedx.json
# Generate from Dockerfilesyft dir:. -o spdx-json > sbom.spdx.json
SBOM in CI/CD Pipeline:
Implementation Guide
Prerequisites
›Claude Desktop or compatible AI client with skill support
›Clear understanding of task or problem to solve
›Willingness to iterate and refine outputs
Time Estimate
15-45 minutes depending on use case complexity
Steps
1Install skill using provided installation command
2Test with simple use case relevant to your work
3Evaluate output quality and relevance
4Iterate on prompts to improve results
5Integrate into regular workflow if valuable
Common Pitfalls
⚠Expecting perfect results without iteration
⚠Not providing enough context in prompts
⚠Using skill for tasks outside its intended scope
⚠Accepting outputs without review and validation
Best Practices
✓ Do
+Start with clear, specific prompts
+Provide relevant context and constraints
+Review and refine all outputs before using
+Iterate to improve output quality
+Document successful prompt patterns
✗ Don't
−Don't use without understanding skill limitations
−Don't skip validation of outputs
−Don't share sensitive information in prompts
−Don't expect skill to replace human judgment
💡 Pro Tips
★Be specific about desired format and style
★Ask for multiple options to choose from
★Request explanations to understand reasoning
★Combine AI efficiency with human expertise
When to Use This
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
Learning Path
1Familiarize yourself with skill capabilities and limitations
2Start with low-risk, non-critical tasks
3Progress to more complex and valuable use cases
4Build expertise through regular use and experimentation
