Researcher Security Advisory Writing Guidelines
Open Security Foundation / OSVDB.org
moderators at osvdb.org
This document has been prepared by the Open Security Foundation (OSF) to assist security researchers in working with vendors and creating advisories. Security advisories help convey important information to the community, regardless of your goals or intentions. While you may have an intended audience in mind as you write an advisory, they will not be the only ones to read it. There is a lot of information that can be included in a properly written advisory, and leaving any out makes your advisory something less than it could be.
The OSF encourages researchers to use this document as a guideline for writing security advisories. We will focus on the content of the advisory, not the style. While there is a logical order of presentation, what ultimately matters is including the necessary information, though some things are most beneficial at the start of an advisory. Remember; more information is better, and including information for other parties ultimately helps more people.
How you disclose a vulnerability is your choice. The debate about “responsible” or “coordinated” disclosure has raged for over two decades. There is no universal accord on what is an appropriate period of time for a vendor to reply to a vulnerability report, or fix the issue, though it is generally agreed that it is at the least more than a day and less than a year. Researchers, we fully encourage you to work with vendors and coordinate disclosure if possible; your goal is to improve security after all, right? The following material will give you additional information and considerations for this process.
Brian Martin & Daniel Moeller
Thanks to Dave, we now have a completely re-written creditee system. For years, we operated off a four field system (name, email, company, url) for tracking vulnerability researchers. While we tracked that information, it was not flexible and led to serious problems with data integrity. Even worse, it didn’t allow for long term tracking of a researcher’s disclosure history. There were several cases where the system couldn’t handle proper data tracking, for example:
- If John Doe works for CompX and discloses a vulnerability, that becomes set in stone as associated with his name. This is problematic if John Doe goes to CompZ and discloses additional vulnerabilities.
- The above scenario is even more problematic if John Doe then releases a vulnerability through a program such as iDefense or ZDI.
- If two researchers shared the same name, there was no way to differentiate them.
While creating a creditee system to track this may seem straightforward, it is surprisingly difficult. After a lot of brainstorming and trying to determine where the system may fall short, we came up with something. What we are now referring to as “creditee v2” will be used with a clean set of data. All previous creditee data entered is labeled (internally) as “v1” and will only display if there is no v2 data.
The new creditee system is a bit more complex, but allows for one individual to be associated with multiple e-mail addresses, companies or organizations. We can also now track the country of the researcher and company separately to account for multi-national companies. With a better data set, we can now do a lot more analysis and generate interesting statistics for vulnerability researchers. As an example of the new system, you can now easily see all vulnerabilities associated with your name, e-mail addresses and affiliations. Clicking on the affiliation will show all researchers and the vulnerabilities disclosed by a given organization.
Even better, this system allows for one click access to your prior vulnerability disclosures. This could be useful for resumes, web page bios and more. We fully encourage you to “ego mangle” to help us fill in the data. Create an account, find your vulnerabilities in the database and fill in the details associated with that disclosure. Note: we are tracking the information associated with the disclosure, not necessarily your current e-mail or affiliation. If you can’t find your vulnerability in the database, mail moderators[at]osvdb.org with details. We’ll help you find it or add it in case it is missing. We’re still working out several bugs in the system, but this is a great overhaul and a foundation of another long term feature enhancement: “researcher confidence”.