Halborn Logo

// Disclosures

Vulnerability Disclosure Policy


Scope of Vulnerability Disclosure Policy

Halborn’s vulnerability disclosure policy primarily addresses the following three situations:

  • Vulnerabilities discovered by Halborn that affect other entities

  • Vulnerabilities reported to Halborn that affect other entities

  • Vulnerabilities reported to Halborn that affect Halborn

Our CVE assignment scope includes all blockchain and Web3 products that rely on smart contracts written in Rust, Go, and Solidity as well as blockchain associated Web2 and Web3 infrastructure not covered by another CNA.

Halborn’s vulnerability disclosure policy covers all our products that do not meet one of the exclusion criteria below, except when the impact is deemed high enough that our risk-based approach would dictate otherwise.

Reporting a Vulnerability

Halborn welcomes reports from independent researchers, industry organizations, vendors, customers, and other sources concerned with product or network security. 

All security issues and questions should be reported via email to the Halborn Security Team at disclosures@halborn.com. Valid submissions will be acknowledged within 24 hours and reporters will receive a more detailed response to the email within 72 hours, indicating perceived severity and the next steps in handling the report.

When we report a security issue, we ask that you provide full details of the security issue including steps to reproduce and the details of the system where the tests were conducted and a clearly defined impact. 

We use CVSS version 3.1 to score vulnerabilities and consider several factors such as active exploitation, customer exposure, and public disclosure timelines while prioritizing response actions for issues.

Handling & Disclosure Process For Issues Affecting non-Halborn Entities

When a security issue is identified by Halborn engineers or disclosed via the reporting process, the following steps will be taken by Halborn to notify the respective parties to fix it:

  • Once we have confirmed the vulnerability, we will gather all the necessary information to communicate the details to the affected party.

  • Halborn will try to establish initial contact with the affected vendor via email regarding the vulnerability and provide supporting documents.

  • If we don’t receive a response from the vendor within seven days of sending the mail, another reminder will be sent. If the vendor did not respond or refuses to acknowledge the vulnerability within 14 days from initial contact, Halborn may publicly disclose the vulnerability.

  • If we receive a response from the vendor, we will notify them about the date of the vulnerability disclosure that we have set.

  • The vendor will be allowed 90 days to provide a patch or relevant fix for the issue. If provided, then the vulnerability will be disclosed immediately following the vendor’s patch or fix release.

  • If a fix is not provided within the 90 day period and no response is received from the vendor, Halborn will disclose the vulnerability on the determined date.

  • In the event that the vendor is unable to provide a fix within the deadline, but has communicated to Halborn regarding the same, then the deadline may be adjusted. A maximum of six months of coordination will be given to the vendor for fixing the vulnerabilities. After that the vulnerability may be disclosed regardless of the fix.

  • The 90-day deadline mentioned above is not a hard deadline. Halborn can shorten or lengthen the deadline based on criteria like the severity of the vulnerability, ease of exploitation, etc.

  • Until the completion of the disclosure process, Halborn will maintain confidentiality of any communication to and from the vendor. However, we will disclose the vulnerability to the public irrespective of the vendor’s support or not.

  • All CVEs assigned by Halborn and its vulnerability disclosures can be found in the Halborn Disclosures Page. Only the advisories present in the security advisory will be considered as official documents.

Handling & Disclosure Process For Issues Affecting Halborn

  • When a security report is received involving Halborn owned or controlled systems or products, it is assigned to an owner who is responsible for evaluating, coordinating remediation, and disclosing the issue as appropriate.

  • The evaluation process addresses the validity, impact, and scope of the reported issue and includes a review to identify any similar issues that might be present.

  • Fixes are implemented as necessary

  • An announcement date is decided for disclosure

  • Prior to public announcement, all affected stakeholders are given a period of time to implement any fixes needed

Rewards for submission of security vulnerabilities

For issues affecting non-Halborn products or systems we will make a good faith effort, to the extent permissible, to award credit to the reporter on our disclosures page.

For issues affecting Halborn a reward may be issued at the discretion of Halborn senior leadership. The reward will be issued primarily based on the severity of the finding, among other considerations.

To be eligible for an acknowledgement or bounty the following conditions must be met:

  • The vulnerability is disclosed to Halborn before it is disclosed publicly, and Halborn or the corresponding vendor are given sufficient time to fix it

  • The vulnerability is not disclosed to anyone else besides Halborn before it is fixed

  • The vulnerability is not exploited until it is fixed

We also require that reporters DO NOT: 

  • Cause potential or actual damage to Halborn, systems, or applications.

  • Use an exploit to view unauthorized data or corrupt data. 

  • Engage in disruptive testing including but not limited to DoS, fuzzing, automated scanning of cloud services, or any action that could impact the confidentiality, integrity, or availability of information and systems.

  • Engage in social engineering (e.g. phishing, vishing, smishing) of Halborn or other organizations’ employees or customers.

Vulnerabilities in Halborn’s Scope

Halborn specifically prohibits any intentional behaviors that are designed to allow unauthorized device or network access, exposure of sensitive device information, or a bypass of security features or restrictions.

Vulnerabilities in Halborn’s scope include any design or implementation issue that substantially affects the confidentiality or integrity of the product and/or impacts user security. Common examples include:

  • Undisclosed device access methods or “backdoors”

  • Hardcoded or undocumented account credentials

  • Undocumented traffic diversion

  • Cross-site scripting

  • Cross-site request forgery

  • Mixed-content scripts

  • Authentication or authorization flaws

  • Server-side code execution bugs

  • Bypass of security feature (Bypass of AV/IPS engine)

Halborn will address any issues of this nature with the highest priority and we encourage all parties to report suspected vulnerabilities for immediate investigation.

The following vulnerability categories are considered out of scope of (unless a proven high impact is demonstrated) and will not be eligible for bounties or credit on our researcher list: 

  • Network-level Denial of Service (DoS/DDoS) vulnerabilities.

  • Cross-site Request Forgery (CSRF) with low security impact (logout CSRF, etc.)

  • Client-side application/browser autocomplete or saved credentials

  • User, account or id enumeration via brute-force

  • Any kind of physical intrusion or social engineering attempts.

  • Missing Cookie flags or Missing/Enabled HTTP Headers/Methods (unless it leads directly to a security vulnerability)

  • Low impact Stack trace disclosures, Information disclosures and banner grabbing issues (Software and Server version disclosure etc.)

  • Reports that have not been validated from automated web vulnerability scanners and SSL/TLS scanners or port scanners.

  • Any low impact issues related to session management (i.e. concurrent sessions, session expiration, session refresh on password reset/change log out, etc.)

  • Vulnerabilities affecting only outdated user agents or application versions

  • Verbose error pages without proof of exploitability or obtaining sensitive information

  • Lack of SSL/TLS or SSL/TLS best practices that do not contain a fully functional proof of concept.

  • Incomplete or missing SPF/DMARC/DKIM records

  • Self-XSS

  • Unchained open redirects

  • Low impact Content Spoofing issues

  • UI and UX bugs (including spelling mistakes)

Contact

Halborn is always open to feedback and suggestions. If you would like to contact us to learn more about this Policy or to discuss any matter related to it, please feel free to email us at disclosures@halborn.com.

Legal Notes

We encourage security researchers to come forward with their findings and report them to us without fear of legal consequences. Halborn does not intend to engage in legal action against any researcher who has performed research according to current best practices for conducting and reporting vulnerability research. Security research must make good faith efforts to avoid violating any law, avoid any action that could negatively impact the confidentiality, integrity or availability of information and systems of either Halborn or its customers.

Disclaimer

All aspects of this Halborn Vulnerability Disclosure Policy are subject to change without notice at any time. Response is not guaranteed for any specific issue or class of issues. Your use of the information on the policy or materials linked from the policy is at your own risk.

Change History

Published: October 11, 2022.

Have concerns, want to learn more, or have a bug you’d like to disclose? Please reach out to us at disclosures@halborn.com.

Halborn is hiring! If you’re someone who can help make our products and this industry more secure, consider joining our team.