Author: Haotian, Independent Researcher Source: X, @tmel0211
Before the clear legal responsibility is determined, there are different voices questioning the professional ethics of “white hats” and the vulnerability disclosure mechanisms and bug bounty programs of centralized exchanges. However, in the security community, this issue is not at all “fresh”:
1) A standardized vulnerability disclosure mechanism is actually a process of coordination between security companies (party B) and clients (party A) to discover vulnerabilities, fix them, and address bug bounties, before the vulnerability is publicly disclosed after being fixed, everyone is happy. Clearly, there were coordination issues between Certik and Kraken:
1. Identify vulnerabilities and promptly report them to the client, describing the type of vulnerability, its severity, and how to reproduce it. If a “white hat” discovers a vulnerability but doesn’t disclose it, they would be acting like a hacker. By choosing to disclose the vulnerability to the client, it shows that their intention is not malicious.
2. Confirm the vulnerability and assess the risk. The security company and the client confirm the existence of the vulnerability, its severity, impact, and design a repair plan. This process involves agreeing on how to collaborate on fixing the vulnerability and setting bug bounty rewards. Otherwise, there may be a situation where the client refuses to pay the bug bounty, claiming that the vulnerability was already reported, which could make the white hat’s efforts go to waste.
3. Develop a repair plan and retest to ensure the successful resolution of the vulnerability. This process usually involves the client’s development team and the security company’s technical staff agreeing on and implementing code fixes together. If it reaches this stage, it means that both parties have reached a consensus on the severity of the vulnerability and the bug bounty rewards, and their common goal is to fix the vulnerability promptly. After that, a press release is issued to disclose the vulnerability and the collaborative fixing process.
2) Whether Certik, as a security company, has a good reputation or is criticized by many, it’s hard to come to a conclusion based solely on moral judgment. One thing is certain, if a security company often stirs up trouble, it must be due to complex and mishandled interests.
After communicating with several friends from security companies, it is believed that the process of this incident might be as follows:
1. Certik did discover and report the vulnerability to Kraken, indicating that the initial intention was not malicious. However, it has now escalated into a major scandal in the security industry, and the underlying reasons need to be clarified.
2. The account marked as a Certik staff member’s KYC only added $4, indicating that the vulnerability testing initially stayed within reasonable limits. Regardless of the cause, the evidence from both sides should be considered, but currently, it does seem to have crossed the boundaries of professional ethics.
3. It is estimated that both parties did not reach an agreement on bug bounty rewards and fixing vulnerabilities, possibly resulting in Kraken rejecting the bug bounty claim. Therefore, during the repair process, Certik might have engaged in a larger-scale “testing” out of personal retaliation or deliberate company behavior.
There are various possibilities for this process to be dragged out, but fundamentally, it is a matter of conflicting interests. The vulnerability disclosure at Kraken, a centralized exchange, is inefficient and opaque, while Certik’s involvement in security vulnerabilities lacks standardization and norms.
In conclusion, the above is only a reasonable speculation. Specific information should be awaited for further disclosure. The key issue of contention between security white hats and centralized institutions lies in the “slow treatment” of the first parties and the lack of transparency in the vulnerability disclosure and fixing process by centralized organizations. 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, permissionless, user-driven modular security layer. Purely centralized security disputes harbor various possibilities in the shadows. A decentralized security service solution is needed to play a role throughout the security protection lifecycle (especially in dealing with uncontrollable factors caused by human error), even though this path is arduous, it is imperative.
In recent years, security audit services have evolved from a simple business cooperation model to a series of controversies, rug scandals after audits, and today’s confrontations between parties A and B, all stemming from the lack of transparency in security services and the complexity of interests in audit business. It is hoped that the security industry, with the exposure of these issues, will further develop standardized standards, optimized processes, and more professional services.
In any case, while some security companies may be replaceable, 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.
