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.
Filed Under: Blogs, DevOps and Open Technologies, DevOps Culture, Doin’ DevOps, Features, IT Security, Latest News Releases, Social – Facebook, Social – X Tagged With: investment, open source, open source security, research, roi
Secure Coding Practices
Step 1 of 7
14%
Does your organization currently implement secure guardrails in the software development process?(Required)
Yes, extensively across all projects
Yes, but only in specific projects or teams
In the process of implementation
No, but planning to in the near future
No, and no plans to implement
What are the biggest challenges you face in implementing secure guardrails within your development processes? (Select all that apply)(Required)
Lack of awareness or understanding
Technical difficulties in integration
Resistance from development teams
Lack of suitable tools
Cost constraints
Other
Other, tell us more:
How effective do you find secure guardrails in preventing security vulnerabilities in your projects? Rate on a scale from 1 (Not effective) to 5 (Highly effective)(Required)
1
2
3
4
5
To what extent are your secure guardrails automated?(Required)
Fully automated
Mostly automated with some manual processes
Equally automated and manual
Mostly manual with some automation
Entirely manual
What features do you prioritize in a secure guardrail solution? (Rank in order of importance)Ease of integration into existing workflowsComprehensive coverage of security vulnerabilitiesCustomizability for specific project needsMinimal impact on development speedActionable insights and recommendationsSupport for a wide range of programming languages and frameworks
What are your organization’s plans regarding the adoption or enhancement of secure guardrails within the next 12 months?(Required)
Expand the use of secure guardrails to more projects
Enhance the capabilities of existing secure guardrails
Maintain current level of secure guardrail use without changes
Reduce reliance on secure guardrails
No plans related to secure guardrails
What best describes your primary role?(Required)
Security Engineer
DevOps Engineer
Platform Engineer
Security champion on the development team
Software Developer
CISO (or equivalent)
Sr. Management (CEO, CTO, CIO, CPO, VP)
Manager, Director
Other
Δ
