Linux Foundation Logo
Zowe Logo

Zowe Security Policy

This Security Policy governs how Zowe handles vulnerabilities identification, mitigation and disclosure.

Our policy is based on the Coordinated Vulnerability Disclosure (CVD) Policy which is also adopted by many other organizations, CISA and ETSI among them. Zowe adapts the following CVD topics to declare complete set of policy requirements for Respond to Vulnerabilities:

The topics listed above contain sets of applicable requirements. Where appropriate the fulfilment of these requirements may be governed by internal processes and guidance. In such cases, a detailed description of the corresponding processes and guidance is provided in separate documents.

NOTE: Wherever appropriate, the policy requirements are mapped to the NIST SSDF Respond to Vulnerabilities (RV) Best practices - see and/or to the Open Source Security Foundation (OpenSSF) Best Practices - see (former Core Infrastructure Initative) - see The mappings are part of this document but are provided as comments and those are not rendered in the markdown viewer.

The individual requirements may be a responsibility of a single participant or the responsibilities could be shared between multiple cooperating participants.

The main participants in the CVD related processes are:

Zowe Response to Vulnerability Policy

Security issues identification

Code review and tests

Vulnerability monitoring

The Security Workgroup continuously monitors well-known sources of information about discovered or otherwise severe security issues. Some sources a listed below:

Any issues found to have impact on Zowe projects, are further analyzed without unnecessary delay.

Information about any identified issues is propagated by the Security Workgroup to the squads for mitigation.

Security issues reporting

Zowe encourages the community, users and security researchers to perform testing and report vulnerabilities.

Please direct all security issues to

To help Zowe developers understand and resolve the issues, please provide accurate details.

Security report template

Please fill in as much as you can of the following template fields:

  - General
    - Date discovered
    - Severity
    - Impact
  - Reporter information  
    - Full name 
    - Contact - preferably e-mail
    - Organization (optional)
  - Environment
    - Operating platform: Win (32/64), Linux (flavor), MacOS (pre-M1 / M1)
    - Hosted (optional):  (y,n,N/A) - (Eclipse Che, Theia, CRW, ...)
    - z/OS (optional) 
      - Version
      - Security manager 
      - Related products names and versions
    - Zowe
      - Version
      - Sub-component/s name and version
  - Issue description   
    - Short (one liner) summary
    - Detailed information - pre-conditions, access rights,   
    - Steps to reproduce

Additional hints and recommendations:

    - While testing or replicating the vulnerability take notes, snapshots, collect log files.
    - Start with a summary.
    - Detail the narrative.
    - Follow the form.
    - Proofread.
    - Avoid emotional language.
    - Avoid abbreviations and conjunctions.
    - Be prompt.

What happens after security report is received by the Security Workgroup

Note 1: We encourage the reporters to work with the Security Workgroup team to resolve the issue before going publicly with it.

Note 2: Security vulnerabilities identified through own testing or reported by community members, and which don't yet have assigned a CVE, are reported by the Zowe Security Workgroup to a CVE Numbering Authority (CNA).

Analysis and assessment

The severity can be one of the:

Security issues mitigation

After the issue is sufficiently documented, the Security Workgroup coordinates the issue mitigation.

The Zowe squads strive to fix the relevant security issues according to their assessed priority within a predefined timeframe.

Security issues disclosure

Solution publishing

Security advisory

Note: GitHub Security Advisories allow the squad to privately discuss and fix a security vulnerability in their project.
Note: Projects hosted in GitHub take advantage of the GH features providing special security advisory dedicated pages.   

Security updates

Security notifications are distributed by the following methods.

For example you can find the API Mediation Layer related security advisories here:

What does the Zowe Disclosure process look like

There are two main processes to obtain information about security vulnerabilities. One process is used by external stakeholders, and the other process is used by internal stakeholders.

Step 1: New issue reported

An external stakeholder reports issues via the mailing list. This issue is then discussed by the Security Workgroup latest at the weekly Security Workgroup call. At this time, issues within the security-reports (private) Repository are created to track related information.

Alternatively, external stakeholders can report their findings through a CVE Numbering Authorities (CNA). In this case, the Zowe organization will be notified, as members of the Federated CVE program, and subsequently can discuss and agree on what to do with the vulnerability. If needed, the Zowe organization will engage the author in discussions around coordinated vulnerability disclosure.

The internal stakeholders report the issue to the security workgroup through a security workgroup member. The issue in the security-reports (private) repository is created to track related information.

Step 2: Impact assessment

The first step after the security workgroup is informed about the vulnerability is to verify the assessment already done by the party bringing the vulnerability forward. A Security workgroup member will be assigned to the issue for further investigation and will track the issue until closure. During the closure, the disclosure process will be initiated.

The closure means that the fix is available and published.

Step 3: Limited Public Disclosure

This step is proposed to coordinate with the vendors using and supporting Zowe. At this stage we will notify all Vendors participating in the Zowe conformance program as either (a) a Zowe Conformant Support Provider or (b) a Zowe Conformant extension.

Step 4: Full public disclosure

This is the final stage during which the CVE is published and information about the vulnerability is shared across other relevant channels along with the fix and recommendation of what to do if someone is impacted.

When can vendors get the notification?

Vendors participating in the Zowe conformance program as either (a) a Zowe Conformant Support Provider or (b) a Zowe Conformant extension will receive notification as part of the limited public disclosure.

The other vendors will be notified during the full vulnerability disclosure. The full vulnerability disclosure will be shared across other relevant channels such as #zowe-user channel in the OMP slack or mailing list.

Additional sources: