7 steps to avoid uncoordinated vulnerability disclosure

Imagine you are the cybersecurity manager for a company that owns the website www.example.com. One day, your sales department receives an email from an unknown individual and forwards it to you. The email content is as follows:

You example.com/login.php page break. Sending XSS.

If no fix, I send to FD in month.

What’s going on? You’ve just been contacted by an ethical hacker reporting a cross-site scripting (XSS) vulnerability in your site. Here are the do’s and don’ts for dealing with the situation to avoid public uncoordinated vulnerability disclosure – and to fix the security issue in your systems.

Step 1. Adopt the right attitude

First of all, realize that you have not been hacked. If this were an attacker, you likely wouldn’t be notified so politely, and the potential impact would be much greater. In fact, you might only have learned of the issue once your web page had been used to attack somebody else or one of your customers filed a lawsuit because their sensitive information was released into the wild.

The person who contacted you is an independent security researcher, aka an ethical hacker. They find security issues and report them in good faith, making money from bug bounties.

Do’s:

• Have respect for the hacker. They contacted you to help, not to harm you.
• Be patient. They might not be great at communicating with companies.
• They might not be a native speaker of English. If possible, try to find out their preferred language and find someone who can help you with translation.
• Respect their privacy. If they insist on using a nickname or an anonymous proxy, do not push them into revealing personal information. If they use PGP to encrypt and sign their messages, use their public key to encrypt your responses as well. Privacy is important for hackers because not all businesses are as smart as you, and many will take legal action even against ethical hackers, often involving law enforcement.
• Remember that if you don’t follow the proposed process and the hacker eventually discloses your vulnerability publicly, the responsibility will be yours, not the hacker’s.

Don’ts:

• Don’t ignore the message. Even if you decide to fix the issue quietly, it may be publicly disclosed before you are ready.
• Don’t try to cut corners, or you may gain a bad reputation in the hacker community, and other ethical hackers won’t be willing to help you with security in the future.

Step 2. Communicate efficiently

To avoid uncontrolled public disclosure of your security vulnerabilities, make sure that the reporting hacker is kept up to date on the remediation process. The reason they reported the issue and want it fixed as soon as possible is that other users might be endangered. For example, an XSS vulnerability in your web application could be used for more effective phishing, enabling attackers to use your domain name to gain trust in social engineering tricks.

Do’s:

• Delegate responsibility correctly. The original email might have reached a non-technical person – maybe a sales or marketing contact. Select a technical employee, preferably from your IT security team, and make them the main point of contact for all communication with the hacker. Make sure this person knows the right attitude to adopt (see step 1).
• Ensure all your employees know how to escalate potential security issues and will not ignore such reports. Train staff in public-facing roles on how to handle security reports, who to forward them to, and when to bypass the escalation process used for regular inquiries.
• Communicate clearly and regularly. Keep the hacker updated on the progress of remediation. Reply immediately to confirm that you received the report and are looking into it. Provide specific time estimates, for example, that you intend to finish research in five business days.
• Ethical hackers follow responsible disclosure practices. They will usually give you a specific timeframe to fix a vulnerability before they disclose it publicly (one month in our example). If they have not specified a timeframe, ask them about their preference and negotiate the timeframe if necessary.

Don’ts:

• Don’t be afraid to ask for additional help or information. If you have a problem confirming the vulnerability, ask the hacker. Even if you have a problem fixing the issue, it won’t hurt to ask the hacker for tips.
• Don’t keep the hacker waiting for updates. If, for example, you promised to investigate within seven calendar days and did not, make sure to contact the hacker, apologize, and provide a new time estimate.

Step 3. Confirm the vulnerability

Before fixing, you should confirm the reported vulnerability and learn more about it. This will make the bug easier to understand and fix.

Do’s:

• Use an automated web vulnerability scanner such as Invicti or Acunetix by Invicti to quickly check if the reported vulnerability is detected. If you run scans with the IAST feature active on your server, you can also get additional information about the exact location of the root cause in your source code or byte code.
• If you need more information to find or confirm the vulnerability, you may need to delegate one of your security engineers to investigate. You could also hire an external company to perform a penetration test or otherwise investigate the issue.

Don’ts:

• Don’t assume that the vulnerability does not exist just because your scanner or your team cannot find or confirm it. Ask the hacker for help and further details. They will often provide a proof of concept to illustrate the issue (as in our example) – ask for one if they did not.

Step 4. Remediate promptly

Even if the reported vulnerability does not seem very dangerous, you should prioritize remediation simply because the issue was reported by an external source and could be disclosed publicly.

Do’s:

• You can often apply a temporary workaround, such as a web application firewall (WAF) rule, to protect your system until you can fix the vulnerability. Invicti scanners integrate with several WAF products and can export rules, so you may even be able to do this automatically.
• If the vulnerability was found in code developed in-house, make the fix an opportunity to educate your developers on avoiding such vulnerabilities in the future. Invicti Learn is one resource with plenty of information about understanding, fixing, and preventing web vulnerabilities.
• Once you are done, ask the hacker who reported the issue to confirm the fix.

Don’ts:

• Don’t think a vulnerability is not your problem if it resides in third-party software. If a fix is not available from that third party, you may have to request it from the vendor or create your own dedicated patch (typically for open-source software). Zero-day vulnerabilities in popular third-party software are often the most dangerous because they can affect multiple organizations, so black-hat hackers try to exploit them first.
• Don’t treat temporary mitigation as a permanent fix. A WAF rule can block a specific attack, but until you fix the underlying vulnerability, you could still be targeted by a different attack.

Step 5. Reward the ethical hacker

Even if you do not have a formal bounty program, you should appreciate and reward the hacker’s help. After all, their report may have saved you from a potentially damaging situation, especially if the bug could have been actively exploited, causing a data breach and reputation loss.

Do’s:

• Decide internally what you are willing to pay the hacker for their help (and formalize the process – see step 7). Make sure that whoever approves such payouts is fully aware of the potential losses and damages if a malicious hacker had found and exploited the vulnerability.
• If the hacker assists your staff with remediation and retesting, be ready to increase the reward.

Don’ts:

• Don’t try to get out of awarding a finder‘s fee. Be honest and transparent, avoiding misleading practices such as saying that the bug has already been reported and a bounty paid out. Trust and respect are fundamental in the independent security researcher community.

Step 6. Disclose the vulnerability

Once the vulnerability is fixed, it is best practice to disclose the issue and all related information for at least two reasons. First of all, there is always the risk that malicious actors have already silently exploited the vulnerability, so you want to be the first to disclose it (rather than see your company name in third-party disclosures announcing that your sensitive data has been stolen). And secondly, publishing a full report is always very positive for the image of your company in the security industry – as an example, see what Cloudflare did when it encountered a major problem.

Do’s:

• Prepare a detailed report including information about who found and reported the vulnerability, how it was confirmed, and how it was fixed. Include as much technical detail as safely possible.
• Publish the report on your website and/or social media. If necessary, communicate directly with all parties that might have been affected by the vulnerability.

Don’ts:

• Don’t treat responsible vulnerability disclosure as something that can harm your company and should be avoided. Clear information on how an issue was introduced, reported, and fixed can be invaluable to other organizations, and disclosing it makes everyone more secure.

Step 7. Build a vulnerability disclosure policy

After fixing the immediate issue, take the opportunity to learn from the experience. If this was your first time dealing with an external report, you likely executed many of the above steps ad hoc, so it’s a good idea to define procedures for the future. The best way to do it is to create your own vulnerability disclosure program and a bug bounty program.

While many companies still don’t have such programs, technology giants such as Microsoft and Google are well-prepared, so you may want to follow in their footsteps.

Do’s:

• Describe your preferred coordinated vulnerability disclosure process (VDP). Decide how you would like to be informed about vulnerabilities in the future. Designate a person to receive reports via email, phone, or any other channels that you select.
• Create a security.txt file for your website with the relevant information, and make sure that your contact information is easy to find.
• Decide on the scope of bug bounties you are willing to award. Provide payout ranges based on specific parameters, such as business criticality and vulnerability class. You can use the automatic issue classification functionality in Invicti products as a starting point for deciding which types of vulnerabilities deserve what payout for which location and criticality.
• Publish information about your coordinated vulnerability disclosure (CVD) process on your website, along with your disclosure guidelines, acceptable testing methods, and bug bounty conditions. Make sure this information is easy to find and easy to read, even for non-native speakers of English.
• You can also work with a third-party partner to help you with processing vulnerability reports and communicating with hackers – HackerOne and Bugcrowd are two popular platforms. Such external platforms automate many of the steps involved in reporting vulnerabilities and paying bounties and are also considered a safe harbor by the community, helping hackers avoid unethical businesses.

Don’ts:

• Don’t assume that adopting a vulnerability disclosure policy will protect you from web application security issues. Knowing how to respond to responsible disclosures is only a small part of your application security program. You still need to perform regular security testing using at least an automatic vulnerability scanner. To find and eliminate issues from development to production, it is best practice to regularly scan production applications for vulnerabilities while also integrating security testing directly into your software development life cycle (SDLC).