As time flies quicker than the DeLorean from Back to the Future, it’s time to reflect on what has been accomplished for the OpenSSF’s Alpha-Omega Project and the Summer 2023 Mentorship Program.
Alpha-Omega is an associated project of the OpenSSF, established in February 2022, with a mission to protect society by improving the security of open source software through direct maintainer engagement and expert analysis, trying to build a world where critical open source projects are secure and that security vulnerabilities are found and fixed quickly.
Jonathan Leitschuh and I were hired in the latter part of 2022 to tackle the objective of rapid implementation and deployment to the Omega side of the project. This piece of work is targeted to scale vulnerability identification, triage, and remediation at scale, leveraging Jonathan’s background and expertise in security vulnerability hunting and disclosure, as well as my technical and leadership expertise in Security Operations, Development Security and Operations, Software Supply Chain Security, and Open Source Software.
The Idea
Jonathan and I have a cadence of conversation where we discuss critical items and how to tackle the upcoming challenges for the project. In one conversation, the idea of hiring “interns” was brought up by Jonathan. As an advocate for Diversity, Equity, and Inclusion (DEI) and helping guide those passionate about entering the cybersecurity field, the idea of the Omega toolchain being built by the next generation of technologists sparked the fire that ignited this idea.
After careful consideration and budget calculation, we presented a proposal to the Alpha-Omega community: we wanted to hire four summer interns to help cover community events, including DEFCON, BSides, and a week-long hacker camp. Being fairly compensated, we also wanted to ensure they were provided with career development and learning opportunities within the Alpha-Omega community. We wanted to hire two engineers to help work on the Omega toolchain and two researchers to help enhance our vulnerability process and usage of Open Rewrite and CodeQL.
The Ask
From the get-go, we knew there would be compromise and negotiation with the community, so we presented our proposal to the Alpha-Omega leadership, ready to come to an open and agreeable plan of action.
There were several back-and-forth conversations between the leaders, ourselves and the Linux Foundation Legal department to ensure the integrity and confidentiality of the sensitive information behind the Alpha-Omega project. Teamwork and communication between the parties was the biggest takeaway from this phase of the program creation. Multiple members were assisting us in the creation of the program and brought up any concerns or issues that they were made aware of.
After several discussions, we realized the best path forward was to carry this out through the well-established Linux Foundation Mentorship Program. By launching an Alpha-Omega specific mentorship program, we would allow four people to get first-hand experience in our open source community, further providing them access to experts within the Alpha-Omega project. This path aligns with the Linux Foundation’s goal of training and empowering the next generation of developers by experts in the community.
Thus, the Alpha-Omega Summer Mentorship program was born with Jonathan and myself taking on the role of Mentors.
The Review
Within a week of announcing the program and circulating on social media,, the Alpha-Omega mentorship program had reached approximately 110 applicants. We extended the deadline for another week and then closed the application, leaving us with a pool of approximately 180 applicants to choose from.
There were five key takeaways from the review and interview process that made a difference in our selection. They are:
- Follow the instructions
- Authenticity & Uniqueness
- Digital Portfolio
- Technical representation
- Strategize your approach
The first wave of denials came from lack of following instructions. The applicants were required to submit a resume, cover letter, links to their social and related media, such as Github and Linkedin, and answer four questions. Any applicant that did not submit the required documentation became automatically disqualified.
There was also the case that several applicants were outside of the US, and unfortunately, during the initial start, we did not have the opportunity to support their regulator requirements. These applicants were also denied. This process can be painstaking for applicants and reviewers who are making unbiased decisions on who feels best for their team’s gaps and upcoming projects.
Next round came the reviews. We had approximately 84 applicants after the initial denial to review. This is where takeaways #2-5 came into play.
We had applicants show up to our public calls and ask questions. Others reached out via social or Slack to ask questions or set up 15-minute chats. Other applicants took the initiative to provide commits and improvements to the open source repositories. When it came time to review the potential applicants, these names shined out bright.
However, due to the constraints of our mentorship program, we could recruit only eight applicants who would move forward through the interview process.
As a reviewer, it’s difficult to provide feedback to all applicants when the applicant provides limited information. We have to ask ourselves, are they not qualified, or has the education system failed to prepare them for how to represent themself and their accomplishments?
And as an applicant, one must wonder, how much information is relevant? Do I need to upload all these documents? The answer is the more detail, the better.
We were looking for applicants with merit, passion, and a desire to overcome their next challenge—individuals making an impact in their field and helping others achieve the same. We skimmed through the details and links the applicants provided to see if their digital footprint clearly demonstrated that they were passionate about open source security and had something to bring to the table.
The Interview
The interview was split into two steps. First was a panel interview with Jonathan and I based around behavior, personality, and teamwork. We asked questions on their experience in software development, testing, and cyber security to understand their background. During this piece of the interview, we also determined whether they would fall under the engineering or research track for the mentorship program.
Once completed, we selected six candidates to move forward with technical interviews. On the security researcher side, the technical interview consisted of a peer programming exercise on how to write a recipe in Java with two challenges they had to tackle. On the engineering side, the participants were asked to present methods to attack a system– a conversational threat model – and how they would implement test cases for their particular use case. The second piece of the engineering technical interview was to understand how they envisioned processes and designed a flow, using LucidChart for visual representation.
At the end of this, we selected our four mentees to participate in our Summer 2023 mentorship program. Notifications were sent out a few weeks prior to the start date. Our team had less than two weeks to prepare and understand what they would be working on.
Setting up for success
After reading Behind the scenes of running Linux kernel Mentorship Programs, my next step was to create a project plan. The creation of the phased out task list is now a template for our future mentorship programs, as well as any of the universities that choose to have a more structured project from the Alpha-Omega team.
With a software lifecycle in mind, the 12 weeks were split into Onboarding and Research, Design, Presentation and Alignment, Implementation, Testing, and Offboarding. See the template link below.
TEMPLATE Omega ToolChain <DATE> – Phased Task list
The tasks in the template are defined generically to support different activities, including meetings, OpenSSF calls, documentation and content creation, and engineering that is needed. These give the individual a full view of the expectation of their involvement within the project and the various tasks they’d be performing.
Besides this spreadsheet, a draft of a software requirement documentation (SRD) was created. Using Lucidchart, I crafted an architecture of the full project between the two individuals and split it for the individual SRD each mentee is responsible for. Under requirements, pieces of the puzzle were written out with several sections incomplete, such as security and testing requirements, use cases, and acceptance criteria.
This gave us a baseline to discuss during the first 3-4 weeks of the mentorship program.
12-week program
Below is a high-level overview of the various activities that were performed. The engineering program was structured to ensure the mentee flows through a software development lifecycle with a test-driven approach to the design. Each 6-week phase ended with a demo presentation to the Alpha-Omega stakeholders.
First 6 Weeks
The first six weeks encompassed a mentee getting comfortable and onboarded to the project and technical solution, finalizing the software requirements document to include requirements, acceptance criteria, future improvements, a documented list of bug patches, test cases, and architectural diagrams.
Onboarding and Research
- Familiarized with their tech stack
- Set up their development environment
- Reviewed and asked questions about the software requirements document
- Scheduled time to review each piece
- Wrote out acceptance criteria and use cases
Design
- Engaged in the technical aspect of their projects
- Worked on the security requirements and test cases
- Uploaded documentation to the alpha-omega mentorship repo
- Created demos of current functionality
- Patched bugs to get expected behaviors for the project
Presentation and Alignment
- Demo prep
- Demo
- Documentation
Last 6 Weeks
For the second half of the Mentorship, they implemented the SRD requirements, explored additional scope changes, and participated in Hacker Summer Camp. See below for further details on the specific technical solution goals.
Implementation
- Omega Analyzer
- Execute 10 pypi scans a week to collect SARIF reports
- Expand language support to Go (also supports pypi and npm)
- Added functionality to
- Upload SARIF report to the Triage Portal
- Pull an assertion report to the output SARIF file
- Begin design discussion on cadence scanning of open source software and how to incorporate it into a cloud architecture.
- Baseline metrics on bulk scan pypi packages on at a time
- Perform pentest for MD5 collision
- Data analytics on tools and telemetry with revamping
- automatic version resolution
- instrumental in being able to do metrics, as well as bulk / cadence scans
- POC of a bulk scan script
- Improvements on performance, error handling, and scanning
- Triage Portal
- Security hardening and enhancement of the API
- Implementation of JWT token for authentication
- Checksum to validate integrity of SARIF file being uploaded
- Validation of file type and size
- Added GraphQL with Graphene to
- handle API requests and database structure
- Structure database
- API documentation
- Additional database table and structure to support assertion details
- Results will store an aggregate count of each assertion
- Improvements on performance, UI/UX
- Security hardening and enhancement of the API
- Assertion Framework
- Initial design discussion of re-architecturing the docker within docker issue
- Improvements on performance
Presentation and Testing
- Demo prep
- Demo
- Documentation
- Run and report on test uses
Offboarding
- Documentation, including future improvements, usage documentation, and the SRF
- Video recording demo of all functionality
- Handoff
Career Development
During the 12-week program, the mentees had multiple opportunities to improve on their career and personal development. The mentees were offered 30 minutes a week primarily focused on their careers. During this time, discussions were had on career development, tips and tricks for their resume, LinkedIn and Github pages, and how to approach job hunting.
The mentees also had access to OpenSSF calendar, Slack, and expertise. This access is available to anyone. The participants took advantage of this networking opportunity and connected with various folks to learn more about open source software, cybersecurity, and career growth.
EDU.DEI Community Office Hours
Once a month, the Education DEI Security Initiative Group (SIG) will provide a community office hour to answer questions related to cybersecurity, open source software, and career development. The mentees were given time to attend the sessions. Standups were by Slack and any blockers communicated directly to the lead. During these calls, they were free to ask any questions pertaining to their situations.
Participants on the call can ask questions and get responses from multiple individuals from the SIG group. Participants are given different strategies and perspectives on how to approach the task. All community office hours have been recorded. Check out the most recent office hours and all the other topics on YouTube via OpenSSF Channel.
After each session, it could be noted that there was growth in the individual’s confidence and ways to tackle problems. From later conversations, they would execute the lessons learned into their own lives, resumes, or digital portfolios—a few noted momentum within their job hunting.
The Retrospective
For each mentee, the prospects of what is impacted after this mentorship are beyond anyone’s expectations, and career paths can take any variation of unlimited possibilities. I can see open source security research taking quantum leaps within the vulnerability identification and scaling architecture, expanding on security research and disclosure analysis in our libraries, becoming new contributors and leaders in the open source world, ready for their voice to be heard.
My objective for this mentorship was to provide the resources and guidance for each to learn and grow into their next level self so they can create a quantum leap for their career.
When we connected during Hacker Summer Camp, a team camaraderie among the mentees was already built between the two “sub-teams.” It was a shining example of the beautiful open source software community, with people coming together to solve a security problem and exploring the curiosity of what-if.
Are you interested in being a mentee for an Open Source project? Check out the The Linux Foundation Mentorship Program for open and upcoming applications for open source mentorships!
