Eight themes of mature software supply chain management practices
REMEDIATION
How do you implement fixes to address identified OSS component risk?
SUPPLIER HYGIENE
Do you know if your OSS components come from a trusted, quality supplier?
APPLICATION INVENTORY
Do you know the key details of your organization's applications, such as stakeholders, ownership, construction, and the software bill of materials (SBOM) for OSS components?
GIVING BACK
Do you contribute to the OSS community?
POLICY CONTROL
What is your tolerance for risk? Do you have automated policy enforcement?
PROJECT CONSUMPTION
Do you govern OSS component selection?
BUILD & RELEASE
Do you understand how your software "parts" and processes come together to build and release applications into production?
DIGITAL TRANSFORMATION
What plans, resources, and training do you have to help institutionalize new processes and tools?
How mature are today’s software supply chains?
We've distilled and presented collective insights from the 621 surveyed individuals in Figure 4.1. To develop this summary, we averaged each individual’s responses on questions that align with the eight themes. In each theme, we scored the responses from 1 to 5, corresponding to the five stages of software supply chain maturity. From Unmanaged (least mature) to Monitor & Measure (most mature), as noted in Figure 4.2.
FIGURE 4.2. FIVE STAGES OF SOFTWARE SUPPLY CHAIN MANAGEMENT MATURITY
Less Mature
More Mature
This first stage is referred to as the Unmanaged stage because organizations are often operating with an "anything goes" mindset, are often reactive, and have minimal process/oversight related to the themes.
A realization of some sort is usually the impetus for thrusting an organization into the Exploration stage. This is often triggered by an "event" that causes an "all hands on deck" reaction to uncover necessary information/solutions, or a champion of some sort leading an improvement effort. This stage is often focused on identifying the perceived problem/inefficiency, learning about current implementations, and starting to explore potential solutions.
In the midst of starting to define processes and implement tooling to improve the identified problem, Ad Hoc solutions reign as the teams work toward institutionalization and socialization of new tooling and processes.
In the Control stage, ad hoc solutions give way to more formalized governance processes across the enterprise. Socialization and institutionalization of these processes and tools is ongoing, but for the most part, stakeholders are bought in to the need for improvement measures and are working towards compliance.
The Monitor and Measure stage occurs once new processes and tools have been institutionalized, and organizations have reached a phase of being able to proactively address OSS component risk. In addition, a healthy amount of ROI is realized, and measurements to demonstrate success are available.
However, in line with the chapter's earlier findings, a broader lack of overall maturity and efficiency in software supply chain management persists. While the focus on open source risk has intensified, this year’s findings revealed a decline in the use of automated open source processes, a lack of well-defined processes, and a lower number of respondents that follow their organization's open source approval procedures. In other words, organizations continue to grapple with immature practices that waste time and resources – weighing teams down and slowing development.
A year-over-year decrease in agreement (9.5%) and increase in disagreement (3.4%) with the statement "We have executive sponsorship" underscores that achieving software supply chain maturity necessitates not only effective tools but also strong organizational support.
In summary, although there is an increased focus on and awareness of open source risk, organizations have ample ground to cover in implementing best practices for mitigating these risks effectively.
In summary, although there is an increased focus on and awareness of open source risk, organizations have ample ground to cover in implementing best practices for mitigating these risks effectively.
Organizations continue to grapple with immature practices that waste time and resources – weighing teams down and slowing development.
Finding #2: Rise in demand for software bills of materials
Thanks to mandates outlined in President Biden's Executive Order 14028, Improving the Nation’s Cybersecurity and growing global regulatory efforts, one open source best practice that is experiencing a growth in adoption is the use of an SBOM.An SBOM serves as a comprehensive inventory, outlining the various components and dependencies of a software application. It provides a detailed list of the software's building blocks, including open source and third-party libraries, along with their respective versions. This document serves as a critical resource for understanding and managing the software supply chain. By enabling developers and organizations to accurately track and assess the security and licensing aspects of software components, SBOMs play a vital role in software development, cybersecurity, and regulatory compliance. SBOMs provide transparency and visibility into software composition, thereby facilitating efficient risk management, enhancing vulnerability response, and supporting effective software maintenance. Ultimately, while the creation of SBOMs themselves doesn’t equate to security, the adoption of SBOMs contributes to building secure, reliable, and trustworthy software systems, benefitting both software producers and consumers.
This year, we took a deeper look at the usage and demand for SBOMs. Findings revealed that nearly 53% of the surveyed engineering professionals reported they are generating an SBOM for every application (Figure 4.3). Notably, respondents who adopted this practice were less likely to report security breaches.
0%
of leaders reported generating SBOMs for their applications
0%
of engineering professionals reported generating SBOMs for their applications
However, when we contrast this with survey results from cybersecurity leaders at large enterprises (over £50 million/$50 million annual revenue), we observed that 75% of these leaders reported generating SBOMs for their applications. Compared to the 53% reported by engineering professionals in our general survey, this discrepancy underscores the heightened demand for SBOMs at larger enterprises. Although, this finding also might just track with last year’s data that revealed how managers often report higher stages of maturity compared to other roles. Compared to respondents working in information security, IT managers were 1.8 times more likely to strongly agree with the statement "We know the Software Bill of Materials (SBOM) for every application."
In addition, nearly half of the respondents have started asking vendors to supply SBOMs for purchased software, underscoring a higher demand for increased transparency in software supply chains.
In addition, nearly half of the respondents have started asking vendors to supply SBOMs for purchased software, underscoring a higher demand for increased transparency in software supply chains.
Finding #3: The critical connection of hygiene and speed in risk mitigation
This year, we investigated how organizations have been impacted by open source risk, particularly those that have experienced security breaches.Our analysis revealed a connection between security breaches and suboptimal management practices such as:
- deploying every change directly to production;
- breaking the functionality of their applications with dependency upgrades; and
- adhering to an entirely waterfall development practice.
Additionally, organizations that experienced breaches exhibited delayed awareness and mitigation of vulnerability risks. Breached organizations were 2.9x more likely to take over six months to become aware of open source vulnerabilities after their discovery, and 1.7x more likely to report never fixing a vulnerability.
Overall, our survey revealed that only 22% of organizations become aware of new open source vulnerabilities within a day of disclosure. Thirty-nine percent (39%) discover them within one to seven days, and 28% take over a week to become aware.
Overall, our survey revealed that only 22% of organizations become aware of new open source vulnerabilities within a day of disclosure. Thirty-nine percent (39%) discover them within one to seven days, and 28% take over a week to become aware.
Our survey revealed that only 22% of organizations become aware of new open source vulnerabilities within a day of disclosure.
The same survey found that 39% of respondents require over a week to mitigate vulnerabilities (Figure 4.4). This means that the majority of bad actors have days to launch a malicious attack on enterprise targets.
FIGURE 4.4. TIME TO REMEDIATE KNOWN VULNERABILITIES AFTER DETECTION
In the context of organizations grappling with security breaches, these findings emphasize the critical connection between maintaining strong hygiene practices and swift risk mitigation. Organizations that have already embarked on the journey to software supply chain maturity are better-equipped to effectively manage open source risks. With advanced software supply chain maturity, these organizations apply streamlined processes for identifying, responding to, and resolving vulnerabilities, significantly reducing the vulnerability window and contributing to their overall maturity.
For organizations navigating the complexities of open source risk and striving for swift mitigation, the path to software supply chain maturity emerges as a pivotal strategy. This enables them to enhance their resilience, ultimately fortifying their security posture and safeguarding against potential breaches.
These findings align with the eight themes of software supply chain management outlined at the beginning of this section. These themes encompass practical strategies aimed at not only enhancing security but also at optimizing developer productivity and reducing the waste of developer time. The journey toward software supply chain maturity is not just a path to enhanced security — it’s also a path to stop wasting developer time. By improving software supply chain maturity, organizations create an environment in which developers can focus on innovation, leading to more resilient and secure software.
For organizations navigating the complexities of open source risk and striving for swift mitigation, the path to software supply chain maturity emerges as a pivotal strategy. This enables them to enhance their resilience, ultimately fortifying their security posture and safeguarding against potential breaches.
These findings align with the eight themes of software supply chain management outlined at the beginning of this section. These themes encompass practical strategies aimed at not only enhancing security but also at optimizing developer productivity and reducing the waste of developer time. The journey toward software supply chain maturity is not just a path to enhanced security — it’s also a path to stop wasting developer time. By improving software supply chain maturity, organizations create an environment in which developers can focus on innovation, leading to more resilient and secure software.
The journey toward software supply chain maturity is not just a path to enhanced security — it’s also a path to stop wasting developer time.
The journey toward software supply chain maturity is not just a path to enhanced security — it’s also a path to stop wasting developer time. By improving software supply chain maturity, organizations create an environment in which developers can focus on innovation, leading to more resilient and secure software.
Establishment and Expansion of Software Supply Chain Regulations and Standards
