Does More Money Improve Open Source Security? –

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


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, 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)






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