Live data from Hacker News

Over 100k Infected Repos Found on GitHub

apiiro.com

71–80 of 187 posts

Re: Over 100k Infected Repos Found on GitHub

#71
This sucks. Supply chain is such an issue.

Even tho we don't currently target any npm releases, I make use of socket.dev to monitor my project by creating an npm release for it. But my project BrowserBox (lightweight virtualized web browser) only uses ~800 dependencies including all descendents, with only 19 top-level deps (cool your heels non-JavaScript folks, this is comparatively lightweight for a full stack boing).

I'm considering just snapshotting all 800 deps into a @browserbox namespace at npm. And then tracking any vulnerabilities discovered and patching the fixes.

It sounds crazy, but that's where we are. At least that way I "own" all the dependencies and can guarantee (up to company security at least) that we don't have supply chain vulns on the Node/JS side.

https://socket.dev

https://github.com/BrowserBox/BrowserBox

Re: Over 100k Infected Repos Found on GitHub

#72

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

Strong disagree. It’s not GitHub’s job to tell you what’s good or bad. Only the user of the code can do that because it’s context specific. “I can trust this code” is a fantasy that won’t happen. Don’t trust code, test it.

Re: Over 100k Infected Repos Found on GitHub

#73

As well as this being our regular reminder to be careful what you pull from public repositories and other sources, and to verify your dependency trees, it raises another question: If malware is massively prolific in public repos, how much does this affect LLMs and other automation tools that are trained using the contents of such resources? What are the chances that we'll see copilot & friends occasionally emit malwa…

I'd expect it to accidentally invent vulnerabilities of its own as well as pasting existing ones from the input set. AI provides no guarantees at all about correctness.

Re: Over 100k Infected Repos Found on GitHub

#74

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

I don't think you truly grasp how small this number is, this is actually good, like really really good. Github has about half a billion repositories.

Getting the actual number is probably very hard. These are the infected repos the OP found during their research.

Re: Over 100k Infected Repos Found on GitHub

#75

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

Comparing github to usenet feels is a reach. Github has always been filled with junk since day 1, people post the same projects, coding exercises etc. The small N% of the repos are actually the interesting ones. This is by design.

Re: Over 100k Infected Repos Found on GitHub

#76

This sucks. Supply chain is such an issue. Even tho we don't currently target any npm releases, I make use of socket.dev to monitor my project by creating an npm release for it. But my project BrowserBox (lightweight virtualized web browser) only uses ~800 dependencies including all descendents, with only 19 top-level deps (cool your heels non-JavaScript folks, this is comparatively lightweight for a full stack boing…

I'm not sure what of this is available in npm, but with crates io and cargo, there are crates like cargo audit and cargo deny that your pipeline can use to check for cve in your dependency tree. Your lock file maintains the sha256 of everything in the tree, so there is no need to mirror things to ensure they aren't modified if their repo gets hacked. Pinning a version a few months behind the newest seems to be the sweet spot that avoids new cve and avoids big chunks of rework from sitting on ancient versions then upgrading all at once. Download count seems like a decent way to gauge top level deps against others with similar purpose, but that's just my subjective opinion.

Austral uses linear types to give fine grained permissions to dependencies. A graphics library doesn't need file io, a network transport library doesn't need microphone access. That is just a mitigation, but it would be nice to see in other languages.

Re: Over 100k Infected Repos Found on GitHub

#77

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

If only there was some sort of system of named domains within which the products and services of various organizations could be located...

Re: Over 100k Infected Repos Found on GitHub

#78

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

It is possible to be a repository for junk, but harmless junk only.

Re: Over 100k Infected Repos Found on GitHub

#79
post #17

What tooling are you people using to avoid that type of issues at your workplace? And are you satisfied with your setup? We are a pretty small team developing SDKs that have a pretty large amount of weekly download. I’ve been evaluating tools such as snyk, aikido.dev, and some solutions built on top of renovate (that we already use for general dependency management), it’s not obvious if they would help with this, and…

I’ve been building an open-source tool Packj [1] to detect publicly malicious, abandoned, typo-squatting, and other "risky" PyPI/NPM/Ruby/PHP/Maven/Rust packages. It carries out static/dynamic/metadata analysis and scans for 40+ attributes such as spawning of shell, use of SSH keys, network communication, use of decode+eval, etc. to flag risky packages.

1. https://github.com/ossillate-inc/packj

Re: Over 100k Infected Repos Found on GitHub

#80

Earlier quoted context omitted.

It's worse, if you address these things seriously, like, as another post here addressed last week, about software quality, you get rapidly stopped in your tracks. Like you say and more; 'but everyone does it like this, why would we waste time?' and 'It is safe enough, maybe later we'll revisit'. It is kind of true clients don't pay for it directly, however, indirectly, it can tank a company.

Herd mentality gets a bad rap, but it generally works for the herd.

Works well on average, and remember that bad actors are also part of the overall herd. It can be very detrimental to the individual (person or company).
Post reply on HN