Cyber Security - The Design perspective: Understanding the growing need for SBOMs...

In my previous article, I developed an argument towards understanding the various standpoints on supply chain insofar as software development is concerned. We learnt that the landscape of software supply chain security is rapidly evolving, with open-source software playing an increasingly significant role. While open-source software offers numerous benefits, it also introduces substantial security risks that require careful management. In today's article, I complement that effort with another dimension where I explore the growing need for software bill of materials (SBOM).

A Software Bill of Materials (SBOM) is a list of all the components that make up a software application. It includes information about the components' versions, licenses, and dependencies.?The Cybersecurity & Infrastructure Security Agency (CISA) notes that SBOM has emerged as a key building block in software security and software supply chain risk management. An SBOM is a nested inventory, a list of ingredients that make up software components.

In recent years, the importance of generating Software Bill of Materials (SBOM) lists for software packages has become increasingly evident. This development is largely a response to the rising number of supply chain cyberattacks that have highlighted the vulnerabilities inherent in packaged software and libraries. As software becomes more complex, comprising multiple discrete files and libraries from both native and third-party sources, the interactions between these components and their potential vulnerabilities pose significant risks to organisations. This section explores the evolution of the need for SBOMs since 2021 and underscores their growing significance in the software industry.

The Catalyst: Supply Chain Cyber Attacks

The year 2021 marked a turning point in the perception of the security of packaged software. A series of high-profile supply chain cyberattacks revealed the fragility of the contemporary notion that software packages and libraries were beyond reproach. These attacks exploited the hidden vulnerabilities within software components, demonstrating how a single compromised element could jeopardise entire systems and networks. The SolarWinds attack, which affected numerous government and private sector organisations, served as a stark reminder of the potential consequences of unchecked software dependencies.

The Complexity of Modern Software

Modern software is increasingly composed of a multitude of discrete files and libraries, often sourced from various third-party vendors. This intricate web of dependencies creates a complex ecosystem where the interactions between components can go unnoticed. Native and third-party libraries, each with their own sets of vulnerabilities, contribute to a landscape where risks are not always apparent. Organisations may unknowingly accept significant risks without a full understanding of the potential vulnerabilities within their software packages.

The Role and Benefits of SBOMs

SBOMs serve as a comprehensive inventory of all components within a software package, providing visibility into the origins and interactions of each element. By detailing the constituent parts of software, SBOMs enable organisations to identify and mitigate vulnerabilities more effectively. This transparency is crucial for maintaining the integrity and security of software systems, especially in an era where cyber threats are increasingly sophisticated and pervasive.

Providing Software Assurance. Developing an SBOM list helps in providing software assurance by offering a clear and detailed inventory of software components. This allows organisations to understand the software's composition, origins, and potential vulnerabilities, thereby ensuring that the software meets security and compliance standards.

Mitigating Vulnerabilities and Reducing Exposure. An SBOM list is vital in bridging the gap between discovering vulnerabilities and the race against time to patch them. With a comprehensive understanding of the software components, organizations can quickly identify and address vulnerabilities, reducing the risk of significant exposures and data breaches. This is particularly important in both on-premise infrastructure and Cloud-native products and services, where the speed and efficiency of patching vulnerabilities are critical.

Industry Disruption and the Need for SBOMs

The growing need for SBOMs has the potential to be disruptive to the entire software industry. As organisations recognise the importance of understanding their software components, the demand for SBOMs is likely to increase. This shift may drive changes in how software is developed, packaged, and maintained, emphasising the need for greater transparency and accountability. The adoption of SBOMs represents a proactive approach to software security, empowering organisations to better manage risks and protect their assets.

The Two Broad Families of SBOM Lists

When it comes to Software Bill of Materials (SBOM) lists, two prominent frameworks have emerged as industry standards: OWASP’s CycloneDX and the SPDX driven by the Linux Foundation. These two frameworks provide methodologies for creating SBOM lists but differ in their approaches, benefits, and ideal use cases.

OWASP’s CycloneDX

CycloneDX, developed by the Open Web Application Security Project (OWASP), focuses on application security and is designed to be lightweight and easily integrable into various software development processes. CycloneDX SBOMs are primarily used in the context of security, providing detailed information about the components, dependencies, and vulnerabilities within a software package.

Benefits of CycloneDX

· Security-Centric: CycloneDX is tailored for security analysis, offering extensive details on vulnerabilities and mitigations.

·?Lightweight: The format is designed to be lightweight, enabling quick and efficient integration into existing workflows.

·?Flexibility: CycloneDX supports a variety of use cases, including vulnerability management, license compliance, and operational risk assessment.

Ideal Use Cases

CycloneDX is particularly useful in scenarios where security is the primary concern, such as:

·?Application security assessments

·?Continuous integration and delivery (CI/CD) pipelines

·?Vulnerability management programs

SPDX by the Linux Foundation

The Software Package Data Exchange (SPDX) specification, driven by the Linux Foundation, aims to provide a standardised format for sharing information about software components, licenses, and copyright information. SPDX is designed to facilitate license compliance and ensure that software packages adhere to legal and regulatory requirements.

Benefits of SPDX

·?Comprehensive: SPDX offers a detailed and standardized format for documenting software components, including licensing and copyright information.

·?Legal and Compliance Focus: The framework is geared towards ensuring license compliance, making it invaluable for organisations that need to adhere to legal and regulatory standards.

·?Wide Adoption: SPDX is widely adopted in the open-source community and supported by various tools and platforms.

Ideal Use Cases

SPDX is best suited for situations where legal compliance and licensing are the main priorities, such as:

·?Open-source software projects

·?Software audits for license compliance

·?Regulatory compliance in highly regulated industries

By understanding the distinct advantages and applications of CycloneDX and SPDX, organisations can choose the right SBOM framework to meet their specific needs. CycloneDX’s security-focused approach is ideal for enhancing application security, while SPDX’s comprehensive documentation supports legal and regulatory compliance. Both frameworks play a crucial role in fostering transparency and accountability within the software industry, contributing to the overall security and integrity of software systems worldwide.

?

Yet, notwithstanding the efficacy of these models in developing SBOM lists, the subjectivity inherent in the levels of abstraction at which such lists are drawn can be a significant concern. This subjectivity may lead to downstream ambiguities, particularly when different stakeholders interpret the SBOM differently or make varying assumptions about its scope and depth. For example, one organisation might consider certain metadata as critical, while another might overlook the same details, leading to inconsistencies that can compromise the SBOM's utility.

In recent times, when most applications are containerised, it is necessary to recognise that software can natively adopt or import other software programs or software libraries during their development, that too, in full or as partial components. During such occasions, it is essential that the designer understands the level of abstraction that is called for, i.e., should the import of system or third-party functionalities be conducted at the application programming interface (API) level, at the file level, where it might contain one or more programming entities, or anywhere in between. The reason this becomes critical is because a designer (or architect, as the case may be) would recognise that such modules are wholly imported into the executing process memory where it would have unlimited access across kernel and user modules. This is where things can and have gone awry in the past. Consequently, each software development must contain its own abstraction hierarchy and describe key control and data flow patterns to eliminate inadvertent mistakes in third-party imports. A well-defined SBOM list which transcribes event flows at multiple levels on such hierarchy and the process of threat modelling can be useful.

To mitigate these ambiguities, it is imperative that any assumptions and suppositions be agreed upon in consensus from the outset. Establishing clear guidelines and definitions at the beginning of the SBOM creation process can ensure that all parties have a unified understanding of what the SBOM entails. This consensus-building is essential to avoid misinterpretations and ensure that the SBOM serves its intended purpose of enhancing transparency, accountability, and security within the software supply chain.

Conclusion

The need for Software Bill of Materials (SBOM) lists has become increasingly critical in the wake of supply chain cyberattacks that have exposed the vulnerabilities within packaged software. As software continues to evolve, comprising multiple discrete files and libraries, the interactions and potential risks associated with these components necessitate greater transparency and understanding. SBOMs provide a valuable tool for organisations to identify and mitigate vulnerabilities, ultimately contributing to a more secure software ecosystem. As the demand for SBOMs grows, the software industry must adapt to this new landscape, embracing the importance of comprehensive software inventories for maintaining security and integrity.

Until next time...