Open source software: How to prevent the open wound

Clearly, the use of open source software is something to be encouraged. Too many development teams have a “not-invented-here” mentality that leads to spending enormous amounts of time on making things that could have been taken off the shelf.

Of course, there’s beauty in building something yourself. Most people will recognize the satisfying feeling of having accomplished something. Whether this is building your own garden shed, repairing your bike without the help of Bicycle Repair Man, or simply mowing your own lawn. In the end, you can see you’ve done something. But when this feeling turns into a phobia of all software coming from outside, things become counterproductive.

As a result, the use of standard libraries and open source components is a widespread phenomenon. It’s something that should be encouraged and included in all design decisions: can we find something out there that already does 80% of what we need?

Truth is, as with all software, things can go horribly wrong. For those not deeply involved in programming: the use of external components, like open source, should not be compared to using standard products in daily life. When you buy a product, like a hammer or a screwdriver, it’ll work the same way now as it will next year or in 20 years. If you use it the way it should be used, it’ll last. Not so with software. And not so with open source. This isn’t because some evil person may have put some backdoor in the software (which could happen, but highly unlikely in proper open source software). Software is a constantly evolving thing and needs to be treated as such. What wasn’t a vulnerability yesterday may very well be a vulnerability today. Hackers are constantly on the lookout for weak spots in software, and of course, there’s no better place to find them than in open source (being open and being used in many places). So, continuous monitoring of the open source components is essential.

Another aspect you need to be aware of regarding your open source components: freshness. It may be that a certain open source component does not (yet) have a known security vulnerability, but you may find it’s more than a year old and actually has seen three new versions. The longer you wait to upgrade, the more difficult the upgrade will be as a result of all the changes involved. This means that at some point, there may be that vulnerability, or you may have to do the upgrade because the open source component doesn’t support that new database version you’re using, and so on. The longer you wait, the riskier it gets.

A final aspect that shouldn’t be forgotten: licensing. The use of some open source software automatically implies that all of your code becomes open source as well. There are very good reasons behind this, but there are equally good reasons to prevent this from happening (if you’re a software company, for instance).

To sum up, the use of open source software is something that should be encouraged. It can save time, speed up development, and, generally, improve the quality of the software overall.

But as much as we enjoy these benefits, using open source software components still comes with risk. And SIG is ready to help. Consider using something like the SIG Open Source Health solution (now part of our software assurance platform, Sigrid) to prevent open source from becoming an open wound.