Participating States will, on a voluntary basis, encourage responsible reporting of vulnerabilities affecting the security of and in the use of ICTs and share associated information on available remedies to such vulnerabilities, including with relevant segments of the ICT business and industry, with the goal of increasing co-operation and transparency within the OSCE region. OSCE participating States agree that such information exchange, when occurring between States, should use appropriately authorized and protected communication channels, including the contact points designated in line with CBM 8 of Permanent Council Decision No. 1106, with a view to avoiding duplication.

3.2 Ensure the organisation implements and publishes an effective vulnerability disclosure process to support a transparent and open culture within the organisation.  Associated technical control: Implement a vulnerability disclosure policy. (The organisation publishes a vulnerability disclosure policy which provides a public point of contact in order that security researchers and others are able to report issues. Disclosed vulnerabilities are then reported to relevant parties (outlined in the implementation guidance) and acted on in a timely manner.)

6.3 Developers and System Operators shall implement and publish an effective vulnerability disclosure process to support a transparent and open culture within the organisation.  11.2 Developers shall provide security updates and patches, where possible, and notify System Operators and End-users of the security updates. 11.2.1 In instances where updates can’t be provided, Developers shall have mechanisms for escalating issues to the wider community, particularly customers and other Developers. To help deliver this, they could publish bulletins responding to vulnerability disclosures, including detailed and complete common vulnerability enumeration. 

2. Implement a vulnerability disclosure policy  All companies that provide internet-connected devices and services shall provide a public point of contact as part of a vulnerability disclosure policy in order that security researchers and others are able to report issues. Disclosed vulnerabilities should be acted on in a timely manner.

INCIBE-CERT has an established CVD (Coordinated Vulnerability Disclosure) policy that supports those who wish to provide information on vulnerabilities detected, both in INCIBE-CERT's own systems and in the systems of third parties, citizens and private entities in Spain. For this reason, INCIBE-CERT provides support to those people who wish to provide information on vulnerabilities they have detected, and acts by anonymising the informant's data, unless the informant expressly indicates otherwise (at any time during the vulnerability management) or a judge so requires.

Provides recommended procedures for the reporter of a vulnerability: # Report the vulnerability to the National Cyber Security Centre SK-CERT as soon as it is detected in order to minimize the risk of abuse by the attackers. # For confidentiality, it is recommended to encrypt the communication via PGP. # The vulnerability report must include a detailed description of the problem. Suggestion of the vulnerability solution is also possible. # It is recommended to include a detailed contact information in the report, along with the means of secure communication (e. g. PGP fingerprint). # SK-CERT may assist the reporter by taking further steps: * to assess a reported vulnerability from an expert viewpoint, * to register CVE number for vulnerability, * to identify entities concerned and their respective contacts (a manufacturer, national CSIRTs, affected users), * to contact entities concerned either with the reporter identity or with the reporter anonymity. # The reporter may specify a vulnerability removal period for the affected entity during which the vulnerability is not disclosed publicly. If the entity does not respond to the report and the deadline expires, the reporter may disclose the vulnerability publicly. It is a good practice to add vulnerability solution methods or mitigation to the vulnerability report. The default period is 30 to 90 days, depending on the nature of the vulnerability  Provides recommended procedures for the affected entities of a vulnerability: * a process of vulnerability reporting (within the process each reported issue should be assessed and not just limited to the vulnerabilities with higher severity), * a process of vulnerability prioritisation and management, * a process of vulnerability disclosure to the public. # The response to each report should be prompt and adequate to the reported vulnerability. # The vulnerability management process should be given a high priority and vulnerabilities should be fixed in the next update. # The vulnerability management process should also include identifying potential victims and the method of their notification. # If the vulnerability is to be disclosed to the public, the company will determine the date of disclosure and notify the reporter if the vulnerability was not detected by the company. After consulting the reporter, it will also choose an appropriate channel for vulnerability disclosure to the community and the public. # The company may reward the reporter for reporting the vulnerability. It may also "offer a reward" for finding vulnerabilities in its products. This procedure is recommended to increase the security of the company's products and services. # Vulnerability reporting should be seen as an opportunity to improve products and a chance to learn about the vulnerability earlier than its abuse causes damage to the user, operator or manufacturer of the product or service. Therefore, it is recommended to treat the reporter gratefully as a person who wants to help as a friendly co-worker. This, of course, does not preclude legal action if the reporter's actions are manifestly unethical or illegal.

Processes are established to receive, analyze and respond to vulnerabilities disclosed to the organization from internal and external sources - The organization should have a formal process to receive the submission of vulnerabilities from internal or external sources (e.g.: internal tests, vulnerability reports, security researchers). Each submission should be analyzed, verified and follow the process for security incident handling, unless it is a false positive.