Bug Bounty & Responsible Disclosure Policy
Introduction
User security is of paramount importance to GridPlus’ efforts. We encourage responsible disclosure of security vulnerabilities via our bug bounty program (“Bug Bounty Program”) described on this page.
The program directly serves our core mission by helping GridPlus be the most trusted hardware security option for storing and actively using digital currency.
The GridPlus Bug Bounty Program’s scope covers all hardware and software vulnerabilities in products directly offered by GridPlus, Inc.
A valid report is any in-scope report that clearly demonstrates a software or hardware vulnerability that harms GridPlus or GridPlus customers. A report must be a valid, in scope report in order to qualify for a bounty. GridPlus will determine in its sole discretion whether a report is eligible for a reward and the amount of the award.
Program Policies
GridPlus pledges not to initiate legal action for security research conducted pursuant to all Bug Bounty Program policies, including good faith, accidental violations. We consider activities conducted consistent with this policy to constitute “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA, and applicable anti-hacking laws such as Cal. Penal Code 502(c). We will not bring a DMCA claim against researchers for circumventing the technological measures we have used to protect the applications in scope of the Bug Bounty Program.
If legal action is initiated by a third party against you and you have complied with the Bug Bounty Program policy, we will take steps to make it known that your actions were conducted in compliance with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party is not bound by our pledge and may determine whether to pursue legal action. GridPlus cannot and does not authorize security research on other entities.
Please contact the GridPlus team before engaging in conduct that may be inconsistent with or unaddressed by this policy. Your message should include a brief description of your intended conduct so that we may determine whether it is consistent with the Bug Bounty Program policy.
We believe it is critical to provide these assurances in order to allow security researchers to fully investigate potential security vulnerabilities. As such, we embrace the standardization of policy language that provides legal protection to security researchers as a part of the #legalbugbounty project.
Researcher Requirements
Complying with the Bug Bounty Program policy requires researchers to adhere to “Responsible Disclosure” which includes:
Reporting vulnerabilities with no conditions, demands, or ransom threats.
Providing GridPlus a reasonable amount of time to fix a vulnerability prior to sharing the details of the vulnerability with any other party.
Not profiting from or allowing any other party to profit from a vulnerability outside of Bug Bounty Program payouts from GridPlus.
GridPlus considers Social Engineering attacks against GridPlus employees to be a violation of Program Policies and will result in researchers being banned from the GridPlus Bug Bounty program. We define Social Engineering as acts that influence people to perform security-impacting actions or divulge confidential information.
Report Evaluation & Reward
In order to be deemed valid, a report must demonstrate a hardware or software vulnerability in the Lattice1 hardware wallet that harms GridPlus or GridPlus customers. Reports that include a clear Proof of Concept or specific step by step instructions to replicate the vulnerability are considerably more effective at communicating a researcher’s findings and are therefore far more likely to be deemed valid.
A report must be a valid, in scope report in order to qualify for a bounty. GridPlus awards bounties based on severity of the vulnerability. We determine severity based on two factors: Impact and Exploitability.
Impact describes the effects of successful exploitation upon GridPlus systems or customers. We make this assessment primarily by examining the effects of exploitation on confidentiality, integrity, or availability of underlying information. Vulnerabilities that require considerable response and remediation efforts or could result in reputational damage are also considered to have greater impact. For example:
Critical Impact: Attackers can read or modify Sensitive Data in a system, execute arbitrary code on the system, or exfiltrate digital or fiat currency in some way.
Low Impact: Attackers can gain small amounts of unauthorized, low sensitivity information impacting a subset of users, or slightly impact accuracy and performance of a system. (Please note that Denial of Service bugs will be considered on a case-by-case basis. Denial of Service issues that don't impact availability of funds or user data will not likely be accepted as a valid report.)
Exploitability describes the difficulty of actively exploiting the vulnerability itself. We make this assessment primarily based on the prerequisites for exploitation, including level of access required, availability of information critical for successful exploitation, and likelihood of alignment of required factors outside the attacker's direct control such as social engineering requirements or timing requirements. For example:
Critical Exploitability: Attackers can unilaterally exploit the finding without significant roadblocks or special conditions outside attacker control.
Low Exploitability: Exploitation is difficult due to several requirements, such as access limitations, complicated social engineering, guessing unknown values, or alignment of unpredictable race conditions.
Severity is determined as a combination of Impact and Exploitability. For example:
Critical Severity: a state of immediate, easily accessible threat of large-scale compromise or irreversible damage to GridPlus or GridPlus customers.
Low Severity: a state of no immediate threat where an opportunity exists for an improvement that may mitigate a potential future vulnerability.
The decision to award a payment for the discovery of a valid security issue is at the sole discretion of GridPlus, Inc.
Researchers are also more likely to earn a larger reward for exceptionally clear and high-quality reports.
Some restrictions apply to bounty eligibility. The researcher must not:
Be a resident of, or make their vulnerability submission from, a country against which the United States has issued export sanctions or other trade restrictions.
Be employed by GridPlus, Inc. or its subsidiaries or affiliates.
Be an immediate family member of a person employed by GridPlus, Inc. or its subsidiaries or affiliates.
Be in violation of any national, state, or local law, or regulation.
Be less than 18 years of age. If you are under 18 years old, or considered a minor in your place of residence, you must get your parents’ or legal guardian’s permission prior to participating in the program.
Previous bounty amounts are not considered precedent for future bounty amounts. Software is constantly changing and therefore the given security impact of the exact same vulnerability at different times in the development timeline can have drastically different security impacts.
Report Closure
GridPlus reviews all findings that are reported via our Bug Bounty Program. Each report submission is reviewed and evaluated to ensure validity. If the description in the report is unclear, GridPlus will request additional information from the reporter. After all information is aggregated; the report submission goes through an internal review and scoring process. After the internal review process is complete, any bugs that are not reproducible, invalid or informative will be closed.
It is up to the researcher to provide detailed information and supporting evidence to support all reports. Failure to provide a detailed report will result in delayed triage and/or ticket closure.
Scope
Scope includes hardware attacks on the Lattice1 or SafeCards, software attacks on the firmware of the Lattice1 or SafeCards.
Examples of In-Scope Vulnerabilities:
Arbitrary code execution on the secure enclave.
Bypass of user confirmation for signing.
Bypass of PIN entry.
Out-of-scope Vulnerabilities:
Exploits on outdated software.
Exploits to the Lattice1 GCE not impacting the HSM and user security.
Vulnerabilities on sites hosted by third parties.
Denial of service attacks.
Legal Disclaimers
We reserve the right to modify the Bug Bounty Program or cancel the Bug Bounty Program at any time.
This current policy described on this page is v1.0 of our Bug Bounty Program.
Last updated