Reduce Friction in the Reporting Process

As a vendor, it is important to not treat reporters with suspicion or hostility. It's likely they have important information about your product, and they want to share it with you. Furthermore, vendors should take care not to frustrate reporters' attempts to make contact by building too many assumptions into their CVD process.

In the course of our own vulnerability coordination efforts, we have observed all of the following erroneous assumptions built into vendor's CVD process:

The vendor and the reporter are engaged in a binding two-way negotiation.

This is false for at least two reasons: First, the reporter noticed an observable fact about a product flaw, and they're free to tell whomever they please. Similarly, the vendor is not obliged to keep the reporter in the loop once the report is received. And while it might be possible to eventually constrain the reporter or vendor contractually, that's not a foregone conclusion at the outset. Secondly, there exist adversaries who are entirely indifferent to whatever reporter-vendor agreements about disclosure might be reached, so even the most strictly binding agreement between vendor and reporter can be rendered irrelevant by events beyond either party's control.

The reporter will wait indefinitely for your reply before communicating with others about what they know.

Technology sometimes fails, and we wonder if a message was received. It is helpful to let the reporter know as soon as possible that the report was received. Give regular updates on the process so that the reporter is involved and there is mutual understanding. If reporters are kept out of the loop, they may seek out a third-party coordinator or even publish their report without notice.

The reporter is always a customer or has a customer ID.

At the CERT/CC, we have hit walls in our communication attempts when a vendor's technical support function refuses to help us without a customer ID number. Be sure your tech support staff understand how to forward vulnerability reports to the appropriate individuals or groups within the organization. Vulnerability reports can arrive from anyone.

The reporter has an account on your private portal.

The reporter may not be a customer with a portal account; furthermore, the reporter may wish to remain anonymous and will be unwilling to register for a portal account. Again, be sure it is easy for reporters to find more than one communication channel.

The reporter is willing to sign an NDA.

Some reporters will not sign an NDA. And they shouldn't have to. Remember that the reporter's participation in CVD is voluntary. Be sure your process can accommodate reporters who are unwilling to sign an NDA. Better yet, avoid NDAs altogether for vulnerability reports.

The reporter can send or receive encrypted mail.

The CERT/CC encourages encrypted mail when possible, but it is not appropriate to presume all reporters can or must use encrypted mail. If the reporter declines to use encrypted mail, offer other options. These may include encrypted zip files or a company upload service such as FTP.

The reporter is willing and/or able to fill out a web form.

Some reporters prefer to use anonymous email; be sure you have more communication lines open than just a web form.

The reporter is a human.

Sometimes reports can be auto-generated by tools. Include a clearly defined reporting format for tools if at all possible.

The reporter will keep your correspondence private.

Lack of response or rudeness on the part of a vendor may result in the reporter choosing to post the correspondence publicly. In addition to the negative attention this draws to the vendor and reporter alike, such negative experiences may discourage finders and reporters from reporting vulnerabilities to the vendor in the future.