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:
- Security issues identification
- Security issues analysis and assessment
- Security issues mitigation
- Security issues disclosure
- Solution publishing
- Disclosure process
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 Zowe Security Workgroup
- The Zowe squads
- External researchers and reporters
- The security architecture of all Zowe projects is reviewed by the Security Workgroup.
- The squads perform internal security code review of newly implemented features and other security related code changes.
- The code reviews are performed by squad members other than the individuals who created the code.
- The squads continuously perform security testing for security issues in their projects' code and configuration.
- Before each major release, the Security Workgroup conducts full penetration testing.
The Security Workgroup continuously monitors well-known sources of information about discovered or otherwise severe security issues. Some sources a listed below:
- NIST National Vulnerability Database
- MITRE CVE List
- Snyk Vulnerability DB
- CISA Exploited Vulnerabilities Catalog
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 zowe-security@lists.openmainframeproject.org.
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.
- After your report is received, a member of the Security Workgroup replies to acknowledge receipt of the report.
- The reporter may be contacted for clarification.
- Without unnecessary delay the report is analyzed.
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).
- Reported issues are analyzed within the security workgroup.
- The issues' analyzes outcome is determined by the risk severity measured by the combination of vulnerability exploitability and its impact.
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 acknowledgmentHigh (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.
- The project's squad discloses a vulnerability by first creating a draft security advisory in the project repository in GitHub.
- For critical priority vulnerability, security patches are created as soon as the issue is fixed in code and configuration.
- The security fixes become an integral part of the latest Zowe distribution.
Note: GitHub Security Advisories allow the squad to privately discuss and fix a security vulnerability in their project.
- After collaborating on a fix, the project maintainers publish the security advisory to a project specific place.
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.
- Publishing project specific advisories in the corresponding project GitHub repository Security page.
For example you can find the API Mediation Layer related security advisories here: https://github.com/zowe/api-layer/security/advisories
- Notification to Zowe users who explicitly requested receiving security alerts and advisories by subscribing to:
zowe-user@lists.openmainframeproject.orgzowe-dev@lists.openmainframeproject.org
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.
An external stakeholder reports issues via the zowe-security@openmainframeproject.org 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.
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.
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.
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.
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 zowe-user@openmainframeproject.org mailing list.