Saneops is proprietary software. We take security reports seriously and welcome coordinated disclosure from researchers and customers.
Reporting a vulnerability
Email: security@your-domain.com
Response SLA: we acknowledge receipt within 2 business days.
Please include:
- A clear description of the issue
- Steps to reproduce
- The affected version (commit hash, Docker image tag, or release tag)
- Your assessment of severity and impact
- Any proof-of-concept code or screenshots (please do not include real customer data)
If the issue is sensitive, encrypt your report with our PGP key: [link to public key when available — replace this line].
What NOT to do
- Do not file a public GitHub issue for security bugs.
- Do not test against production systems you do not own.
- Do not run automated scanners against our hosted service without prior written permission.
- Do not exfiltrate customer data under any circumstances.
Scope
In scope:
- The Saneops codebase
- Official Docker images and binary releases
- The hosted service at *.saneops.com (when it goes live)
- First-party documentation that could mislead users into insecure
configurations
Out of scope: - Third-party dependencies (please report to those upstream maintainers) - Social engineering of Saneops employees - Physical attacks on Saneops infrastructure - Issues requiring a privileged user to take an additional unusual action (e.g. self-XSS) - Denial-of-service via brute-force volume that doesn't bypass our rate limits
Bug bounty
We don't currently have a public bounty program. Reporters of valid issues will be credited (with their consent) in our release notes and on our security page. We're happy to discuss compensation case-by-case for high-severity findings.
Our commitments
When you report responsibly:
- We will acknowledge within 2 business days.
- We will keep you updated on progress at least every 14 days.
- We will not pursue legal action against good-faith research that follows this policy.
- We will credit you publicly when the fix ships, unless you prefer to remain anonymous.
Hardening posture
The current security posture is documented in
docs/security.md and visible at runtime to
admins at /admin/security on any deployment.
Highlights:
- bcrypt passwords; minimum 10-char policy with class diversity
- CSRF (double-submit cookie) on all UI mutations
- Per-IP sliding-window rate limits on auth + webhooks
- 5-failed-login soft-lock for 15 minutes
- AES-128-CBC + HMAC-SHA256 (Fernet) for secrets at rest
- Comprehensive security headers (CSP, HSTS, X-Frame-Options, etc.)
- Run-log redaction for any param matching token | secret | password
| apikey | webhook_url | authorization
- 5 MiB cap on inbound webhook bodies
- Tenant isolation at every query