If you discover a security vulnerability in VaneDB, please report it responsibly:

1. Do NOT open a public GitHub issue for security vulnerabilities
2. Email the maintainer at security@tsvetkov.org (or open a private security advisory on GitHub)
3. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Any suggested fixes (optional)

• Acknowledgment: Within 48 hours
• Initial Assessment: Within 7 days
• Fix Timeline: Depends on severity
  • Critical: 24-72 hours
  • High: 1-2 weeks
  • Medium: 2-4 weeks
  • Low: Next release cycle

• Memory safety issues (buffer overflows, use-after-free)
• File format vulnerabilities (malicious index files)
• Integer overflows leading to security issues
• Thread safety bugs causing data corruption
• Input validation bypasses

• Denial of service via large allocations (documented limitation)
• Performance issues
• Bugs that require physical access to the system
• Issues in dependencies (report to upstream)

VaneDB implements several security measures:

• Input validation: All public APIs validate inputs
• Bounds checking: Array accesses are bounds-checked
• Overflow protection: Integer overflow checks in file parsing
• File format validation: Magic numbers, version checks, size limits
• Atomic file operations: Crash-safe save with temp file + rename
• Sanitizer testing: AddressSanitizer and UBSan in CI

We appreciate responsible disclosure and will acknowledge security researchers who report valid vulnerabilities (with their permission).