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 5 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 https://csrc.nist.gov/publications/detail/sp/800-218/final and/or to the Open Source Security Foundation (OpenSSF) Best Practices - see https://openssf.org/ (former Core Infrastructure Initative) - see https://www.coreinfrastructure.org/. 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:
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.
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.
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.
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).
The severity can be one of the:
Critical (C) - An event that, if it occurred, would cause program failure (inability to achieve minimum acceptable requirements).
Critical issues are fixed as early as possible and not later than 30 days after the issue acknowledgment
High (H) - An event that, if it occurred, would cause major cost and schedule increases. Secondary requirements may not be achieved.
High issues are fixed within next minor/patch release within 30 days of the issue acknowledgment.
Medium (M) - An event that, if it occurred, would cause moderate cost and schedule increases, but important requirements would still be met.
Medium issues are fixed within 90 days, basically with the next regular release of the project.
Low (L) - An event that, if it occurred, would cause only a small cost and schedule increase. Requirements would still be achieved.
Low issues are fixed when the squad decides to fix but not later than 180 days from issue acknowledgment.
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.
Zowe discloses fixed vulnerabilities in a timely manner giving the users sufficient time to plan their upgrades.
We however don't disclose the vulnerabilities fixed in the latest release as we respect the need for at least 45 days to decide when and how will the users upgrade.
When a new release is published, the project list the vulnerabilities fixed in the previous release.
For example when we'd release Zowe v2.3 we'd publish the list of vulnerabilities that were fixed in the version 2.2. The issues that were fixed would be published in the Zowe Docs in the Release Note section.
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. See: https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory
Security notifications are distributed by the following methods.
For example you can find the API Mediation Layer related security advisories here: https://github.com/zowe/api-layer/security/advisories