We release patches for security vulnerabilities in the following versions:

Note: vibe-validate is currently in beta (0.9.x releases). We recommend always using the latest version for the most up-to-date security fixes.

Please do not report security vulnerabilities through public GitHub issues.

Instead, please report security vulnerabilities via email to:

jeff.r.dutton@gmail.com

You should receive a response within 48 hours. If for some reason you do not, please follow up via email to ensure we received your original message.

Please include the following information in your report:

• Type of vulnerability (e.g., command injection, path traversal, etc.)
• Full paths of source file(s) related to the vulnerability
• Location of the affected source code (tag/branch/commit or direct URL)
• Any special configuration required to reproduce the issue
• Step-by-step instructions to reproduce the issue
• Proof-of-concept or exploit code (if possible)
• Impact of the issue, including how an attacker might exploit it

This information will help us triage your report more quickly.

1. Initial Response: Within 48 hours of report submission
2. Triage: Within 5 business days - we'll confirm the vulnerability and begin work on a fix
3. Fix Development: Depends on complexity, but we aim for < 2 weeks for critical issues
4. Release: Security patches are released as soon as possible after verification
5. Disclosure: Public disclosure after patch is released and users have had time to update

vibe-validate executes user-defined commands from configuration files using shell: true by design.

Threat Model:

vibe-validate's command execution follows the same trust model as npm/pnpm scripts:

• Command Source: Commands are defined in vibe-validate.config.yaml (user-controlled file in the repository)
• Trust Level: Same as scripts in package.json - users control what commands execute
• Attack Surface: Commands are NOT constructed from:
  • CLI arguments
  • Environment variables from untrusted sources
  • External user input
  • Network responses

Why shell: true is Used:

vibe-validate requires shell: true to provide the features users expect:

1. Shell Operators: Support for &&, ||, |, >, < in commands
   • Example: "npm test && npm run build"
2. Environment Variables: Users can set variables inline
   • Example: "NODE_ENV=test vitest"
3. Cross-Platform: Automatically uses cmd.exe on Windows, sh on Unix
4. Command Chaining: Multiple commands in a single validation step

Not Vulnerable To:

• ❌ CLI injection (commands not from command-line arguments)
• ❌ External input injection (no user input in command construction)
• ❌ Environment variable injection (no untrusted $VAR expansion)
• ❌ Third-party API injection (no network-based command construction)

User Responsibilities:

Users should:

• Only use configuration files from trusted sources
• Review all validation step commands before running validation
• Be cautious with third-party templates that execute arbitrary commands
• Treat vibe-validate.config.yaml like package.json (code review required)

vibe-validate interacts with git repositories. Security features:

• All git branch names are sanitized to prevent command injection
• Git commands use array-based spawn() to avoid shell injection (see git package tests)
• No arbitrary git commands are executed - only specific safe operations
• File Operations: Tree hash calculation uses Node.js fs module (not shell commands)
  • fs.copyFileSync() instead of cp command (prevents injection in file paths)
  • fs.unlinkSync() instead of rm command (prevents injection in file paths)
  • No string interpolation in shell commands for file operations

vibe-validate stores validation state in git notes:

• Validation history is stored in git notes under refs/notes/vibe-validate/runs
• No user credentials or secrets should be stored in validation state
• Git notes may contain error output from validation commands
• Git notes are not pushed by default (requires explicit git push origin refs/notes/*)

vibe-validate respects standard environment variables but does not:

• Execute code from environment variables
• Store secrets in environment variables
• Log environment variables to state files or logs

1. Trust Your Configuration: Only use configuration files from trusted sources
2. Review Templates: Examine template configurations before using them
3. Keep Updated: Use the latest version of vibe-validate for security fixes
4. Audit Commands: Review all validation commands in your config
5. Limit Scope: Run validation in isolated environments (CI/CD, containers) when possible

• User-Provided Commands: vibe-validate executes commands defined in user configuration files. Users are responsible for ensuring these commands are safe.
• Error Output: Validation error output is embedded in state files. Ensure error messages don't contain sensitive information.
• Git Repository Access: vibe-validate requires read/write access to the git repository for tree hash calculations.

We follow these practices during development:

• Dependency Auditing: Regular pnpm audit checks for vulnerable dependencies
• Static Analysis: ESLint with security-focused rules
• Code Review: All changes require review before merging
• Automated Testing: Comprehensive test suite including security-focused tests
• Minimal Dependencies: We minimize third-party dependencies to reduce attack surface

If you have questions about this security policy, please email jeff.r.dutton@gmail.com.