Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Kenneth van Wyk: Looking beyond Heartbleed

Kenneth van Wyk | April 28, 2014
We can do things now to make things a little easier should we face another widespread security defect in code like OpenSSL.

So what's the difference between a linked library and a software framework used to build the software? Well, a linked library is generally a compiled library that is called from other code. Those things are connected, or "linked," when the dependent software is built. A software framework, on the other hand, is typically source code that is either compiled already or byte-compiled (like Java code) from within our code. The bottom line is that the differences are subtle, but there's one practical thing that really matters. When we change framework software, we typically need to completely recompile our own software, whereas with a library, particularly a dynamically linked one, we don't necessarily need to rebuild our own dependent software.

From a change management standpoint, that's a big deal. If you don't agree, ask your software developers when last they updated any production software simply because one of the frameworks they use was updated. It almost never happens. System libraries, on the other hand, are likely to be updated whenever our servers go through upgrade cycles.

But either way, we need an up-to-date inventory of what's in our code. When a dependency is updated, we need to authoritatively know what software needs to be rebuilt. Even changing a dynamically linked library out from underneath our production software should necessitate some testing to ensure that our production software is still behaving as we expect it to.

So, from my point of view, one of the best things we can do to help us respond to similar problems as Heartbleed is to maintain an inventory of software dependencies. We should know and have a maintained list of all the dependencies of our production software.

Building that inventory and keeping it up to date is not a trivial task by any means, but it is likely to save you some heartache in the long run. Even if you're not developing your own business software, simply knowing the dependencies of your installed production software systems is worth the effort.

 

Previous Page  1  2 

Sign up for Computerworld eNewsletters.