Title: The Complexities of Bug Disclosure and the Importance of Transparent Processes
Author: Haotian, Independent Researcher
Source: X, @tmel0211
Before the clear legal responsibilities are determined, there will always be different voices questioning the professional ethics of “white hats,” as well as the bug disclosure and bug bounty mechanisms of centralized exchanges. However, this issue is not “new” in the security community:
1) A well-established bug disclosure mechanism is actually a coordinated process between security companies (party B) and their clients (party A) to address issues related to bug discovery, bug fixes, and bug bounties. Only after the bug has been fixed and disclosed to the public does everyone feel satisfied. It is evident that there were coordination issues between Certik and Kraken in this process:
1. The white hat discovers a bug and promptly reports it to the client, providing details about the bug’s type, severity, and how to reproduce it. If the white hat chooses not to disclose the bug, they would be considered a hacker. Since they chose to disclose it to the client, it indicates that their intention is not malicious.
2. The bug is confirmed and assessed for risk. Both the security company and the client acknowledge the bug’s existence, severity, impact, and design a plan for fixing it. This process also involves determining how the bug bounty will be distributed. Otherwise, the client may use the excuse that the bug has already been reported to refuse to pay the corresponding bug bounty, leaving the white hat empty-handed.
3. A bug fix plan is formulated and retested to ensure successful resolution. Typically, the client’s development team and the security company’s technical personnel collaborate to implement the code fix. If the process reaches this stage, it means that both parties have reached a consensus on the “bug severity level and bug bounty arrangements.” Therefore, their shared objective is to promptly fix the bug and then publicly disclose it through a press release, revealing the entire process of bug discovery and joint resolution.
2) Whether Certik is highly regarded or widely criticized in the security industry, it is difficult to conclude based solely on moral judgment. However, if a security company frequently gets involved in controversies, it is likely due to the complexity of the underlying interests and mishandling of those issues.
I communicated with some friends in security companies, and they believe the following might be the process in this case:
1. Certik did discover and report the bug to Kraken, indicating that their intentions were not those of a “hacker.” However, this incident has become a major scandal in the security industry, and the underlying causes and consequences need to be clarified.
2. The account marked as Certik staff’s KYC account only had a balance increase of $4, indicating that the bug testing initially remained within reasonable limits. Regardless of the reasons, the evidence provided by both parties will determine the final verdict. However, it is clear that the boundaries of professional ethics were indeed crossed.
3. It is possible that the bug bounty and bug-fixing collaboration between the two parties did not reach an agreement. Kraken may have rejected giving the corresponding bounty for reasons related to the bug report. As a result, during the bug-fixing period, Certik engaged in a larger-scale “test” as a form of personal retaliation or intentional corporate behavior.
There are various possibilities for disputes in this process, but fundamentally, they are issues related to conflicting interests. The bug disclosure process of centralized exchanges like Kraken is inefficient and lacks transparency, while Certik’s involvement in security vulnerabilities lacks standardization and norms.
In conclusion, the above is only a reasonable speculation, and further disclosure of the results will provide more accurate information. However, the key point of contention between security white hats and centralized organizations lies in the slow response from the central institutions and the lack of transparency in the bug disclosure and fixing processes. This is the focal point that everyone should pay attention to.
This is also the fundamental reason why I previously praised @GoPlusSecurity for building an open, censorship-resistant, user-driven modular security layer. Purely centralized security disputes involve various hidden possibilities. Only a decentralized security service solution can play a role throughout the entire security protection lifecycle, especially in dealing with uncontrollable factors caused by human errors, although this path may be challenging and long, it is necessary.
In the past few years, security auditing services have evolved from a business cooperation model of one project after another. The endorsement controversies, rug scandals after audits, and the ongoing conflicts between parties A and B are all closely related to the lack of information transparency in security services and the complexities of the audit business itself. It is hoped that with the exposure of these issues, the security industry can establish more standardized standards, optimized processes, and professional services.
Regardless, certain security companies may be replaceable, but the sacred image of security guardians must not be compromised. At the same time, the contributions of security white hats should be respected by the market.
