Challenges in the Software Supply Chain
Most large organizations are now leveraging third party and open source software to accelerate development, reduce timelines, trim development costs and stay competitive.
However, use of third party code in any software that is transferred, commercially or non-commercially, within the supply chain brings new complications. These complications can span quality, contractual, licensing compliance and security vulnerability domains. Difficulties arise when the inclusion of third party components in a project are not tracked.
For proper supply chain management an accurate description of the components that make up a particular software project is needed. A number of free and commercial tools have been used to record what has gone into the making of a software package and where each component comes from.
The format of these records, up to now, has been fairly ad hoc. Furthermore, the whole software supply chain has lacked the necessary standards to ensure that all third party components that make up a project come with complete records. Inconsistencies with the way licenses are referenced and captured increases the time and cost associated with ensuring compliance.
The source of the licensing information, that is whether the information was provided by the supplier of the software, via a record in the software package, or by an auditor within the organization, makes follow up investigation frustrating. A consistent process for communicating information about software packages is largely missing from the software supply chain.
What is SPDX?
The Software Package Data Exchange (SPDX) aims to establish an industry standard for communicating information about the components, licenses and copyrights associated with a software package internally and across the external software supply chain.
Based on this standard, a software package is augmented with an SPDX file that contains specific information about the package. Think of an SPDX file as a Bill of Materials (BOM) associated with a software package. Like any other BOM, it is hierarchical in nature, describes the top-level product (the software package), and its subassemblies and raw materials (software files).
SPDX files may be used to communicate the composition of a software package between business partners for quality and compliance purposes, or within an organization for the additional objective of code portfolio rationalization. One key benefit of SPDX is simplifying the licensing management of all software, including open source software. SPDX standard is sponsored by the Linux Foundation and developed through close collaboration between a number of players in the software industry including Protecode.





Join us on social network