Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do you security-audit external software using NPM packages?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Ask HN: How do you security-audit external software using NPM packages?

#71

Post by laurent123456 »

TekMol wrote: post #3

Independent of the language, I only use external code if it is small enough that I can manually review it. Often I refactor it into a single file during this process. This of course excludes the majority of packages out there. But apart from security, it has another benefit: These dependency very rarely break and need updates. So compared to projects with a more complex stack, projects with a lean stack are easier to…

I think a developer who does that is doing a disservice to the company they are working for. If I start looking at a project and see a bunch of outdated packages that have been copied and pasted there and tweaked who knows how, I quit right away. Not to mention that these packages most likely have various unpatched security issues.

And if the package is not "small enough", I guess it means it needs to be re-implemented from scratch? If a company is happy to pay you for that (and is aware of it), why not, it's fun actually, but not very productive.

Re: Ask HN: How do you security-audit external software using NPM packages?

#72

Post by BjornW »

TheRealBrianF wrote: post #69

Sonatype Lifecycle is designed to analyze a built package and figure out what's inside it, specifically when there aren't manifest files to tell you what's -supposed- to be there. It can obviously do a lot more, but the analysis is designed to solve the exact problem you're describing. https://blog.sonatype.com/mapping-the-javascript-genome-for-...

Will have a look at this. Thanks for sharing.

Re: Ask HN: How do you security-audit external software using NPM packages?

#73

Post by dncornholio »

PeterisP wrote: post #62
dncornholio wrote: post #58

Earlier quoted context omitted.

How is this different from any other programming language that has dependencies?

A quantitative difference - in other programming languages you usually use a very limited number of dependencies, and the organization can follow every individual dependency that's used in production, knowing which versions you are using and tracking and monitoring their releases/notifications/changelogs as part of their software inventory. Like, a random quite large project that I recall had 10 dependencies from thr…

Sure but this problem is not mutually exclusive to npm.

Python has pip, Rust has crates, Ruby has gems..

The fact that other languages have fewer dependencies, is (imo) probably because there aren't many dependencies uberhaupt?

My argument by the way, is that many dependencies is a feature, not a bug. And the developer probably looked at you like that because he thinks you have no trust in his ability to pick dependencies..

Re: Ask HN: How do you security-audit external software using NPM packages?

#74

Post by geofft »

TekMol wrote: post #32
apples_oranges wrote: post #21

Earlier quoted context omitted.

Refactoring into a single file sounds like a bit of a pain, since you have to do it every time the external code gets updated. Also how do you deal with dependencies that come with their own dependencies? Do you avoid them?

every time the external code gets updated I do not keep my fork in sync afterwards. dependencies that come with their own dependencies Depends on the dependencies. If you give me an example, I can tell you what I would do.

This is a fantastic trick! By copying the source code (which is legal) but not declaring the dependencies in a package.json or similar, nobody will ever get on your case for CVEs in dependencies, and you can save so much time and churn by not updating them.

Re: Ask HN: How do you security-audit external software using NPM packages?

#75

Post by tompazourek »

richardwhiuk wrote: post #59
tdrdt wrote: post #46

I believe one thing that can help security a little is to use full version numbers in your dependency list. This applies to all package managers. Because the moment someone hits update on the package manager nothing will get updated and you won't receive potential dangerous updates you did not review first. Edit: sorry this is not relevant to the question...

You want to have a file specifying your dependencies, and a file specifying your currently locked set - e.g. Cargo.toml and Cargo.lock, or Gemfile and Gemfile.lock, or pyproject.toml and poetry.lock You'll then want tooling to periodically update your locked dependencies, so that you pick up fixes to security vulnerabilties. That wants to go through your CI.

This is a double edged sword.

Because on one hand, you do pick up hotfix patches, but on the other hand, you are possibly bit more exposed to supply chain attacks.

Any ideas on how to balance that out? Or should we just not consider supply chain attacks to be a real threat?

Re: Ask HN: How do you security-audit external software using NPM packages?

#77

Post by tompazourek »

orangepanda wrote: post #6

Is there really anything better than `npm audit`, even with all its faults? Any relatively popular and well tested library will pull in dozens of dependencies. $ du -hs node_modules 289M node_modules Yeah no...

npm audit reports known vulnerabilities, but I think it doesn't help against supply chain attacks, or does it?

Re: Ask HN: How do you security-audit external software using NPM packages?

#78

Post by WA »

2OEH8eoCRo0 wrote: post #66
tdrdt wrote: post #46

I believe one thing that can help security a little is to use full version numbers in your dependency list. This applies to all package managers. Because the moment someone hits update on the package manager nothing will get updated and you won't receive potential dangerous updates you did not review first. Edit: sorry this is not relevant to the question...

Full version numbers, pin your dependencies, commit dependencies to a local repo. Update them only when necessary (security patch, feature you need).

Can you elaborate? Your local repo then re-exports the dependencies to be consumed by your application or how would you do it properly?

Re: Ask HN: How do you security-audit external software using NPM packages?

#79

Post by Zababa »

dd82 wrote: post #53
TekMol wrote: post #3

Independent of the language, I only use external code if it is small enough that I can manually review it. Often I refactor it into a single file during this process. This of course excludes the majority of packages out there. But apart from security, it has another benefit: These dependency very rarely break and need updates. So compared to projects with a more complex stack, projects with a lean stack are easier to…

>It would be great if there was a "single small file packages" movement so that more lean open source software will be created. uh, no. what would be even better if TC39 did something beyond window dressing and JS gets a sane standard API so these idiotic requirements for API fill in are no longer required. These packages are required solely because JS has a crappy API and a vacuum was filled. This increases the surf…

> uh, no. what would be even better if TC39 did something beyond window dressing and JS gets a sane standard API so these idiotic requirements for API fill in are no longer required.

That would remove the most used libraries. You could make babel, express, lodash/underscore, moment and stuff like that core, sure. But then you still have people using lots of libraries, especially in the frontend world for components.

> Other languages have their own issues. But they also have saner stdlibs so the attack vectors are different.

There's also more of a culture of just writing things yourself.

Re: Ask HN: How do you security-audit external software using NPM packages?

#80

Post by PeterisP »

dncornholio wrote: post #73
PeterisP wrote: post #62

Earlier quoted context omitted.

A quantitative difference - in other programming languages you usually use a very limited number of dependencies, and the organization can follow every individual dependency that's used in production, knowing which versions you are using and tracking and monitoring their releases/notifications/changelogs as part of their software inventory. Like, a random quite large project that I recall had 10 dependencies from thr…

Sure but this problem is not mutually exclusive to npm. Python has pip, Rust has crates, Ruby has gems.. The fact that other languages have fewer dependencies, is (imo) probably because there aren't many dependencies uberhaupt? My argument by the way, is that many dependencies is a feature, not a bug. And the developer probably looked at you like that because he thinks you have no trust in his ability to pick depende…

The primary difference with other languages is not the availability of features - in general, pretty much every major language has almost all what you might need - but the differences in bundling. Many other languages have larger standard libraries, so things that might be "yet another dependency" in npm would be part of the standard distribution in other languages; and there are different approaches to bundling, as the same thing that might be dozens of dependencies in npm would be distributed and maintained as a single large package elsewhere.
Post reply on HN