We actively support the following versions with security updates:

Please do not report security vulnerabilities through public GitHub issues.

If you discover a security vulnerability, please send an email to:

[INSERT SECURITY EMAIL ADDRESS]

Include the following information:

• Type of vulnerability
• Full path of the 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

• Acknowledgment: Within 48 hours of your report
• Initial Assessment: Within 5 business days
• Regular Updates: At least once per week until resolution
• Disclosure Timeline: We aim to disclose vulnerabilities within 90 days

We support safe harbor for security researchers who:

• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of services
• Only interact with accounts they own or with explicit permission
• Do not exploit a security issue beyond what is necessary to confirm its existence
• Allow reasonable time to respond before publicly disclosing

We will not take legal action against researchers who follow these guidelines.

1. Keep Updated: Always use the latest stable version
2. SSH Keys: Use SSH key authentication, never passwords
3. Least Privilege: Run with minimum required permissions
4. Audit Logs: Review logs regularly for suspicious activity
5. Network Security: Use these tools only within trusted networks or through VPN
6. Credential Storage: Never commit SSH keys or passwords to version control

1. Input Validation: Always validate and sanitize user input
2. Command Injection: Use proper quoting and avoid eval
3. Secrets: Never hardcode credentials or secrets
4. Dependencies: Keep dependencies updated
5. Code Review: All changes require security-focused review
6. Testing: Include security test cases

• SSH-only: Remote operations use SSH exclusively
• No Root: Tools do not require root access
• Read-only: Default mode is read-only, no modifications to remote systems
• Explicit Flags: All potentially dangerous operations require explicit flags
• Connection Limits: Built-in rate limiting and connection throttling
• Secure Defaults: Conservative defaults prioritize security over convenience
• Input Validation: All input is validated before processing
• Error Handling: Errors fail securely without exposing sensitive information

This project relies heavily on SSH. Follow these SSH best practices:

1. Key-based Authentication:

   # Generate strong SSH key
   ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_servers

2. SSH Config:

   Host production-*
     User serviceaccount
     IdentityFile ~/.ssh/id_ed25519_servers
     StrictHostKeyChecking yes
     UserKnownHostsFile ~/.ssh/known_hosts_production
     ServerAliveInterval 60
     ServerAliveCountMax 3
   

3. Restrict Key Usage:

   # On remote server in ~/.ssh/authorized_keys
   command="/usr/local/bin/audit-only.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA...

• Tools require SSH access to target servers
• Use dedicated service accounts with limited privileges
• Consider using SSH bastion/jump hosts for additional security
• Implement SSH certificate authentication for larger deployments

• Server information may be sensitive
• Use --csv output carefully, may contain sensitive paths
• Store output files securely
• Consider data retention policies

• Tools should run from trusted networks
• Consider network segmentation
• Use VPN for remote access
• Implement network-level access controls

• We will respond to your report within 48 hours
• We will keep you informed throughout the resolution process
• We will credit you in security advisories (unless you prefer anonymity)
• We will not take legal action against good-faith security research

1. Report received: Acknowledge within 48 hours
2. Validation: Confirm and assess severity (5 business days)
3. Fix Development: Develop and test fix
4. Security Advisory: Draft advisory with CVE request if needed
5. Release: Deploy fix in patch release
6. Public Disclosure: Publish advisory after fix is available

We use CVSS 3.1 for severity ratings:

• Critical (9.0-10.0): Immediate action required
• High (7.0-8.9): Fix in next patch release
• Medium (4.0-6.9): Fix in next minor release
• Low (0.1-3.9): Fix in next major release

Published security advisories are available at:

• GitHub Security Advisories
• CVE database (for critical vulnerabilities)

This project uses:

• Dependabot: Automated dependency updates
• CodeQL: Static code analysis
• ShellCheck: Shell script security analysis
• Secret Scanning: GitHub secret scanning

For security concerns, contact:

• Email: [INSERT SECURITY EMAIL]
• PGP Key: [INSERT PGP KEY FINGERPRINT] (optional)

For general questions, use GitHub Discussions.

This security policy is based on best practices from:

• GitHub Security Policy Template
• OWASP Secure Coding Practices

Last Updated: October 2025