3 ms·
There’s no way that’s true. Last I checked there were 16M packages in npm, not counting versions. If we bump that up to 20M and add a multiple of 30 to account
by elcerebro 3y ago
There’s no way that’s true. Last I checked there were 16M packages in npm, not counting versions. If we bump that up to 20M and add a multiple of 30 to account for versions, we get 60M total tar.gz files we’d need to scan.
At a total cost of $1B that would put scanning a single package at $16/package? Nonsense. Even at $1 in compute time on aws that feels outlandishly high…
You can’t retroactively scan the package Socket missed. It was removed from npm. Scanning on demand means you’re going to miss critical relationships across threat groups, or across disparate but related packages.
- ianpenney 3y agoRetroactive scanning, you have a point. Integrating the scan into your CI/CD would catch it. As for the numbers: see 39 mins into https://youtu.be/jWujI7Hk8O4 https://youtu.be/jWujI7Hk8O4 I used to work at npm as the SRE manager right before the acquisition and the ballpark figures make sense to me.
- elcerebro 3y agoI admittedly pulled the numbers out of thin air, and things I thought I’d seen before. Had a second to sit down, and I _way_ overestimated my counts. Per NPM there are 2,480,373 packages. According to Whitesource [1] there are an average of 12.3 versions per package. This gives us a total of 30,508,587.9 archives to scan. At a cost of $1B to scan that means each package would cost $33.959… There’s no way that’s reality. That seems like several orders of magnitude too high. 1. https://threatpost.com/malicious-npm-packages-web-apps/178137/ https://threatpost.com/malicious-npm-packages-web-apps/17813...