itb-nz logo
Story image

Fingerprinting: A new security for open source software

28 Jun 2018

Open Source Software (OSS) has changed the way software works. It’s found in almost everything, with almost all new apps and modern systems incorporating some open source components. The vast majority, 78 per cent, of companies run open source software, and two-thirds create software for customers built on open source; but like many things that come free, there are always rules to follow.    The problem? Some members of the developer community can also be very casual about copying files, code snippets, images, binaries or entire modules without respecting their open source licences. Even if the developers are strict about reporting licences for their main components, chances are they’re using code that was already casually copied and enhanced.    How do we fix this? Fingerprinting. Much like checking a person’s fingerprints at the airport, source code fingerprinting is the process of comparing the source in an application to a database of open source projects to see if there’s code that’s been cut and pasted or otherwise brought into the application.

This remains the only way to reliably discover what third-party content lives in the code. The risk of undetected code is great – both from a licensing and vulnerability standpoint. Developer teams should be asking themselves a few simple questions before using the code, like where it came from and if they have the right to use it.

What are the licensing considerations and potential problems?

There’s been a lot of discussion of “How much is too much?” for cut-and-pasted code over the years, with a tension between the “How else am I supposed to do this?” and the “Source code has copyright and licences associated with it” camps.

It may be clear that a whole page of source code that originally has a copyright and licence at the top should have that information preserved, but what about a few lines or a method that comes from a file that lacks this information? Your best source of guidance around what’s appropriate is your company’s IP lawyer.

If you don’t have one or they don’t not have an opinion on open source licensing policy, there are many outside counsel who specialise in this topic.

A lack of a licence should be a clear warning sign to the developer that they may be causing downstream problems for their project. A little care and resource at this point can save a later headache.

What’s problematic about how developers do this now?

It’s common for developers to want to give credit where credit is due. The problem with how this is commonly done is that often the original copyright and licence isn’t brought along with the snippet, and the developer may give credit in a flippant way using language such as “code stolen from xyz” or “shamelessly lifted from the Foo project”.  While this language is taken badly by the legal team, it’s often a sign of the developer trying to carve out attribution for this copied code.

It’s important to provide clear guidance on how to properly bring in code snippets for licensing and security review purposes. Preserving or adding the proper copyright and license information is important to remain in compliance. It’s also invaluable for future readers of the source code to understand who wrote what.

What are typical policies around the cutting and pasting of source code?

While all companies have different considerations or use cases, this type of guidance typically involves proper procedures for recording the owner, contact information and licence for the snippet in question. 

If this information isn’t readily available, a request to the original author is sometimes made. This request includes a pointer to the code in question, the use case and a request for a specific licence if not already specified. If there is no response, or the license the author selects is contrary to your policy, it’s common to look for a new source for code that solves your problem.

Creating a compliant product can be simple if you follow the right steps. Educating developers and implementing organisation-wide policies will help guarantee a secure product, using open source, that is ready for your customers.

Article by Flexera's director of sales A/NZ, Hugh Darvall.

Link image
A great ERP tool achieves a lot for your customers & financials
NetSuite’s cloud native SRP is not a project management tool that talks to your finance system. It's end-to-end project management capability for service professionals, integrated with NetSuite's full ERP solution. More
Link image
APAC CFOs share their secrets to customer experience success
We've collected the most common FAQs from CFOs in the Australia-Pacific region (along with client examples) to empower you with a return on investment model that will highlight the true impact of experience management.More
Story image
Time to take responsibility: E-waste - a global crisis
e-Waste is the world’s fastest-growing domestic waste stream, fueled by consumption rates of equipment, short life cycles, and few options for repair.More
Link image
Embedding security into DevOps is a locked door. Here's the key
Vulnerable software is often the primary enabler of successful cyber attacks. That's why modern security teams need solutions that will find and fix these vulnerabilities.More
Story image
Interview: ACE Training execs discuss how to capitalise on NZ's new data centre region
Microsoft's bombshell announcement last month to build a data centre region in New Zealand made waves with the country's enterprises. Graham Dwyer and Ray Deklerk discuss the wider implications and benefits.More
Story image
CenturyLink expands cloud alliance with Dell and VMware in Asia Pacific
The partnership is designed to offer a hybrid cloud solution to help digital businesses in Asia Pacific successfully modernise their application workloads and manage their cloud journey.More