It sounds simple: If you pay developers more money, they’ll improve the quality of their code, right? The evidence isn’t so clear.
There has been little direct evidence that paying open-source developers results in more secure code – until now. The Atlantic Council’s Digital Forensic Research Lab (DFRLab) recently showed a correlation between funding for maintainers and the security of open source code.
Specifically, the researchers found “prima facie evidence of a positive effect of general open source software funding on open source software security.” They looked at the 1,000 most downloaded Python Package Index (PyPl) and npm JavaScript packages. Using Open Source Security Foundation (OpenSSF) tools such as “funder-finder” and the “Security Scorecard” the researchers saw a connection between financial support and security enhancements.
That may sound like an obvious conclusion, but the evidence was not as clear as you might think. The researchers report with only “moderate confidence” that a meaningful connection exists “between more open source project funding and improved security posture. …[M]ore funding generally correlates with more dramatically differentiated security practices.”
This seems to go against common sense. As Dana Wang, OpenSSF’s Chief Architect, said, “Balancing the security, reliability, availability, performance, and cost of open-source software is not trivial. Maintainers sometimes have to choose between new features, bug fixes, and less critical security patches.” And, even after such open source project security fiascos as Log4J, as we all know, security all too often comes too low on developers’ priority list.
Still, other research, such as programming security company Tidelift‘s 2023 State of the Open Source Maintainer Report, showed that “paid maintainers were 25-30% more likely to have completed the [security] work or plan compared to unpaid maintainers. On every development practice surveyed, paid maintainers were significantly more likely to implement it than unpaid maintainers.”
Sometimes security fixes are needed and available, but corporations aren’t adopting them. In another study from Synopsys, the 2024 Open Source Security and Risk Analysis Report, not quite half of codebases contained open source components with no new development in the last two years; 91% contained components ten or more versions behind the latest version. This is a failure by open source users, not underpaid open source developers. Bad companies! Bad!
Returning to the DFRLab study, its researchers also found that diversity in funding sources appeared to be beneficial. That is, projects with multiple supporters apparently do better (with security at least) than those with a single backer. This suggests that investors should look at a variety of support mechanisms rather than solo-source funding.
One reason why the results are so fuzzy is that we don’t have enough data. As the DFRLab crew observed, the “OpenSSF Scorecard tool itself has several quirks… Scorecard does not necessarily capture all the security improvements that might occur during a project. For example, a security audit, paid for voluntarily by maintainers who received funding, might look for and remediate new vulnerabilities while likely not directly improving any Scorecard metric. Some practices may also meet OpenSSF criteria in principle but be missed by the automated scorecard check. For example, a project might include a strong security policy but with a different filename than what the scorecard search is looking for, and thus not pass the subcheck.”
As DFRLab states, we need more research to understand how funding affects security. No one can really doubt that more money helps, but the most effective way to fund projects, maintainers and developers – and how we should measure the results – remain unclear.
Given how critical open source security is to all of our technology, the sooner we figure it out, the better.
Photo credit: Jonathan Kemper on Unsplash
