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 any more. 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.”
—Doug Dooley

The ESG study, which was prepared for Data Theorem, 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 said the importance of having an accurate inventory of third-party APIs and cloud services was key, making software bills of materials (SBOM) 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.

[ Get the report: The Buyer’s Guide to Software Supply Chain Security | Join the Webinar discussion: Why you need to upgrade your AppSec tools for the new era ]

1. Firms 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 key

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.”
—Melinda Marks

5. Security can be scaled by enabling developers

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

The top priority for investments in software supply chain security over the next 12 to 18 months, nearly half the scanning open-source code components and third-party libraries for vulnerabilities (44%). “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.”
—Matt Rose

Given the complexity and disparity of software supply chains, Rose wrote recently that the complexity of modern development called for modern tools to manage risk across the software development lifecycle (SDLC).

“While legacy AppSec testing (technologies such as SAST, DAST, RASP, and SCA) focuses on source code, 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. More recently, the Enduring Security Framework, a public-private working group led by the National Security Agency (NSA) and CISA, stepped up its software supply chain security guidance with a call for complex binary analysis and reproducible builds, Rose noted.

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by John P. Mello Jr.. Read the original post at: https://www.reversinglabs.com/blog/complexity-and-software-supply-chain-security-study-5-key-takeaways