Guide
How to Tell if a GitHub Repo Is Safe: A Practical Checklist
Nobody reads every line of an unfamiliar project before using it. What experienced developers actually do is check a short list of signals that reliably separate a project worth trusting from one worth avoiding. This guide is that list, in the order it is worth working through.
First, decide what you are actually about to do
The honest answer to “is this repo safe?” depends entirely on what you plan to do with it. The risk is very different across these three cases:
- Reading the code. Essentially no risk. Browsing source on GitHub executes nothing.
- Running or installing it. Real risk. Install steps, build scripts, and the project’s dependencies can execute code on your machine with your user’s permissions.
- Depending on it in something you ship. Ongoing risk. You inherit not just today’s code but every future update, plus whatever its own dependencies pull in.
Set your bar accordingly. A quick experiment in a throwaway container deserves less scrutiny than a package that will sit in your production build for two years.
1. Check what runs during install
This is the highest-value check and the one most people skip. Many ecosystems allow a package to execute
scripts automatically during installation, which means code can run before you have read a single source file.
In the npm ecosystem these are lifecycle scripts such as preinstall, install, and
postinstall, documented in the
npm scripts reference.
Open the manifest and look at the scripts section before you install anything. Ask:
- Is there an install or postinstall hook at all? Most libraries do not need one.
- Does it download or execute something from a remote URL?
- Does it run a shell script, a binary, or an obfuscated one-liner?
- Does the hook make sense for what the project claims to do?
A native-code library compiling a binding during install is normal. A CSS theme fetching a script from an unfamiliar domain during install is not.
2. Read the dependency surface
You are not just trusting this project. You are trusting everything it depends on, and everything those projects depend on. A small dependency list made of well-known packages is far easier to reason about than a deep tree of unfamiliar ones.
- Open the manifest and count the direct runtime dependencies.
- Recognise the names. Unfamiliar packages doing security-sensitive work deserve a closer look.
- Watch for names that look like typos of popular packages. Typosquatting is a common way malicious code gets installed.
- Check whether a lockfile is committed, which tells you the project pins what it builds against.
If the repository has Dependabot alerts enabled and visible, that is a positive signal that the maintainers are tracking known vulnerable dependencies.
3. Confirm somebody is still maintaining it
An unmaintained project is not automatically dangerous, but nobody is going to fix its next security problem. That matters enormously if you plan to depend on it.
- Recent commits. When did meaningful work last land, not just a README tweak?
- Releases. Is there a tagged release history, or has nothing shipped in years?
- Issue behaviour. Do maintainers reply, or do issues sit untouched?
- Archived status. GitHub lets maintainers archive a repository, marking it read-only. An archived project is at least honest about being finished; a quietly inactive one is the more misleading of the two.
Ignore the star count here. Stars measure attention the project received at some point, not whether anyone is looking after it now.
4. Check the licence before you rely on it
A licence is a usage question rather than a malware question, but getting it wrong can be the more expensive mistake. Code published without a licence is not automatically free to use: as Choose a License explains, default copyright rules mean nobody has permission to use, copy, or modify it.
- Is there a
LICENSEfile, and does it match what the README claims? - Does the licence permit commercial use if that is your plan?
- Does it impose obligations, such as sharing your own source, that conflict with how you intend to ship?
5. Look for deliberate security practice
Well-run projects leave visible evidence that security is something they think about:
-
A
SECURITY.mdfile or published security advisories, showing there is a way to report problems responsibly. - A test suite, and CI that actually runs it on pull requests.
- Code review visible in the pull request history rather than everything pushed straight to the main branch.
- For a deeper automated view, the OpenSSF Scorecard project scores repositories against a set of security heuristics.
6. Sanity-check the account behind it
Accounts are cheap to create, so treat this as weak supporting evidence rather than proof. Still, a brand new account with no other activity, publishing a package that impersonates a well-known tool, is a meaningful warning. Look at account age, other repositories, and whether the project is referenced anywhere outside its own README.
Red flags worth stopping on
Any one of these justifies slowing down and looking harder:
- Install-time scripts that fetch and execute remote code.
- Obfuscated, minified, or base64-encoded source in a project that has no reason to ship it.
- A name that closely imitates a popular package.
- Binaries committed to the repository with no build process that explains them.
- Code that reads environment variables, tokens, or SSH keys without a functional reason.
- A README promising far more than the code plausibly implements.
- Disabled issues combined with no contact route, so problems cannot be reported.
What a quick check cannot prove
Every check above raises or lowers your confidence. None of them proves a repository is safe, and it is worth being clear about the limits:
- Clean metadata does not mean clean code. Malicious logic can hide in a project that looks tidy.
- Today’s safe version does not guarantee tomorrow’s. Maintainer accounts get compromised and ownership changes hands.
- Signals are heuristics, not verdicts. They tell you where to look, not what is true.
When the stakes are high, there is no substitute for reading the code that runs, pinning exact versions, and testing in an isolated environment first.
The short version
If you only have two minutes, do these five things:
- Read the install and build scripts in the manifest.
- Skim the direct dependencies for unfamiliar or typosquatted names.
- Check the date of the last real commit and whether issues get answers.
- Confirm a licence exists and permits your use.
- Run it in a container or throwaway environment the first time.
Common questions
How do I know if a GitHub repo is safe?
There is no single check that proves a repository is safe. Review what runs during install, how large and current the dependency list is, whether the project is actively maintained, whether the licence permits your use, and whether the code does anything unexpected with the network, the filesystem, or credentials.
Are popular GitHub repos safe by default?
No. Star counts measure past attention, not current safety or upkeep. A widely starred project can be unmaintained, and a small project can be well run. Judge current activity and the code itself rather than popularity.
Is it safe to download code from GitHub?
Downloading and reading source code is low risk. Risk appears when you install, build, or run it, because those steps can execute code from the project and its dependencies on your machine. Review the install path before running anything.
SourceBrief can speed up the first pass by surfacing these public signals in one place, but it does not run a security audit and does not execute repository code. Treat it as a way to decide where to look, and keep the judgement yourself.
Trying to work out what the project actually does? Read how to understand a GitHub repository fast.