sandboxxer-audit

Sandbox Security Auditor

Overview

Performs comprehensive security audits of Claude Code Docker sandbox configurations and provides recommendations for hardening based on best practices.

Official Documentation References

• Dev Container Specification - Official spec
• Developing inside a Container - VS Code guide
• Advanced Container Configuration - Advanced topics
• GitHub Codespaces - Codespaces integration
• devcontainer.json Reference - Full property reference

When to Use This Skill

Use this skill when:

• User wants security audit of existing sandbox
• User asks about security best practices
• User needs to review firewall configuration
• User preparing for production deployment
• User working with sensitive data
• User wants to verify secure configuration

Do NOT use this skill when:

• Setting up new sandbox (security review is part of /sandboxxer:quickstart)
• Troubleshooting Docker connectivity issues (use /sandboxxer:troubleshoot)
• Troubleshooting native Linux/WSL2 issues (use /sandboxxer:linux-troubleshoot)

Usage

Via slash command:

/sandboxxer:audit

Via natural language:

• "Can you audit my sandbox security?"
• "Review the firewall configuration"
• "Check my sandbox for security issues"
• "What security best practices should I follow?"
• "Is my sandbox configuration secure?"

The skill will:

12-step security audit workflow with findings categorization and actionable recommendations.

1. Scan existing DevContainer configuration files
2. Audit firewall configuration and domain allowlists
3. Check for security best practices violations
4. Review exposed ports and network configuration
5. Provide prioritized security recommendations
6. Suggest concrete remediation steps

Examples

Example: Security Audit Request

User: "Can you audit my sandbox security?"

Assistant: "I'll perform a comprehensive security audit of your Claude Code Docker sandbox."

The skill will systematically check:

1. Configuration files for hardcoded secrets
2. Firewall rules and allowed domains
3. Credentials and secrets management
4. Port exposure and network configuration
5. Container permissions and capabilities
6. Volume mounts and file access
7. Network isolation settings

The audit provides:

• Security issues found (with severity ratings)
• Specific recommendations for each issue
• Commands to implement fixes
• Best practices guidance

Security Audit Workflow

1. Scan Configuration Files

Check for security issues in:

• .devcontainer/devcontainer.json
• .devcontainer/Dockerfile
• .devcontainer/init-firewall.sh
• docker-compose.yml
• Environment variable files

2. Firewall Configuration Audit

Check Firewall Mode:

grep FIREWALL_MODE .devcontainer/devcontainer.json
echo $FIREWALL_MODE

Verify Allowed Domains:

• Review ALLOWED_DOMAINS array in init-firewall.sh
• Check each domain's necessity
• Look for wildcard domains (less secure)
• Verify no suspicious or unnecessary domains

Recommendations:

• ✅ Use strict mode for production, team environments, sensitive data
• ✅ Minimize whitelisted domains - only what's absolutely needed
• ✅ Prefer specific subdomains over wildcards
• ✅ Document why each domain is needed (add comments)

Report Format:

Firewall Audit:
- Mode: [strict/permissive]
- Whitelisted domains: [count]
- Concerns:
  ⚠ domain.com - Explain why this might be problematic
  ✓ api.anthropic.com - Necessary for Claude Code

3. Credentials and Secrets Audit

Check for Hardcoded Credentials:

# Search for common password patterns
grep -r "password.*=" .devcontainer/ docker-compose.yml
grep -r "API_KEY.*=" .devcontainer/
grep -r "SECRET.*=" .devcontainer/

Verify Default Passwords:

• Check docker-compose.yml for devpassword, rootpassword, etc.
• Ensure these aren't used in production
• Verify .env files are in .gitignore

Recommendations:

• ❌ Never commit credentials to version control
• ✅ Use environment variables: ${localEnv:API_KEY}
• ✅ Use .env files (and add to .gitignore)
• ✅ Rotate credentials regularly
• ✅ Use secrets management for production (Docker secrets, Vault)

4. Port Exposure Audit

Check Exposed Ports in docker-compose.yml:

# BAD: Unnecessary exposure
postgres:
  ports:
    - "5432:5432"  # Only needed if accessing from host

# GOOD: Internal only
postgres:
  # No ports section - only accessible from Docker network

Recommendations:

• ✅ Don't expose ports unless needed from host
• ✅ Use Docker networks for inter-container communication
• ⚠ Document why ports are exposed
• ❌ Never expose in production without firewall rules

5. Container Permissions Audit

Check User Configuration in Dockerfile:

# GOOD: Non-root user
USER node

# BAD: Running as root
# USER root

Check Linux Capabilities:

"runArgs": [
  "--cap-add=NET_ADMIN",  // Required for firewall
  "--cap-add=NET_RAW"     // Required for packet filtering
]

Recommendations:

• ✅ Run as non-root user (node, UID 1000)
• ✅ Only add necessary capabilities
• ⚠ NET_ADMIN/NET_RAW needed for firewall, but are powerful
• ✅ Verify sudoers config limits what node user can sudo

6. Volume and Mount Audit

Check Volume Mounts:

"workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"

Recommendations:

• ✅ Only mount what's needed
• ❌ Never mount Docker socket unless absolutely necessary
• ✅ Use volumes for database data (not bind mounts)
• ⚠ Workspace is shared with host (by design, but be aware)

7. Network Isolation Audit

Check Network Configuration:

networks:
  default:
    name: my-project-network

Verify:

• Services on same network can communicate freely
• Network name is unique per project
• No unexpected services on the network

8. Dependency Security

For Python projects:

# Check for known vulnerabilities
uv add safety
safety check

For Node.js projects:

npm audit
npm audit fix

Recommendations:

• ✅ Audit dependencies regularly
• ✅ Keep base images updated
• ✅ Use official images only
• ✅ Pin versions in production

9. Lifecycle Hooks Security Audit

Check Lifecycle Commands in devcontainer.json:

• initializeCommand - ⚠️ Runs on HOST before container starts
• onCreateCommand - Runs once when container created
• updateContentCommand - Runs on rebuild
• postCreateCommand - Runs after creation
• postStartCommand - Runs on every start
• postAttachCommand - Runs on every attach

Example Configuration:

{
  "initializeCommand": ["docker", "version"],
  "onCreateCommand": "npm install",
  "postCreateCommand": "npm run build",
  "postAttachCommand": "echo 'Container attached'"
}

Security Concerns:

• ❌ initializeCommand has HOST access - audit carefully
• ⚠️ Verify commands don't download/execute untrusted scripts
• ✅ Use pinned versions in any package installs
• ⚠️ Avoid curl | bash patterns in lifecycle hooks
• ✅ Review all commands for potential security issues

Reference: Lifecycle Scripts

10. Dev Container Features Audit

Check Features in devcontainer.json:

"features": {
  "ghcr.io/devcontainers/features/node:1": {
    "version": "18"
  },
  "ghcr.io/devcontainers/features/python:1": {}
}

Security Recommendations:

• ✅ Use official features from ghcr.io/devcontainers/features/*
• ✅ Pin feature versions (e.g., :1 not :latest)
• ⚠️ Review third-party features before use
• ❌ Never use features from untrusted sources
• ✅ Audit feature installation scripts when possible
• ✅ Check feature source on GitHub before adding

Official Features Registry: Over 200 pre-built features available at Dev Container Features

Reference: Dev Container Features Specification

11. Dotfiles Security Audit

Check Dotfiles Configuration in devcontainer.json:

{
  "dotfilesRepository": "your-github-user/dotfiles",
  "dotfilesInstallCommand": "install.sh",
  "dotfilesTargetPath": "~/dotfiles"
}

Security Concerns:

• ⚠️ Dotfiles scripts execute automatically in container
• ❌ Don't use untrusted dotfiles repositories
• ✅ Review install scripts in dotfiles repo before use
• ✅ Use personal, controlled dotfiles only
• ⚠️ Dotfiles can modify shell config and environment
• ✅ Audit dotfiles for malicious commands

Reference: Personalizing with Dotfiles

12. Environment Variables Security

Types of Environment Variables in devcontainer.json:

{
  "containerEnv": {
    "NODE_ENV": "development"
  },
  "remoteEnv": {
    "DISPLAY": "${localEnv:DISPLAY}"
  }
}

Environment Variable Patterns:

• containerEnv - Available in container
• remoteEnv - Available to VS Code processes
• ${localEnv:VAR} - Forwarded from host
• .env files - Loaded from workspace root

Security Concerns:

• ❌ Never commit secrets in containerEnv
• ✅ Use ${localEnv:API_KEY} for secrets
• ⚠️ .env files should be in .gitignore
• ✅ Use GitHub Codespaces secrets for cloud environments
• ❌ Don't hardcode credentials in devcontainer.json
• ✅ Review all environment variables for sensitive data

GitHub Codespaces Integration:

• Use Codespaces secrets for sensitive values
• Secrets are automatically available as environment variables
• Organization-level secrets for team projects

Reference: Variables in devcontainer.json

Security Report Format

Provide comprehensive report:

# Security Audit Report - [Project Name]

## Summary
- Overall Risk Level: [Low/Medium/High]
- Critical Issues: [count]
- Warnings: [count]
- Recommendations: [count]

## Critical Issues ❌
1. [Issue] - [Explanation] - [Fix]

## Warnings ⚠
1. [Warning] - [Explanation] - [Recommendation]

## Good Practices ✅
1. [What's done well]

## Recommendations
1. [Improvement] - [Why] - [How]

## Security Checklist
- [ ] Firewall configured and tested
- [ ] No hardcoded credentials
- [ ] Default passwords changed/not in production
- [ ] Minimal port exposure
- [ ] Non-root user configured
- [ ] Dependencies audited
- [ ] Secrets properly managed
- [ ] Network isolation verified
- [ ] Lifecycle hooks reviewed (especially initializeCommand)
- [ ] Dev Container features from trusted sources
- [ ] Feature versions pinned
- [ ] Dotfiles repository trusted and reviewed
- [ ] Environment variables not exposing secrets
- [ ] GitHub Codespaces secrets configured properly (if using Codespaces)

Threat Model Reference

From docs/features/SECURITY-MODEL.md:

What we protect against:

• Accidental data exfiltration
• Malicious dependencies
• Credential theft
• Resource exhaustion

What we DON'T protect against:

• Trusted user abuse
• Docker escape
• Side-channel attacks
• Compromised base images

Hardening Recommendations

For Development

• Use strict firewall mode
• Document all allowed domains
• Use project-specific API keys
• Review AI-generated code before committing

For Production

• Switch to strict firewall if not already
• Change ALL default passwords
• Use secrets management (not env vars)
• Enable Docker security scanning
• Implement network monitoring
• Set up intrusion detection
• Regular security audits
• Resource limits on containers
• Log all firewall blocks

Key Principles

• Defense in depth - Multiple security layers
• Principle of least privilege - Minimal permissions
• Trust but verify - Audit even with firewall
• Document security decisions - Explain trade-offs
• Regular audits - Security is ongoing process

Usage Examples

Example 1: Basic Security Audit

User requests a security review of their existing DevContainer:

User: Can you audit my sandbox security?
Assistant: I'll run the security auditor to review your configuration.
/sandboxxer:audit

The skill scans configuration files, checks firewall settings, and provides a prioritized list of security recommendations.

Example 2: Pre-Production Security Check

User preparing to deploy and wants to ensure security hardening:

User: We're about to go live. Can you check if our development environment is secure?
Assistant: I'll perform a comprehensive security audit focusing on production readiness.
/sandboxxer:audit

The skill performs deep security analysis, reviews all network configurations, and provides deployment-specific recommendations.

Example 3: Firewall Configuration Review

User experiencing connectivity issues and wants to verify firewall is properly configured:

User: My API calls are being blocked. Can you check my firewall?
Assistant: I'll audit your firewall configuration.
/sandboxxer:audit

The skill reviews firewall mode, allowed domains, and provides guidance on adding necessary domains while maintaining security.

Footer

---