Ray Security Vulnerability Disclosure Policy

At Ray, safeguarding the integrity and security of our products and services is a top priority. We are committed to
ensuring that any vulnerabilities are promptly addressed to protect our clients, partners, and stakeholders. This policy
outlines our approach to the responsible disclosure and remediation of security vulnerabilities. We greatly appreciate
the efforts of security researchers and the community in helping us maintain the highest standards of security.

Introduction and Commitment to Security

Ray is committed to protecting our users’ data and the integrity of our systems. We recognize the valuable role that
security researchers play in identifying vulnerabilities and encourage responsible disclosure. Our approach to security
is proactive, collaborative, and transparent.

This policy covers:

Ray Products and Services: All Ray software & hardware, cloud services, on-premises Ray solutions.

Scope

We consider the following types of vulnerabilities to be in scope for our Responsible Disclosure Program:

• Remote Code Execution (RCE) vulnerabilities
• SQL Injection (SQLi) vulnerabilities
• Cross-Site Scripting (XSS) vulnerabilities
• Cross-Site Request Forgery (CSRF) vulnerabilities
• Sensitive Data Exposure vulnerabilities
• Authentication and Authorization vulnerabilities
• Denial of Service (DoS) vulnerabilities
• Privilege Escalation vulnerabilities
• Insecure Direct Object References (IDOR)
• Server-Side Request Forgery (SSRF)
• Open Redirect vulnerabilities with high impact

Out of Scope

The following types of vulnerabilities are considered out of scope for our Responsible Disclosure Program:

• Vulnerabilities in third-party software or services not under Ray’s control
• Vulnerabilities requiring unlikely user interaction (e.g., self-XSS)
• Vulnerabilities in outdated browsers, plugins, or platforms
• Vulnerabilities with low impact (e.g., missing security headers, verbose error messages & more like such )
• Vulnerabilities requiring physical access to devices
• Vulnerabilities in test or staging environments
• Vulnerabilities in personal or test accounts
• Vulnerabilities caused by social engineering or phishing
• Vulnerabilities in Ray’s corporate infrastructure not directly related to customer-facing products
• Account/e-mail enumeration using brute-force attacks
• Valid user account/email enumeration not requiring brute-force will be considered
• Any low impact issues related to session management (i.e. concurrent sessions, session expiration, password
  reset/change log out, etc.)
• Bypassing content restrictions in uploading a file without proving the file was received
• Clickjacking/UI redressing
• Client-side application/browser autocomplete or saved password/credentials
• Descriptive or verbose error pages without proof of exploitability or obtaining sensitive information
• Directory structure enumeration (unless the fact reveals exceptionally useful information)
• Incomplete or missing SPF/DMARC/DKIM records
• Issues related to password/credential strength, length, lockouts, or lack of brute-force/rate limiting
  protections
• Account compromises (especially admin) as a result of these issues will likely be considered VALID
• Lack of SSL or Mixed content
• Leaking Session Cookies, User Credentials, or other sensitive data will be reviewed on a case by case basis
• If leaking of sensitive data requires MiTM positioning to exploit, it will be considered out of scope
• Login/Logout/Unauthenticated/Low-impact CSRF
• CSRF Vulnerabilities may be acceptable if they are of higher impact. Examples of low impact CSRF include:
  Add/Delete from Cart, Add/remove wishlist/favorites, Nonsevere preference options, etc.
• Low impact Information disclosures (including Software version disclosure)
• Missing Cookie flags
• Missing/Enabled HTTP Headers/Methods which do not lead directly to a security vulnerability
• Reflected file download attacks (RFD)
• Self-exploitation (i.e. password reset links or cookie reuse)
• SSL/TLS best practices that do not contain a fully functional proof of concept
• URL/Open Redirection
• Use of a known-vulnerable library which leads to a low-impact vulnerability (i.e. jQuery outdated version leads
  to low impact XSS)
• Valid bugs or best practice issues that are not directly related to the security posture of the client
• Vulnerabilities affecting users of outdated browsers, plugins or platforms
• Vulnerabilities that allow for the injection of arbitrary text without allowing for hyperlinks, HTML, or
  JavaScript code to be injected
• Vulnerabilities that require the user/victim to perform extremely unlikely actions (i.e. Self-XSS)
• Self-XSS for a Persistent/Stored XSS will be considered. Please review the Self-XSS article for more
  information.
• Any type of XSS that requires a victim to press an unlikely key combination is NOT in scope (i.e. alt+shift+x
  for payload execution)

Additional specific vulnerability types considered out of scope due to low impact:

• IIS Tilde File and Directory Disclosure
• SSH Username Enumeration
• WordPress Username Enumeration
• SSL Weak Ciphers/ POODLE
• CSV Injection
• PHP Info
• Server-Status if it does not reveal sensitive information
• Snoop Info Disclosures

Guidelines for Responsible Disclosure Program

Ray adheres to the principle of Coordinated Vulnerability Disclosure. When Ray receives a security vulnerability report,
we work diligently to develop a solution and release it to our customers, ensuring their protection as swiftly as
possible.
We respectfully request that the security community allows us the necessary time to fix vulnerabilities before publicly
disclosing any information, and we ask that you follow the guidelines outlined below:

How to Report a Vulnerability

Reports should be submitted through Ray’s designated security email: security@ray.life We encourage encrypted communication and provide a public PGP key for secure submissions.

What Happens After You Report

Upon receiving a vulnerability report, Ray will:

• Acknowledge Receipt: We will confirm receipt of your report within 48 hours.
• Initial Triage: Conduct an initial review to assess the validity and severity of the reported issue.
• In-Depth Analysis: A comprehensive analysis will be carried out by our security team to understand the full scope and impact.
• Remediation Planning: We will develop and implement a fix or mitigation strategy.
• Coordination with You: Throughout the process, we will keep you informed of our progress and may seek additional information or clarification.
• Public Disclosure: Once the issue is resolved, we will work with you to coordinate public disclosure, ensuring that the timing and details are aligned with responsible disclosure practices.

Coordinated Disclosure Process

Ray follows a coordinated disclosure approach:

• Resolution Timeline: We aim to resolve all reported issues as swiftly as possible, typically within 90 days. If we require more time, we will communicate this to you with justifications.
• Pre-Disclosure: We ask that you do not publicly disclose any details of the vulnerability until we have had the opportunity to address it and release a fix.
• Public Credit: We are happy to credit security researchers for their discoveries, provided they adhere to our responsible disclosure guidelines.

Legal Protections

Good Faith Interaction: If you act in good faith to discover and report vulnerabilities, Ray will not initiate legal action against you.

Safe Harbor Provision

• This policy is intended to provide legal protection for security researchers who follow it. However, Ray cannot offer protection if your activities violate laws or regulations outside the scope of this policy.
• Do not attempt to exploit the vulnerability or gain unauthorized access to any systems.
• Do not modify or delete data during the testing process.
• Comply with all applicable laws and regulations in your country and Ray’s terms of service.
• Ray reserves the right to pursue legal action against individuals who cause harm or violate the law.

Exclusions

The following activities are excluded from this policy:

• Denial of Service (DoS) Attacks: Any form of DoS attacks, including volumetric attacks, is not allowed.
• Social Engineering: Phishing or other social engineering attacks against Ray employees, partners, or customers are prohibited.
• Physical Testing: Physical attacks on Ray’s offices, data centers, or personnel are not covered.
• Non-Security Bugs: Bugs that do not directly pose a security threat, such as UI issues or performance bugs, should not be reported under this policy.

Transparency and Continuous Improvement

Ray is committed to transparency in our security processes. We regularly review and update our policies to reflect the evolving threat landscape and best practices. Your feedback is crucial in helping us enhance our security posture.

Transparency and Continuous Improvement

For any questions about this policy or to report a vulnerability, please contact our security team at security@ray.life