Open source software is taking the world of software development into new frontiers and changing the way industries create and consume software. However, there is a learning curve with open source use and businesses need to not only be able to trust the open source software being used in their solutions, but they need to manage potential risks responsibly and get involved with the open source community.
If not properly implemented or managed, open source software can introduce security vulnerabilities, compliance issues, copyright infringement and even create bad publicity for companies.
“Even though companies’ technology depends heavily on open source, most organizations aren’t properly tracking it. They’re not properly monitoring their use of the open source and the third-party components,” Michael Lelchuk, manager of professional services at Flexera, said in a webinar. “It’s almost impossible to mitigate that risk…without knowing what’s in your code.”
Because of this, Lelchuk explained open source software license compliance is more important than ever. In order to properly comply and create trust in the software supply chain, Lelchuk along with Mark Gisi, director of the open source program office at Wind River Systems, provided a number of recommendations on what to do and where to get started.
Education:
First and foremost, there needs to be an understanding about open source in general and the open source software used within a company, Lelchuk explained. Businesses need to educate employees as well as put processes and tools in place.
Open Source Bill of Materials (BOM):
Secondly, companies need to produce an open source Bill of Materials, which is a disclosure list and assessment of what is in the code, the components it depends on, and how it is being used and distributed. “It’s really an assessment of risk,” Lelchuk said. “Producing a comprehensive Bill of Materials is perhaps one of the most important actions for development teams to take.” It allows businesses to understand exactly what is in the code and what is going on within that code and enables engineering teams to see issues, roll out patches and bug fixes in a timely manner as well as provide a good assessment of security vulnerabilities.
However, according to Wind River’s Gisi, there is no standard format for the BOM, but he does believe there will be a standard published in the near future to make it easier to create and consume BOMs.
Software Package Data Exchange (SPDX):
In order to create an open source BOM, there are a couple of pieces of technologies that can help. The Software Package Data Exchange was introduced in 2010 and it is a Linux Foundation open standard for properly communicating software BOM information such as components, licenses, copyrights and security references. “It is really about getting a very detailed analysis of all the licensing in a particular software package at the file level,” said Gisi. “It is an open source project where many people can come in who have a lot of experience with compliance and sharing compliance information to develop a specification for how you might structure data.”
OpenChain:
OpenChain is more of a certification for open source licensing in the supply chain. “Think of it as a compliance program and you want to certify your compliance program meets some basic minimum requirements,” said Gisi. According to Gisi, there are six pillars of the OpenChain specification:
- Policy
- Training to ensure everyone is aware of the policy and different processes
- Roles & responsibilities for instance there will be developers and others assigned to do things like prepare the compliance artifacts, and legal counsel to make sure everything is correct
- Identity, review, clear and track: gathering up all the components, understanding the software being shipped, and maintaining the software over time for every single release
- Preparation of compliance artifacts
- Community engagement
“Code can come from anywhere, and it also consists of a variety of different flavors. There is the source code, the binaries, the dependencies, cut-and-paste code and so forth. Because of all this and because of the fact that code comes from various entry points, people don’t really know what code they have in the codebase,” said Flexera’s Lelchuk. “What you don’t know, can hurt you from our experience.”
Learn more:
Managing Open Source Code: Create Trust in the Software Supply Chain
Creating and maintaining trust with open source software
Content provided by SD Times and Flexera
