What You Don’t Know CAN Hurt You

Posted by John Zielinski on March 10, 2016

Once upon a time when people would ask what I did for a living I would say that I was a software archeologist. While that didn’t make a lot of sense to people outside of the software industry, it made perfect sense to many people within the industry. That was a relatively simple time. Most mainframe systems were written in COBOL with some PL/I and BAL encountered along the way. Systems running on desktops and distributed servers were usually written in C or C++ with a smattering of other languages showing up on occasion. Run time libraries were often limited to what was provided with the operating system or developed in-house. The picture is much different today.

Today it’s not uncommon to find systems built with Java, Javascript, C#, Python, PHP, Objective-C, Swift and Ruby, and those are just the most popular languages. On top of that, these systems include third party library content – both commercial and open source – as well as source files that more than likely include at least some lines that were copied and pasted from a point of origin somewhere outside of the organization where the code in question is being used. This leads to the very important question, “What’s in your code?”

Based on forensic analysis of many codebases over a number of years it turns out that there are organizations that are only aware of about two percent of the content in their systems that came from outside. For many more – perhaps most – the number is around five percent. Few, if any, are aware of one hundred percent.

If your systems rely on third party content and you don’t know that it’s in there, then how can you be sure that there are no undiscovered vulnerabilities? Consider how many organizations were affected by Heartbleed and were blissfully unaware until things hit the fan. Much more recently we became aware of DROWN and it’s been estimated that as many as 11 million websites that use OpenSSL are at risk. Do you know whether yours is one of them?

How can you be aware that you’re adequately addressing the intellectual property requirements of the third party content that’s in your software? There’s a widespread belief among developers that open source software can be used in any way that they please without concern. After all, it’s free and open. Your IP counsel – and more importantly, the IP counsel of the owner of the third party content in question – may see things differently. If you don’t know what kind of license is associated with something, then how do you know whether you’re meeting the terms of that license? How do you know whether there are issues that require remediation? How much of your codebase requires remediation? Don't forget about the licensing requirements associated with things like images and sounds.

Do you have a proactive process in place to prevent incidents involving third party content from occurring? Good governance suggests that third party content be reviewed and approved before use. If you don’t have a process and tools in place to support this, then even after you’ve managed to address whatever issues you have today you’re leaving the door open to both new issues and recurrence of what you take the time to fix.

Here’s a little checklist that you may want to review because what you don’t know can definitely hurt you.

John Zielinski

Related Tags

Sign up to get Email Notifications

News & Events

Knowledge Center