Vulnerability Disclosure Policy

Ray Secure Innovations is committed to protecting the security, privacy, and reliability of our products, platforms, services, customers, and users.

We welcome good-faith security research and responsible vulnerability reporting from security researchers, customers, partners, vendors, and the broader security community. This Vulnerability Disclosure Policy explains how to report security vulnerabilities to Ray Secure Innovations, what information to include, how we handle vulnerability reports, and how we coordinate remediation and disclosure.

This policy applies to Ray Secure Innovations products and services, including SD-WAN, firewalls, VPN solutions, secure gateways, Cloud Controller, embedded Linux-based appliances, networking firmware, APIs, web management interfaces, containerized services, virtual appliances, and future networking and cybersecurity products.

1. Purpose

The purpose of this policy is to provide a clear, responsible, and secure process for reporting suspected security vulnerabilities affecting Ray Secure Innovations products and services.

This policy is designed to:

• Help security researchers report vulnerabilities safely and responsibly.
• Help Ray Secure Innovations validate, prioritize, remediate, and disclose vulnerabilities.
• Protect Ray customers and users from unnecessary risk.
• Support coordinated vulnerability disclosure.
• Support CVE assignment and publication where applicable.
• Align Ray Secure Innovations’ vulnerability handling practices with recognized industry standards, including ISO/IEC 29147, ISO/IEC 30111, CVSS, CWE, and RFC 9116.

2. Scope

This policy applies to suspected vulnerabilities in Ray Secure Innovations products, services, platforms, firmware, software, APIs, cloud-managed components, and management interfaces.

In-Scope Products and Components

The following product and technology areas are generally in scope:

3. Out-of-Scope Activities

Researchers must not perform testing that causes harm, disrupts services, accesses unauthorized data, or affects Ray customers, employees, partners, or third parties.

The following activities are out of scope:

Generally Low-Impact or Out-of-Scope Findings

The following may be considered out of scope unless a clear security impact is demonstrated:

• Missing non-security HTTP headers.
• TLS configuration observations without practical exploitability.
• Clickjacking on pages with no sensitive action.
• Self-XSS.
• Email spoofing reports without demonstrated SPF, DKIM, or DMARC bypass impact.
• Rate limiting observations without account compromise or material abuse potential.
• Vulnerable third-party library reports without evidence of reachability or exploitability.
• Reports generated only by automated tools without validation.
• Best-practice recommendations without a specific exploitable vulnerability.
• Vulnerabilities affecting only unsupported or end-of-life products, unless Ray determines there is exceptional risk.

4. Supported Products and End-of-Life Products

Ray Secure Innovations prioritizes vulnerability handling for supported products and actively maintained versions.

A product is generally considered supported if it is within its published support lifecycle and Ray is providing security updates, maintenance updates, or technical support for that version.

End-of-life or end-of-support products may not receive security updates. However, Ray may still evaluate reports involving end-of-life products when:

• The issue may affect supported products.
• The issue affects shared code or shared components.
• The vulnerability is actively exploited.
• The issue presents significant risk to customers or the broader ecosystem.
• Ray determines that disclosure or mitigation guidance is appropriate.

5. How to Report a Vulnerability

Please report suspected vulnerabilities to Ray Secure Innovations using one of the approved reporting channels below.

For urgent reports involving suspected active exploitation, remote unauthenticated compromise, credential exposure, or widespread customer impact, include the following text in the email subject line:

6. Information to Include in a Vulnerability Report

To help us validate and remediate vulnerabilities efficiently, please include as much detail as possible.

Example Report Format

7. Expected Response Timeline

Ray Secure Innovations aims to respond to vulnerability reports according to the following service level objectives.

These timelines are goals and may vary depending on report quality, vulnerability complexity, affected products, customer exposure, third-party dependencies, exploit activity, and remediation requirements.

8. Report Acknowledgement

After receiving a vulnerability report, Ray Secure Innovations will:

1. Acknowledge receipt within the target response timeline.
2. Assign an internal tracking identifier.
3. Review whether the report appears to be in scope.
4. Request additional information if needed.
5. Begin triage and technical validation.
6. Coordinate communication with the reporter where appropriate.

Acknowledgement of a report does not mean that Ray has confirmed the issue as a vulnerability, accepted the submitted severity, committed to issuing a CVE, or committed to publishing a security advisory.

9. Vulnerability Validation Process

Ray Secure Innovations reviews vulnerability reports using a structured validation process.

During validation, Ray may assess:

• Whether the affected product or component is owned, maintained, or distributed by Ray.
• Whether the affected version is supported.
• Whether the issue can be reproduced.
• Whether the behavior creates a security impact.
• Whether exploitation is realistic.
• Required privileges, access, configuration, or user interaction.
• Whether the issue affects one deployment, multiple products, or shared components.
• Whether the issue is already known or already assigned a CVE.
• Whether the issue originates in a third-party or open-source component.

Possible validation outcomes include:

10. Severity Assessment

Ray Secure Innovations uses industry-recognized methods to evaluate vulnerability severity and customer impact.

Ray may use:

• CVSS v3.1
• CVSS v4.0
• CWE classification
• Product-specific risk analysis
• Exploitability assessment
• Threat intelligence
• Customer exposure analysis
• Availability of mitigations or compensating controls

CVSS Severity Ratings

Ray may adjust remediation priority based on factors beyond the CVSS Base Score, including active exploitation, internet exposure, default configuration, product deployment model, available mitigations, and operational impact.

11. Coordinated Vulnerability Disclosure

Ray Secure Innovations follows coordinated vulnerability disclosure principles to protect customers while recognizing the contribution of security researchers.

Ray generally prefers public disclosure after:

• The vulnerability has been validated.
• A fix, patch, upgrade, workaround, or mitigation is available.
• Affected customers can take action.
• CVE assignment or request is complete, where applicable.
• Coordination with third parties or upstream maintainers is complete, where needed.

Ray may publish an advisory before a complete fix is available if:

• The vulnerability is actively exploited.
• The issue is already public.
• Exploit code is available publicly.
• Immediate customer mitigation is required.
• A third-party vendor publishes related information.
• Ray determines that early disclosure is necessary to protect customers.

Researchers are expected to coordinate public disclosure with Ray and avoid publishing technical details before Ray has had a reasonable opportunity to validate, remediate, and notify customers.

12. Security Researcher Expectations

Ray Secure Innovations appreciates good-faith security research. Researchers participating under this policy are expected to:

• Test only systems and products they own or are authorized to assess.
• Avoid service disruption, data destruction, privacy violations, and unauthorized access.
• Use only the minimum testing necessary to demonstrate impact.
• Stop testing immediately if sensitive data is encountered.
• Do not access, copy, modify, delete, or disclose data that is not your own.
• Do not establish persistence, perform lateral movement, or expand access.
• Do not use social engineering, phishing, malware, or physical attacks.
• Keep vulnerability information confidential during coordination.
• Provide clear technical details to support validation.
• Comply with applicable laws and regulations.

13. Safe Harbor

Ray Secure Innovations supports good-faith security research conducted in accordance with this policy.

When research is conducted in good faith, follows this policy, avoids harm, and is reported responsibly to Ray, Ray does not intend to initiate legal action against the researcher for the act of identifying and reporting the vulnerability.

This safe harbor does not apply to activity that:

• Causes harm to Ray, customers, users, partners, or third parties.
• Accesses, modifies, destroys, or exfiltrates data without authorization.
• Disrupts services or systems.
• Uses social engineering, phishing, physical attacks, malware, or persistence.
• Targets systems outside the scope of this policy.
• Violates applicable law.
• Continues after Ray requests that testing stop.
• Involves extortion, threats, ransom demands, or coercive disclosure.

This policy does not authorize unlawful activity or access to systems, networks, products, services, or data without permission.

14. Confidentiality

Vulnerability information may create risk if disclosed prematurely. Ray expects all parties to protect sensitive vulnerability information during the coordination process.

Researchers should not publicly disclose or share the following before coordinated disclosure:

• Exploit code.
• Detailed reproduction steps.
• Vulnerable endpoints.
• Credentials, keys, tokens, or secrets.
• Customer data.
• Crash dumps containing sensitive information.
• Internal Ray communications.
• Unreleased patches or mitigation details.
• Reserved CVE IDs that are not yet public.

Ray will take reasonable steps to protect researcher contact details, non-public vulnerability details, customer information, and sensitive technical evidence. Ray may share vulnerability information internally and with affected vendors, coordinators, customers, legal advisors, regulators, or service providers where necessary to validate, remediate, coordinate, or disclose the vulnerability.

15. Third-Party Component Vulnerabilities

Ray products may include third-party software, hardware components, libraries, operating system packages, drivers, container images, or cloud service dependencies.

When a reported vulnerability originates in a third-party component, Ray may:

7. Determine whether Ray products are affected.
8. Assess whether the component is present, reachable, enabled, and exploitable.
9. Evaluate whether Ray configuration or hardening reduces impact.
10. Coordinate with the third-party vendor, upstream maintainer, or appropriate CNA.
11. Track upstream patches or mitigations.
12. Patch, update, disable, mitigate, or document the issue where appropriate.
13. Publish a Ray advisory if customer action is required.

16. Open Source Vulnerabilities

Ray Secure Innovations uses and may contribute to open-source software.

For open-source vulnerabilities, Ray may evaluate:

• Whether the component is included in a Ray product.
• Whether the vulnerable code path is reachable.
• Whether the component is enabled by default.
• Whether Ray has modified the component.
• Whether an upstream fix is available.
• Whether the issue already has a CVE.
• Whether multiple vendors are affected.

Ray may coordinate with upstream maintainers and may publish a Ray advisory when an open-source vulnerability affects Ray customers or requires Ray-specific action.

17. CVE Assignment Process

Ray Secure Innovations supports responsible CVE assignment and publication practices.

Where applicable, Ray may assign, request, or coordinate CVE IDs for vulnerabilities affecting Ray products and services.

CVE Eligibility

A vulnerability may be eligible for CVE assignment when:

• It affects a publicly released product.
• It has a security impact.
• It is independently fixable or documentable.
• It is not a duplicate of an existing CVE.
• It falls within Ray’s CNA scope or an appropriate CNA’s scope.
• Public disclosure is planned or required.
• Sufficient information exists to create a complete CVE record.

Issues That May Not Receive a CVE

Ray may decline or not request CVE assignment for:

• Reports without security impact.
• Duplicate vulnerabilities.
• Product hardening recommendations.
• Best-practice observations without exploitability.
• Vulnerabilities affecting only unsupported end-of-life products.
• Customer-specific misconfigurations.
• Vulnerabilities entirely owned by another CNA’s scope.
• Internal-only issues with no public product impact.
• Issues that cannot be reproduced or validated.

18. Vulnerability Handling Workflow

Developer note: render the following Mermaid diagram on the webpage if Mermaid rendering is supported. Otherwise, use it as source for a visual workflow graphic.

19. Internal PSIRT Workflow

Ray’s vulnerability handling process may involve Product Security, Engineering, Cloud Operations, Support, Legal, Communications, Product Management, and executive stakeholders where appropriate.

Developer note: render the following Mermaid diagram on the webpage if Mermaid rendering is supported. Otherwise, use it as source for a visual workflow graphic.

20. Security Advisory Publication

Ray Secure Innovations publishes security advisories to help customers understand risk and take appropriate action.

A security advisory may include:

21. Customer Notification

Ray Secure Innovations may notify customers through one or more of the following channels:

• Ray security advisory page.
• Customer support portal.
• Email notification to registered security contacts.
• Release notes.
• Product update notices.
• Partner or reseller communication.
• Direct outreach for critical issues.

Customer notifications may include:

• Affected product and versions.
• Fixed versions.
• Severity and impact.
• Known exploitation status, where available.
• Recommended customer action.
• Workarounds or mitigations.
• Upgrade or patch instructions.
• Ray support contact details.

22. PGP Key

Ray Secure Innovations recommends encrypting sensitive vulnerability reports when a Ray PSIRT PGP public key is available.

Once a company-owned PSIRT PGP key is created, Ray should publish the public key at:

Only the public key should be published. The private key must never be published on the website.

23. security.txt

Ray Secure Innovations publishes security contact information using an RFC 9116-compatible security.txt file.

Recommended location:

Recommended contents:

24. Researcher Recognition

Ray may acknowledge researchers in public advisories or an acknowledgments page when:

• The report results in a validated vulnerability.
• The researcher requests credit.
• The researcher follows this policy.
• Disclosure coordination is completed responsibly.

Ray may decline or modify public credit where necessary for legal, privacy, safety, operational, or compliance reasons.

25. Legal Disclaimer

This policy is provided for informational purposes and to encourage responsible vulnerability reporting. It does not create a contract, warranty, service-level agreement, employment relationship, agency relationship, or entitlement to compensation.

Ray Secure Innovations may modify this policy at any time. Ray may decline to investigate, remediate, disclose, credit, or assign/request a CVE for any report at its discretion, including where the report is out of scope, not reproducible, duplicative, unsupported, low impact, legally sensitive, or not actionable.

Nothing in this policy authorizes unauthorized access, violation of law, disruption of systems, access to customer data, attacks on third-party systems, or public disclosure of confidential vulnerability information before coordination.

Researchers are responsible for complying with all applicable laws and regulations.

26. Policy Review

Ray Secure Innovations reviews this policy periodically and may update it based on changes to products, services, vulnerability handling practices, legal requirements, standards, customer needs, or CVE Program requirements.

27. Questions

For questions about this policy or to report a suspected vulnerability, contact: