Cybellum disclosure policy for security researchers and vulnerability reporters
This page is the point of contact for anyone wishing to report vulnerabilities. To report security or privacy issues in Cybellum products or servers, as well as in other embedded products and associated servers, please submit a vulnerability report to [email protected].
Eligible issues
Cybellum will accept vulnerability disclosures in its scope, which include:
Issues in Cybellum products: Cybellum is committed to ensuring the security of its products, and to helping other vendors develop and distribute secure products. For its own products, Cybellum will review and fix all reported security vulnerabilities in a timely manner, working in full cooperation with the person or organization who reported them.
Issues in other embedded products: Cybellum is also available to help external researchers report security vulnerabilities in a responsible and helpful way, as part of the company’s research scope which includes embedded products developed and deployed by other vendors and the associated ecosystem, including servers and mobile applications. Cybellum can help the researcher by assigning CVE numbers and publishing official advisories on the NIST and MITRE websites, in addition to Cybellum’s website. Cybellum can also help the vendor ensure that the disclosure takes place in a responsible manner.
Cybellum only works with researchers who apply ethical hacking and responsible disclosure methods. Please refrain from any unlawful or malicious actions, do not access or make unauthorized changes to another company’s systems and data, and do not harm the security and privacy of products and users.
For issues that affect vendors outside of Cybellum’s scope, we will redirect your request to the MITRE Corporation or another applicable CVE Numbering Authority.
For any technical issues that do not pose a threat to privacy or security, please email us at [email protected].
Submitting a vulnerability report
Please include the following information in the report:
- Reporter: Name, contact information, and affiliation.
- Product: Software name, package, and the URL through which the software was obtained.
- Version: The affected version range.
- Description: What is the vulnerability and how can it be exploited? In as much detail as possible, provide step-by-step guidance to setting up and executing the exploit (scripts and code examples are welcome). Since detailed vulnerabilities are easier to confirm, they will get higher priority.
- Disclosure: Has the vulnerability been disclosed to other parties, publicly or privately? If so, when and to whom?
Other optional information that can help us process the report and communicate with you includes more information about yourself, the vulnerability type (for example, remote code execution), and its location in code or binary.
Response timeline
Initial response: Cybellum will respond with an initial confirmation within 48 hours after receiving the vulnerability report.
Disclosure review: The Cybellum vulnerability research team will review the report within a week and respond by either confirming the report, requesting more information, or rejecting it (for example, if the information is insufficient and cannot be confirmed, or if the vulnerability has already been disclosed to Cybellum or the public.)
Contact the vendor: Cybellum will contact the affected vendor within 72 hours once we have sufficient information on the vulnerability.
Reserve the CVE number: Cybellum will also initiate the reservation of a CVE number within 72 hours after having sufficient information on the vulnerability unless the vulnerability is meant to remain private.
Public disclosure: We prefer to receive the vendor’s agreement in all cases. We also prefer to set disclosure timelines on a case-by-case basis, taking into account the vendors’ ability or difficulties in patching the systems. However, we recommend a 120-day embargo period if the reporter wants to disclose the vulnerability without the vendor’s agreement. Because Cybellum deals primarily with embedded devices, we believe that this period accurately reflects the time it would take for the vendor to test and roll out patches to remotely installed devices, while also respecting the need for disclosure for the person who reported the vulnerability.