A FUNDING.yml file tells you a project has set up ways for people to give it money. It does not tell you how much arrives, who receives it, or whether the project is healthy. Treat it as a weak signal that maintainers want support, and pair it with activity and ownership checks.
What the file is
GitHub lets maintainers add a FUNDING.yml file in the repository's .github folder on the default branch. It powers the sponsor button. GitHub's documentation says a project can list one organization and up to four sponsored developers in GitHub Sponsors, one username or project per external platform, and up to four custom URLs.
Supported platforms in the documentation include GitHub Sponsors, Open Collective, Liberapay, Ko-fi, Patreon, Tidelift, Polar, thanks.dev, Buy Me a Coffee, IssueHunt and LFX Mentorship. For Tidelift the syntax uses the registry name and package name, for example npm, pypi, rubygems, maven, packagist or nuget.
What you can infer
| What you see | Reasonable reading | Not proven |
|---|---|---|
| File exists | Maintainers accept support | That any money is received |
| Organization listed | Funding may go to a group | How it is shared |
| Several individuals listed | More than one person is involved | That all are active |
| Only a custom link | Funding route is off platform | Anything about scale |
| No file | Nothing declared | That the project is unfunded |
GitHub also notes that funding links are meant for direct support of open source projects, not advertising or other causes.
Why it matters for risk
Maintainer time is the scarce input behind security fixes. The Open Source Guides list "not enough time or resources" among causes of maintainer burnout, and quote maintainers who want financial support so they can do the work without draining savings. That connects funding to continuity. For more on that link, see open source funding models and security.
A funding file is therefore one of several continuity signals, next to a second maintainer, recent releases and a security contact.
What to do with the signal
- Add funding status to your dependency review as a note, not a score.
- List the dependencies that carry the most of your product, then check whether any has a funding route.
- If your company depends on a project with an open funding route, decide whether to support it. See spend sponsorship money on security.
- If there is no route, consider offering help other than money: see how to help maintainers without money.
- Never read a funded project as a safe project. Check advisories and releases too.
A caution on interpretation
Funding platforms differ, and the file does not show amounts. A project can be well supported with no file, or listed on a platform with little income. Use the file to start a conversation, not to end one. Safeguard can help with the inventory part. Its SBOM and dependency scanning lists what your projects actually pull in, so you can see which components you depend on and decide where to look closer. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a sponsor button mean the project is well funded?
No. It shows a funding route exists, not how much money is received.
Where does GitHub look for the file?
In a FUNDING.yml file in the repository's .github folder on the default branch.
Sources
- Displaying a sponsor button in your repository, GitHub Docs
- Maintaining Balance for Open Source Maintainers, Open Source Guides
Last reviewed: 19 October 2026.
