Tried, Tested and Proven

Co-ordinated Disclosure Policy


This policy details how Portcullis manages the public reporting of security vulnerability information we hold to computer industry vendors, our customers and the public. This policy intends to enable all parties to understand and address vulnerabilities expeditiously in their environment and to minimize the risks that vulnerability information poses.

The goals of the policy are:

  • To assist in the identification and remediation of vulnerabilities in a manner which is effective and efficient for all parties.
  • To minimize the risk to all parties from such vulnerabilities
  • To provide all parties with information that supports independent corroboration of these vulnerabilities.
  • To provide the security community with the information necessary to learn from these vulnerabilities and thus identify, manage, and reduce the risks of future vulnerabilities in information technology as may occur.
  • To minimize the amount of time and resources that all parties would otherwise be required to manage these vulnerabilities.
  • To facilitate long-term research and development of techniques, products, and processes for understanding, avoiding or mitigating security vulnerabilities
  • To circumvent such antagonism as can sometimes arise in the absence of a formal disclosure policy such as this one.


The basic steps of the Portcullis Security Vulnerability Reporting Process, with details in the subsequent section of this document, are below. These steps are aspirational in nature, and while Portcullis will attempt to follow them and encourages the other parties involved to follow them, there can be no guarantees that differing factual situations will not affect any parties’ implementation of the process.

The basic steps are:

1. Discovery: Portcullis discovers a security vulnerability (“the bug”) either by accident or while working on specific security research

2. Notification. Portcullis notifies the vendor of the product that contains the bug (“initial notification”). In turn, the vendor provides Portcullis with evidence that the initial notification was received (“vendor receipt”)

3. Validation: The vendor tries to verify and validate Portcullis claims (“reproduction”)

4. Resolution: The vendor tries to identify where the bug resides (“diagnosis”). The vendor develops a patch or workaround that eliminates or reduces the risk of the vulnerability (“fix development”). The fix development is then optionally tested by Portcullis to ensure that the bug has been corrected (“patch testing”). Portcullis notifies the vendor of the outcome of the patch testing

5. Release: In a coordinated fashion, the vendor and Portcullis publicly release information about the vulnerability, along with its resolution. The vendor may initially release this information to its customers and other organizations with which it may have special relationships


The following describes how Portcullis intends to operate during each phase of the Advisory Process.

Phase 1: Discovery

Portcullis will validate its findings and draft an “initial notification” email.
The purpose of this first email will be to:

  • Confirm an appropriate vendor contact
  • Establish whether the vendor wishes to use PGP
  • Provide a copy of our co-ordinated disclosure policy
  • Give the vendor details of the product and version affected

At this point details of the vulnerability will be entered into Portcullis’ internal bug tracking system.

Phase 2: Notification and Acknowledgement

Upon internal validation of the potential flaw, Portcullis will distribute the “initial email” and record the “initial notification” date.

Portcullis will utilise external databases such as OSVDB’s vendor dictionary as well as the vendors web site to locate a suitable contact.

If Portcullis is not able to identify the appropriate security-related email address for that vendor, an email will be sent to one or more of the following contacts:

  • security@
  • support@

Once the notification is sent by Portcullis, Portcullis will expect a response by email (“vendor receipt”) from the vendor within 7 days that (a) acknowledges that they have received and read the notification and (b) describes how they intend to engage with Portcullis.

After receiving a response from the vendor, or where no response is forthcoming Portcullis’ published list of upcoming advisories will be updated to reference the vendor concerned. No details will be provided as to the product or type of vulnerability that has been found. In the latter case, Portcullis may then proceed to phase 5 at their discretion.

Phase 3: Validation

During this phase, it is anticipated that the vendor will attempt to address the vulnerability (“reproduction”). Portcullis will provided more detailed information in the manner agreed which should allow the correct identification of the code containing the bug.

1. If the vulnerability is found in a product which is supported by the vendor (“supported product”) then the vendor should.

1. Reproduce the vulnerability,
2. Determine if there is enough evidence for the existence of the vulnerability if it cannot be reproduced,
3. Determine if the vulnerability is already known (and possibly already resolved), or
4. Work with Portcullis or other security experts to determine if the vulnerability is related to the
specific environment in which it was discovered (including configuration errors or interactions with
other products). As resources permit, Portcullis will help the vendor with the validation phase when

2. If the vulnerability is found in an unsupported or discontinued product, the vendor may refuse to validate the vulnerability. However, the vendor should undertake measures to ensure that the reported vulnerability does not exist in supported product versions or other supported products based on the vulnerable product.

3. The vendor should examine its product to ensure that it is free of other problems that may be similar to the reported vulnerability. Related vulnerabilities in the same product are often found by others after a specific vulnerability is publicly disclosed. Finding multiple vulnerabilities up front during the validation phase saves the vendor and customer’s time and money by minimizing the need to create and install multiple patches.

4. The vendor should provide status updates to Portcullis every 7 days from initial notification. The vendor and Portcullis may come to an agreement for sharing less frequent updates.

5. The vendor should notify Portcullis when it is able to reproduce the vulnerability

6. The vendor should attempt to resolve the vulnerability as described in phase 4 within 30 days of initial notification. There are valid reasons why vulnerabilities cannot be resolved within this time period. If a good faith effort is being made by the vendor to validate the vulnerability, Portcullis will delay the public disclosure of information about the vulnerability until a resolution is found or created.

7. If the vendor is aware of other vendors that share the same code base as the affected product, the vendor should either (1) notify those vendors, or (2) notify a vulnerability coordinator, such as Bugtraq, that other vendors may be affected by the reported vulnerability.

Phase 4: Resolution

The resolution of a vulnerability should involve action regarding one or more of the following:

  • Patch creation
  • Recommendation of configuration change
  • Design change
  • Workaround

During this phase, Portcullis recommends that the vendor should:

1. Identify the fundamental nature of the flaw within the source code or in the design of the product (“diagnosis”).

2. Determine whether to (a) provide a patch, configuration or design change, or workaround that appropriately reduces or eliminates the risk of the vulnerability (“fix development”), or (b) provide Portcullis with specific reasons for their decision to pursue an alternative to fixing the vulnerability.

3. Request time extensions from Portcullis when necessary.

4. Test the patches, configuration changes, and workarounds sufficiently to clarify how it might or may not adversely affect the operation of the product.

5. Provide Portcullis with details of the proposed fix (“fix development”). The vendor should also provide Portcullis with any patches so we may optionally conduct our own testing of the fix (“patch testing”). This will help Portcullis confirm that the vulnerability has been reduced or eliminated. A vendor may have existing policies in place that require that only supported customers have access to this information; these policies should also be communicated to Portcullis by email.

If the vendor does not participate in the validation or resolution phases, or if the vendor is unresponsive to Portcullis, then Portcullis considers that it is unlikely that the vendor’s customers will be fully satisfied.

Phase 5: Release

1. Portcullis will work with the vendor to create a timetable pursuant to which the vulnerability information may be released to Portcullis customers, the vendor’s customers and the general public in a coordinated fashion.

2. However, if the parties cannot agree to a coordinated release of the vulnerability information and a forced disclosure is triggered, Portcullis will honour a “grace period” of up to 30 days, during which it will unilaterally update the published list of upcoming advisories to include further summary information to the public. No details of the specific vulnerability will be disclosed in an effort to reduce the likelihood that attackers might exploit the product based on receiving the new vulnerability information. Portcullis will make every effort to describe or publish workarounds, configuration or design changes, or even patches where this information is not available from the vendor. After the expiration of the 30-day grace period Portcullis will publicly release the full Security Advisory.

3. If the vendor has not resolved the vulnerability within the timeframe determined in the Release Phase, then Portcullis may work with a coordinator, such as CERT/CC ( to announce the vulnerability to customers and the public.

4. If another security reporter has publicly announced the vulnerability before the release date agreed between by Portcullis and the vendor, Portcullis may immediately share details of the vulnerability with its customers who might be exposed to such vulnerability.

5. The security advisory will contain the following information:

  • Advisory references. An internal Portcullis reference and an external MITRE supplied CVE ID
  • Vendor name. The name(s) of the vendor of the product
  • Vulnerable products. The name(s) of the vulnerable product(s) with specific version(s) affected
  • Vulnerability title. The type of vulnerability discovered
  • Reporter. The name of the author(s) of the advisory
  • Details. 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
      • Preventative measures to address similar problems in the future
  • Impact. A description of the impact the vulnerability has/can have on the system i.e. “remote execution of code” or “local privilege escalation”
  • Exploit code. Where deemed necessary/desirable Proof of Concept code to enable the verification of the issue(s) discovered
  • Workaround. If known, Portcullis will recommend available courses of action for customers to eliminate or mitigate the vulnerability in their environment


This policy is intended conform with Internet-Draft, “Responsible Vulnerability Disclosure Process”, by Steve Christey of MITRE and Chris Wysopal of @stake. Portions of this policy are also based on “Full Disclosure Policy (RFPolicy) v2.0″ by Rain Forest Puppy

  • Vendors should provide a security contact address on their web site and make it easy to find
  • Vendors should set up a security response process to respond to security vulnerabilities in a timely manner
  • Vendors should incorporate lessons learned into training for their security, IT, product and marketing organizations
  • Vendors should notify customers that someone has reported a problem, present a temporary work-around and/or tell customers that they are working to provide a final resolution
  • Vendors should clearly notify customers and the public when a resolution is (a) faulty, (b) revised or (c) resolved
  • Vendors should credit the reporter who notified them of the vulnerability if the reporter was working to responsibly protect customers
  • Vendors should create and communicate a vulnerability response policy which details how they respond to and assess reports of vulnerabilities, how long customers should expect to wait for a typical resolution, and information about vulnerability reporting standards, if any, that they follow

Suggestions for customers

  • The customer must not assume that the lack of details in a public vulnerability report will prevent the creation of an exploit
  • If a vendor has released information regarding a vulnerability, then the customer should assume that the information is credible. The customer should not require that the vulnerability be demonstrated before applying the resolution
  • If a vendor has not released such information, but a well-established reporter or coordination center has, then the customer should assume that the information is credible. The customer should not require that the vulnerability be demonstrated before applying the resolution
  • If vulnerability information has been released and a grace period exists, then the customer should apply the resolution to its system during the grace period immediately
  • Where possible, the customer should test any patches, configuration or design changes, or workarounds on test systems before making the changes in an operational environment
  • The customer should inform the vendor and the public if a patch, configuration or design change, or workaround does not appear to work as described.
  • The customer should give preference to products whose vendors follow coordinated disclosure practices