Show HN: CLI that spots fake GitHub stars, risky dependencies and licence traps
I wrote StarGuard to put that number in perspective based on my own methodology inspired with what they did and to fold a broader supply-chain check into one command-line run.
It starts with the simplest raw input: every starred_at timestamp GitHub will give. It applies a median-absolute-deviation test to locate sudden bursts. For each spike, StarGuard pulls a random sample of the accounts behind it and asks: how old is the user? Any followers? Any contribution history? Still using the default avatar? From that, it computes a Fake Star Index, between 0 (organic) and 1 (fully synthetic).
But inflated stars are just one issue. In parallel, StarGuard parses dependency manifests or SBOMs and flags common risk signs: unpinned versions, direct Git URLs, lookalike package names. It also scans licences—AGPL sneaking into a repo claiming MIT, or other inconsistencies that can turn into compliance headaches.
It checks contributor patterns too. If 90% of commits come from one person who hasn’t pushed in months, that’s flagged. It skims for obvious code red flags: eval calls, minified blobs, sketchy install scripts—because sometimes the problem is hiding in plain sight.
All of this feeds into a weighted scoring model. The final Trust Score (0–100) reflects repo health at a glance, with direct penalties for fake-star behaviour, so a pretty README badge can’t hide inorganic hype.
I added for the fun of it it generating a cool little badge for the trust score lol.
Under the hood, its all uses, heuristics, and a lot of GitHub API paging. Run it on any public repo with:
python starguard.py owner/repo --format markdown It works without a token, but you’ll hit rate limits sooner.
Please provide any feedback you can.
IMO this is a slight green flag; not red.
Heuristics are never perfect and it's all iterative but it's all about understanding the underlying assumptions and taking the knowledge you get out of it with your own context. Probably could enhance it slightly by a run through an LLM with a prompt but I prefer to keep things purely statistical for now.
You could etch that thing into granite as far as I can tell. The only thing left to do is rewrite it in Rust.
> CTOs, security teams, and VCs automate open-source due diligence in seconds.
The people that probably have less brain cells than the average programmer to understand the nuance in the flagging.
It's a shame that this tool penalizes such projects, which I think are vital to a healthy open source ecosystem.
It's a nice project otherwise. But flagging stable projects from solo developers really sticks out like a sore thumb. :(
Of course, the problem with that is the adversary could easily simulate the same effect by mixing together some fall-off functions and a bit of randomness.
1. Fork to stars ratio. I've noticed that several of the "bot" repos have the same number of forks as stars (or rather, most ratios are above 0.5). Typically a project doesn't have nearly as many forks as stars.
2. Fake repo owners clone real projects and push them directly to their account (not fork) and impersonate the real project to try and make their account look real.
Example bot account with both strategies employed: https://github.com/algariis
This is nuts to me. A star is a "like". It has carries no signal of quality and even its popularity proxy is quite weak. I can't remember the last time I looked at stars and considered them meaningful.
This looks like a cool project, but why on earth would it need Python, Java, Go, AND Ruby?
It does seem like the repo is missing some files though; make is mentioned in the README but no makefile and no list of python dependencies for the script that I can see.
> Dependencies | SBOM / manifest parsing across npm, PyPI, Maven, Go, Ruby; flags unpinned, shadow, or non-registry deps.
The project seems like it only requires Python >= 3.9!
1. there are hallucinatory descriptions in the Readme (make test), and also in the code, such as the rate limit set at line 158, which is the wrong number
2. all commits are done on github webui, checking the signature confirms this
3. too verbose function names and a 2000 line python file
I don't have a complaint about ai, but the code quality clearly needs improvement, the license only lists a few common examples, the thresholds for detection seem to be set randomly, _get_stargazers_graphql the entire function is commented out and performs no action, it says "Currently bypassed by get_ stargazers", did you generate the code without even reading through it?
Bad code like this gets over 100stars, it seems like you're doing a satirical fake-star performance art.
You would assume if it was pure ai generated it would have the correct rate limit in the comments and the code .... but honestly I don't care and yeah I ran the read me through GPT to 'prettify it'. Arrest me.
I know it's the age of ai, but one should do a little checking oneself before posting ai generated content, right? Or at least one should know how to use git and write meaningful commit messages?
do you want a world where people can randomly sue you for any random damages they suffer or do you want nice things like free code hosting?
Isn't that already a thing, but in the US, not the entire world.
the /ee folders are a disgrace
Or users could ignore the stars and go old school and you know, research their dependencies before they rely on them.
lol
found a couple non-maintained projects for managing them
https://github.com/astralapp/astral https://github.com/gkze/gh-stars
I check the docs, features, and sometimes the code quality. Sometimes I check the date of the last commit.
I never even noticed the stupid stars until they started being mentioned on HN.
99.99999% of my interaction is via git pull and push :)