The Open Source Security Summit returned for its fourth year, and the tone was notably different from previous editions. The early summits were dominated by alarm — high-profile incidents, underfunded maintainers, and a general sense that the open-source supply chain was one bad commit away from catastrophe.
This year felt more like a working session. The problems are still serious, but the community has moved from hand-wringing to building. Here are the five takeaways that mattered most to our team.
1. Maintainer Sustainability Has Real Funding Models Now
The open-source funding conversation has been stuck in a loop for years: maintainers are overworked and underpaid, companies depend on their work but do not contribute, and the ecosystem is fragile as a result. We have all heard it. Most of us have nodded along and changed nothing.
What is different in 2026 is the emergence of funding models that actually work at scale:
The Sovereign Tech Fund (Germany) has distributed over 30 million euros to critical open-source projects since its launch. Their model — government funding for digital infrastructure — has inspired similar programs in France, the Netherlands, and South Korea.
Tidelift's managed open-source model has grown to cover 5,000+ packages with paid maintainers who commit to security practices, timely patching, and SBOM production. Enterprise customers pay for the assurance, maintainers get paid for the work. It is not charity — it is a market.
GitHub Sponsors and Open Collective have matured their payout mechanisms and reporting, making it easier for companies to fund maintainers and track the impact.
None of this solves the problem completely. Thousands of critical packages are still maintained by volunteers with no funding. But the trajectory is positive, and the summit's funding track showcased models that are replicable.
2. Package Repository Security Is Improving, But Slowly
The summit dedicated an entire day to package repository security, featuring maintainers from npm, PyPI, crates.io, and Maven Central.
npm has rolled out mandatory 2FA for all maintainers of packages with more than 1 million weekly downloads. They are also piloting automated malware detection that scans packages on publish, using static analysis and behavioral sandboxing.
PyPI implemented trusted publishers, allowing packages to be published only from verified CI/CD pipelines. This eliminates the risk of credential theft leading to malicious package uploads — the attack vector behind the ctx and phpass incidents.
crates.io has the advantage of Rust's memory safety and a smaller ecosystem. Their focus has been on provenance attestation, using Sigstore to sign all published crates.
Maven Central remains the laggard. The JVM ecosystem's complexity — multiple build tools, artifact formats, and repository proxies — makes security improvements harder to implement uniformly.
The key gap across all repositories: none of them perform reachability analysis or behavioral analysis at the depth needed to catch sophisticated supply chain attacks. Packages that are technically malicious but appear benign under static analysis still slip through.
3. VEX Is Ready for Production
Vulnerability Exploitability eXchange (VEX) has been "almost ready" for two years. At this summit, it crossed the threshold into practical usability.
The turning point was tooling. Until recently, producing a VEX document required manual effort — a security analyst determining whether each CVE in your dependency tree was exploitable and writing a machine-readable statement for each one. That does not scale.
New tools demonstrated at the summit can generate VEX statements automatically based on reachability analysis, deployment context, and compensating controls. The output is not perfect — human review is still needed for ambiguous cases — but it covers 70-80% of cases automatically.
The consumption side has also matured. Major vulnerability scanners now accept VEX documents as input and suppress findings that the VEX document marks as "not affected." This closes the loop: produce a VEX document, feed it to your scanner, and your triage queue only contains findings that are actually relevant.
4. The OpenSSF Scorecard Is Becoming a Procurement Signal
The OpenSSF Scorecard — an automated tool that evaluates the security practices of open-source projects — has been around since 2020. What is new is how it is being used.
Several speakers from large enterprises described incorporating Scorecard results into their dependency selection process. If a package has a Scorecard below a threshold (commonly 6/10), it triggers a manual review before it can be added to the approved dependency list.
Federal agencies are going further. The GSA's FedRAMP Marketplace now includes Scorecard data for open-source components used in authorized cloud products. This creates a procurement signal: if your product depends on poorly-scored open-source projects, it may face additional scrutiny during FedRAMP authorization.
The Scorecard itself has improved significantly. The latest version includes checks for SBOM production, VEX availability, Sigstore signing, and branch protection rules. It is becoming a comprehensive security posture assessment for open-source projects.
5. The "All Volunteers" Narrative Is Misleading
One of the most provocative talks at the summit challenged the common narrative that critical open-source software is maintained by unpaid volunteers.
The speaker presented data showing that 85% of commits to the top 500 most-depended-on open-source projects come from developers employed by companies that pay them to contribute. The "unpaid volunteer maintaining critical infrastructure in their spare time" is real — the xz-utils incident proved that — but it is the exception, not the rule, for the most critical packages.
The implication is that the maintainer sustainability problem is more nuanced than "nobody is paying for open source." The problem is that funding is concentrated in the most visible projects, while the long tail of less-prominent but still-critical packages receives almost nothing.
This reframing matters for how we allocate resources. Instead of broad-based funding that spreads thin, the community needs targeted investment in the specific packages that are both critical and underfunded. The OpenSSF's Critical Projects Working Group is doing this analysis, and their findings should inform how organizations direct their open-source security budgets.
Looking Forward
The overall message from the summit was cautiously optimistic. The open-source supply chain is more secure than it was two years ago. Funding models are emerging. Repository security is improving. Tooling for VEX, provenance, and scoring is maturing.
But the attack surface is also growing. AI agents consuming open-source packages at machine speed, dependency trees that are deeper and more complex than ever, and nation-state adversaries that view open-source as a strategic target — these are challenges that require sustained investment and community collaboration.
How Safeguard.sh Helps
Safeguard integrates OpenSSF Scorecard data, VEX document consumption, and Sigstore provenance verification into a unified supply chain security platform. When your team selects a new dependency, Safeguard can surface its Scorecard, known vulnerabilities, maintainer activity, and provenance information — all before the dependency enters your codebase. For organizations that want to operationalize the best practices discussed at the summit, Safeguard provides the tooling to make it practical.