Supply chains for contemporary software systems are ever more complex and dynamic. Cybersecurity risk is considerably increased by the lack of systemic insight into the design and operation of these systems.
The adoption of a standardized information carrier describing the internals and sources of software components is encouraged by the growing complexity of IT landscapes and supply chain integrity in order to achieve software transparency.
The Software Bill of Materials (SBOM) is a machine-readable file or electronic document that lists the parts of a piece of software. It is advantageous to become aware of weaknesses in the underlying software components and to more accurately predict how those defects will affect the IT environment. Additionally, an SBoM helps operators and selectors of IT resources manage risk better.
The NCSC hired CapGemini Invent to research the current landscape, potential goals, and potential uses of SBoM in a cybersecurity context. The possibilities for software development, software selection and procurement, software operation, and SecDevOps are all included in the study report. The general conclusions are as follows:
1. In the field of IT security, SBoM is becoming more well-known.
2. SBoM is regarded as helpful for overseeing IT security.
3. The existence of an SBoM is thought to be a sign of an IT product’s quality.
4. The tools and data standards that are accessible are limited.
5. There is ongoing discussion over how to strike a balance between practical use and SBoM complexity.
The application of SBoM is not widely standardized.
The findings of this study contribute to better understanding of novel ideas and offer suggestions for new research and advancements in this area of interest.
Creating a bill of materials for software
An SBOM can be produced while a software program is being developed. There are a number of technologies that can connect with continuous integration/continuous development (CI/CD) technology to construct an SBOM as part of a development pipeline.
Utilizing software composition analysis (SCA) tools, which can identify the components present in each program, is another way to create a cybersecurity bill of materials. SCA scanning may happen after an application has been finished developing or even earlier.
Employing an industry standard form for the distribution of SBOM data is essential for developers and end-user companies who require or desire visibility into supply chain risk. The SBOM data must be transferable and easy to understand in order to be used in other applications, regardless of whether the company generates an SBOM during development using a SCA tool or not.
One of the industry standards for SBOMs is ISO/IEC 5962:2021 for the Software Package Data Exchange (SPDX) specification. Software vulnerability, risk, and patch management solutions can make use of SBOMs created in the SPDX format to help enterprises comprehend the underlying software components they use.
NTIA has also started a project called Software Identification (SWID) tagging to help with delivering the data fields component of an SBOM. CycloneDX, created by the Open Web Application Security Project (OWASP), is another widely used standard for supporting businesses in creating SBOM manifests.
What benefits do SBOMs offer?
SBOMs let businesses identify whether they are exposed to publicly known security flaws in software components, whether those components were created internally, bought commercially, or were open source software libraries. Software engineering teams can identify hazardous attacks during development and deployment with the help of SBOMs, which generate and validate information on the provenance of code and component relationships.
For instance, a zero-day vulnerability in Apache Log4j, a popular open source Java logging library, was found in December 2021. Security professionals were obliged to act quickly to find applications that used the hacked library after the vulnerability was found. Organizations with SBOMs have quicker response times because they can map apps to vulnerable dependencies.
SBOMs also increase productivity by combining proprietary and open source applications. Even though many businesses use the same parts, each one does its own analysis of compliance risks and vulnerability searches. SBOMs’ open infrastructure and data sharing structure may speed up business processes by encouraging group collaboration.
What disadvantages come with employing SBOMs?
Data exchange and sharing standards have an impact on SBOM success because they are most beneficial when everyone in the supply chain follows them. It might take some time to attain this consensus because of the number of technologies and software that are currently in use or on the horizon.
The purpose of adaptation is another thing to think about. Documents called SBOMs are dynamic. Every every release of a component must come with a fresh SBOM. Release and consumption of new components without corresponding SBOM alterations are particularly risky. Because they help businesses integrate SBOM capabilities into software development, packaging, and release operations, SBOM creation and management tools are crucial for wider adoption.
Furthermore, dependencies that can be accessible through package managers are detected by SBOM producing technologies. Developers can add pre-compiled binaries or uncompiled code to their codebases, giving the appearance of completion.
Teams working on software development should not confuse complete SBOMs with ones that are only one layer deep. To provide complete transparency, SBOMs must list each component as deeply as feasible in the dependency network. Additionally, SBOMs can provide hierarchical information, with a separate SBOM for each component.
