On GitHub, look for the Sponsor button on the repository page. It appears when the maintainers add a FUNDING.yml file to the .github folder on the default branch. That file can list sponsored developers, an organisation, external funding platforms and custom links, so it is the quickest way to see whether a dependency accepts support.
Where the information lives
GitHub's documentation explains that a repository can display a sponsor button to increase the visibility of funding options. The button is configured by editing a FUNDING.yml file in the repository's .github folder, on the default branch. It can include sponsored developers in GitHub Sponsors, external funding platforms or a custom funding URL.
What the file allows
The documentation sets limits that tell you how to read it.
| Item | Limit stated |
|---|---|
| External platform entries | One username, package name or project name per platform |
| Custom URLs | Up to four |
| GitHub Sponsors | One organisation and up to four sponsored developers |
The file lists each platform on a new line with a simple key and value syntax. Because of the limits, a project with several funding routes may show only the main ones, so also read the README and the project website.
Why funding is a risk question
A project with no funding route is not necessarily at risk, and a project with one is not necessarily safe. But funding sustains maintenance, and maintenance is what you rely on when an advisory arrives. A routine check of how your dependencies can be supported belongs next to checks of how they handle security reports.
Open Source Guides notes that there are many resources for maintainers who want support, and suggests turning on GitHub Sponsors as a first step. Seeing that route in use tells you the maintainers expect to receive support.
Steps for a team
- List your ten most critical open source dependencies by how hard they would be to replace.
- For each, open the repository and look for the Sponsor button.
- Read the FUNDING.yml file and the README for other routes.
- Record who in your company could approve a payment, and from which budget.
- Decide what you want in return: nothing, a named thank you, or a conversation about support. Be clear it is not a purchase of fixes unless a written agreement says so.
- Follow up each year, since links change.
For maintainers
Add a FUNDING.yml even if you are not sure anyone will use it. Keep one link per platform and use the custom link for a page that explains how money is used. If you publish a security policy, link it from the same README so users find both together.
Quick check
Where must FUNDING.yml be?
In the .github folder of the repository, on the default branch.
Does sponsoring a project buy priority fixes?
Not by default. Only a written agreement can promise that, so read any terms.
What if there is no sponsor button?
Check the README and website, or ask the maintainers politely how they accept support.
How Safeguard helps
Safeguard's SBOM and dependency scanning show which upstream versions you depend on, and reachability analysis helps you decide which advisories matter for your code. Compliance and evidence automation can record how you handled each one. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can run the free scan on a manifest to see where you stand.
Sources
- GitHub Docs, Displaying a sponsor button in your repository: FUNDING.yml location and limits. Fetched 19 October 2026.
- Open Source Guides, Maintaining Balance for Open Source Maintainers: funding resources. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
