
Ask HN: Does anyone investigate open source packages before using in prod? - lyttlerock
I&#x27;m curious to hear if anyone else does any due diligence before using open source packages in production? Not anything major - just checking for recent commits &#x2F; activity, issue logs, etc.
======
alltakendamned
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.

~~~
jfoster
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.

~~~
cpach
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.

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

------
austincheney
Yes.

If you work in a secure environment or support critical infrastructure there
are teams whose sole purpose is to approve/deny releasing software regardless
of who wrote it. Such teams will typically require source code, written
justification, senior management signed approval, and test validation. In the
case where source code is not provided, such as closed source commercial
software, the vendor will be required to accept liability for all losses due
to their software as ratified by a signed contract.

------
WA9ACE
I normally read a good chunk, if not all of the code of a dependency before I
add it to my projects except in the case of community standard things (in
Ruby) such as ActiveSupport or Sequel. Going over a prospective dependency a
few months ago bore fruit in proving why you should always do this. NewsAPI is
a neat little API for fetching news whose docs just so happen to show a ruby
gem. Being the lazy developer I am I’d like to use the gem than build another
API client, but before I did that I read the source as one should. Low and
behold what do I find but the evil eval in the code for a dirt simple API
client. No thanks.

[https://github.com/olegmikhnovich/News-API-
ruby/blob/master/...](https://github.com/olegmikhnovich/News-API-
ruby/blob/master/lib/news-api.rb#L47)

~~~
amoitnga
Is this malicious? I'm honestly curious, as I don't have much experience still
in the field. my answer to OPs question is NO , but I'd like to grow.

------
jfoster
This article might be of interest:

[https://medium.com/hackernoon/im-harvesting-credit-card-
numb...](https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-
passwords-from-your-site-here-s-how-9a8cb347c5b5)

------
nikitaga
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 and smaller dependencies than typical because of
these self imposed constraints.

On the upside, borrowing a pattern or a dozen lines of code instead of pulling
a dependency that will remain 90% unused is really underrated. As is
understanding how things work under the hood.

~~~
overkalix
> 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.

~~~
nikitaga
Haha well tbh I just didn't feel the need for more deps in such libraries.
It's a tougher choice in application code!

------
uvw
I would be surprised if anyone has enough resources or willingness to do that
for every open source package they are using. For companies that go through
auditing, they can CTA by relying on products like Nexus IQ.

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

~~~
gitgud
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...

~~~
carapace
> 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 and mostly very good at bringing in projects on time and under
budget.

Somewhere in there he talks about how they'll track their dependencies in a
kind of "portfolio", I forget the details, but it translates in IT to a
"dependency portfolio" and you would (if you're large enough) have an actual
"Deps Dept." and a Deps Manager whose sole job is tracking dependencies and
their updates and patches, etc.

> working on an app that has 82 npm dependencies

Ach! Well, see, there's your problem right there. :-)

Seriously though, one of the benefits of a dependency portfolio is to help you
know when your system has gotten out of hand. The problems are still there
even if you don't look at them, eh?

> It's absolutely ridiculous to investigate all of them... but it's also
> necessary if you want to be sure...

Ya feel. ;-)

~~~
gitgud
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.

~~~
carapace
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.

~~~
amoitnga
Thanks for sharing. It would be very interesting to know some of the examples
when it payed off. Could you please share?

------
bjourne
Doesn't everyone? That's one of the annoying parts of using other people's
code. You have no idea how good or bad it is until you have thoroughly vetted
it.

------
bnchrch
These comments feel skewed. I look for activity and support. Reading the
actual code is typically far from my mind.

The time-opportunity cost isnt worth it on average

------
amoitnga
In my case no. But I tend to use the big guns. I'm willing to learn though

------
bluGill
Yes, if there are no commits at all I know I'm stuck maintaining it.

~~~
sigjuice
Or it could be mature and stable software that doesn't need constant
maintaining.

~~~
bluGill
Maybe, but then I'd expect a small number of bug fix commits. Most software
never matures in that way.

------
wolco
Sort of. By the time you choose the package that info should be known.

