←back to thread

121 points artski | 1 comments | | HN request time: 0.208s | source

When I came across a study that traced 4.5 million fake GitHub stars, it confirmed a suspicion I’d had for a while: stars are noisy. The issue is they’re visible, they’re persuasive, and they still shape hiring decisions, VC term sheets, and dependency choices—but they say very little about actual quality.

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.

Show context
nottorp ◴[] No.43964044[source]
Of course, github could just drop the stars, but everything has to entshittify towards "engagement" and add social network features.

Or users could ignore the stars and go old school and you know, research their dependencies before they rely on them.

replies(2): >>43964717 #>>43965265 #
Vanclief ◴[] No.43964717[source]
Stars are just a signal. When I am looking at multiple libraries that do the same, I am going to trust more a repo with 200 starts that one with 0. Its not perfect, but I don't have the time to go through the entire codebase and try it out. If the repo works for me I will star it to contribute to the signal.
replies(3): >>43964844 #>>43965556 #>>43965696 #
tough ◴[] No.43965696[source]
I use stars for bookmarking purposes, i wouldn't care if they go private but would miss the feature
replies(1): >>43966217 #
aquariusDue ◴[] No.43966217[source]
Same along with lists. I've got more than a thousand starred repos by now.
replies(1): >>43966541 #
1. tough ◴[] No.43966541[source]
Sadly lists had a hard cap at 32 or 36 or something like that.. i was too eager early with my specificity (hav elists w 1 repo) and now i cant make new ones (need to delete others)

lol

found a couple non-maintained projects for managing them

https://github.com/astralapp/astral https://github.com/gkze/gh-stars