Live data from Hacker News

Ask HN: Does anyone investigate open source packages before using in prod?

news.ycombinator.com

21–30 of 40 posts

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#21

I am paranoid about security of all those packages, so yes, even before just downloading, I check the authors, activity and read the source code. Not always – e.g. I skip the source code if it's something big AND very reputable AND I decided that I need it such as scala/scala or facebook/react – but I do my best. It's very annoying, it's not free, and it affects what kinds of libraries I use. My projects have fewer a…

> My projects have fewer and smaller dependencies than typical

Taking a look at your at your github projects and build.sbt... this is quite an understatement.

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#23
post #20
post #16

Earlier quoted context omitted.

Do you have a pragmatic approach that you typically recommend, considering that (without version pinning thousands of packages) anything could change from one day to the next? (even if a package was "good" today, it could turn "bad" tomorrow) The best I've been able to come up with is to pick things that have minimal dependencies of their own. It doesn't eliminate the threat, but it does at least reduce it.

IIRC there is some kind of SaaS solution for this but right now I can’t recall its name. Maybe someone else here knows? Edited: I reached out to some security people and it seems like the following are popular tools for this use case: Snyk / Dependabot / Whitesource.

Github have a security check that scans your repo's dependencies and warns you about vulnerabilities too

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#24
post #4

Yes, in depth. Not just the packages but their dependencies as well.

How long does it take you to do this for e.g. all the dependencies for a bare bones Angular, Vue or React app?

I couldn't begin to estimate. (We don't use those.)

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#25
post #19

Earlier quoted context omitted.

The "deps portfolio" gets updated whenever the deps change. In practice the flow goes like this: 0. A dev wants to use a new dependency, likely after experimenting with it a little bit. 1. Preliminary evaluation, which includes a transitive dependency scan. ("Too many dependencies" is a valid fail condition all on it's own.) 2. If everything looks good we bring it and it's deps into our internal repo. This includes t…

When one of the transitive dependencies fixes a security issue, is it then re-evaluated prior to being updated in the internal repo? I'm guessing you work at a pretty large tech company. It seems wasteful that so many companies might be replicating this work. I wonder if there might be the opportunity for a body to review & approve packages on behalf of many companies. Perhaps npm will eventually move in this directi…

> When one of the transitive dependencies fixes a security issue, is it then re-evaluated prior to being updated in the internal repo?

Yes, but this is typically pretty low overhead. And when it's not, it usually means there is some issue that has to be addressed anyway.

> I'm guessing you work at a pretty large tech company.

I did once, but right now "we" is a tiny startup (we're using Elm and Erlang.)

> I wonder if there might be the opportunity for a body to review & approve packages on behalf of many companies.

Ideally, that's what Free/Open Source Software would be, eh?

In the old days there were "sysadmins", System Administrators, who handled a lot of this sort of thing.

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#26

Earlier quoted context omitted.

How long does it take you to do this for e.g. all the dependencies for a bare bones Angular, Vue or React app?

I couldn't begin to estimate. (We don't use those.)

I just don't see how anyone could realistically look at all the lines of code that any nontrivial JavaScript app relies on in any depth.

I'm sure most people don't review the code for their operating system, drivers, web server, compiler, browser etc. but they do assess if the entities that write + support them are worth trusting. This is likely the only realistic approach for complex JavaScript apps also.

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#28
post #7

Earlier quoted context omitted.

Really? What about all the dependencies from those dependencies?... For example, our company is working on an app that has 82 npm dependencies and over 17,000 resolved npm packages... It's absolutely ridiculous to investigate all of them... but it's also necessary if you want to be sure...

> Really? What about all the dependencies from those dependencies?... Yep, all the way to the end. I got the idea from a book called "Hollywood Secrets of Project Management Success" by James R. Persse. It's two books interleaved really, one is just a standard pitch for Agile methods (IMO), but the other is a presentation of the process that large film studios use to make movies. The movie industry is ~100 years old…

Thanks for the response, that's an interesting way to deal with it. How do you verify a dependency? Do you literally examine the source code? Make sure the build is reproduced? or just the meta data? (downloads, stars) has the portfolio actually prevented any vulnerabilities?

It's pretty common for JS projects to have thousands of transitive dependencies, I'm not sure keeping a private portfolio is much use. The entire open-source ecosystem is built on the foundation of trust, if I use a package that's being used by 500 other packages, I can have a high degree of certainty that the package is safe, and by locking the dependencies with yarn.lock I can prevent sneaky updates from entering the system.

Anyway maybe I'll look into the dependency portfolio, see how it goes.

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#29
post #16

It's interesting to see so many people here checking the code of all their open source packages, so here's my take on it as a security consultant: No, most people don't, they even have a hard time keeping library versions up to date.

Do you have a pragmatic approach that you typically recommend, considering that (without version pinning thousands of packages) anything could change from one day to the next? (even if a package was "good" today, it could turn "bad" tomorrow) The best I've been able to come up with is to pick things that have minimal dependencies of their own. It doesn't eliminate the threat, but it does at least reduce it.

No it’s not easy to realize. From a security perspective the idea is to always run the latest. Breaking backwards compatibility becomes a more difficult proposition. In reality you need to have an engineer test or analyze the updates. Some mature libraries maintain backwards compatibility (eg openssl) but if using something like npm it becomes almost impossible.

Re: Ask HN: Does anyone investigate open source packages before using in prod?

#30
post #28

Earlier quoted context omitted.

> Really? What about all the dependencies from those dependencies?... Yep, all the way to the end. I got the idea from a book called "Hollywood Secrets of Project Management Success" by James R. Persse. It's two books interleaved really, one is just a standard pitch for Agile methods (IMO), but the other is a presentation of the process that large film studios use to make movies. The movie industry is ~100 years old…

Thanks for the response, that's an interesting way to deal with it. How do you verify a dependency? Do you literally examine the source code? Make sure the build is reproduced? or just the meta data? (downloads, stars) has the portfolio actually prevented any vulnerabilities? It's pretty common for JS projects to have thousands of transitive dependencies, I'm not sure keeping a private portfolio is much use. The enti…

Cheers!

> How do you verify a dependency? Do you literally examine the source code?

Yeah. It's part of the overhead of using the software. You also look at the history of bugs and how they were handled.

> It's pretty common for JS projects to have thousands of transitive dependencies

Yeah, I know, and it's bonkers IMO.

> The entire open-source ecosystem is built on the foundation of trust

In practice, yes, but in theory, no. The whole idea is that you get to see the code you're running, because the guys who wrote it are clowns. Free Software started when RMS wanted to fix his printer and Xerox said, "No."

> if I use a package that's being used by 500 other packages, I can have a high degree of certainty that the package is safe

I think history has shown that that reasoning is at best probabilistic, eh? You're gambling.

Now, of course, there are limits. Some things get a pass. Do we audit the source of the bash shell? No, despite the fact that it's maintained by a single volunteer.

> Anyway maybe I'll look into the dependency portfolio, see how it goes.

Check out that "Hollywood Secrects" book I mentioned.

Post reply on HN