A security vulnerability is a flaw within a software system that can cause it to work contrary to its documented design and could be exploited to cause the system to violate its documented security policy or function.

The purpose of a Security Advisory is to provide information that assists the general public in understanding a security vulnerability, the products and versions it affects, steps required for "reproduction" of the discovered vulnerability and the steps that can be taken to defend affected systems and networks against it.

A Security Advisory may contain, but is not limited to the following:

• Root Cause: The underlying coding flaw that resulted in the vulnerability.
• Attack Vectors: The scenario(s) via which an attacker could exploit the vulnerability.
• Timeline: The dates of important milestones. Examples include the date the SA was submitted to the Vendor, the date on which the Vendor reported its finding to the Finder, and so forth.
• Vendor Status: Information about the anticipated availability of a bulletin or patch from the vendor.
• Vendor Response: if received, such as a brief statement, a link to a security bulletin or patch information in. This makes it easier for customers to find the information they need in order to address the vulnerability in their environment.

Terms and Abbreviations

• The Finder: The security researcher, customer, or other interested person or organization who discovers the vulnerability.
• The Vendor: The person, organization, or company that developed the product, or is responsible for maintaining it.

Caveats

The Finder may, at its discretion,

1. provide the means by which readers can confirm the authenticity, origin and validity of the security advisory.
2. provide a repository for the security advisories it publishes the location of this repository is listed in the Finder's Security Reporting Policy.
3. publish its security advisories on its own subscription mail lists or public vulnerability disclosure lists.

The Vendor may, at its discretion,

1. provide a means of proactively notifying interested parties when new security advisories are published.
2. provide a means by which readers can confirm the authenticity and origin of the security advisory.
3. the vendor is responsible to provide proper credits for the discovery of this vulnerability. If he chooses not to provide proper credits he will loose his privilege for further notifications

Phases

Discovery

The Finder discovers what they consider to be a security vulnerability (the Potential Flaw), validates the findings, and prepares a report (Security Advisory) describing the Potential Flaw.

The discovery of this Potential Flaw occurs but not limited to:

1. We (Exploitlabs) performed a customer audit and this flaw was discovered on a software or hardware product.
2. The vulnerability was discovered during our scheduled security evaluation of critical software or hardware components.
3. The vulnerability was discovered by accident.

Notification

The Finder notifies the Vendor and advises him of the Potential Flaw. The Vendor must confirm that he has received the notification.

The Vendor shall report one of the following to the Finder:

1. The Flaw is confirmed.
2. The Flaw has disproved.
3. The Flaw requires further investigation.

If the Vendor's investigation confirms that the Flaw exists, the Vendor shall advise the Finder of its plans for addressing the issue.

NOTE: If a third party publicly discloses the Flaw before the release date agreed to by the Finder and Vendor, or if the Flaw comes under active exploitation, then the Finder or Vendor may immediately release its Security Advisory.

Release

In a coordinated fashion, the Vendor and the Finder publicly release information about the vulnerability, along with its resolution. If the Vendor chooses to release its remedy independently, it shall inform the Finder of its decision, and shall exercise reasonable efforts to provide ample lead time before doing so.

During the first fourteen (14) calendar days after the release of a Security Advisory to the Vendor, the Vendor and Finder restrict the release of supplementary data in the interest of giving users time to protect their systems, and share it only with people or organizations associated with defending systems against the vulnerability, protecting critical infrastructures, law enforcement, and so forth. Once this grace period expires, the supplementary data can be distributed as each party deems. If no Vendor response is received within seven (7) calendar days the Finder shall release any and / or all information it deems necessary to fulfill it's safe notification to the general public.

NOTE: These timelines shall be doubled ( 28 and 14 days ) for Open Source developers and those products covered under the GNU GENERAL PUBLIC LICENSE or any other free software license.

The Vendor shall exercise reasonable efforts to make the notification available to all users who might be affected, provide information that assists users in determining whether they are using an affected version of the product, and provide information that assists users in minimizing the risk the Potential Flaw poses to their systems.

The Vendor shall include information such as:

1. The effect of exploiting the vulnerability.
2. Configuration settings that make a system more or less susceptible to attack via the vulnerability.
3. Known side effects of the remedy.
4. Proper credits.

As discussed in Notification above, the Finder and Vendor should act in concert to simultaneously release their advisories after a remedy is available. However, if a third party publicly discloses the vulnerability before the remedy's release date, or if the vulnerability comes under active exploitation, it may be necessary to act separately. Even in this case, however, it is important to avoid exacerbating an already bad situation.