5 key takeaways from ESG's software supply chain complexity report
"The Growing Complexity of Securing the Software Supply Chain" report highlights key challenges for application security teams. Here's what you need to know.
Organizations are struggling with software supply chain security. That fact was further exposed this month with the Enterprise Strategy Group's new study, “The Growing Complexity of Securing the Software Supply Chain.”
The 28-page study, based on a survey of 368 IT, cybersecurity, and application development professionals at organizations in the United States and Canada, found that 91% of organizations have experienced a software supply chain incident in the last 12 months. The most common security incidents were zero-day exploits on vulnerabilities in third-party code (41%); misconfigured cloud service exploits (40%); open-source software and container image exploits (40%); secrets, passwords, and tokens stolen from source code repositories (37%); and API data breaches in third-party software and code (35%).
The complexity of creating software in the modern era makes it difficult to secure the software supply chain, Data Theorem COO Doug Dooley said in an interview.
This is a pervasive and deep problem. No company is building 100% of their software by themselves anymore. There's a long tail of software suppliers in the ecosystem right now, from cloud service providers to open-source software developers to software vendors.
The ESG study found that one of the most critical needs of organizations trying to secure their software supply chain is to have a handle on what's in their software and how it's working. "Because of the massive number of suppliers and partners, continuous discovery of components across the software supply chain is a major challenge," ESG Practice Director for Cybersecurity, Melinda Marks, said in a statement.
Marks said a majority of organizations (88%) in the survey stressed the importance of having an accurate inventory of third-party APIs and cloud services, making software bills of materials (SBOMs) key. However, she said the study found that creating and maintaining SBOMs was proving to be a challenge.
Here are five key takeaways from the new ESG software supply chain security study.
1. Organizations say their supply chain security is 'robust,' but challenges persist
Despite nearly three-quarters (74%) of organizations saying they have “robust” software supply chain security capabilities, they report multiple challenges and concerns with using third-party software. Specifically, at least one-third of respondents identified being too dependent on open-source software (OSS), struggling to identify vulnerabilities in the OSS code, or being victims of hackers that target popular OSS code.
2. Optimizing the efficiency of security in development is paramount
Organizations need to look for ways to optimize efficiency as they incorporate security into their development processes to secure their software supply chain. Currently, organizations use tools both periodically by set time periods and upon code changes.
3. Few organizations are using tools to generate SBOMs
Regulations increasingly call for SBOMs to ensure software supply chain security. However, organizations are struggling to build accurate inventories of their software code composition. According to the study, only 22% of organizations are using an SBOM-generation tool. Of those, only 48% currently generate an SBOM as a part of the application development process for all applications, while 49% do so on a case-by-case basis.
4. SBOMs are vital but still too difficult to generate
Those organizations generating SBOMs find them useful for managing software supply chain risk. Unfortunately, more than three-quarters of the organizations using tools to generate SBOMs find the process challenging (36%) or very challenging (43%).
While it's understood SBOMs are important to software supply chain security, most organizations are challenged with creating and maintaining current SBOMs. Organizations need continuous runtime scanning, discovery and inspection of open-source components, third-party libraries, and APIs in source code to best secure their applications.
Security organizations realize the need to empower developers to efficiently fix code issues to mitigate application vulnerabilities. Most organizations are prioritizing this effort to “shift security left” to developers, with more than nine in 10 identifying it as a high (39%) or top (52%) priority. The good news is that a majority of developers are completely (40%) or mostly (24%) comfortable taking on security responsibilities, with only 11% not comfortable with the idea.
When failure is not an option
The emergence of cloud-native applications and a growing reliance on third-party APIs and cloud services have fundamentally altered the software supply chain security challenge, by introducing new attack surfaces that have "already been exploited and are poised to remain in the crosshairs of hackers and cybercriminal activity," Dooley said.
Invest in modern software supply chain security tools
Nearly half or survey respondents said the scanning of open-source code components and third-party libraries for vulnerabilities (44%) was their top priority for investments in software supply chain security over the next 12 to 18 months. "That's a basic first step," Dooley said. Other items on the priority list include inspecting APIs in source code (39%), creating an SBOM (38%), and scanning production environments for vulnerabilities (37%).
Where it becomes more complicated is when you're using a third-party API service and you don't have the underlying code. You're using it like a black box.
Doug Dooley
Failure to rise to the challenge of supply chain security problems puts sensitive data and applications at risk and erodes the trust and integrity enterprise customers have built their business on, Dooley said.
Matt Rose, field CISO at ReversingLabs, said SBOMs are a great first step in an organization's software supply chain security journey. But they need to go beyond the SBOM's creation to a comprehensive software supply chain security program.
SBOMs can help in a lot of ways because they give a list of all the ingredients in a software package. But they don't give you information on how these ingredients interact. It is not realistic to think that a third-party vendor will send source code for you to inspect for supply chain risks. That's because no vendor is ever going to say, "My software is riddled with holes."
Software supply chain security mechanisms need to be implemented in a way that is not cumbersome, complex, or disruptive to existing CI/CD and release processes. NIST's Secure Software Development Framework is the best standard right now, but there are others as well.
While legacy AppSec testing (technologies such as SAST, DAST, RASP, and SCA) focuses on application source code, packages, and an application at runtime, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks.
Matt Rose
With complex binary analysis, organizations can evaluate all of the software they produce and consume, including third-party commercial software. The Enduring Security Framework, a public-private working group led by the National Security Agency (NSA) and CISA, recently stepped up its software supply chain security guidance with a call for complex binary analysis and reproducible builds, Rose noted.
Follow us
Subscribe
Get the best of RL Blog delivered to your in-box weekly. Stay up to date on key trends, analysis and best practices across threat intelligence and software supply chain security.
Topics
Shai-Hulud worm arrests: Why this is not the end
The TeamPCP actors, alleged to be behind one of the most active supply chain threats, were arrested — but this is not the end of Shai-Hulud.
