The Linux Foundation Projects
Skip to main content

University Program Details

Engaging Universities in Vulnerability Discovery in Open Source

Purpose

Students participate in a vulnerability discovery class/project.

Goal

The purpose of the project will be to use their knowledge of programming and security to:

  • Discover new vulnerabilities in open source projects
  • Determine whether the vulnerabilities are exploitable
  • Write up the vulnerability details, estimate their severity, and report it responsibly to the maintainer.
  • Work with the maintainer if needed on a fix.
  • Allow students to gain experience with working in open source projects, with the OpenSSF community, and build on their resume with security experience.

Additional knowledge/concepts:

  • Using security tools
  • Security-oriented code review
  • Determining exploitability
  • Responsible disclosure, how to contact maintainers, etc.
  • CVEs

Audience

  • Target students in CS or similar fields.
    • Entry Level
      • They will require:
        • Onboarding training
        • Mentor / Lead / Coach
      • Experienced Coder / vulnerability (bug bounty)
        • Project based on student’s Identified by Programming Language or familiar with tool
      • They will require:
        • Onboarding training
        • Mentor / Lead / Coach
  • Prerequisites: At least two semesters of programming and one semester of security, plus a series of pre-reading/watching material (responsible disclosure, code review, use of various static analysis tools, etc.).
  • Suggestion: Students should work in 3-5 person teams.

Desired Outcomes

Roles and Responsibilities:

Involved parties and definitions:

  • University Champion is a professor, advisor, or university representative speaking on behalf of the student population and the university, with regards to the involvement of the assigned projects and partnership between the OpenSSF and the University.
  • Selected Student(s) are one or more students from the University’s Champion who are either partnered in teams or working on individual assigned projects.
  • Alpha-Omega are the members of the OpenSSF Alpha-Omega team.

As a University Champion

  • Liaison / Point of Contact
  • Manage the team from academic perspective

As a selected student

  • Could be teams of up to 5 students.
  • Depending on expertise, career paths, and curiosity, teams could be split into subgroups and focused on separate tasks, such as software engineering, vulnerability research, triaging.

As Alpha-Omega

  • Handling technical issues related to projects
  • Access Slack channel Omega tool and Github Repo

OpenSSF Involvement

  • OpenSSF will provide a forum (via Slack) for any participating students to ask questions, receive feedback, etc.
  • OpenSSF (A-O) creates onboarding documentation and videos for guiding students on how to get started for vulnerability research.

Reporting Expectations for Alpha Engagements

Should we just link the Reporting Expectations on GitHub? I think the examples are to indepth so maybe we modify that a bit plus we want them to provide an update bi-weekly. We can modify as you see fit.

[Reporting]

Mentorship Link

https://lfx.linuxfoundation.org/tools/mentorship/

We encourage students to write a summary of the analysis and results, describing the specific OSS projects analyzed, analysis approach(es) used, and overall results. Once any disclosed vulnerabilities are fixed (or verified as ones that will not be fixed), we encourage these reports to be shared publicly and a “security review” entry added to link to that report in the security reviews repository here: <https://github.com/ossf/security-reviews>. This will enable others to know what evaluation(s) were done on that OSS and give credit to the reviewers.