4 ms·
One of the biggest problems here is that there is no “chain of custody” from Github source to uploaded NPM module; otherwise one of the developers using the mal
by btown 9y ago
One of the biggest problems here is that there is no “chain of custody” from Github source to uploaded NPM module; otherwise one of the developers using the malicious package could have audited the source code before including it in their own code. ‘npm publish’ would ideally insist on reproducible builds, enforce this by minifying or compiling packages itself, and finally encourage the community to always audit the code associated with a module. Of course, people are lazy, NPM has no incentive to incur that server and engineering overhead, and someone could sneak in code anyways with a minor version update... There’s no clear solution here, and I think the only thing keeping up this house of cards is that there are much easier ways for black hats to make money.
- djsumdog 9y agoEven if you had that, no one is going to inspect all that code. npm is a cluster-farkle of insane amounts of packages. The whole point of the article is you should implement CSP.
- altstar 9y agoHe actually has a work-around to CSP. He updated his post.
- deleted 9y ago[deleted]
- mulmen 9y agoSure but why not implement CSP and also get your packages from somewhere trustworthy and audit the code you actually run? Just because "most people are lazy" doesn't mean you have to be. "Audit the code you run" is still good advice right?
- asaph 9y agoIt's often impractical to audit the source code for all your 3rd party dependencies even if they are open source. When was the last time you or anyone you know reviewed every line of your web framework or DI framework? How about the dependencies of your dependencies? Many organizations don't even review all the code their developers write internally. Does your organization code review 100% of releases? Since inception? Like it or not, we're all placing a lot of trust in our dependencies.
- JonathonW 9y agoI have a fairly simple Node project at work; it pulls in nine runtime dependencies, plus 13 development-time dependencies (most of those are babel or eslint-related). Assuming none of those are pulling shenanigans like mentioned in the article (distributing different code than in their source repositories, or deliberately obfuscating malicious code), it's not completely unreasonable for me to go through and audit my direct dependencies. But, since the Javascript standard lib is crap, all of my direct dependencies have their own large pile of dependencies, which themselves depend on a bunch of stuff, and so on. By the time it's all said and done, my "simple" Node project pulls in several hundred dependencies (I didn't go through and count, but my 'yarn.lock' on that project has ~4200 lines). I can't audit all of that code. (This is particularly bad in Node and Javascript, but applies to other languages too. I don't think anyone's ever fully audited all of our Nuget dependencies, or Python dependencies... fortunately, those both tend to be more self-contained, so at least we know what we're getting there.)
- Tomte 9y ago> I have a fairly simple Node project at work; it pulls in nine runtime dependencies, plus 13 development-time dependencies (most of those are babel or eslint-related). A well known German blog just claimed that creating a new skeleton project using @angular/cli results in 31 direct dependencies, almost a thousand dependencies in total and 300 MB code. That's just wow.