caro is a safety-first CLI tool that generates shell commands using local LLMs. Security is fundamental to our mission: we must prevent dangerous command execution while maintaining user trust in the tool.

This document outlines:

• Supported versions and security update policy
• How to report security vulnerabilities
• What qualifies as a security issue
• Our response timeline and process
• Recognition for security researchers

caro is currently in early development (v0.1.x). Security updates are provided for:

Once caro reaches v1.0.0, we will maintain security support for:

• Latest stable release: Full security support
• Previous major version: Critical security fixes only for 6 months after new major release
• Older versions: No security support (upgrade recommended)

DO NOT report security vulnerabilities through public GitHub issues.

We use GitHub's private security advisory system for vulnerability reports:

1. Navigate to the Security tab: Visit github.com/wildcard/caro/security

2. Create a private security advisory:

   • Click "Report a vulnerability"
   • Provide a clear description of the vulnerability
   • Include steps to reproduce
   • Describe the potential impact
   • Suggest a fix if possible

3. Wait for acknowledgment: We will respond within 48 hours with:

   • Confirmation of receipt
   • Initial assessment of severity
   • Expected timeline for investigation

If you cannot use GitHub's security advisory system:

• Email maintainers directly (email addresses listed in repository maintainer profiles)
• Encrypted communication: If needed, request a PGP key for sensitive disclosures

A good security report includes:

• Description: What is the vulnerability?
• Impact: What can an attacker accomplish?
• Reproduction steps: How to trigger the vulnerability
• Affected versions: Which versions are vulnerable?
• Environment: OS, Rust version, configuration details
• Proof of concept: Code, commands, or screenshots demonstrating the issue
• Suggested fix: If you have ideas for remediation (optional)

Example report structure:

Title: Command Injection via Unescaped Model Output Description: The MLX backend does not properly escape special characters in model-generated commands, allowing injection of additional commands via carefully crafted prompts. Impact: An attacker can execute arbitrary commands by providing a prompt that causes the model to generate output containing shell metacharacters (;, &&, ||, etc.). Reproduction: 1. Use MLX backend with default safety settings 2. Provide prompt: "list files" (but craft model to return "ls; rm -rf /") 3. Safety validator does not catch the injection 4. User executes the command, triggering unintended rm Affected versions: 0.1.0 - 0.1.3 Environment: - macOS 14.5, Apple M1 - Rust 1.75.0 - caro v0.1.2 Suggested fix: Apply shell escaping using the `shell-escape` crate before passing commands to the safety validator. Validate that model output contains only a single command with no metacharacters outside of quoted strings. 

Our commitment to security researchers:

For critical vulnerabilities (remote code execution, privilege escalation), we will:

• Prioritize investigation immediately
• Develop a fix within 7 days if possible
• Release an emergency patch version
• Coordinate disclosure timing with you

For high/moderate vulnerabilities, we will:

• Develop a fix for the next scheduled release
• Include the fix in the next minor version
• Coordinate disclosure after patch is available

We consider the following security vulnerabilities:

• Command injection: Ability to execute unintended commands
• Pattern evasion: Bypassing dangerous command detection
• Metacharacter exploitation: Using shell features to escape validation
• Path traversal: Accessing files outside intended scope
• Privilege escalation: Bypassing --allow-dangerous restrictions

Examples:

• Crafting prompts that cause model to generate commands that bypass safety checks
• Using shell quoting or escaping to hide dangerous patterns
• Exploiting race conditions in validation vs execution
• Unicode or encoding tricks that bypass regex patterns

• Model tampering: Ability to replace cached models with malicious versions
• Checksum bypass: Circumventing model verification
• Cache poisoning: Injecting malicious models into the cache directory
• Path substitution: Redirecting model loading to attacker-controlled files

Examples:

• Modifying cached model files to generate malicious commands
• Bypassing SHA-256 checksums during model downloads
• Symlink attacks on cache directory
• TOCTOU (time-of-check-time-of-use) vulnerabilities in model loading

• Shell injection: Executing unintended shell code
• Environment pollution: Manipulating environment variables to change behavior
• Subprocess exploitation: Using subprocess features unsafely
• Signal handling: Race conditions in command execution

Examples:

• Injecting shell commands via $() or backticks
• Setting LD_PRELOAD or other dangerous env vars
• Exploiting eval or other dynamic code execution
• Race conditions between validation and execution

• Sensitive data exposure: Leaking user data, API keys, or system information
• Prompt injection: Extracting system prompts or internal configuration
• Cache inspection: Reading cached models or manifests to gain insights
• Log leakage: Exposing sensitive information in logs or error messages

Examples:

• Prompts that cause model to output configuration files
• Reading .env files or API keys from error messages
• Accessing other users' cached models on shared systems
• Timing attacks revealing model or system state

We do not consider the following as security vulnerabilities:

• Attacks requiring physical access to the machine
• Social engineering or phishing attacks on users
• Vulnerabilities in third-party dependencies (report those upstream)
• Attacks requiring user to manually edit configuration with malicious intent

• Model generating incorrect or suboptimal commands (use GitHub Issues)
• Model failing to understand prompts (this is a model quality issue)
• Model output being slow or inefficient (performance issue, not security)

• Safety validator blocking commands you intended to run (use --allow-dangerous)
• Requiring confirmation for risky commands (this is intentional)
• Refusing to generate commands for destructive operations (by design)

• Consuming disk space with large model downloads (expected usage)
• Using significant CPU/memory during inference (expected usage)
• Denial-of-service via repeated requests (rate limiting is not implemented)

However, if you can demonstrate remote or persistent resource exhaustion vulnerabilities, those may be in scope.

While using caro:

1. Review generated commands before execution, especially for sensitive operations
2. Never use --auto mode for destructive or privileged operations
3. Keep caro updated to get the latest security fixes
4. Verify model checksums when downloading from Hugging Face
5. Limit --allow-dangerous usage to specific, understood cases
6. Check logs regularly for unexpected model or command behavior
7. Use restricted shells if deploying caro in shared environments

caro employs security-first development practices:

We apply multiple layers of security:

1. Input validation: Sanitize prompts before sending to models
2. Output validation: Check generated commands against safety patterns
3. Execution sandboxing: Consider containerization for high-risk environments
4. Least privilege: Never run as root, minimize file permissions
5. Fail-safe defaults: Block dangerous operations unless explicitly allowed

Our safety validator includes patterns for:

• Filesystem destruction: rm -rf /, mkfs, dd if=/dev/zero
• Fork bombs: :(){ :|:& };: and variants
• Privilege escalation: sudo su, chmod 777 /
• System path tampering: Operations on /bin, /usr, /etc
• Device writes: Direct device manipulation

See src/safety/patterns.rs for the complete pattern library.

• cargo-audit runs on all PRs to detect vulnerable dependencies
• deny.toml configuration restricts dependency licenses and sources
• Minimal dependencies to reduce attack surface
• Pinned versions in Cargo.lock for reproducibility

• Security-focused code review for all PRs touching safety validation
• Property-based testing with proptest for safety validator
• Integration tests for command execution paths
• Manual security testing before releases

We practice coordinated disclosure:

1. Private investigation: We investigate reported vulnerabilities privately
2. Fix development: We develop and test a fix without public disclosure
3. Coordinated release: We release the fix and coordinate disclosure with reporter
4. Public announcement: We publish a security advisory with credit to reporter

• Day 0: Vulnerability reported privately
• Day 2: Acknowledgment sent to reporter
• Day 7: Assessment and severity classification
• Day 30: Target fix release for critical issues
• Day 30+: Public disclosure after fix is released

We will work with reporters to:

• Coordinate disclosure timing
• Provide credit in security advisories
• Give advance notice of fix releases
• Respect reporter preferences for anonymity

Once a fix is released, we will:

• Publish a security advisory on GitHub
• Update CHANGELOG.md with security fix details
• Release a patch version with the fix
• Notify users via release notes and discussions

We recognize security researchers who help improve caro:

No security vulnerabilities have been reported yet. Be the first!

Security researchers who responsibly disclose vulnerabilities receive:

• Public acknowledgment in security advisories (unless anonymity is preferred)
• Credit in release notes for the fix version
• Hall of Fame listing in this document
• Priority support for future security research

Qualities we value:

• Responsible disclosure: Following our private reporting process
• Clear communication: Providing detailed, actionable reports
• Collaboration: Working with us to verify fixes
• Patience: Understanding that fixes take time to develop properly

For security concerns:

• Report vulnerabilities: GitHub Security Advisories
• Security questions: GitHub Discussions (for non-sensitive topics)
• Maintainer contact: See repository maintainer profiles for direct contact

caro takes security seriously. Thank you for helping us keep our users safe.

Last updated: 2025-10-03 Security policy version: 1.0