We take the security of our SMS Dashboard system seriously. If you discover a security vulnerability, please follow these steps:

1. DO NOT create a public GitHub issue for security vulnerabilities
2. Email security concerns to: [security@example.com]
3. Include the following information:
   • Type of vulnerability
   • Full paths of source file(s) related to the issue
   • Location of affected code (tag/branch/commit or direct URL)
   • Step-by-step instructions to reproduce
   • Proof-of-concept or exploit code (if possible)
   • Impact assessment

• Initial Response: Within 48 hours
• Status Update: Within 7 days
• Resolution Target:
  • Critical: 7 days
  • High: 14 days
  • Medium: 30 days
  • Low: 90 days

• NixOS: Declarative, reproducible system configuration
• Cloudflare Workers: Edge computing with built-in DDoS protection
• D1 Database: Encrypted at rest with automatic backups
• API Authentication: Dual auth system (Auth0 for users, API keys for daemons)

• Content Security Policy (CSP) headers
• XSS Protection via framework sanitization
• HTTPS Only with HSTS enabled
• SameSite Cookies for CSRF protection

• Input Validation on all API endpoints
• SQL Injection Protection via prepared statements
• Rate Limiting on API endpoints
• Request Size Limits to prevent DoS

• Memory Safety through Zig's compile-time checks
• No Buffer Overflows with bounds checking
• Safe String Handling with proper allocators
• Privilege Separation (runs as non-root user)

• Encryption in Transit: TLS 1.3 minimum
• Encryption at Rest: Database encryption
• PII Handling: Phone numbers partially masked in logs
• No Sensitive Data in Logs: API keys and passwords filtered
• Secure Secret Storage: Environment variables and SOPS

We employ multiple automated security scanning tools:

• CodeQL: Static analysis for vulnerabilities
• Semgrep: SAST with OWASP rules
• Gitleaks: Secret detection
• npm audit: Dependency vulnerabilities
• OWASP Dependency Check: Known vulnerability scanning

• Weekly Security Reports: Automated vulnerability summaries
• OpenSSF Scorecard: Security best practices evaluation
• License Compliance: Ensure compatible open-source licenses

Before submitting a PR, ensure:

• No hardcoded secrets, API keys, or passwords
• All user input is validated and sanitized
• SQL queries use prepared statements
• New dependencies are from trusted sources
• No use of eval() or similar dangerous functions
• Error messages don't leak sensitive information
• Proper authentication checks on new endpoints
• Rate limiting considered for new APIs
• Security headers included for web responses
• Logging doesn't include sensitive data

• SMS messages may contain sensitive data (OTPs, verification codes)
• Messages are stored encrypted in the database
• Access requires proper authentication
• Automatic cleanup of old messages recommended

• Orange Pi daemons use API keys for authentication
• Keys should be rotated periodically
• Keys must be transmitted over HTTPS only
• Failed authentication attempts are logged

• Treated as PII (Personally Identifiable Information)
• Partially masked in logs and error messages
• Full numbers only visible to authenticated users
• ICCID mappings provide additional privacy layer

cd sms-dashboard
npm audit --production  # Check production dependencies
npm audit fix          # Auto-fix vulnerabilities

cd orange-pi-daemon
zig build-exe src/main.zig -O ReleaseSafe  # Enable safety checks
zig test src/tests.zig -fsanitize=undefined  # Run with sanitizers

# Check for exposed secrets
gitleaks detect --source . -v

# Scan for vulnerabilities
semgrep --config=auto .

# Check dependencies
npm list --depth=0 | grep -E "(lodash|jquery|bootstrap)" # Known vulnerable packages

• OWASP Top 10
• CWE/SANS Top 25
• Zig Safety Documentation
• Cloudflare Security Best Practices

• Security Issues: [security@example.com]
• General Questions: Use GitHub Discussions
• Bug Reports: Use GitHub Issues (non-security)

This security policy is regularly reviewed and updated. Last update: January 2025