30.2: Models for Sustainable Security Investment¶

Market failures in open source security don't mean improvement is impossible—they mean that market forces alone won't produce optimal outcomes. Various models have emerged to address these failures, channeling resources toward security work that would otherwise go unfunded. From foundation-based pooled investment to corporate security teams to industry consortia, each model attempts to overcome specific barriers to investment while bringing its own strengths and limitations.

Understanding these models helps stakeholders choose appropriate approaches for their context. A Fortune 500 technology company has different options than a healthcare industry consortium or a small open source project seeking sustainability. Some models work better for broad ecosystem improvement; others target specific projects. Some require scale; others work at any size. Evaluating these tradeoffs enables more effective allocation of limited security resources.

Foundation-Based Funding¶

Foundations aggregate resources from multiple organizations, providing neutral governance and professional management of open source security investment. The foundation model addresses free-rider problems by creating collective action mechanisms—organizations contribute because their peers do, and because the foundation provides coordination they couldn't achieve individually.

Linux Foundation and OpenSSF:

The Linux Foundation hosts the Open Source Security Foundation (OpenSSF), which has become the primary vehicle for coordinated open source security investment. OpenSSF pools funding from premier members (Google, Microsoft, Amazon, Intel, and others) contributing substantial annual fees.

OpenSSF deploys resources through multiple programs:

• Alpha-Omega: Dedicated security work on critical projects
• Tool development: Sigstore, Scorecard, SLSA, and other shared infrastructure
• Working groups: Collaborative standards development
• Education: Security training and best practices guidance

The foundation model provides:

• Neutral governance: No single company controls direction
• Professional management: Full-time staff coordinates activities
• Collective action: Pool overcomes individual free-rider incentives
• Visibility: Public commitment creates peer pressure for contribution

Limitations:

• Governance overhead: Consensus processes can slow decision-making
• Political dynamics: Large members may exert disproportionate influence
• Resource allocation: Deciding which projects receive investment is contentious
• Sustainability: Depends on continued corporate commitment

Apache Software Foundation:

The Apache Software Foundation demonstrates a different model—volunteer governance with modest corporate sponsorship. Apache provides:

• Security team coordinating vulnerability response across 350+ projects
• Infrastructure for secure distribution
• Legal protection for contributors
• Governance frameworks promoting security practices

Apache's lighter-touch model works because many Apache projects have commercial backing that provides indirect security investment. However, purely volunteer projects within Apache may still lack dedicated security resources.

Smaller foundations:

Smaller foundations like the Python Software Foundation, Ruby Association, and others fund security work within their ecosystems. These organizations:

• Focus investment on specific language/ecosystem
• Rely on fewer, often smaller, sponsors
• May struggle to fund comprehensive security programs
• Provide critical coordination that wouldn't otherwise exist

Foundation model assessment:

Foundations work well for broad ecosystem investment but may be less effective for specific project needs.

Corporate-Sponsored Security Teams¶

Several major technology companies maintain dedicated teams working on open source security—not just for their own projects, but for the broader ecosystem.

Google Open Source Security Team (GOSST):

Google's Google Open Source Security Team (GOSST) represents the most significant dedicated corporate investment in ecosystem-wide open source security:

• Dedicated engineers: Full-time security engineers working on open source
• Tool development: Sigstore, OSV, SLSA originated from Google investment
• Direct project engagement: Engineers work with critical projects
• Research: Security research benefiting the ecosystem

GOSST demonstrates that corporate investment can produce substantial ecosystem benefit. Tools developed by the team are now used across the industry, multiplying impact far beyond Google's direct involvement.

Why this model works for Google:

• Scale: Google's security depends on open source; ecosystem security is self-interest
• Resources: Google can afford significant investment
• Talent: Attractive work draws top security engineers
• Influence: Contributions build reputation and standards influence

Microsoft's investments:

Microsoft contributes through multiple channels:

• GitHub security features: Dependabot, code scanning, secret scanning free for open source
• Security researchers: MSRC researchers investigate open source vulnerabilities
• OpenSSF leadership: Governance participation and funding
• Direct contributions: Engineers contributing to projects Microsoft uses

Microsoft's acquisition of GitHub multiplied impact—security features built into the platform reach millions of projects automatically.

Limitations of corporate teams:

• Company-dependent: Teams exist at company discretion and can be reduced in downturns
• Strategic alignment: Investment may prioritize company interests over ecosystem needs
• Sustainability: Long-term commitment uncertain
• Coverage gaps: Companies focus on software they use, leaving gaps

Replicability:

Corporate security teams require:

• Substantial resources (millions annually)
• Strategic alignment between company and ecosystem security
• Engineering talent interested in this work
• Long-term commitment from leadership

This model is available mainly to large technology companies with significant open source dependencies.

Bug Bounty and Audit Subsidies¶

Bug bounty programs and audit subsidies create market incentives for security work that wouldn't otherwise occur.

Bug bounty effectiveness:

Research on bug bounty effectiveness shows mixed results:

• Finding density: Bug bounties find vulnerabilities, but often the "low-hanging fruit"
• Researcher motivation: Higher bounties attract more sophisticated researchers
• Coverage: Bounties incentivize finding, not fixing or preventing
• Quality variation: Report quality ranges from excellent to nearly useless

Internet Bug Bounty and Huntr:

Programs providing bounties for open source vulnerabilities:

• Internet Bug Bounty: Corporate-funded bounties for critical infrastructure (now called Secure Code Bounty Program)
• Huntr: Platform providing bounties across open source projects (now focused on AI/ML security after Protect AI acquisition)

These programs have paid over $1 million for open source vulnerabilities¹. However, bounty levels are typically lower than corporate programs, limiting researcher interest.

Audit subsidies:

Organizations like OSTIF fund professional security audits:

• Systematic coverage: Audits provide comprehensive review, not just opportunistic findings
• Expert assessment: Professional auditors bring deep expertise
• Funded externally: Projects receive audits they couldn't afford

OSTIF has coordinated audits of dozens of critical projects, identifying hundreds of vulnerabilities. The organization provides approximately $1.5 million per year in recent audit funding². Audit quality depends on auditor selection and scope definition.

Google's Patch Rewards:

Google's Patch Rewards program pays for security improvements, not just vulnerability discovery:

• Rewards for proactive security hardening
• Payment for fixing vulnerabilities (not just finding them)
• Incentivizes ongoing security investment

This model addresses a gap in traditional bounties by rewarding the full security improvement lifecycle.

Model assessment:

Bounties and audits complement each other—bounties provide continuous coverage while audits provide depth.

Consortium Approaches¶

Industry-specific consortia pool resources to address shared security concerns in open source software they commonly depend on.

Financial services:

The financial industry has particular incentives for open source security investment:

• Regulatory pressure for third-party risk management
• Shared dependencies across competitors
• High cost of security incidents
• Sophisticated threat environment

FINOS (Fintech Open Source Foundation) coordinates some financial services open source work, though security-specific consortia remain less developed than the opportunity suggests.

Healthcare:

Healthcare organizations share dependencies and face common regulatory pressures (HIPAA, FDA requirements). Opportunities for consortium investment include:

• Shared medical device software components
• Common healthcare data standards implementations
• Regulatory compliance tooling

Healthcare consortium investment in open source security remains limited despite clear shared interests.

Automotive:

The automotive industry, through organizations like GENIVI (now COVESA) and Automotive Grade Linux, coordinates on shared platforms:

• Safety-critical software requires high security standards
• Regulatory requirements (UNECE) mandate security
• Shared investment reduces duplication

Automotive represents one of the more developed consortium models, driven by regulation and safety requirements.

Consortium model strengths:

• Aligned interests: Industry members share dependencies and threats
• Competitive dynamics: Even competitors can collaborate on shared infrastructure
• Domain expertise: Industry-specific knowledge guides investment
• Regulatory leverage: Regulators may encourage or require coordination

Limitations:

• Coordination costs: Aligning competitors requires significant effort
• Scope limitations: Focus on industry-specific needs may miss broader ecosystem
• Antitrust concerns: Competitor collaboration raises legal considerations
• Free-rider risk: Even within consortia, some members may undercontribute

Paid Support and Security Tiers¶

Some projects and organizations offer paid support tiers that fund security work.

Enterprise distribution model:

Companies like Red Hat, Canonical, and SUSE provide enterprise Linux distributions with:

• Security response teams
• Extended support periods
• Security-certified configurations
• Indemnification

Customers pay for guaranteed security response, funding work that benefits the broader ecosystem.

Tidelift model:

Tidelift pays maintainers to:

• Address security issues promptly
• Follow secure development practices
• Provide security documentation
• Maintain packages professionally

Enterprise customers pay Tidelift; Tidelift distributes funds to maintainers. This creates a commercial channel for sustainability.

Dual licensing:

Some projects offer dual licensing:

• Open source license for community
• Commercial license with additional rights/support

Revenue from commercial licenses funds development including security work. This model works for projects with commercial demand for the commercial terms.

Strengths:

• Creates market mechanism for funding
• Aligns payment with value received
• Sustainable if sufficient customers exist

Limitations:

• Only works for projects with commercial demand
• Many critical projects have no obvious commercial buyer
• Creates potential misalignment between community and commercial users
• May not fund systemic improvements

Hybrid Models and Experimentation¶

Emerging models combine elements from multiple approaches.

Alpha-Omega as hybrid:

Alpha-Omega combines:

• Foundation governance (OpenSSF)
• Corporate funding (Google, Microsoft, Amazon, Citi)
• Direct project engagement (dedicated engineers)
• Both targeted (Alpha) and broad (Omega) investment

This hybrid draws on foundation neutrality, corporate resources, and direct technical engagement.

GitHub's model:

GitHub combines:

• Commercial platform (subscription revenue)
• Free security features for open source
• Foundation participation
• Direct tool development

Microsoft's GitHub investment funds security features benefiting the entire ecosystem.

Sovereign Tech Fund:

Germany's Sovereign Tech Fund represents government investment in open source infrastructure:

• Public funding for public goods
• Focus on digital sovereignty
• Multi-year commitments
• Significant scale

Government funding addresses market failures that private investment alone cannot resolve.

Experimentation areas:

Emerging experiments include:

• Web3/crypto funding: Projects like Gitcoin explore new funding mechanisms
• Quadratic funding: Matching mechanisms that amplify small donations
• Security DAOs: Decentralized organizations coordinating security work
• Micro-grants: Rapid, low-overhead funding for specific improvements

These experiments haven't yet proven sustainable at scale but may yield new models.

Comparative Effectiveness¶

Different models suit different contexts:

No single model addresses all needs. The most robust approaches combine multiple models—foundations for governance, corporate investment for resources, bounties for coverage, audits for depth, and commercial support where markets exist.

Recommendations¶

We recommend stakeholders adopt approaches matching their context:

For large technology companies:

1. Fund OpenSSF at premier member levels, supporting shared infrastructure
2. Consider dedicated security teams if scale justifies investment
3. Sponsor audits for critical dependencies through OSTIF or directly
4. Release internal tools that could benefit the ecosystem

For industry groups:

1. Explore consortium approaches for shared dependencies
2. Coordinate audit investments to avoid duplication
3. Fund industry-specific security improvements
4. Share threat intelligence relevant to common dependencies

For open source projects:

1. Pursue foundation affiliation for governance and resources
2. Apply for audit funding through OSTIF, NLnet, or similar
3. Explore commercial support models if enterprise demand exists
4. Engage with Alpha-Omega for critical projects

For policy makers:

1. Fund public goods directly through programs like Sovereign Tech Fund
2. Create incentives for private investment in open source security
3. Support foundation coordination as effective collective action
4. Avoid mandates without resources that burden volunteer projects

The most effective approaches combine multiple models, creating layered investment that addresses different market failures through different mechanisms. No single solution exists—sustainable security investment requires an ecosystem of approaches working in concert.