| SQOUT® Log in

SQOUT Security Policy

Notice: This security policy outlines how we handle vulnerability reports and our commitment to security best practices.

Reporting a Vulnerability

If you discover a security vulnerability in SQOUT, please email krelina@qudef.com with:

  • Description of the vulnerability
  • Steps to reproduce the issue
  • Potential impact of the vulnerability
  • Your contact information (optional)

Do not open public GitHub issues or disclose vulnerabilities publicly before we have had a chance to address them.

Responsible Disclosure Timeline

Day Action
Day 1 You report the vulnerability
Day 3 We acknowledge receipt and begin investigation
Day 7 We provide an initial assessment and timeline for fix
Day 30 We aim to have a patch ready and tested
Day 60 Public disclosure (after you've had time to patch)

Scope

✓ IN SCOPE

We welcome reports on:

  • Authentication & authorization bypass
  • SQL injection / NoSQL injection
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Broken access control
  • Sensitive data exposure
  • Insecure deserialization
  • Using components with known vulnerabilities
  • Insufficient logging & monitoring
  • Quantum cryptography implementation flaws
✗ OUT OF SCOPE

Please don't test:

  • Denial of Service (DoS) attacks
  • Brute force attacks or password spraying
  • Social engineering or phishing
  • Physical security issues
  • Third-party services (contact them directly)
  • Accessing other users' data beyond disclosure
  • Outdated browser/plugin compatibility
  • Missing security headers (low-priority)

Security Practices

  • Data in Transit: HTTPS is enforced — plain HTTP is redirected and HSTS is sent. The TLS version itself is settled by the proxy terminating your deployment
  • Password Security: Passwords are hashed using industry-standard algorithms
  • API Authentication: API endpoints use opaque bearer tokens — 48 bytes of randomness, stored only as a SHA-256 hash and never in plaintext
  • Credentials Management: Database credentials and secrets are managed via environment variables (never hardcoded)
  • Security Updates: Regular security updates are applied promptly
  • Audit Logging: Sensitive operations are logged for accountability and monitoring
  • Django Security: We follow Django 6 security best practices and keep dependencies updated

Recognition

Security researchers who responsibly disclose vulnerabilities will be:

  • Credited in our release notes (if desired)
  • Added to our Security Contributors list
  • Invited to test pre-release versions

Questions?

For any questions about this security policy, please reach out to:

krelina@qudef.com

Last Updated: 19 September 2026
Policy Version: 1.2
Canonical URL: /.well-known/security.txt

Contacting us as an authority. Member State authorities, the European Commission and the European Board for Digital Services may contact QuDef electronically at contact@qudef.com. We accept correspondence in English and Dutch. This is also the contact point published in our security.txt.