By Munawar Hafiz and Ataf Fazledin Ahamed, OpenRefactory
In February of 2023, a group of volunteers inside OpenSSF’s Identifying Security Threats working group organized a virtual mini-summit for maintainers of critical open source software projects. The maintainers discussed the challenges of doing what they are doing.
Maintainers shared that when they started a project, the goal was usually to address some important problem that the team could solve. There was no desire to produce either a popular project or a critical one. Yet, maintainers indicated when their projects became widely adopted, non-functional requirements such as security all of the sudden became a key concern. In most of the cases, the security tasks are handled by a team that was formed after the fact, and the team members are burdened with multiple responsibilities.
Most of the maintainers who work on open source projects are volunteers. They might be working full-time as a software developer at a company and have to find time in off-hours to contribute to these projects. And they are working with limited resources. Most of these projects demand cross-platform operation and run on diverse operating systems with varying physical configurations. Maintainers might not have access to all of these environments for thorough testing, leading to undiscovered bugs.
Maintainers need support from security practitioners to get to a better security posture. OpenRefactory has received a grant from Alpha-Omega to bring help to the maintainers.Â
Scope of the Project
OpenRefactory is working alongside Alpha-Omega’s principals to report security vulnerabilities at scale in open source projects. It works with the maintainers to get the vulnerabilities fixed using these steps:
- The team plans to analyze the top 10,000 open source libraries written in Java, Python and Go. For analysis, the team uses OpenRefactory’s own Intelligent Code Repair (iCR) and the Omega Analyzer.
- The team concentrates on critical security (e.g., SQL Injection, Cross-Site Scripting (XSS), Command Injection, Path Manipulation, Deserialization, XML External Entity (XXE) Injection, etc.,) and reliability issues (null pointer dereference, data race, blocking operations, etc.,). In addition, the team reports logical bugs in code.
- The team triages manually and follows the model outbound vulnerability disclosure policy to report the bugs in a responsible manner.
- The team follows the submissions and works with the maintainers to correct the issues.
Vulnerability Disclosure Policy
The OpenRefactory team is using a custom-created dashboard (the Triage Portal) to triage the bugs that have been reported by the tools. The dashboard implements a coordinated vulnerability disclosure policy that has been prescribed by the principals at the vulnerability disclosure working group. The team typically reports its security findings through GitHub’s Private Vulnerability Reporting system.
In case the mechanism isn’t enabled by the project maintainers, the team creates a GitHub issue notifying the maintainers that they have found a possible vulnerability and requests them to enable it so that the team may submit the report. Different projects may have specific mechanisms for engaging in such discussions, such as a mailing list or a forum. In those cases, the team reports the vulnerabilities in compliance with the maintainers’ guidelines.
iCR is able to synthesize fixes in many cases. In those cases, the fixes accompany the bug report. This is highly valued by the maintainers since it saves their time to take appropriate actions. In some cases, the team manually creates a proof-of-concept example to demonstrate the way the vulnerability can be exploited.
Recent Results
In a span of four months, from August to November 2023, the team has triaged 1,079 open source projects and submitted 168 bug reports (security, reliability and logical bugs). The team is maintaining a publicly available spreadsheet where the data can be found.
There are 79 security and reliability bugs that have been reported. The reported bugs include cross-site scripting, command injection, cross-site request forgery, deserialization issues, weak cryptography issues, data races, null pointer dereferences, etc.
Among the bugs submitted, about 45% of the reports have been already accepted by the maintainers. About 5% of the bug reports were challenged. The rest of the bug reports are going through the process of being accepted/merged by the maintainers.
Get Involved
- Modern day developers do not build everything from scratch. They reuse artifacts that are available as open source. But choosing the right open source solution is a hard problem. Maintainers should consult the simple publicly available listing before they choose an open source artifact.
* OpenRefactory invites the community to be involved in the endeavor. If an individual or a team wants to follow a similar approach and run a specific SAST tool on a set of projects, OpenRefactory can collaborate with them by sharing the Triage Portal with them to efficiently report the vulnerabilities and storing the results in the same place. The external effort may focus on other languages not covered by the current scope of work, e.g., JavaScript, PHP, C/C++, etc.
- OpenRefactory has kept the result reporting mechanism simple on purpose. This works for now but may be cumbersome in the future when there are more results. If front-end experts have a better idea on how to present the results, OpenRefactory would love to collaborate.
About the Authors
Munawwar Hafiz is the CEO of OpenRefactory. Ataf Fazledin Ahamed is a software security engineer at OpenRefactory who is involved with the work funded by Alpha-Omega. For more information, contact: info@openrefactory.com