The Linux Foundation Projects
Skip to main content
Blog | Mentorship | Zowe

Mentorship: Zowe Security Workgroup CVE Publication Automation

By | November 14, 2023

Written by Sidharth Bhardwaj, Maharaja Surajmal Institute of Technology, New Delhi

Introduction
Hi, I’m Sidharth Bhardwaj a sophomore at Maharaja Surajmal Institute of Technology, pursuing
Electronics and Communication Engineering. My journey into the world of open source was ignited
during Hacktoberfest. This event wasn’t just about improving code or making valid pull requests, it was a gateway that introduced me to the collaborative world of Git, GitHub, and the power of open-
source communities.

This led me to explore alternative paths within the open-source landscape, ultimately guiding me to
the LFX mentorship program.

What’s the LFX Mentorship?

LFX Mentorship is a open source program happens 3 times in a year with motive to new developers
exposure to and experience of working in an open source community while working on a real project.
For more details highly recommend to go through Linux Foundation Mentorship docs. So, I started exploring different projects by various organizations with many different skills and
technologies some of it I haven’t even heard of in my life. While exploring organizations Open
Mainframe Project caught my attention, and within it, the project Zowe Security Workgroup CVE Publication Automation. This aligned perfectly with my skillset which is Node.js, REST API. The projects top view was to streamline complex processes through automation.

How did I get accepted?
Once the application process started, I submitted my resume and cover letter, which covered questions like “How did you find out about our mentorship program? Why are you interested in
this program? What experience and knowledge/skills do you have that are applicable to this
program? What do you hope to get out of this mentorship experience?” I also submitted a technical document that contains my approach for how I’m going to achieve the final goal and an outline to the implementation plan for automating the publication of CVEs.  I also contribute some “good first issues” to get familiar with the Open Mainframe Project and Zowe.

What I did during my mentorship? 

Watch the video below or keep reading!


During initial 2 weeks I learned GitHub Actions – an automation tool that integrates seamlessly with our workflow hosted on GitHub. Which also introduced me to YAML scripts, a cornerstone for automation pipeline. We also created a active technical document outlining the implementation plan and details of the automation and validation of the CVEs. And choose slack as the communication channel between me and my mentor Jakub Balhar, Principal Product Owner at Broadcom and Zowe TSC Chair.

The project’s focus on Common Vulnerabilities and Exposures (CVE) exposed me to an domain of CVE databases, each housing crucial information about vulnerabilities within organizations and products. The absence of an automated process for uploading discovered CVEs to MITRE’s database was a huge inefficiency. We aimed to address this through a streamlined pipeline, automating the publication process. The core structure of the project revolved around a Node.js architecture, through a series of essential scripts. Our main script, index.js , extracted data from cve.json pass it through the validator function made in compliance with MITRE’s cve-schema json 5.0 that validates the json if its in correct format and leveraging the securityUtils functions, setting the stage for CVE uploads.

For updating found CVEs we decide to upload them to MITREs CVE test instance, explored cve services repository how we can integrate there service in our project. Got my credentials to access the test services offered as set of RESTful API’s, got my hands dirty exploring there Swagger API documentation and testing them via client like Postman. Implemented an IDR service to reserve the required number of CVE IDs extracted from pull request, vulnerabilities to report takes that as an input from the PULL_REQUEST_TEMPLATE we made for this specific purpose. Then creates a new CVE with CVE ID to upload it to test services, we moved this step to our workflow. The initial workflow was just greetings message to someone who makes a PR, to get familiar with GitHub Actions, Octokit API and Core modules.

For the main workflow we created a custom GitHub action that runs both manually and through a opening or reopening a PR that extracts the details of the cve.json file and assume it to be correct next step was to reserves an ID and then directly publish it to MITREs test instance and provides the CVE ID and the link of the site to see result of published CVE through octokit API as a comment to the PR.

Here are the sample usage of the project:

We than added a functionality to verify and validate the JSON file later gets uploaded to test instance, so we need to make sure it was correct and shouldn’t get upload if it’s not. The validator need to check the required keys for basic upload then check optional keys and they are in correct format and finally verify no keys other than required or optional are present. We for the basic schema and covering all optional keys we referred cve-schema repository and made schema from there cnaContainer format of JSON 5.0 minimal sample and advance sample record. To validate this schema initial approach is to pass it in a recursive function which accepts CVE from JSON file via Node.js core modules and compare the properties and than it’s data type specified in the schema and even handles the nested object within data but was replaced by popular library ajv which significantly reduced the complexity. After this the development of the pipeline was pretty much ready and functional.

Validator sample:

Here’s the Workflow Architecture

We then moved to unit testing of all the functions and there coverage for the different components of whole workflow. We made sure the code has test coverage more than 80% but due to time constraints we couldn’t do integration testing. These tests would involve actions like creating PRs, verifying comments, and reserving IDs on Mitre’s test instance. For writing unit test we used Jest. We then made a separate workflow to make sure test runs as a part of every PR. And improved readme as we progress in project.

Concluding it all

Time flies!! These 12 weeks were like a snap for me the learnings I got and the challenges having the best time with privilege to work on a project that aligned perfectly with my skills.

I would like to express my gratitude to my mentor Jakub Balhar who helped me understand the project and clearing stupid doubts. I would also like to thank LFX and Open Mainframe community for this opportunity to work with them.

You can find the complete project here. Feel free to contribute. You can connect and reach out to me on LinkedIn.