This is the situation with the software supply chain

Open source software has long established itself as an integral part of software development – whether for corporate applications, in the smart factory or in the IoT. But what about security and compliance? A look at the growing use of OSS components and the search for best practices and standards.

Guest post Higher productivity, faster time-to-market and lower costs – the list of advantages of Open Source Software (OSS) is long. It is not without reason that OSS components today make up up to 50 percent of the code of commercial software. However, current usage cannot hide the fact that there is still room for improvement in terms of management and compliance. Revenera came across 80,157 critical OSS components when examining more than 2.6 billion lines of code. The 80 percent increase is due, among other things, to the number of Node.js packages from NPM modules used. On average, a compliance violation, a vulnerability or the like was found every 32,600 lines of code. The amazing thing: Although 45 percent of the code base examined in the audits consisted of open source components, the companies knew only 1 percent of these components before the start of the audit process.

Nicole Segerer (Image: Revenera)As head of Revenera’s product management and marketing teams, Nicole Segerer, author of this guest post, directs product planning, strategy and roadmap plans, as well as market planning, positioning and marketing for Revenera’s solutions. Nicole has more than 15 years of experience in software product strategy and marketing. Before joining Revenera, she headed the marketing strategy at Acando (Image: Revenera).

Blind spot in software development

Where does this lack of transparency in dealing with OSS come from? The reasons for this are different. Software is usually made up of different components that also come from different sources – starting with proprietary code and code from partners and third-party providers to open source repositories on the Internet.

In addition to packages and dependencies, subcomponents, binary files without manifest files, multimedia files, images / icons, codecs and copy / paste codes – and their respective licenses – must also be taken into account. Open source does not automatically pose more risks than any other code. However, its complexity makes accurate documentation and continuous management along the supply chain extremely difficult.

If you think you are up-to-date on the use of OSS components in your own company, you should be able to answer the following questions without any problems. Who wrote the code? In which applications and IoT devices is this used? Are there any security or compliance issues with this code? And have these problems been solved? There are no simple answers to these questions, also because not all OSS risks are equally relevant for everyone. While the legal department pays special attention to the compliance of a software product, it must be clear in the software supply chain which open source / commercial packages are contained in the binary files. The development team in turn focuses on the timely delivery of a product, while the security team deals with software vulnerability management.

Open source in the software supply chain (Image: Revenera)

Ask the question of trust: Initiatives and BOM

It is therefore not surprising that open source initiatives have repeatedly tried to establish uniform processes along the software supply chain. Legally binding guidelines for dealing with OSS, its cross-sectoral adoption as well as a continuous control of the guidelines have so far not existed or only in the beginning. Software providers, IoT manufacturers and tech companies are largely free to decide how they manage OSS in their products and how they act with partners, contractors and the open source community within the software supply chain. However, this does not mean that standards and recommendations are completely lacking.

SPDX format

Software Package Data Exchange (SPDX) describes a standard format developed by a working group of Linux Foundation developed as part of the “Open Compliance Program” and introduced in 2011. SPDX should simplify the handling of OSS, especially with regard to licenses and copyrights. All information on the software package as well as the license and copyright information at the package and file level are clearly listed in the SPDX format. In addition, SPDX provides metadata about the author of the code and the time of programming.

Revenera software: SPDX format (Image: Revenera)

With this transparency, SPDX has done a lot to strengthen trust in open source and simplify collaboration between providers. The consistent notation of information facilitates the automation of license entry and reduces the workload. A good example is the BusyBox, which is part of the standard tool for many developers. This program runs on a top-level package under the General Public License (GNU GPL). However, if you examine the tool more closely, there are almost 800 files in the lower levels, the licenses of which differ from GPL. With SPDX, developers can more easily identify such differing licenses and combine all licenses at the file level in a single file in order to clear up ambiguities.

OpenChain project

OpenChain is another open source project of the Linux Foundation. Here, too, the goal is to strengthen trust between companies within the software supply chain by adhering to certain standards. The high-ranking members include, among others Microsoft, CISCO, Google and Adobe. The project provides a framework for the use of OSS and supports companies in creating the basic requirements for an internal quality assurance program. A fixed procedure is not mandatory. Rather, best practices are described that show companies how to implement a basic open source compliance program.

Nevertheless, OpenChain adheres to a few basic rules. This includes the development of open source guidelines, appropriate training for developers, legal and security teams and third parties, and finally the clear allocation of roles and responsibilities. The software bill-of-materials (BOM or SBOM) also plays an important role, which has to be verified once and regularly checked and adjusted in the further course – for each new version of software.

Bill of Materials (BOM)

The BOM is a current directory of all software components used and their dependencies. What sounds simple is very complex in practice. Software developers use different OSS components or use third-party commercial components that themselves contain OSS. If the necessary information is only missing at one point, the documentation chain is interrupted and the individual “components” of software are difficult to trace.

Software supply chain: Bill of Materials (Image: Revenera)

Even if the implementation of the BOM still leaves a lot to be desired, the parts list has become established in the industry in recent years. In most open source initiatives, it is considered a core element of compliance programs and is therefore often included in the contractual agreements. The FDA (The Food and Drug Administration) has already announced in a report that it is considering the introduction of BOM as part of a pre-market submission for medical devices. In the long term, it seems that the BOM will become a mandatory program.

Missing standards & tools

As promising as these developments and initiatives are, there are still no binding requirements and standards. Both are urgently needed. An incorrect or incomplete parts list in the long line of software developers and providers can undermine all compliance efforts. And even if everyone involved in the software supply chain seamlessly records and passes on their OSS components, the question remains of a standardized format. Otherwise, the consolidation of data and the integration into the automated management and scanning tools will take place.

In general, many companies still lack solutions that automatically scan open source and reliably identify security gaps and compliance violations. Baseline audits and fast scans do not provide sufficient results here. As part of forensic audits, Revenera, for example, discovered an average of six percent more compliance risks per audit than with standard audits. Software Composition Analysis (SCA) tools, on the other hand, not only reveal which source libraries are used by developers, but also which third-party libraries are linked to them by default. The exact proportion of the adopted code can be determined as a percentage within the proprietary source code.

In the long term, there is no way around integrating OSS scanning into the built process of applications and implementing a compliance program. It is therefore all the more important to agree on clear guidelines and standards in order to close security and compliance gaps in the software supply chain in the long term.

Collaboration platform Slack: work efficiently – no matter where

Before COVID-19, remote work was almost unthinkable for many companies. Today they realized that it can work very well if the general conditions are right. Find out in this webinar how you can optimally react to changing working conditions with the Slack collaboration solution.

Leave a Reply

Your email address will not be published. Required fields are marked *