←back to thread

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

(socket.dev)
1208 points jamesberthoty | 2 comments | 16 Sep 25 11:22 UTC | HN request time: 0.42s | source
Show context
pragma_x ◴[16 Sep 25 20:37 UTC] No.45267685[source]▶
So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat.

Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and actively removes known vulnerable ones.

replies(2): >>45267827 #>>45273776 #
1. arccy ◴[17 Sep 25 09:49 UTC] No.45273776[source]▶
Google has Assured Open Source for Python / Java https://cloud.google.com/security/products/assured-open-sour...

Some other vendors do AI scanning

I doubt anyone would want to touch js packages with manual review.

replies(1): >>45278369 #
2. pragma_x ◴[17 Sep 25 16:56 UTC] No.45278369[source]▶
It would take labor, that's for sure. Manual review of everything JS is just too massive a landscape to cover. Automation is the way to go here, for sure.

I think the bare minimum is heavy use of auditjs (or Snyk, or anything else that works this way), and maybe a mandatory waiting period (2-4 weeks?) before allowing new packages in. That should help wave off the brunt of package churn and give auditjs enough time to catch up to new package vulnerabilities. The key is to not wait too long so folks can address CVE's in their software, but also not be 100% at the bleeding edge.