From the Certik-Kraken dispute, we can see the industry pain points: when will the decentralized security solution come?

Author: Haotian

Actually, before the clear legal liability is defined, there will be different voices on the professional ethics of the ‘white hats’ and the vulnerability disclosure mechanism and bug bounty mechanism of centralized exchanges. However, in the security community, this issue is not ‘new’ at all: 01928374656574839201

1. A proper vulnerability disclosure mechanism is actually a process of coordinating the discovery, vulnerability repair, bug bounty, etc. between the security company as the second party and the customer as the first party. Then everyone can see the disclosure after the vulnerability is fixed, and all are happy. It is quite obvious that there were problems in the coordination process between Certik and Kraken:

1. Discover vulnerabilities and report them to the client in a timely manner, describing the type of vulnerability, the degree of harm, and how to reproduce it. If a ‘white hat’ discovers a vulnerability but does not disclose it, they will become a hacker. However, if they choose to disclose it to the client, it shows that their subjective intention is not an attack.

2. Confirm the vulnerability and assess the risk. The security company and the client confirm the existence of the vulnerability, as well as the severity of the vulnerability, the scope of impact, and the design of the repair plan. This process will determine how to collaborate on the vulnerability repair, how to set up bug bounties, etc. Otherwise, it is easy to occur that the client refuses to pay the corresponding bug bounty on the grounds that the vulnerability has been reported, which may make the white hat work in vain.

3. Develop a repair plan and retest to ensure that the vulnerability is successfully repaired; this process is generally agreed upon and implemented by the client’s development team and the technical personnel of the security company. If it can be pushed to this step, it means that both parties have reached an agreement on the vulnerability level and the corresponding bug bounty. Therefore, the common goal of both parties is to repair the vulnerability in a timely manner, and then issue a press release to disclose the vulnerability and the process of joint repair.

2. Certik, whether this security company is well-regarded or criticized by everyone, it is difficult to have a definite conclusion based solely on moral judgments, and I will not make any evaluations here. Just one point, if a security company often gets involved in disputes, it must be due to overly complicated and mishandled vested interests.

I communicated with some friends from a few security companies and think that the process of this matter may be:

1. Certik did discover and report the vulnerability to Kraken, indicating that the intention was not a “hacker” behavior, but it 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 KYC only added $4, indicating that the vulnerability test initially stayed within reasonable limits. From now on, regardless of the reason, evidence from both sides should be the basis. However, it is indeed beyond the boundaries of professional ethics.

3. It is estimated that the two parties have not reached an agreement on the division of labor in bug bounty and vulnerability fixes. It is possible that Kraken Exchange refused to provide corresponding rewards for reported vulnerabilities. Therefore, Certik conducted a larger-scale “testing” during the repair period, whether it was “personal” retaliation or intentional actions by the company.

There are multiple possibilities for wrangling in this process, but essentially it is a problem of conflicting interests. The vulnerability disclosure of Kraken, a centralized exchange, is inefficient and opaque, and Certik’s involvement in security vulnerabilities lacks norms and standards.

Summary: The above is only a reasonable speculation, and the specific results shall be subject to further disclosure. However, the key issue that security white hats encounter in submitting bugs with centralized institutions is the “slow treatment” and the opaque process of vulnerability disclosure and remediation by centralized organizations, which is the cause of “disputes and frictions” between the two parties. This is the focus issue that everyone should pay attention to.

This is also the fundamental reason why I previously praised @GoPlusSecurity for building an open, non-collusive, user-driven modular security layer. Various opaque possibilities exist in purely centralized security disputes. Only a decentralized security service solution can play a role in the entire security protection lifecycle (especially uncontrollable factors caused by human reasons), although this road is difficult and long, it is imperative.

In the past few years, security audit services have moved from a simple business cooperation model of one order after another. During this process, there have been endorsement storms, audit-related rug scandals, and even today, the confrontation between Party A and Party B is closely related to the lack of transparency in security services and the complexity of audit business itself in terms of sensitive information interests. It is hoped that the security industry can have more standardized standards, optimized processes, and professional services as problems are exposed.

Anyway, the position of certain security companies can be replaced, but the sacred image of security guardians cannot be compromised. At the same time, the contributions of security white hats should also be respected by the market.