With the EU’s Cyber Resilience Act (CRA) applying in full from December 2027, manufacturers must document every component of the products they ship in a Software Bill of Materials (SBOM), and identify every vulnerability those components carry. Article 3(39) of the regulation defines SBOM as "a formal record containing details and supply chain relationships of components". The Act was written for better security, vulnerability tracking and reporting in the EU, but it also fundamentally changes the liability model, especially from the funding landscape perspective.
From goodwill to risk management
The CRA's obligations are triggered by commercial activity, regardless of whether the software is proprietary or open source. They fall on manufacturers, the entities placing products with digital elements on the EU market for commercial purposes. Non-commercial open source projects stay outside the CRA scope and, in practice, already publish their dependency trees voluntarily using CycloneDX and SPDX open source standards. What the CRA legally acknowledges for the first time within the EU is that a product's dependencies are as security-critical as the top-level product itself.
This matters for the digital sovereignty agenda the EU has placed at the centre of its next
decade. The law no longer treats dependencies as secondary and now integrates them into its core compliance framework. However, in current open source funding practices, public agencies and corporate sponsors still fund only the top-level projects, if at all.
With the CRA in place, funding open source dependencies stops being goodwill and becomes risk management. The implicit social contract, if you use it, give back, becomes an explicit business imperative. The most effective way to manage this risk is to proactively fund the maintenance and security of those dependencies, transforming a potential liability into a
managed assets.
Sovereign software, global dependencies
Take OpenTalk, the open source video-conferencing platform. Unambiguously European product: German GmbH, EUPL-1.2 licence, in production across Schleswig-Holstein's ministries as a sovereign alternative to commercial conferencing. Yet its Rust backend depends on LiveKit (US), Tokio (US-maintained), OpenTelemetry (CNCF, a US non-profit), and the AWS SDK, while its TypeScript-and-React frontend sits inside the same broadly US-anchored JavaScript ecosystem. The one EU-anchored backend dependency is diesel, the German-built ORM, supported by NLnet and Germany's Federal Ministry of Research, Technology and Space.
Same with scikit-learn, Python's de facto machine-learning library, used across European research institutes, hospitals and public sector data teams. France treats it as critical infrastructure and has funded it through Inria (France's national digital research institute) and the national AI strategy, yet its five runtime dependencies span three currencies and at least two non-EU fiscal jurisdictions – NumPy and SciPy fiscally sponsored by NumFOCUS, a US non-profit, narwhals independently maintained from Cardiff, UK.
No EU software stack is fully EU-built: critical pieces come from all over the world, from the Americas to Asia. If we want secure and robust software in Europe, we cannot pretend we can assemble it from EU components alone.
Crossing borders
Inside the EU, a SEPA transfer to a maintainer in another Member State is near-free and settles in a day or two. Step outside the SEPA zone and the picture changes drastically: substantial FX margins, multi-day clearing, and coordination across half a dozen jurisdictions for a single project's dependency tree.
On funding platforms, host fees and payment processing drain 3-13% from every donation
before it reaches the recipient. Liberapay asks no platform cut and roughly 3-5% in processing; Open Collective charges a 10% fiscal host fee. Several platforms also cap what a single sponsor can send to a single recipient: Liberapay at €100 per week, GitHub Sponsors at $12,000 per month, so scaling corporate support across a dependency tree forces a fragmented portfolio of small transfers.
If a funder wants to reach the dependencies, what are the options? One is to push redistribution down to the top-level maintainer who is already coordinating code, weeding out AI slop, and facing a burnout crisis. Adding international financial distribution to that load is not realistic. The second is to route the money through a consultancy intermediary, which is worse: funds meant for open source flowing through actors with no open source mandate of their own.
Missing rails
By the end of next year, with every commercial product on the EU market shipping its SBOM, the dependency tree becomes a forest with every open source and proprietary dependency mapped down the roots. A funder may want to support what they see in that forest. The financial system that would carry money through borders, currencies, jurisdictions, is not built for it.
Can we make cross-border funding more efficient, so grants are not eroded by fees and currency conversion? Can we make it faster, moving at the speed of the internet rather than pausing on bank holidays? Can we make it fair, so the pie is shared across the top-level project and its dependencies, and redistribution is not an administrative penalty for maintainers?
A dependency graph built on infrastructure designed with transparency, programmability, and intermediary minimisation would provide a fairer, more efficient funding environment — my candidate answer to those questions. Perhaps it is time to look seriously at new payment rails open source funding needs: I believe Ethereum has carried those properties in its design from the start, and is ready to be put to the test now, in exactly the kind of cross-border, dependency-aware coordination Europe's digital sovereignty demands.
About the Author
Sofia Sukhinina is an OSPO researcher within the Funding Coordination team at the Ethereum Foundation. Her research focuses on how organisations, from government OSPOs in Europe and beyond to companies with open source funding programmes, approach the funding of upstream dependencies, and how programmable payment rails could support the cross-border distribution this work requires. The views expressed in this article are her own.