The Sovereign Tech Agency Explained: Public Money for Open Source

The Sovereign Tech Agency is a German public agency that pays for maintenance and security work on the open source components the rest of the software world builds on. It is financed by the Federal Ministry for Digital Transformation and Government Modernisation, it is a subsidiary of SPRIND, and it grew out of the Sovereign Tech Fund, which started investing in October 2022.

This guide goes one level deeper than our posts on whether funding or sponsorship makes a dependency safer, how sponsorship models compare and maintainer burnout. We read the agency's programme pages, FAQ, portfolio entries and announcements from October 2023 to October 2026, the European Commission's page on the Cyber Resilience Act (CRA) and open source, and Alpha-Omega's published application process. Every figure and date below comes from those pages, and where the agency's own pages disagree, we say so.

Key takeaways

• The Sovereign Tech Agency (STA) commissions work on foundational open source software: libraries, package managers, protocol implementations, developer tools and cryptography. It is financed by the German digital ministry and is a subsidiary of SPRIND.
• It began as the Sovereign Tech Fund, which presented its pilot round to the German parliament on 18 October 2022 and became one programme inside the new Sovereign Tech Agency on 4 November 2024.
• It runs five programmes: the Fund, Sovereign Tech Resilience (formerly the Bug Resilience Program), the Fellowship, Standards and the Challenge.
• By 13 October 2026 the agency reported more than 110 investments and over 60 million euros across those programmes.
• The Fund considers only work costing more than 50,000 euros on openly licensed foundational technology that no other public body already funds, and takes about six months from application to contract.
• Public money here is a commission, not a donation: defined work, milestones, progress reports tied to invoices and a final report.
• Funding is a signal about maintenance capacity, not a security guarantee. A funded or audited dependency still needs to be inventoried, pinned, patched and checked in your own pipeline.

What is the Sovereign Tech Agency?

The agency describes itself as "the engine room for digital sovereignty." Its about page sets out the argument behind it in plain terms: almost every modern technology rests on open source building blocks, those building blocks do not receive adequate support and investment, and that market failure threatens the stability, competitiveness and security of everything built on top. The agency's answer is "targeted and long-term public funding" for the foundation.

The focus is narrow on purpose: libraries for programming languages, package managers, open protocol implementations, developer tools and encryption technologies. These are components most people never install directly but that end up inside almost every application through dependency trees. The agency does not pay for end user apps.

The FAQ names Adriana Groh (CEO) and Luisa von Beust (Managing Director) as its leaders. It also says the agency works with free and open source software (FOSS) communities everywhere, not just in Germany or the EU, because those communities are "distributed all around the world."

Who funds the Sovereign Tech Agency?

The agency's FAQ says it is financed by the German Federal Ministry for Digital Transformation and Government Modernisation (BMDS) and is a subsidiary of SPRIND, whose legal entity is SprinD GmbH in Leipzig. The site footer adds that it operates "on the basis of a decision by the German Bundestag."

The ministry has changed. The 21 November 2023 announcement says the Fund "was launched in 2022 by the German Federal Ministry for Economic Affairs and Climate Action (BMWK)", and the November 2024 rename post still thanks BMWK. If you cite the funder, cite the current FAQ and the date you read it. Resilience has its own budget line: it has run since 2023, "after the German Bundestag allocated funds in the federal budget for a bug bounty program."

When did it start, and how did the Fund become an Agency?

The November 2024 change was structural, not a rebrand: creating the legal entity made the team realise "fund" no longer covered everything it did. The Fund continues as the main programme, and existing contracts did not change.

What programmes does the Sovereign Tech Agency run?

The agency's site lists five programmes in October 2026, one of them renamed.

The Sovereign Tech Fund: commissioned work on foundations

The Fund is the original and largest programme. It invests "globally in the open software components that underpin Germany's and Europe's competitiveness and ability to innovate", on the logic that fixing one widely used component benefits every product built on it. Its requirements:

• Applications only through the online platform, in German or English.
• Activities must relate to developing or maintaining open digital base technologies. Development is the primary focus; audits and community events can be included "should they be necessary."
• The work must cost more than 50,000 euros, the current minimum.
• No other public body may already be funding the same activities.
• Code under an OSI approved or FSF Free/Libre licence; documentation without non-commercial or no-derivatives clauses.

It does not finance prototypes and is "currently not looking for user-facing applications, such as messaging apps or file storage services."

Sovereign Tech Resilience: audits, engineering help and bounties

Sovereign Tech Resilience, the renamed Bug Resilience Program, is the programme most directly about security. Its page starts from the premise that "it is not enough just to find and fix bugs": small teams often lack the time to act on what audits and bounties uncover. So it combines services delivered by specialist implementation partners and scoped with the maintainers. Since the September 2026 relaunch they are:

• Technical debt management. Code modernisation, dependency management, test coverage, CI, build work and fixing known issues.
• Transition to memory safety. Choosing which components suit a rewrite in a memory-safe language, then doing it while keeping compatibility. The page cites public reports that up to 70 percent of serious security bugs are memory safety issues.
• Post-quantum encryption readiness. Auditing cryptographic dependencies and integrating standardised post-quantum algorithms, including hybrid approaches.
• Compliance with the Cyber Resilience Act. Gap assessments, vulnerability handling processes, documentation and maintainer training.
• Security audits. Manual and automated code review, architecture review and fuzz testing, with disclosure timed with the maintainers.
• Software supply chain security. Reproducible builds, signed release artifacts, SLSA levels, secure dependency management and Software Bills of Materials (SBOMs).
• Bug and fix bounty platform. Bounties for researchers, plus a "fix" bounty paid to the project for each reported and fixed vulnerability.

A status note dated September 2026 says the bounty platform is clearing a large backlog and is "not accepting new reports or launching new bounty programs" until it finishes, expected in autumn 2026. That is a lesson in itself: rewarding discovery creates work someone has to pay to fix. Projects join by applying, by invitation or on a service provider's recommendation, and services are free to them.

The Sovereign Tech Fellowship: paying people, not projects

The Fellowship "invests directly in the people behind the code": maintainers, community managers and technical writers whose work of reviewing changes, triaging security issues and documenting processes is "hard to quantify." The 2026 round closed on 6 April 2026:

• Up to twelve fellows, starting from May and June 2026.
• Freelance contracts of 3 to 12 months at 6 to 32 hours a week, or up to three two year employee positions paid under the German public sector agreement (TVöD-Bund) at 64,000 to 82,000 euros a year full time.
• Maintainers must contribute to at least three FOSS projects and be a maintainer (able to merge or release) of at least one.
• Organisations seeking money for maintainers they employ are pointed to the Fund instead.

The Fellowship began as a pilot announced in August 2024 for Q4 2024, with a first cohort of six announced in February 2025. The October 2026 anniversary post counts 20 fellows so far.

Sovereign Tech Standards: maintainers in the room where specs are written

The newest programme addresses a gap security teams often miss: the people who implement standards in open source are rarely present when standards are written. In an agency survey, three quarters of maintainers relied on standards, yet very few could afford to help develop them. The pilot runs from mid June 2026 to June 2027 with up to ten maintainers at the IETF, W3C or ISO, each paid 4,800 to 5,200 euros a month for about 10 hours a week plus training, mentoring, fees and travel. The first cohort of ten was announced on 27 July 2026.

The Sovereign Tech Challenge: competitions for structural problems

The Challenge uses competitions. The first, the Contribute Back Challenges (applications 6 June to 6 July 2023), asked organisations that use open source to give back in developer tooling, securing software production and documentation, paying 65,000 to 300,000 euros per team per four month round. The agency announced 1.3 million euros for nine first round teams on 19 October 2023 and counts 14 Challenge projects in total. The software production challenge was explicitly about supply chains: "dependencies must be known and vulnerabilities must be fixed quickly before they can be exploited."

How are projects selected, and what do contracts pay for?

The FAQ describes two routes: "pull" (the team scouts technologies through research and recommendations) and "push" (open applications). In its first year the team identified 195 technologies worth investing in, about 100 by research and 95 through applications.

The six selection criteria

Eligible Fund applications are reviewed against six criteria:

"Vulnerability" here does not mean a CVE. It means the funding gap: important work nobody else pays for. We borrow that idea in the walkthrough below.

How long it takes

The FAQ adds that once invoices with reports are submitted and approved, payment can take up to 30 days.

What a contract looks like

The agency commissions work rather than giving grants; the five year review credits a "low-barrier procurement model" that lets it contract maintainers, small teams and informal communities. According to the FAQ, milestones and scope are agreed during scoping, progress reports are tied to invoices (an email with links to pull requests is enough), and a final report covers impact, challenges and next steps.

The portfolio shows what gets bought. curl's money paid for a clean-up of 122 known bugs and new options for newer HTTP versions. OpenSSH's covered removing or securing risky legacy features, a new cryptographic algorithm and better FIDO integration. Log4j's covers a faster release pipeline for emergency fixes, fuzz testing, a performance testbed and SBOMs.

So the common summary "maintenance, not features" is not quite right. The Fund page says development is the primary focus, as long as it is foundational technology rather than prototypes or end user apps. Sometimes keeping a foundation healthy means a new algorithm or protocol version.

How is this different from donations and sponsorships?

A donation buys goodwill; a commission buys defined work. A sponsorship is usually unrestricted, unreported, chosen by visibility and open ended. An agency contract names deliverables such as fuzzing or a bug backlog, requires reports, is chosen against published criteria, runs for a fixed term (certainty during it, a cliff at the end) and appears in a public portfolio with amounts and years. The full comparison of four funding models is in a table later in this guide.

Which kinds of projects has it funded?

The portfolio at sovereign.tech/tech lists every investment with a status (current or past), an amount and the years. The first pilot round in 2022, according to the "Our First Year" post, covered nine technologies: OpenMLS, curl, OpenBGPd, Bundler and RubyGems, WireGuard, OpenPGP.js and GopenPGP, OpenSSH, Sequoia PGP and Fortran. That mix already shows the pattern: protocols, package managers, cryptography and language tooling.

A sample of portfolio entries we checked on 24 October 2026:

The full list also covers package managers (RubyGems and Bundler, conda and mamba, Arch Linux package management, Cabal, Nix), languages and runtimes (PHP, Fortran, Babel, the OpenJS Foundation), cryptography (OpenMLS, OpenPGP.js, Let's Encrypt, the OpenSSL Foundation), time and routing (Pendulum, OpenBGPd), desktop and media stacks (GNOME, KDE, FFmpeg, GStreamer) and Java tooling (JUnit, logback, PMD).

Three entries stand out for supply chain teams. Package URL is the identifier SBOM standards use to name components, so investment there improves the accuracy of every SBOM tool. OpenSSF Scorecard is the automated check we use in the walkthrough below. Apache Maven resolves most Java dependency trees.

The agency's own October 2026 PHP2Shell post adds a concrete security example: in 2024 the agency funded the first external security audit of PHP's core in over a decade, coordinated by the Open Source Technology Improvement Fund (OSTIF), a non-profit. The agency says the audit produced 17 security related findings and contributed to later work on the underlying problem behind one of the PHP2Shell vulnerabilities fixed on 21 October 2026. Our PHP2Shell explainer covers that incident.

How does it relate to other funding efforts?

Public money is one of several sources, and the agency's own pages position it as a complement. Here is how it fits with the others.

Alpha-Omega

Alpha-Omega's mission is "catalyzing sustainable security improvements across open source." Its site says it is backed by large technology companies, including cloud providers and AI developers, with an annual budget of over 7 million US dollars. The agency's Log4j page notes that the Open Source Security Foundation (OpenSSF) announced the project; see our OpenSSF explainer. Its "How to Apply" page describes four 12 week seasons a year: a month of intake, a month co-designing the statement of work with its security experts, and a month of decision and disbursement. Recipients must use an OSI approved licence and publish monthly public reports.

The two cooperate: in June 2025 they co-hosted a "maintain-a-thon" at UN Open Source Week in New York. The difference is the money's source and focus. Alpha-Omega is company funded and aims squarely at security outcomes; the agency is state funded and weighs public interest and funding gaps across maintenance, standards and people.

Foundation grants and membership funding

Foundations fund governance, legal support and infrastructure from membership dues, but do not always pay maintainers. The agency's Log4j page says the Apache Software Foundation provides governance and infrastructure for Log4j but "does not provide financial support to Log4j maintainers or contributors", and that the core maintainers had no significant financial support before the agency's investment. See our posts on foundation governance models and the Eclipse Foundation for how those bodies are run.

A European level fund: the Digital Commons EDIC

On 29 October 2025, according to the agency, the European Commission announced the Digital Commons European Digital Infrastructure Consortium (EDIC), an EU legal vehicle for member states to pool resources on digital infrastructure. France, Germany, Italy and the Netherlands founded it, with Luxembourg, Slovenia and Poland as observers; the official launch was scheduled for 11 December 2025 in The Hague. In October 2026 the agency described work with the consortium "on a pilot for a European Sovereign Tech Fund." That is a pilot, not an operating EU fund, so treat claims of an EU wide fund already paying projects with caution.

The CRA's open source steward role

According to the European Commission's CRA open source page, only free and open source software made available on the market in the course of a commercial activity carries manufacturer obligations. Open source not monetised by its manufacturer is not a commercial activity, and contributors to projects not under their responsibility are not covered.

The CRA also creates the open source software steward: a legal person that supports the development of open source products intended for commercial activities on a sustained basis and plays a main role in their viability. Under Article 24, stewards need a cybersecurity policy for secure development and vulnerability handling, must cooperate with market surveillance authorities and must report actively exploited vulnerabilities and severe incidents. Under Article 64(10) they are not subject to administrative fines.

We found nothing on the agency's pages describing itself as a steward; it acts as a funder that helps projects prepare. Its September 2026 CRA compliance service exists for that, and the agency gives the dates as reporting obligations from 11 September 2026 and full compliance by December 2027, after entry into force in December 2024. For manufacturers the point from our Eclipse post stands: if your product includes open source, the due diligence on that component is yours. A funded audit is evidence for it, not a substitute.

What does public money change for supply chain security?

Most supply chain risk does not come from exotic attacks. It comes from slow releases, untested code, unclear vulnerability handling, missing SBOMs and a single tired maintainer. Public money targets exactly those conditions.

What the agency reports it has achieved

From the Resilience page and relaunch post:

• Security audits funded through the programme found an arbitrary code execution pathway in conda-forge and logic bugs in Rails' Active Storage that could lead to dangerous file access.
• Engineering work added more than 10,000 lines of test code to systemd.
• The Yocto Project had 221 CVEs triaged, some dating back to 1998.
• The bug and fix bounties received more than 790 submissions, of which more than 80 were accepted and rewarded, including 3 rated critical and 19 rated high by CVSS severity.
• Several components, including systemd, Log4j and Sequoia PGP, used more than one service at the same time.

Fund contracts such as Log4j's release pipeline and fuzzing, or OpenSSH's removal of risky legacy features, are the same kind of dull, structural improvement that makes a component easier to trust and faster to patch.

Why fixing, not finding, is the bottleneck

The relaunch post says AI tools are speeding up vulnerability discovery. It cites curl ending its paid bug bounty in January 2026 over a flood of low quality AI reports, after which real security reports arrived at twice the previous year's rate. The PHP2Shell post sums it up: "Finding vulnerabilities is not the same as fixing them."

For consumers of open source, more advisories will arrive, faster, for the same components. Your pipeline must absorb more upgrades without breaking, and the projects you depend on need capacity to ship fixes. Public funding helps with the second. Only you can do the first.

The limits

Public funding has real limits, and pretending otherwise would mislead anyone using "is it funded?" as a risk signal.

• It is selective. By November 2024 more than 500 submissions had proposed over 114 million euros of work; the five year total across all programmes is over 60 million euros. Most critical projects go unfunded in any given year.
• It is time limited. The portfolio marks curl and OpenSSH as "Past". A project funded in 2023 may be back to volunteers today.
• It is slow by design. About six months to a contract is fast for public procurement, but it is not incident speed.
• It does not change your exposure. A funded audit helps the audited version, not the outdated copy pinned in your lockfile.
• The funder has capacity limits too. The bounty platform pause in autumn 2026 shows a funded programme can be overwhelmed by volume.
• It is a political choice. Continuity depends on future budgets, and the funding ministry has already changed once.

How do public, foundation, corporate and individual funding compare?

There are four main ways money reaches open source maintainers. None is best in every respect, and a healthy critical project usually has more than one.

Read the "security signal" row carefully. A specific funded audit with a published report is strong evidence about one version at one point in time. A foundation's security policy and release process are evidence about how future fixes will be handled. A sponsorship badge on its own tells you little.

How to check whether your critical dependencies are funded or audited

This walkthrough turns the agency's own idea of "vulnerability" (important work that nobody pays for) into a review you can run on your dependency tree. It uses only free, public data. Nothing here modifies the projects you look at.

Step 1: Build an inventory of what you actually ship

Start with an SBOM or a full dependency listing from your package manager.

# Node.js: full resolved tree as JSON
npm ls --all --json > deps-npm.json

# Python: what is installed in the build environment
python -m pip list --format=json > deps-pip.json

# Java with Maven: resolved dependency tree
mvn dependency:tree -DoutputType=text -DoutputFile=deps-maven.txt

# Go modules
go list -m -json all > deps-go.json

If you use Safeguard, the CLI produces the same inventory as an SBOM and matches it against vulnerability data in one step:

safeguard scan --dir .
# results are written as JSON under ./output

Step 2: Pick the dependencies that matter most

Shortlist components that score high on the agency's first two criteria, applied to your own system:

• Prevalence in your estate. Components present in many of your services, or at the base of your images.
• Relevance to your risk. Components that parse untrusted input, handle cryptography, run at build time, or sit on the network edge.

A list of 10 to 30 components is a reasonable first pass for most organisations.

Step 3: Find each component's source repository

Package names do not always match repository names. The Open Source Insights API (deps.dev) returns, for each package version, the links the package declares, including its source repository. For Log4j core:

# Source repository and other links declared by one version
curl -s "https://api.deps.dev/v3/systems/maven/packages/org.apache.logging.log4j%3Alog4j-core/versions/2.24.3" \
  | jq -r '.links[] | .label + "  " + .url'

# The five most recently published versions, as a rough view of release cadence
curl -s "https://api.deps.dev/v3/systems/maven/packages/org.apache.logging.log4j%3Alog4j-core" \
  | jq -r '.versions | sort_by(.publishedAt) | .[-5:][] | .versionKey.version + "  " + .publishedAt'

The API marks these repository links as unverified metadata, so confirm the repository on the project's own site before you rely on it.

Step 4: Check security practices with OpenSSF Scorecard

OpenSSF Scorecard, which the Sovereign Tech Fund itself funds, rates repositories on checks such as security policy, maintenance, fuzzing, pinned dependencies, signed releases and dangerous workflows. Its public API returns the latest results for many popular repositories:

curl -s https://api.securityscorecards.dev/projects/github.com/curl/curl \
  | jq -r '.date, .score, (.checks[] | "\(.name): \(.score)")'

When we ran this on 24 October 2026, curl scored 9 overall, with 10 for Maintained, Security-Policy, Fuzzing and Vulnerabilities, and 8 for Signed-Releases. A score of -1 means the check could not be evaluated, not that it failed. Use the individual checks rather than the headline number; a project can score well overall and still have no signed releases, which may matter more to you than anything else on the list.

To run Scorecard yourself on a repository the API does not cover, the project's site documents a command line tool and a GitHub Action; the command line needs a GitHub personal access token with public_repo scope.

Step 5: Read the project's security policy

A security policy tells you how vulnerabilities are reported and how quickly fixes ship. For GitHub hosted projects:

# Look for a SECURITY.md in the usual locations
for p in SECURITY.md .github/SECURITY.md docs/SECURITY.md; do
  gh api "repos/curl/curl/contents/$p" --jq '.html_url' 2>/dev/null && break
done

# Check whether private vulnerability reporting is enabled (requires appropriate access)
gh api repos/curl/curl/private-vulnerability-reporting --jq '.enabled' 2>/dev/null

Note who handles reports, whether there is a disclosure timeline and which versions receive fixes. A policy that supports only the latest release changes how fast you must upgrade.

Step 6: Check public funding and audits

Now check the public record:

• Sovereign Tech Agency portfolio. Open sovereign.tech/tech and search for the component. Each entry shows status, amount, years and, for older entries, what the money paid for. Status "Past" means the contract ended.
• Alpha-Omega grant recipients. Its site lists grant recipients and publishes monthly reports from funded projects.
• The project's own site. Many projects publish audit reports in a security or documentation section, often with a list of findings and the versions in which they were fixed.
• The project's foundation. Foundation hosted projects may publish security policies, CNA status and release rules.

A quick scripted check against the agency portfolio page:

curl -s https://www.sovereign.tech/tech | grep -o 'sovereign.tech/tech/[a-z0-9-]*' | sort -u > sta-portfolio.txt
grep -i -E 'curl|openssh|maven|log4j|package-url' sta-portfolio.txt

Treat a match as a lead and read the entry; a portfolio listing tells you work was commissioned, not that it is finished or that every issue in your version is fixed.

Step 7: Map audit findings to the versions you run

An audit report is about a specific version or commit. Find the fixed version for each finding and compare it with what your lockfile resolves. If an audit found and fixed 17 issues in a release you have not adopted yet, you carry all 17. This is the step most teams skip, and it is where public money actually reaches your risk.

Step 8: Record a funding and maintenance signal for each component

For each shortlisted component, write down:

This record is also useful evidence for CRA due diligence on components you integrate.

Step 9: Decide where to contribute

The last column, the funding gap, is where your own money or engineering time does the most good. Use this decision table:

Common mistakes

• Treating "funded" as "safe". Funding buys capacity for defined work over a defined period. It says nothing about whether your pinned version includes the fixes.
• Reading an old portfolio entry as current support. The agency marks entries as current or past. A 2022 contract is history, not a guarantee.
• Citing the wrong funder. Older agency pages name BMWK; the current FAQ names the digital ministry. Check the date of whatever you cite.
• Saying the agency only pays for maintenance. Its Fund page says development is the primary focus. It excludes prototypes and end user apps, not new features in foundational code.
• Assuming the agency is a CRA steward for the projects it funds. It is a funder that helps projects prepare. The steward role applies to legal persons that support the project's development on a sustained basis.
• Expecting an EU fund to be open for applications. The European Sovereign Tech Fund is a pilot under the Digital Commons EDIC. Check for an official programme page before planning around it.
• Counting bounty submissions as fixed bugs. More than 790 submissions produced more than 80 rewarded reports. The rest were duplicates, out of scope or not valid, and the platform paused new reports to clear a backlog.
• Skipping your own inventory. Without an SBOM you cannot tell which funded or audited components you run, or in which versions.
• Ignoring the people. The Fellowship and Standards programmes exist because the bottleneck is often a person, not a codebase. A dependency with one exhausted maintainer is a risk even if its code is clean today.

FAQ

What is the Sovereign Tech Agency?

It is a German public agency that funds maintenance, development and security work on foundational open source software, such as libraries, package managers, protocol implementations, developer tools and cryptography. It is financed by the Federal Ministry for Digital Transformation and Government Modernisation and is a subsidiary of SPRIND.

Is the Sovereign Tech Fund the same as the Sovereign Tech Agency?

Not any more. The Fund started in 2022. Since 4 November 2024 the Sovereign Tech Agency has housed the Fund and the other programmes, and the Fund remains its main programme for direct investment. The current FAQ names the Federal Ministry for Digital Transformation and Government Modernisation as funder; earlier pages named BMWK.

Can projects outside Germany get Sovereign Tech Agency funding?

Yes. The FAQ says the agency works with people, companies and FOSS communities everywhere, because the communities behind foundational technologies are distributed worldwide. The Standards programme also states it is open to maintainers worldwide, with payments in euros.

How much money does the Sovereign Tech Fund give?

The Fund's current minimum is work costing more than 50,000 euros. Portfolio entries we checked range from 195,000 euros (curl, 2022 and 2023) to 600,000 euros (Apache Maven, 2024 to 2026). The agency reports over 60 million euros across all programmes in its first five years.

How do I apply to the Sovereign Tech Fund?

Through the online application platform only, in German or English. Check the six criteria first (prevalence, relevance, vulnerability, public interest, activities and expertise) because the agency says it cannot advise applicants before they submit. Expect up to 10 weeks for the first response and about six months to a contract.

What is Sovereign Tech Resilience?

It is the agency's security programme, formerly the Bug Resilience Program. It provides services at no cost to projects: technical debt work, security audits, bug and fix bounties and, since September 2026, help with memory safety, post-quantum cryptography, supply chain security and CRA compliance.

Does Sovereign Tech Agency funding make a dependency secure?

No. It makes defined work possible, such as an audit, a faster release pipeline or fuzzing. You still need to know which version you run, upgrade to versions that contain the fixes and keep checking for new vulnerabilities.

How is the Sovereign Tech Agency different from Alpha-Omega?

The agency is funded by the German state and weighs public interest and funding gaps across maintenance, people and standards. Alpha-Omega, according to its site, is backed by large technology companies, has an annual budget of over 7 million US dollars and focuses specifically on security improvements, with grants decided in 12 week seasonal cycles.

Is there an EU version of the Sovereign Tech Fund?

Not yet as a running programme. The agency says it is working with the Digital Commons EDIC, a consortium founded by France, Germany, Italy and the Netherlands, on a pilot for a European Sovereign Tech Fund.

Where Safeguard fits

Safeguard does not fund open source projects, and nothing in this guide depends on Safeguard. The fit is on the consumer side of the problem. Public money improves the components; your organisation still has to know which components and versions it ships and keep them current. Safeguard scans repositories, container images and SBOM files, matches components against vulnerability databases, shows which of your projects contain a given component and version, and uses reachability analysis to rank what to fix first. Policies and gates in the platform can stop a known vulnerable version from shipping. That is the part of the funding walkthrough above (steps 1, 2 and 7) that you can automate. Safeguard does not track which projects are funded or audited, and it does not replace reading a project's security policy or audit report.

Public funding makes upstream fixes more likely and faster, but a fix only lowers your risk once it runs in your builds, and closing the gap between an upstream release and your production deployment is your job. When an audit or bounty finds an issue in a component that nobody is funded to fix yet, you also need options for the time before any upstream fix exists.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This demo shows a real Safeguard CLI session: the assistant reads a finding and its advisory, asks before each command, upgrades lodash to 4.17.21, runs the install and tests with your approval, and pushes nothing. The same flow is how you would adopt the fixed release that a funded audit or bounty produced upstream, one approved step at a time.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. It is a quick way to produce the dependency inventory that step 1 of the walkthrough needs.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, Claude can query your Safeguard projects and findings, which helps when you need to find every project that still carries an old version of an audited library.

Click through it at your own pace, or open it full screen.

You can download Safeguard or read the CLI documentation to try it on your own repositories.

Quick check

Sources

• Sovereign Tech Agency: home page and programme overview
• Sovereign Tech Agency: About
• Sovereign Tech Agency: Frequently Asked Questions
• Sovereign Tech Fund programme page
• Sovereign Tech Resilience programme page
• Sovereign Tech Fellowship programme page
• Sovereign Tech Standards programme page
• Sovereign Tech Challenge programme page
• Sovereign Tech Agency: technologies portfolio
• Portfolio entry: curl
• Portfolio entry: OpenSSH
• Portfolio entry: Apache Log4j
• Portfolio entry: Apache Maven
• Portfolio entry: Package URL
• Portfolio entry: OpenSSF Scorecard
• Sovereign Tech Agency: Our First Year (18 October 2023)
• Sovereign Tech Agency: The Sovereign Tech Fund is becoming permanent and an independent organization (21 November 2023)
• Sovereign Tech Agency: The Sovereign Tech Fund, part of the new Sovereign Tech Agency (4 November 2024)
• Sovereign Tech Agency: Open, Resilient, European, the EDIC Digital Commons (29 October 2025)
• Sovereign Tech Agency: Sovereign Tech Resilience relaunches with four new services (28 September 2026)
• Sovereign Tech Agency: Celebrating five years of strengthening open digital infrastructure (13 October 2026)
• Sovereign Tech Agency: PHP2Shell exposes the funding gap in open-source security (23 October 2026)
• Sovereign Tech Agency: news archive
• SPRIND, Federal Agency for Breakthrough Innovation
• Alpha-Omega: home page
• Alpha-Omega: How to Apply
• European Commission: Cyber Resilience Act and open source
• OpenSSF Scorecard
• OpenSSF Scorecard public API result for curl
• Open Source Insights API (deps.dev) package endpoint for log4j-core

Last reviewed: 24 October 2026. The Sovereign Tech Agency updates its programme pages, criteria and portfolio regularly; check the current page and its date before relying on a specific rule, amount or deadline.