Socket's company blog reports on malicious packages and supply chain attacks across npm, PyPI, Go and other open source ecosystems.
HN links it for reports on compromised npm, Go and Trivy packages; the founder comments on attack details, and others share its tools.
you are not alone... https://socket.dev/blog/curl-project-and-go-security-teams-reject-cvss-as-broken
I believe there must be some "Murphy's law" or something with a name for that situation. When there is an established system and process there will be people geniunely using and it will work 100% for such people and bring value to all parties. And then there will be people "gaming the system" (for instance "security" "researchers" using CVE created by them as a personal or corporate KPI) and abusing other legitimate players. It is like patent trolls but better fortunately for us.
Fortunately for all people of reason, the system itself gets patched. Maybe not in the best way possible but still. Two examples:
- Openvex - this is my way as a project owner/developer/maintainer to declare that CVE-XXXX-YYYYY is false positive and why.
- context-aware vulnerability scanning (or exploitability scanning) - govulncheck is a great example of that. You run and it says, module X has vulnerabilities Y and Z but you keep calm because we have not found any symbols in your codebase using it.
I wish more scanners would adopt the second approach and projects like npm would greatly benefit from it. As you truly note you pick a random project and it will be 50% filled with ReDos or something that will be sitting in some nested dependency of eslint's dep tree that will never see the light of production environment's CPU.
That being said, any vulnerability reporting and obtaining a CVE ID…
This attack is pretty bad, but as shown by the tiny ROI for the attacker mentioned in this article (about $500 so far: https://intel.arkm.com/explorer/entity/61fbc095-f19b-479d-a037-5469aba332ab) this really isn't quite as ecosystem-catastrophic as it sounds, for a few reasons:
* Major attacks on large packages like this are caught fairly quickly - a few hours in this case - making the vulnerable window _relatively_ small.
* NPM locks installed dependencies by default, against both the version & a hash of the content, so you'll only install the new malicious version if you happen to be adding or updating this dependency specifically within the window this version is still live. It's effectively sort-of TOFU. If even you ran `npm install` in a project already using this dependency in the specific window it was live, you will not normally install the malicious version.
* There's quite a few tools to help mitigate the risk here, like https://socket.dev and npq (https://github.com/lirantal/npq).
As one datapoint, look at the download stats for the affected Chalk package for example (https://www.npmjs.com/package/chalk?activeTab=versions) - the vast majority of installs were not installing the latest version anyway.
There are caveats to this: e.g. you can use npm without a lockfile, in which case a fresh local install can pull down unexpected versions, or you could be manually updating/adding a different package which happens to depend on an affected package (which might…
In agreement with frodd above.
Dependencies and supply chain attacks are probably the greatest risk to a lot of software orgs, as they run them across all their environments: Development (with secrets and other valuable artefacts on developer VMs), CI/CD pipelines which may have access tokens to production (and other) environments, and production itself.
Notably even security companies are being impacted by this[0]. The scale of these attacks has amplified quite significantly the past three years, but are not solely exclusive to the javascript ecosystem [1] or even just namesquatting/typosquatting [2].
The resolution is broader security awareness, "onion layered" security controls and implementing simple non-burden inducing processes and policies. Sometimes not updating (what was wrong with the previous version of a dependency if there was no immediate vulnerability or production issue caused by it?) or having a two week cool down for updates (which some supply chain tooling natively supports) can appease some security functions through clear communication of the supply chain risk etc.
If anyone has interest in courses aligned to your org on improving developer and broader engineering management awareness on this, e-mails in my profile :).
[0] - https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
[1] - https://orca.security/resources/blog/hades-pypi-supply-chain-attack/
[2] -…
1. We are in beta right now! We have the data and analysis, and are working hard to make it easy to integrate project specific views into it.
2. https://socket.dev/roadmap See https://socket.dev/npm/issue for analysis we have developed on a per-package basis. We are working on integrating these with our GitHub App to provide custom tailored project views into this data. More info here https://socket.dev/blog/inside-node-modules
3. It will be a paid product, but is free while it is in beta. We plan on keeping it free for open source.
We are looking into providing support for the Deno ecosystem down the road as well. The capabilities stuff they have is super great, but you lose all of that benefit for every dependency as soon as you turn it off, so we think there is probably room for this kind of analysis there. Hopefully Socket can provide a similar signal that --allow-net provides, but for all of npm!
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
These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev or https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses.
Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well.
Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here.
> The responsibility lies with