Skip to content ↓ | Skip to navigation ↓

Several months ago, I was having a conversation with an engineer who was struggling with the various build system and legal hoops one has to deal with to include a third-party library.

“Is third-party software even worth it?” he asked in frustration. At the time, the comment struck me as more than a little ridiculous.

We use Java, which has a rich ecosystem of available libraries that allow development teams to deliver more functionality in less time. Unless you want to re-implement cryptography, network communication, database drivers and a whole host of other solved problems, you leverage the results of others’ work.

But that gained efficiency comes with a cost—increased security risk. Now not only do you need to worry about vulnerabilities you might be introducing, but also those of the countless contributors of other code you’re relying on. The obvious example here is Heartbleed—countless developers incorporated OpenSSL and inherited the serious vulnerability that it contained.

That’s not to say that the people who developed the third-party library necessarily have lower standards with respect  to secure coding. But by pulling in someone else’s code, you’re increasing the footprint of your software; you have just added many more lines of code (and some low rate of defects) than you could have written yourself in that period of time. That’s why you added it—because it let you get something done faster.

So in light of this added risk, let’s get back to the engineer’s question: is third-party software even worth it?  In the abstract, yes—if you’re smart about how you incorporate it, you can deliver significantly more value to customers than you could otherwise. But on a case-by-case basis, he is asking exactly the question we should be asking ourselves every time an engineer comes with a new set of libraries.

Here are some questions you might consider as you evaluate the risk versus reward:

Is its footprint proportional to its value?

You’re adding code to your product in order to get value X. Does the library you are bringing in address value X specifically or does it address the entire alphabet of problems?

Think frameworks here—popular ones like Grails or Spring solve a vast array of problems and do so by pulling in a host of other third-party software. If you find yourself pulling in a heavyweight framework to solve a single concern in your product, you might be in the “not worth it” space.

Interestingly, Java itself has had this problem, distributing all parts of the JRE under all circumstances. In doing so, it was exposing servers to end-user vulnerabilities and vice-versa with no benefit for those users.  More recently, they have responded by providing server-only distributions that exclude end-user-focused JARs like Web Start.

Is it actively maintained?

Maybe this one goes without saying, but if the authors of your library have gone dormant, you ought to move on. Consumers of libraries and products find out they have vulnerabilities when fixes are issued;  hackers find out when they compromise them. If nobody is there to fix the issues, you’ll have no idea what vulnerabilities you’re putting in customer environments.

How easily can you update it?

Assuming someone is out there to issue updates in response to discovered security issues, you’re going to need to update your software to consume newer versions. How hard is that going to be? Are there well-known touch points between your software and the third-parties’ software or is the relationship complicated?

If you can’t easily identify what needs regression testing upon a third-party update, you’re going to end up regression testing everything. Be careful here that the eventual cost of staying up-to-date doesn’t override the early benefits of adding the library.

Assuming your increase in risk footprint is right-sized to the value you’re getting and that you can justify and accommodate the ongoing maintenance, pulling it in is probably the right thing to do. You’re probably not an expert in what it does, so writing it yourself is more likely to result in defects and security issues.

Leverage the work of others in these circumstances—it’s worth it. Just make sure that the next time an excited engineer comes with a package of libraries that solves all of the world’s problems you make him or her stop and identify the problems it causes, as well.





picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].


Header image courtesy of ShutterStock