Security policy.

If you've identified a security vulnerability affecting kalisecu.com or one of our services, write to us at security@kalisecu.com. Please include:

• A clear, factual description of the vulnerability
• Steps to reproduce it
• Estimated severity (your view)
• Any helpful screenshots or technical proof

In scope:

• kalisecu.com and its subdomains (unless stated otherwise)
• The customer dashboard
• The public API
• Documents and operational procedures distributed by Kalisecu

Out of scope:

• Our clients' sites (you must have their explicit authorisation before any test)
• Third-party services we use (report directly to the third party)
• Denial-of-service attacks, brute-force, phishing of our staff
• Already known and public vulnerabilities

To benefit from our no-prosecution commitment and keep the discussion healthy, we ask you to:

• Not exfiltrate, modify or destroy data. If you accidentally access data that doesn't belong to you, stop immediately and report it.
• Not test on accounts or data that aren't yours.
• Not publicly disclose the vulnerability before we've had a reasonable time to fix (90 days by default, negotiable).
• Not use the vulnerability for illegal purposes or to harm our clients.

We don't (yet) keep a public hall of fame, but: if you report a vulnerability following the rules above, we thank you warmly, credit you publicly with your consent, and discuss compensation case by case according to severity and report quality.

The founder of Kalisecu, Mehdi Rahmani, is himself active on bug-bounty programmes and notably reported a critical vulnerability on ProConnect, the French government's digital identity platform. We understand the value of a good report.

For the curious, here is a non-exhaustive summary of our measures:

• Hosting in France (OVH SAS, Scaleway SAS)
• TLS 1.2+ encryption everywhere, HSTS, strict CSP
• Multi-factor authentication on operational accounts
• Logical multi-tenant isolation of client data
• Security updates applied under SLA according to severity
• Encrypted backups and regularly tested restoration
• Quarterly internal audit of accesses and logs

In accordance with RFC 9116, a /.well-known/security.txt file is published at the site root listing the reporting modalities.