You know your supply chains, but do you know the origin of your software?

In today's rapidly evolving digital landscape, the realm of software engineering is becoming increasingly complex. The software that powers our modern world consists not only of bespoke source code but also incorporates numerous third-party (open source) libraries that provide essential generic functionality.

Open-source libraries, often maintained externally, speed up software development by supplying ready-to-use software components. However, they may also harbor vulnerabilities that can compromise the security of the entire software ecosystem. According to the 'Checkmarx 2024 State of Software Supply Chain Security' report, a staggering 63% of survey respondents fell victim to software supply chain attacks in the last two years alone, highlighting the urgent need for a proactive approach to managing software dependencies.

Similarly, when software engineers integrate third-party libraries into their projects, they find themselves (often unknowingly) in a complex web of licensing obligations associated with those libraries. It is crucial to understand and manage these licensing obligations to ensure legal compliance and mitigate potential risks for the software product. Permissive licenses, such as MIT or Apache, allow the software to be used, modified, and distributed under relatively lenient terms, often requiring little more than the inclusion of the original copyright notice. Conversely, more restrictive licenses like GPL (GNU General Public License) or AGPL (Affero General Public License) may impose stricter conditions, requiring that derivative works be licensed under the same terms and providing access to the source code. Failing to understand and comply with these licensing obligations can have serious repercussions, potentially leading to legal disputes, loss of intellectual property rights, and reputational damage.

In this light, having accurate and up-to-date insight into the composition of the software is imperative from a risk management perspective. A Software Bill of Materials (SBOM) provides this insight. An SBOM provides a comprehensive overview of the components and versions of the libraries included in the software. It provides crucial visibility into the software supply chain and serves as a fundamental building block for ensuring security, compliance, and risk management in the software development lifecycle.

An SBOM can be instrumental in managing dependencies from both security and legal standpoints. It enables software engineers to identify and mitigate weaknesses present in the utilized libraries, thereby fortifying the overall security posture of the software. Furthermore, from a legal perspective, an SBOM empowers organizations to analyze the licensing obligations associated with their software components, ensuring compliance and mitigating legal risks. 

With the implementation of the Digital Operational Resilience Act (DORA), risk management regulations for financial institutions in the EU have expanded to include ICT and security risk management, broadening their focus beyond ensuring adequate capital to cover operational risks.

The Software Bill of Materials (SBOM) aligns with several of the DORA metrics, contributing to enhanced risk management in financial institutions. These contributions include:

• Reducing the change failure rate: SBOM facilitates the early identification of problematic components or dependencies, helping to prevent failures in production.
• Restoring service faster in case of security incidents: SBOM enables the quick identification of affected components, leading to expedited response times during security incidents.
• Reducing the lead time for changes: SBOM assists in identifying dependencies and potential conflict or compatibility issues upfront, thereby streamlining integration and deployment processes and reducing lead time for changes.

The mandatory nature of implementing the Software Bill of Materials (SBOM) is evident in view of its ability to directly contribute to meeting the risk management metrics outlined in the Digital Operational Resilience Act (DORA).

With customers increasingly demanding greater transparency into the components of the software they consume, an SBOM can also serve as a valuable asset in meeting these expectations. Notably, the Log4J incident, a remarkable moment in Fall 2021 when a vulnerability in a widely used library named Log4J was published, exemplifies the critical importance of having a comprehensive overview of the used software components: organizations worldwide scrambled to assess the impact of a critical vulnerability in the logging component on their software assets.

The establishment and maintenance of an SBOM, ideally integrated into the automated CI/CD pipeline, should become a standard step in every self-respecting software engineering department. It is imperative for CISOs and IT leaders to support software engineers in comprehending these new risks and taking appropriate measures as part of the software delivery and operations processes. In addition, the importance of the SBOM is becoming a crucial element as part of Due Diligence work to support a mergers and acquisitions since an exchange of software - and thus intellectual property (IP) - is seen as an event in which all liabilities related to these third-party libraries are transferred to another party. Setting up an SBOM is essential for proactively mitigating security and compliance risks, safeguarding the organization's reputation, and customer trust.

For organizations seeking expert support in setting up an SBOM for their software products and interpreting the results, Dennis Stam, Director at KPMG’s Digital Enablement practice in the Netherlands, and Kevin Bankersen, lead of KPMG’s Tech Advisory team, are available to provide tailored guidance and assistance. Reach out to us to explore how KPMG can collaborate with your organization to enhance your software supply chain security and compliance posture.

Dennis Stam
Director, Digital Enablement
KPMG in the Netherlands 

Kevin Bankersen
Senior Manager, Forensic
KPMG in the Netherlands