Aichaku is designed with security as a fundamental principle. While it doesn't handle cryptographic operations like Salty or release management like Nagare, it maintains strict security standards for file operations, path validation, and user input handling. This document outlines our security measures, compliance status, and responsible disclosure process.

Aichaku has been assessed against the OWASP Top 10 (2021) security risks, adapted for a methodology support library context:

• Path Validation: Strict validation of all file paths and output directories
• Directory Traversal Protection: Prevents ../ and absolute path exploits
• Write Restrictions: Only writes to designated .claude/output/ directories
• Read Limitations: Only reads from bundled methodology files

• No Secrets Storage: Never stores API keys, tokens, or credentials
• Secure Examples: All examples use placeholder values
• Documentation: Promotes secure practices in generated templates
• Environment Variables: Encourages proper secret management

• Path Sanitization: All file paths validated and sanitized
• Template Safety: No dynamic code execution in templates
• Command Prevention: Never executes shell commands from user input
• Markdown Escaping: Proper escaping in generated documentation

• Minimal Attack Surface: No network operations, no database
• Separation of Concerns: Methodologies isolated from implementation
• Fail-Safe Defaults: Conservative file permissions (0644)
• Stateless Design: No persistent state or sessions

• Secure Defaults: Safe configuration out of the box
• Error Handling: Generic error messages without system details
• No Debug Info: No stack traces or paths in production
• Clear Documentation: Security guidelines in all templates

• Zero Dependencies: Pure Deno implementation
• No npm Packages: Eliminates supply chain risks
• Deno Runtime: Secure-by-default permissions model
• Version Pinning: Locked Deno standard library versions

• No Authentication: Design eliminates auth vulnerabilities
• Local-Only Operation: No network authentication needed
• No User Management: No accounts or sessions to compromise
• Stateless Architecture: No session hijacking risks

• Version Tracking: Clear version info via Nagare
• No Auto-Updates: Static installation prevents tampering
• File Integrity: Generated files include metadata
• Reproducible Output: Same input produces same output

• Activity Logging: Tracks methodology usage patterns
• No Sensitive Data: Never logs personal or project details
• Audit Trail: Clear history in output directory structure
• Error Tracking: Logs failures without exposing details

• No Network Operations: Completely offline functionality
• No External Resources: All templates bundled
• No URL Processing: Eliminates SSRF entirely
• Local File System Only: No remote file access

All file operations are protected by multiple validation layers:

1. Path Validation: Reject suspicious patterns
2. Directory Constraints: Only write to allowed directories
3. Name Sanitization: Safe file naming conventions
4. Permission Control: Conservative file permissions

• File name validation (alphanumeric + safe characters)
• Path traversal prevention
• Size limits on generated content
• Template variable sanitization

• Generic error messages for users
• Detailed logging for developers (without sensitive data)
• Graceful failure modes
• No system information disclosure

# Run security-focused tests
deno task test:security

# Test path validation
deno test tests/security/path-validation_test.ts

# Test input sanitization
deno test tests/security/input-sanitization_test.ts

# Full test suite with coverage
deno task test:coverage

1. Path Traversal Testing:

   # Attempt directory traversal
   aichaku generate "../../../etc/passwd"
   # Expected: Error - Invalid path

2. Input Validation Testing:

   # Test with special characters
   aichaku create "project'; rm -rf /"
   # Expected: Sanitized to "project-rm-rf"

3. File Permission Testing:

   # Check generated file permissions
   ls -la .claude/output/
   # Expected: -rw-r--r-- (0644)

We appreciate responsible disclosure of security vulnerabilities.

1. Create Issue: Use GitHub Issues with [SECURITY] tag
2. Email: security@aichaku.dev (if available)
3. Include:
   • Detailed description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested remediation (if any)

• Acknowledge receipt within 48 hours
• Provide updates on remediation progress
• Credit researchers (if desired) in release notes
• No legal action against good-faith researchers

• Denial of Service attacks on local file system
• Social engineering
• Physical access attacks
• Issues requiring root/admin privileges

Aichaku tracks:

• Failed path validation attempts
• Invalid input patterns
• File operation errors
• Unusual usage patterns

• OWASP Top 10 (2021): Adapted for local tools
• File System Security: Best practices for path handling
• Input Validation: Industry standard sanitization
• Error Handling: Security-conscious messaging

Initial Security Implementation:

• Path traversal protection with comprehensive validation
• Input sanitization for file names and content
• Secure file permissions (0644) for all generated files
• Error messages that don't expose system information
• Zero network operations by design
• No dependency vulnerabilities (zero dependencies)
• Comprehensive security test suite
• Documentation emphasizing security practices

InfoSec: Establishes security-first foundation for methodology support

Following security principles from Salty:

1. Never Trust User Input: All paths and names validated
2. Fail Securely: Safe defaults and graceful failures
3. Minimize Privileges: Only necessary file permissions
4. Defense in Depth: Multiple validation layers
5. Secure by Default: No configuration needed for safety
6. No Sensitive Data: Never store personal information

Last Security Review: 2025-01-05
Next Scheduled Review: 2025-04-05
Security Contact: Create Issue