27 September 2026·5 min read
Open-source audit checklist. How do you check whether a project is safe to use?
To check whether an open-source project is safe to use, look at six things: what the licence asks of you, who pays the maintainers, who actually commits, which paid services it depends on, where your data goes, and how quickly security fixes land. A star count answers none of them.
Check what the licence asks of you, what you'll still pay for, where your documents go, and who fixes it when it breaks. Most of that is sitting in four files: the licence, the security policy, the environment template and the commit history. The part that's usually missing is who pays for the work. When nobody says, treat it as unknown.
The question comes up every time a free alternative to a paid tool gets popular. "Free" and "open source" tend to get used as if they settle it. They describe the price and the licence, and nothing else.
Here are the six checks, in the order we'd do them.
- The licence. Open
LICENSE. MIT and Apache-2.0 let you modify and ship the code with few obligations beyond keeping the notice. AGPL-3.0 asks more: if you modify the code and let other people use your version over a network, you have to offer them your modified source. That's no problem for an internal tool. It matters a lot if you plan to sell a product built on it. - Who pays the maintainers. Look for
.github/FUNDING.yml, a sponsors page, a company behind the GitHub organisation, or a paid hosted version. A company can steer the roadmap towards what it sells. If nobody is paying, the work continues only as long as the maintainers choose to do it unpaid. - Who actually commits. Stars measure attention. The commit history shows who does the work, how many people are involved and how recently. Read the security policy or maintainers file as well, because the people who send commits and the people responsible for merging and fixing aren't always the same list.
- Which closed services it depends on. Read
.env.example. Every API key it asks for is a service you either pay for or can't run yourself. A project can be fully open source and still do nothing without a paid API behind it. - Where your data goes. Follow each outbound call: model providers, error reporting, analytics, third-party lookups. Check whether telemetry is on by default and which setting turns it off.
- How fast security fixes land. Read
SECURITY.md, the published advisories and the patch history. You're looking for how reports are handled, which versions receive fixes, and how long past findings took to close.
What do good and bad answers look like?
None of this tells you whether the code is any good. That's a code review, and it's a separate job. What the checklist tells you is what you're signing up for: the obligations you take on, the services you still pay for, where documents travel, and who is on the hook when something breaks.
The order is flexible, with one exception. If the project will handle client files or anyone's personal data, do checks five and six first, because those are the failures that cost you. For a weekend experiment on your own laptop, the licence is the only check likely to catch up with you later, and only if the experiment turns into a product.
What if there's no code to read?
The part we're least sure how to judge is check two. A solo maintainer with no funding can still run a careful project, and a company behind one brings money along with its own priorities. So which do you trust more: a project with a company behind it, or one with nobody paying and a clear security policy? If there's a project you're about to rely on, send us the repo and say what you'd use it for.
Reply on X.
Branch A: What do good and bad answers look like?
One row per check. A red flag isn't automatically a veto. It tells you what you're taking on, and whether that's acceptable depends on what you plan to use the project for.
| Check | Green flag | Red flag |
|---|---|---|
| Licence | A standard licence in LICENSE, and you can say what it asks of you | No licence file, a custom licence, or "source available" terms that restrict commercial use |
| Who pays | Funding is stated: a company, sponsors, a foundation or a paid hosted version | Nobody says, or features keep moving from the free version to a paid tier |
| Who commits | Several people commit and review, with activity in recent months | One account does everything, or pull requests sit unanswered for months |
| Closed services | Paid services are optional or swappable, and a local alternative is documented | Core features only work with one vendor's API or a hosted database you can't run yourself |
| Your data | Every outbound call is documented, and telemetry is off or has a named setting to turn it off | Telemetry nobody mentions, found only by watching network traffic |
| Security fixes | A SECURITY.md with a private reporting channel, a stated response time and published advisories | No policy, vulnerabilities discussed in public issues, or old reports left unanswered |
A missing licence file is worth a special mention. It doesn't mean the code is free to use. Without a licence, the author keeps all rights by default, so you have no permission to copy, modify or distribute it.
Branch B: What if there's no code to read?
For a hosted API or a closed model, you can't open LICENSE or the commit history. Most of the checks still apply, but you answer them from different documents.
- Licence becomes the terms of service. Look for what you're allowed to build, who owns the output, and how much notice they give before changing the terms.
- Who pays is usually you. The question becomes whether the price is published and whether a free tier has an end date.
- Who commits becomes the changelog and the status page. They show how often the product ships and how honestly outages get reported.
- Closed services now describes the whole product. What matters is how hard it would be to leave: data export, and whether the API follows a format other providers also support.
- Your data is the check that matters most. Read the data policy for retention, whether your inputs are used for training, and how to opt out.
- Security fixes moves to the trust or security page, the security contact and the incident history.
Open-weight models sit in between. The weights run on your own hardware, so nothing leaves your machine unless the software running them sends it somewhere, and that software is its own project to check. Read the model licence closely too, because some "open" model licences restrict commercial use or large deployments.