Scope
In Scope
This policy applies to services and infrastructure operated by Rix:
- Websites:
*.rix.fr - Rix infrastructure and APIs
- Services hosted for our clients only with prior written authorization from the client
Out of Scope
- Our clients' infrastructure (without explicit written authorization)
- Third-party services we use but do not directly operate
- Systems of our partners or suppliers
How to Report a Vulnerability
Secure Communication Channel
Encrypted Email (recommended): security@rix.fr
- PGP Key: 67B08D2BE9C8ACC2C40D28F1F69D39C94B03BD79
- We accept anonymous reports
security.txt file: https://www.rix.fr/.well-known/security.txt
Information to Provide
To help us process your report effectively, please include:
- Detailed description of the vulnerability
- Steps to reproduce (PoC)
- Potential impact and estimated severity
- Affected versions if known
- Any relevant technical information (logs, screenshots, HTTP requests, etc.)
- Your contact information for follow-up (optional, anonymous reports are accepted)
Safe Harbor - Legal Protection
If you act in good faith and comply with this policy during your security research, we consider your research authorized and we commit to:
- Not initiate legal action against you
- Work with you collaboratively to understand and resolve the issue quickly
- Publicly acknowledge your contribution if you wish
This protection applies only if you comply with the rules defined below.
What We Expect From You
Authorized Behavior
- Notify Rix promptly of any discovered vulnerability
- Provide sufficient details to allow us to reproduce and fix the vulnerability
- Act in good faith and not exploit the vulnerability beyond what is strictly necessary for demonstration
- Respect data confidentiality
Prohibited Behavior
- Data access: Do not access, modify, delete, or store data that does not belong to you
- Denial of service: Do not perform any tests that could impact service availability (DoS, DDoS, stress tests)
- Social engineering: Do not test our employees through phishing, pretexting, or other manipulation techniques
- Privacy violations: Do not violate the confidentiality or privacy of our users or employees
- Premature public disclosure: Do not publicly disclose the vulnerability before we have had time to fix it and have given you our approval
What You Can Expect From Us
Response Times
| Stage | Timeline |
|---|---|
| Acknowledgment of receipt | 3 business days |
| Initial severity assessment | 5 business days |
| Regular communication | Update at least every 15 days |
Target Remediation Times
| Severity | Target Remediation Time | Workaround |
|---|---|---|
| Critical | 7 days | If possible, communicated immediately |
| High | 30 days | If necessary |
| Medium | 90 days | - |
| Low | 180 days | - |
Note: These timelines are targets. Technical complexity may require adjustments that we will communicate.
Our Commitments
- Transparency: Regular communication on the progress of the fix
- Recognition: Public mention of your contribution (if you wish) once the vulnerability is fixed
- Good faith: No legal action will be taken if you comply with this policy
- CVE: Request for CVE identifier for eligible vulnerabilities
- Public advisory: Publication of a security advisory once the vulnerability is fixed
Coordinated Disclosure
We favor a coordinated disclosure approach:
- Private report: You report the vulnerability to us confidentially
- Acknowledgment: We confirm receipt within 3 business days
- Assessment: We assess severity and impact
- Remediation: We develop and deploy a fix
- Validation: We inform you of the fix and invite you to validate
- Public disclosure: You may publish your discovery after 90 days or by mutual agreement
Non-disclosure period: We ask you not to publicly disclose the vulnerability for 90 days from your initial report, or until the fix is deployed and validated (whichever comes first).
If you feel we are not treating your report with the required seriousness, you may notify us. As a last resort, after 90 days, you are free to publish at your discretion.
Bug Bounty Program
We currently do not have a formal bug bounty program with financial rewards.
However, we publicly acknowledge the contributions of researchers who wish on:
- Our technical blog
- Published security advisories
- Our social media
Out of Scope / Exclusions
The following are not considered vulnerabilities under this policy:
Issues Without Demonstrated Impact
- Absence of best practices without demonstrated security impact (e.g., absence of DNSSEC, non-optimal CSP headers)
- Misconfigured SPF/DMARC/DKIM without demonstrated exploitation
- Missing security headers without functional exploitation
- User or email enumeration without demonstrated exploitation
- Theoretical vulnerabilities without functional PoC
Out of Technical Scope Issues
- Vulnerabilities in obsolete browser versions (not supported by the vendor)
- Clickjacking on pages without sensitive actions
- Attacks requiring physical access to the machine
- Attacks requiring already obtained admin privileges
- Open redirect without demonstrated impact (no credential theft, no credible phishing)
Social Engineering Issues
- Phishing test results
- Social engineering test results
Severity Criteria
We assess severity according to the CVSS v3.1 methodology, taking into account:
- Critical: Remote code execution without authentication, full data access
- High: Unauthorized access to sensitive data, significant privilege escalation
- Medium: Limited data access, bypass of security mechanisms
- Low: Minor information leakage, configuration issues
Disclosure History
We will publish here the vulnerabilities fixed in a coordinated manner with researchers.
No public disclosure to date.
Questions and Contact
For any questions regarding this policy: security@rix.fr
Last updated: January 30, 2026
Version: 1.0
This policy may be modified at any time. We will publish updates on this page with the revision date.