A lot of software depends on open source. Web apps, and plenty of enterprise applications, draw on libraries maintained by volunteers. Open source software helps cut development time and cost. For many development teams, it’s also a poison pill.
According to GitHub’s annual State of the Octoverse security report, most of the projects that it hosts rely on at least one piece of open source software. It also found a startling fact: open-source vulnerabilities often lurk undetected by project teams for over four years.
In an ideal world, an open source project team would be on top of these security issues, finding and fixing them in a concerted effort to secure this software before unscruplous online sleuths find them first. In reality, security isn’t top-of-mind for these developers, many of whom aren’t paid. In fact, according to the Linux Foundation’s 2020 Free and Open Source Software (FOSS) Contributor Survey, security barely registers.
Open source security just isn’t sexy
Most OSS contributors spend the least time of all on enhancing project security, according to the Linux Foundation report. This wasn’t just a result of industry pressure, because it was also the least likely task to be described as ideal by the survey base, at just 2.3% on average.
Time spent fixing security issues varied little across paid and volunteer contributors. In fact, the only real difference in time allocation was between core contibutors or maintainers and occasional or one-time contributors. The former spent more than twice as much time on security as the latter, indicating that they understand the importance of security, at least in part. Nevertheless, security was the least-addressed issue among this group too.
Why is security such an afterthought for OSS projects? Developers just don’t find it sexy. One respondent told the Linux Foundation: “I find the enterprise of security a soul-withering chore and a subject best left for the lawyers and process freaks. I am an application developer.” As if any modern application developer can afford to ignore code security.
The survey results showed clearly that most OSS developers consider security to be somebody else’s problem. The most-valued contribution from external sources among survey respondents were bug and security fixes.
What could help redress the imbalance? Money will be a key factor, although simply throwing it at existing developers won’t be especially effective, warned the Foundation. They’re typically motivated by other things. Top of the list was a need for the specific features that they contribute to the application, while the second was a simple love of learning. The third most popular motivator was tied closely to the first: a need for creative, challenging, or enjoyable work. Conversely, payment was the least common factor driving survey respondents to contribute to open source projects.
Funding open source security where it counts
This focus on non-monetary factors doesn’t mean that money isn’t important at all, though. The report noted that over a third of contributors still felt financial contributors were potentially beneficial to at least one of the open source projects they contributed to, and that they were the second most important contributions after code contributions.
We can deduce that open source coders don’t want to line their own pockets, but they do appreciate more resources to make them more effective. That means money might best be directed to specific resources like security-related tools and audits, the Foundation’s report says.
Fixing existing code remains a critical problem in open source projects, many of which have been in development for years. Security audits are a good starting point, and the Linux Foundation points to its Open Source Security Foundation (OpenSSF) as a partial solution. This proposes security audits for open-source projects. Another initiative is its Core Infrastructure Initiative, a project that channels funding from large tech companies to fund security drives in open source software.
Bug hunting is only part of the journey to a more secure open-source community, though. The other is driving better security into development. That’s especially important in an environment where developers are distributed, and in which a group of occasional coders complements the work of core developers and maintainers. To this end, the report recommends bolstering security practices with better continuous integration tooling, introducing developer communities to mentoring programs run by tech companies and nonprofits, and also using badging programs. The Core Infrastructure Initiative has a Best Practices Badge that highlights projects with solid security foundations, for example.
Even then, open-source volunteers focused purely on security will remain thin on the ground. If you fancy carving out a niche for yourself by bug hunting among these projects, here’s a guide to exploring large open source codebases. Good luck!