As the current security landscape becomes increasingly competitive, the tactics of those who seek to compromise security systems for their financial or political gain also become increasingly advanced. The response, naturally, is for companies to perpetually adapt their strategies to respond to the current threats. The z/OS platform, which manages a wide range of resources, such as financial transaction data, user accounts, and other internal business information, is a prime target for hackers to seek out weak points in security systems through which these types of sensitive information could be leaked.

Zowe, a flagship project of the Open Mainframe Project, is the gateway to z/OS from the distributed computing world. As such, the design of Zowe is built on the paramount principle of ensuring that the inherited security of z/OS and the mainframe platform will not be compromised by its usage at any point, including its usage across distributed networks. To reflect this guiding principle Zowe adheres to regulations, follows the best cybersecurity practices, and intends to track and adopt any new and relevant developments.

One such measure of adhering to this principle is the role of the Zowe Technical Steering Committee, the governing body for the Zowe project, which conducts weekly Security Working Group meetings of security champions from each squad. The main goal of these meetings is to understand the project’s current security posture, and look for ways to improve it in the future. The working group also oversees the preparation of policies related to security, and owns all processes relevant to system vulnerabilities.

One of the overarching principles in ensuring the highest standard of security is fostering the “shift-left” strategy, whereby security considerations are central to the entire development approach. The integration of Security across DevOps is known as DevSecOps. If we can not prove that our process is good, then why should anyone believe in the results we produce?

Secure requirements

Zowe’s policies lay the foundation upon which everyone involved in the project works. Well established policies underscore the importance of security, and define the expectations placed on all contributors to the project. The key requirements of policies followed by Zowe come from the Linux Foundation and the Open Mainframe Project. Additionally, the Technical Steering Committee closely follows policy developments such as U.S. President Joe Biden’s Executive Order on Cybersecurity, and takes measures to ensure that the Zowe project conforms to these requirements.

The Linux Foundation requires Zowe project to:

• Publish Software Bill of Materials (SBOM)
• Publish Third-party Statement (TPSR) — Statement about all the products and packages that are used within the project.
• Regularly analyze code with tools for static analysis
• Regularly verify running applications with tools for dynamic analysis
• Regularly conduct external security audits

Additionally, the Open Mainframe Project requires Zowe project to:

• Fulfil the criteria for Core Infrastructure Initiative (CII) badge

The Zowe project follows developments in the security of Open Source Software by closely observing and interacting with the Open Source Security Foundation (Open SSF). The Open SSF working groups prepare guidelines on the best ways of securing Open Source Software, investigating what tooling is available, addressing how to responsibly perform full disclosure, as well as looking into other vital topics.

Secure development

When exploring the issue of what constitutes secure development in the Zowe project, it helps to consider some fundamental questions: How can one trust a product/solution like Zowe if the process that is used to deliver the code itself cannot be trusted? How does Zowe ensure that the contributions are safe and conform to the quality requirements established by the Zowe project? Considering that supply chain vulnerabilities introduce problems outside of a contributor’s direct control, what can the Zowe project do to mitigate security vulnerabilities within its dependencies?

Let’s take a closer look at what is behind these questions to bring us closer to some answers.

Contributions to Zowe

To store all the code and keep track of all the issues and future work associated with it, Zowe uses GitHub. Using GitHub with Git as a backing tool provides a reasonably solid guarantee that the Zowe project will not lose any code, and will always be able to determine the source of any and all contributions.

The developers responsible for specific projects within Zowe are organized into squads. Every squad has regular meetings and consists of multiple members, which are either independent, or coming from different organizations. Each squad is responsible for the projects it owns.

All code contributions are reviewed. If the contribution brings significant new functionalities, it must be presented to the software architecture workgroup before the actual code is contributed. If the contribution does not constitute a significant new functionality, the contributing squad is still required to follow the rest of the procedure for code contributions, but is not required to make an architectural presentation. A good example of a topic for discussion in the architecture workgroup is the introduction of a new, significant dependency to the project.

The follow-up step is for contributions to be reviewed by a committer to the squad that is responsible for the specific project in question. The review of the contribution is carried out by means of a pull request. The reviewer verifies that the code does what it should, meets the established quality requirements, and conforms to the contribution guidelines specific to the squad. The guidelines contain instructions on the types of automated tests that need to be provided.

As part of the pull request process, a few automated tools are involved. A complete set of unit and integration tests are run to verify that a regression is not being proposed. The results are integrated into SonarCloud to demonstrate the overall code coverage. SonarCloud also analyzes the code for quality and known security risks.

To further improve the code’s quality and security, at least one tool for dynamic analysis of the code is run for every release. Issues found by the tool within the code are fixed as part of the release process.

Dependencies within Zowe

As we all know, one of the primary sources of vulnerabilities found in software development are those originating within 3rd party libraries used as dependencies. The Zowe project is in no way different. This being the case, the following steps are necessary to limit potential risks resulting from dependencies:

1. The addition of new dependencies is discussed during the relevant squad call to limit the risks of introducing such dependencies. Introduction of such dependencies should also be addressed within the architecture working group if deemed significant.
2. The codebase for any new dependencies is scanned and vulnerabilities in the current dependencies are determined weekly. Any discovered vulnerabilities are discussed within the security working group, and based on their severity, these vulnerabilities are planned for resolution. Medium and high-severity issues are usually fixed with the next minor release. Critical issues can result in a security patch version of Zowe.
3. There is a process in place whereby third-parties reach out to zowe-security@lists.openmainframeproject.org to inform the TSC about security vulnerabilities within Zowe’s code. If the TSC finds any security risk introduced in the code, the committee publishes information via the standard process and lets all users know about the need to update.
4. All vulnerabilities are published in Zowe Docs, specifying which vulnerabilities were fixed in the previous version. For example, when Zowe 1.28 was released, the vulnerabilities fixed in Zowe 1.27 were also published with this new release.

Conclusion

Zowe, as the most popular Open Source software for the mainframe platform based on LFX Insights, is committed to adhering to the core principle of security-designed development. Controls to prevent malicious actors from contributing harmful code are built into the project, both in terms of the project architecture as well as the review process. Based on this inherent design, there is nothing preventing a developer from depending on Zowe in production environments.

If you enjoyed this blog checkout more Zowe blogs here. Also, feel free to ask a question and join the conversation on the Open Mainframe Project Slack Channel #Zowe-dev, #Zowe-user or #Zowe-onboarding. If this is your first time using the slack channel register here.