sandboxxer-audit

Category: Testing & Security | Uploader: andrewcchoi | Downloads: 0 | Version: v1.0（Latest）
Use when user wants to audit sandbox security, review firewall configuration, check for security best practices, or harden their Claude Code Docker sandbox environment
Changelog: Source: GitHub https://github.com/andrewcchoi/sandbox-maxxing
Directory Structure

Current level: skills/sandboxxer-audit/
📄 SKILL.md 14.3 KB
SKILL.md

---
name: sandboxxer-audit
description: Use when user wants to audit sandbox security, review firewall configuration, check for security best practices, or harden their Claude Code Docker sandbox environment
whenToUse: |
  - 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 or credentials
  - User wants to verify secure configuration
  - Before deploying to cloud environments (Azure, AWS, etc.)
  - Compliance or security review requirements
---

# 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](https://containers.dev/) - Official spec
- [Developing inside a Container](https://code.visualstudio.com/docs/devcontainers/containers) - VS Code guide
- [Advanced Container Configuration](https://code.visualstudio.com/remote/advancedcontainers/overview) - Advanced topics
- [GitHub Codespaces](https://docs.github.com/en/codespaces/quickstart) - Codespaces integration
- [devcontainer.json Reference](https://containers.dev/implementors/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:**

![Security Audit Flow](../../docs/diagrams/svg/security-audit-flow.svg)

*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**:
```bash
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**:
```bash
# 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`:
```yaml
# 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:
```dockerfile
# GOOD: Non-root user
USER node

# BAD: Running as root
# USER root
```

**Check Linux Capabilities**:
```json
"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**:
```json
"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**:
```yaml
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**:
```bash
# Check for known vulnerabilities
uv add safety
safety check
```

**For Node.js projects**:
```bash
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**:
```json
{
  "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](https://containers.dev/implementors/json_reference/#lifecycle-scripts)

### 10. Dev Container Features Audit

**Check Features** in `devcontainer.json`:
```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](https://containers.dev/features)

**Reference:** [Dev Container Features Specification](https://containers.dev/implementors/features/)

### 11. Dotfiles Security Audit

**Check Dotfiles Configuration** in `devcontainer.json`:
```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](https://code.visualstudio.com/docs/devcontainers/containers#_personalizing-with-dotfile-repositories)

### 12. Environment Variables Security

**Types of Environment Variables** in `devcontainer.json`:
```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](https://docs.github.com/en/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces) for sensitive values
- Secrets are automatically available as environment variables
- Organization-level secrets for team projects

**Reference:** [Variables in devcontainer.json](https://containers.dev/implementors/json_reference/#variables-in-devcontainerjson)

## Security Report Format

Provide comprehensive report:

```markdown
# 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

---
Comments 0
Latest | Hot
Please login before commenting.
No comments yet. Be the first one!
sandboxxer-audit

Directory Structure

SKILL.md

Report

Notice
