The Enterprise Strategy Group report, Walking the Line: GitOps and Shift Left Security: Scalable, Developer-centric Supply Chain Security Solutions, shows that software supply chain risk extends beyond open-source.
In response to software supply chain attacks such as Log4Shell, SolarWinds, and Kaseya, 73% of respondents say they have increased their efforts significantly to secure their organisations’ software supply chain through a variety of security initiatives.
These initiatives include the adoption of some form of strong multi-factor authentication technology (33%), investment in application security testing controls (32%), and improved asset discovery to update their organisation’s attack surface inventory (30%).
Despite those efforts, 34% of organisations report that their applications have been exploited due to a known vulnerability in open-source software (OSS) within the last 12 months, with 28% having suffered a previously unknown (“zero-day”) exploit found in open-source software.
As the scale of OSS usage increases, its presence in applications will naturally increase as well. Current pressure to improve software supply chain risk management has placed a spotlight on software Bills of Materials (SBOMs).
The other side of the coin
But exploding OSS usage and lacklustre OSS management have made the compilation of SBOMs complex—as confirmed in the ESG research, which shows that 39% of survey respondents marked this task as a challenge of using OSS.
“As organisations are witnessing the level of the potential impact that a software supply chain security vulnerability or breach can have on their business through high-profile headlines, the prioritisation of a proactive security strategy is now a foundational business imperative," said Jason Schmitt, general manager of the Synopsys Software Integrity Group.
“While managing open-source risk is a critical component of managing software supply chain risk in cloud-native applications, we must also recognize that the risk extends beyond open-source components. Infrastructure-as-code, containers, APIs, code repositories—the list goes on and on and must all be accounted for to ensure a holistic approach to software supply chain security.”
Rising fears about open-source
While open-source software may be the original supply chain concern, the shift toward cloud-native application development has organisations concerned about the risks posed to additional nodes of their supply chain.
This includes not only additional aspects of source code, but also how cloud-native applications are stored, packaged, and deployed, as well as how they interface with one another through application programming interfaces (APIs).
About 45% of survey respondents identified APIs as the vector most susceptible to attack, along with data storage repositories (42%) and application container images (34%).
Nearly all (99%) of respondents said their organisations either currently use, or plan to use, OSS within the next 12 months. While concerns exist with the maintenance, security, and trustworthiness of these open-source projects, the top concern relates to the scale at which open-source is being leveraged within application development.
Fifty-four per cent of organisations list “having a high percentage of application code that is open-source” as their primary concern.
The possibilities
Tim Mackey, principal security strategist within the Synopsys Cybersecurity Research Center, says an SBOM allows operators of software to know what third-party software producers included in their applications, whether it be from an open-source, commercial or contracted third party.
This knowledge is critical when designing a patch management process, as without it there is an incomplete view of the software risks present in any application—regardless of origin.
“Armed with this information, once the next zero-day vulnerability of Log4Shell proportions emerges (and it will) your organisation will be able to act quickly and effectively to defend against attacks targeting third-party software components,” he added.
Survey findings also suggest that although developer-focused security and “shifting left”—a concept focused on enabling developers to conduct security testing earlier in the development lifecycle—is growing among organisations building cloud-native applications, 97% of organisations have experienced a security incident involving their cloud-native applications within the last 12 months.
Faster release cycles are also presenting security challenges for all teams. Application development (41%) and DevOps (45%) teams agree that developers often skip established security processes, while 55% of application developers agree that security teams lack visibility into development processes.
Sixty-eight per cent of respondents indicated that they are highly prioritising adopting developer-focused security solutions and shifting some security responsibilities to developers, although more developers (45%) are currently responsible for application security testing than security teams (40%). These developers are twice as likely to use internally developed or open-source security tools than specialized third-party vendor solutions.
At the same time, developers are playing a bigger role in securing the software supply chain of cloud-native applications, yet only 36% of security teams reported being comfortable with development teams taking responsibility for testing.
Concerns such as overburdening development teams with additional tooling and responsibilities, disrupting innovation and velocity, and obtaining oversight around security efforts remain the biggest obstacles to developer-led application security efforts.
