Fingerprinting: A new security for open source software
FYI, this story is more than a year old
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.