Vulnerability Disclosure Policy

Purpose
This policy details how AppSecInc manages reporting of security vulnerability information to product vendors, our customers, and the public. The overall goal of this policy is to help all parties understand and address vulnerabilities in their environment, thus minimizing risk for everyone.

Process Of Vulnerability Reporting
The vulnerability reporting process has four primary steps: discovery, notification, resolution, and release. Whenever possible, AppSecInc will follow these steps. However, specific circumstances (like an unresponsive party in the process) may make this impossible.

• Discovery: When we discover a flaw, we will create a vulnerability summary report which includes both a high-level description of the vulnerability and a detailed technical description.
• Notification: AppSecInc will notify the appropriate vendor(s) of the flaw by sending an e-mail with the summary report. We encourage vendors to acknowledge receipt of this information and to begin their own internal validation.
• Resolution: Following the recommendations of independent organizations like the Computer Emergency Response Team (CERT), AppSecInc will maintain a silence period of 45 days after the notification step, during which vendors are encouraged to do their own testing and build a fix (patch, workaround, etc.).
• Release: Vulnerability release to the general public will generally follow successful completion of the resolution process. Depending on factors including vulnerability severity, exploit availability, and disclosure by third parties, however, AppSecInc may add protections, checks, and tests to its products at any time.

AppSecInc's vulnerability release, or security advisory, will contain the following:

• Advisory Name: A descriptive name.
• Report Date: The date the Security Advisory is submitted to the vendor.
• Release Date: The date the Security Advisory is to be released to the public.
• Product: The name of the vulnerable product(s), with the specific affected versions.
• Platform: The operating system(s) or other platform information.
• Severity: A one-line description of the severity such as "remote execution of code" or "local privilege escalation."
• Author: The author (or authors) of the advisory.
• Vendor Status: Information about the anticipated availability of a bulletin or patch from the vendor (if available).
• CVE Candidate: CVE candidate vulnerability reference number (information regarding CVE is available at http://cve.mitre.org).
• Reference: A URL to the security advisory within the archives on the AppSecInc web site
• Overview: An executive overview of the vulnerability.
• Details: The details will include some or all of the following: a description of how the vulnerability presents itself, components and configurations that are affected, mitigating factors, workarounds or configuration changes to resolve the vulnerability, and/or preventative measures for similar problems in the future.
• Vendor Response: AppSecInc will include vendor information, if provided, such as a brief statement, a link to a security bulletin or patch information in our public release. This makes it easier for customers to find the information they need in order to address the vulnerability in their environment
• Recommendations: AppSecInc will recommend available courses of action for customers to eliminate or mitigate the vulnerability in their environment. The customer must decide which course of action, if any, is best for their environment. This section will include one or more of the following: vendor patch information, configuration changes, additional software or hardware protection methods, and/or methods for detecting and finding vulnerable systems.
• Disclosure Policy: A link to this document and other disclosure policies pertinent to this vulnerability reporting process.
• Signature Information: A link to the key used to sign the Security Advisory on the AppSecInc web site.

• Proof of concept code or test code that could readily be turned into an exploit.
• Sufficiently detailed technical information, such as exact data inputs, buffer offsets, or shell code strategies, that could expedite the writing of exploit code.