OASIS Vulnerability Handling & Disclosure Policy

This version of the OASIS Vulnerability Handling & Disclosure Policy was approved by the OASIS Board of Directors on 14 June 2023 and became effective immediately.

For details on how the policy is implemented, see the Vulnerability Handling & Disclosure Process.

Table of Contents

1. Purpose
2. Definitions
3. Procedures
3.1 Receiving a report of a possible vulnerability
3.2 Notifying OASIS staff and responsible parties
3.3 Notifying affected stakeholders
3.4 Notifying reporting organizations
3.5 Forming a vulnerability response team
3.6 Setting up a secure workspace
3.7 Addressing the vulnerability
3.8 Approving the remediation
3.9 Disclosure
3.10 Addressing vulnerability reports when there is no Responsible Party
3.11 Security Researcher Hall of Fame
3.12 Legal Obligation

1. Purpose

The OASIS Vulnerability Handling and Disclosure Policy governs how OASIS committees and staff receive and address reports of potential vulnerabilities. Vulnerability disclosure helps implementers and users of technical work assess their risk, protect their systems and data, and prioritize defensive actions. It also helps establish OASIS work product as trustworthy and legitimate in the user and developer community.

This document ensures that OASIS members understand their role in responding to reports of potential vulnerabilities or flaws and have a clear set of directions for addressing such reports. It also addresses OASIS’s role in providing neutral oversight and ensuring that records of the actions taken are maintained comparable to that done for a committee’s routine work. The policy also addresses when and how such a record should be made public.

The procedures outlined in this document may temporarily suspend other requirements of OASIS policies, most notably those for transparency and public records of proceedings.

This policy provides:

  • guidelines on receiving and responding to reports of potential vulnerabilities;
  • guidelines and procedures for assessing and addressing reported vulnerabilities.

2. Definitions

Most defined terms in this document have the meaning provided in OASIS Defined Terms. Additional definitions specific to the OASIS Intellectual Property Rights (IPR) Policy can be found in that document.

  • Embargo period – a period of time during which a reported vulnerability is kept confidential by OASIS and the responsible party to allow a solution to be determined and disseminated to affected stakeholders.
  • Executive Session – closed meetings of members of the responsible party for purposes of addressing a report of a vulnerability without making its details public.
  • Flaw – synonym for “vulnerability.”
  • Remediation – the steps taken by a responsible party to assess, address, and propagate a fix to a reported vulnerability or the steps to be taken by stakeholders to implement the fix.
  • Responsible Party – An individual or set of individuals who ensure that the report is investigated and addressed. The Responsible Party is the person(s) in a position to make sure a response team is formed and gets the resources it needs. Generally, in the case of an OASIS Technical Committee, the Responsible Party consists of the TC Administrator, as well as the full TC led by the chair(s) of that Technical Committee. In the case of an OASIS Open Project, the Responsible Party consists of the Project Governing Board
  • Stakeholders – parties whose work product may be adversely affected by the vulnerability but who are not directly responsible for fixing it (for example, a vendor whose product implements an OASIS Standard), other members of a Technical Committee beyond the Responsible Party and the response team or the public in general.
  • Vulnerability – any element in a specification or technical implementation that could allow an implementation to be exploited in ways that violate its proper intended use.
  • Vulnerability response team or response team – people appointed by the full membership of the responsible party to remediate the flaw. May include non-OASIS members under conditions described in the following sections.

3. Procedures

3.1 Receiving a report of a possible vulnerability

OASIS members and staff have an obligation to receive, record, and act on any report or claim of a vulnerability in any OASIS work product or deliverable that is brought to their attention, whether the flaw seems feasible or not.

OASIS will provide the OASIS Vulnerability Disclosure Process and make it accessible from the OASIS home page, and provide SEO terms to make it easily discoverable via internet search.

An OASIS member or staff may receive a report of a vulnerability in a variety of ways: through the OASIS Vulnerability Disclosure Process, through communications to or within the TC, or through personal, private communications (i.e. by email or phone). Regardless of how a report is received, the recipient must act on it.

If it is not provided in the initial disclosure, the recipient of the report should attempt to collect:

  • The name, version, and a link to the standard, specification, site, package, or code module;
  • If possible, the recipient’s assessment of the vulnerability severity (low/medium/high);
  • Description of the vulnerability, including how it was found and if it can be exploited;
  • In the case of a vulnerability discovered in a standard or specification, any known implementations of the standard or specification that the vulnerability has been discovered on;
  • Steps to reproduce, if relevant and available;
  • The reporters contact information (name and email), unless the reporter requests to remain anonymous.

The recipient must acknowledge receipt of the information from the reporter within 72 hours. See the Vulnerability Disclosure Process for detailed instructions.

3.2 Notifying OASIS staff and responsible parties

The recipient of a vulnerability report must notify the responsible parties for the affected specification or technical work. In the event a report is not received via the OASIS Vulnerability Disclosure Process, the recipient must either enter the report via the Disclosure Process themselves, ask the reporting party to do so, or promptly notify a member of the OASIS staff so that they can add the report. Staff will coordinate with the recipient and responsible parties on the steps needed to respond.

If the recipient is not a member of a responsible party or does not expect to be directly engaged in remediation, OASIS staff will take over working with the responsible party. The recipient must keep the report confidential but otherwise shall have no further obligations regarding the reported vulnerability.

Details of the vulnerability must not be communicated via any means that could be publicly visible (for example, by an email to a committee mailing list).

The responsible party can be notified, in a regular or specially-called meeting, or via other secure communications channels accessible only by members of the responsible party and OASIS staff.

Disclosures of vulnerabilities are not to be made public, for example in meeting minutes. If the responsible party is notified in a meeting, the meeting may be organized and held in Executive Session so that the topic and discussion are kept confidential. OASIS staff must be invited to such a meeting, and minutes must be taken although they will not be required to be published on the committee mailing list as is normally required by section 1.7 of the OASIS Committee Operations Process. The minutes must note that work was taken in Executive Session.

OASIS staff will report regularly to the Executive Director and the OASIS Board of Directors that vulnerabilities have been reported. Details may be provided in a meeting of the Board but must not be shared via any means that could be publicly visible.

3.3 Notifying affected stakeholders

As part of its evaluation of the vulnerability report, the responsible party shall decide when and how to notify affected stakeholders. Depending on the potential severity of a flaw or the scale of implementations, the responsible party may choose to alert stakeholders immediately or may choose to wait until steps to remediate have been defined. The responsible party shall make reasonable efforts to locate and notify stakeholders, however neither OASIS nor the responsible party guarantee that all stakeholders can be located and contacted.

If notification of the vulnerability includes steps for implementing a fix, the responsible party may provide an embargo period before making the report public to enable affected stakeholders to implement the fix. Neither OASIS nor the responsible party shall have any obligation to confirm that all stakeholders have implemented the fix before making the reported vulnerability public.

The decision on when and how to notify stakeholders shall rest with the Responsible Party except for the reporting provision in section 3.9. However the OASIS Executive Director or Board of Directors may direct OASIS staff to report the vulnerability publicly if, in their opinion, continued secrecy presents an unacceptable risk of damage to affected stakeholders or to the reputation and standing of OASIS. OASIS staff may review and require changes to any written communication regarding the vulnerability and its remediation prior to its being sent.

3.4 Notifying reporting organizations

As part of its evaluation of the vulnerability report, the responsible party shall decide if, when, and how to notify vulnerability databases such as the NIST National Vulnerability Database (https://nvd.nist.gov/), MITRE’s Common Vulnerabilities and Exposures (CVE® ) (https://cve.mitre.org/), or Carnegie Mellon University Software Engineering Institute’s CERT/CC Vulnerability Notes Database (https://www.kb.cert.org/vuls/). Consideration should be given to notifying relevant industry and global reporting organizations. OASIS staff will assist in the decision on request.

3.5 Forming a vulnerability response team

The responsible party shall consult with members of the committee as a whole in order to decide who shall assess the reported vulnerability to determine whether it agrees that a flaw exists.

The responsible party may request additional information, such as proof of concept code, before reaching a conclusion. If the responsible party does not agree that the vulnerability exists or believe that it poses no clear risk to stakeholders, the party shall notify OASIS staff and prepare a response to the reporter. The response shall contain an explanation of the reasons the party disagrees with the report and include a statement of how to appeal the decision to OASIS staff following the same procedures described in section 3.2 Appeals in the OASIS TC Process. The party shall store a copy of the response in its archives but no further action will be required.

If the responsible party agrees that the flaw exists, it shall notify OASIS that remedial action is needed and form a vulnerability response team made up of members deemed to have the expertise and interest to identify, analyze, correct and document the fix to the flaw.

The responsible party may invite outside experts, including the reporter of the flaw, to assist in addressing the vulnerability if it deems such expertise necessary. The party must notify OASIS staff of their request. OASIS shall offer to such invited expert a temporary, no-cost membership in OASIS for the duration of the remedial work. The invited expert shall be required to sign the OASIS Membership Agreement and take whatever actions are necessary to become a Member of the responsible party (e.g. join an OASIS Technical Committee). If the expert declines to take these actions, they shall not be allowed to participate directly in the remedial work although they may offer input and feedback via approved OASIS feedback channels.

3.6 Setting up a secure workspace

Unless the vulnerability is determined by the responsible party to be minor and quickly resolved, OASIS shall set up a secure, private team workspace. The workspace will provide all the functions of the responsible party’s regular set of collaborative tools but it will only be visible only to the members of the team and OASIS staff supporting the work. The workspace shall be visible to members of the responsible party unless such visibility cannot be provided without exposing the contents to the public.

Team members shall follow the normally applicable OASIS processes while working in the secure workspace (e.g. meeting minutes, ballots). Team members should maintain appropriate professionalism while working in the private workspace and expect that any or all of its records could become public in the future.

3.7 Addressing the vulnerability

The vulnerability response team shall work together using the secure workspace collaboration tools to identify and document changes needed to fix the affected work product(s). One member of the team shall be assigned the duty of liaison to the full committee and the responsible party and shall provide regular, verbal updates on the work.

If the response team needs copies of documentation or code for its work, OASIS shall create private copies of the resources for the use of the team. These resources shall only be accessible and visible to the team during the remediation. Changes to these resources to be applied to the existing work of the TC shall be merged back once the report of the vulnerability has been made public.

The response team shall be responsible for communicating with other stakeholders as needed, for example to communicate how to address the flaw in their implementations. The response team shall take reasonable care to keep such communications private, however neither the response team, the responsible party, nor OASIS guarantee privacy.

3.8 Approving the remediation

When the response team deems its work to be finished, it shall prepare a final report that includes the fix(es) that address the vulnerability, and present the report to the full committee and the Responsible Party. The full committee shall determine how to incorporate the fix(es) into the committee’s work products. Approval requires the appropriate level of vote for the OASIS work product the vulnerability is being reported against. For example, a vulnerability fix for an issue discovered in a Committee Specification, requires a Special Majority Vote, while a vulnerability fix for an issue discovered in a Committee Specification Draft requires a Full Majority Vote.

Once the response team’s final report is presented to the committee, its role is ended.

Merging any proposed changes into work products developed by the committee shall proceed under the normal procedures followed by the party (e.g. working drafts of Technical Committee specifications).

3.9 Disclosure

In addition to the requirements of section 3.3 and 3.4 above, OASIS staff shall, after a maximum of 90 days, make information about the vulnerability publicly accessible, unless instructed not to do so by the Executive Director or the OASIS Board of Directors or external legal authority. If permitted, the disclosure may happen sooner on appeal from any member(s) of the responsible party, stakeholder, or in response to a legitimate legal demand.

OASIS may, at its discretion, issue a press release or provide other information on the vulnerability. However, OASIS shall not be required to make any formal public announcement or release of information regarding the vulnerability.

3.10 Addressing vulnerability reports when there is no Responsible Party

In the event that the party responsible for the work affected by the vulnerability report is closed or otherwise unavailable to respond, and no other group has taken responsibility for maintenance of the work, it shall be the responsibility of OASIS staff to determine how best to respond.

Staff shall have the responsibility to identify experts who can evaluate and address the flaw. OASIS shall make best efforts to assemble a response team and address the vulnerability however OASIS shall not guarantee that it can remediate the flaw.

3.11 Security Researcher Hall of Fame

Following the processes outlined in section 3.9, OASIS will create a Security Researcher Hall of Fame page, or optionally, attach it as an addendum on the page containing the OASIS Vulnerability Disclosure Process. Any researchers who submit first-of-a-kind vulnerabilities for which the processes outlined in sections 3.6, 3.7, 3.8, and 3.9 are executed, should be listed on this page if they desire.

OASIS reserves full and final judgment on which researchers may be listed on the Hall of Fame. Researchers may be added and removed from the Hall of Fame at any time on the sole discretion of OASIS.

OASIS commits to not pursue or support any legal action related to vulnerabilities disclosed according to the OASIS Vulnerability Disclosure Process, recognizing that OASIS can not make commitments on behalf of its membership.