Story image

Fingerprinting: A new security for open source software

28 Jun 18

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.

Disruption in the supply chain: Why IT resilience is a collective responsibility
"A truly resilient organisation will invest in building strong relationships while the sun shines so they can draw on goodwill when it rains."
The disaster recovery-as-a-service market is on the rise
As time progresses and advanced technologies are implemented, the demand for disaster recovery-as-a-service is also expected to increase.
Apax Partners wins bidding war for Trade Me buyout
“We’re confident Trade Me would have a successful standalone future," says Trade Me chairman David Kirk
The key to financial institutions’ path to digital dominance
By 2020, about 1.7 megabytes a second of new information will be created for every human being on the planet.
Proofpoint launches feature to identify most targeted users
“One of the largest security industry misconceptions is that most cyberattacks target top executives and management.”
What disaster recovery will look like in 2019
“With nearly half of all businesses experiencing an unrecoverable data event in the last three years, current backup solutions are no longer fit for purpose."
NVIDIA sets records with their enterprise AI
The new MLPerf benchmark suite measures a wide range of deep learning workloads, aiming to serve as the industry’s first objective AI benchmark suite.
McAfee named Leader in Magic Quadrant an eighth time
The company has been once again named as a Leader in the Gartner Magic Quadrant for Security Information and Event Management.