In Dependencies We Trust: How vulnerable are dependencies in software modules?

Maybe the Apache Foundation could have a project like that?

http://osvdb.org/ http://www.datalossdb.org/

QA only tested with these specific versions. You're damned right we're only shipping with those exact versions.

It's not just security that this hurts: I've worked on a few projects now where one or two of the dependencies introduced early on later became the source of the majority of the work on the project. Often dependencies added to solve one problem are unable to solve other problems and are designed in such a way that they are tightly coupled to everything that uses them. The result: either you put in the time to rip out the dependency, or you pile workarounds on top of workarounds to the point that it would have been easier to write the dependency yourself.

There is, of course, a balance to be had here: a solid library can save you an immense amount of work. But only a handful of the libraries I have used are actually solid, and I'm increasingly unwilling to pull in dependencies I haven't used before.

As a rule of thumb: I never want to use a library that's not versioned 1.0 or higher. A 1.0 version doesn't mean that it's ready for use in production systems, but a 0.x version number has always meant it's not ready, in my experience.

I think languages with a compile step naturally tends towards static linking for SaaS systems since single compiled blobs are much easier to manage and deploy.

But Docker is also pretty much static linking of the entire runtime environment, and that seems to be getting some traction where people have messier deployments.

Static linking can _also_ be dangerous: with dynamic linking, update your openssl, all your stuff is fixed. With static, you have to recompile every single thing that uses openssl...

But maybe you mean "bundling the dependencies", or at least refering to exact versions by cryptographically secure hashes, including all transitive dependencies. I've seen lots of "package.json" files refering to ">=2.2" which is horrible from a reproducibility standpoint. I like the way composer writes out "composer.lock" files which specify exact versions. Thus, even if you don't want to check in the "vendor/" subdirectory into your VCS, you should at least more or less be able to reproduce your dependencies exactly. Of course, checking in your "vendor/" dir is even better since your build no longer depends on an internet connection and an available remote server.

Or maybe all those scripting languages and their associated package managers (npm, gem, composer, etc) should take a note from the dpkg/rpm/C-style "lib*.so" world. Settle for stable APIs and stick with a release for the lifetime of an OS edition.