How should businesses address risks in software supply chain attacks?
Software supply chain attacks are becoming increasingly rampant as cybercriminals continue to find ways to wreak havoc on organizations. In fact, research by NCC group showed that cyberattacks on supply chains have increased by 51% in the last six months.
However, the study also showed that only 53% of the survey respondents felt that their company and its suppliers are equally responsible for the security of supply chains. The lack of responsibility and ownership could not only lead to these organizations being targeted but also face regulatory penalties.
For example, the EU’s Digital Operational Resilience Act (DORA) mandates that financial entities include key security requirements in their contracts with third parties, indicating that regulators are increasingly emphasizing the organization’s role in supplier risk management.
What makes an attack on the software supply chain even more concerning is that the lack of visibility could not only disrupt the organization but almost every process and other organizations that are linked to it as well.
Another survey also showed that 64% of organizations conceded that an attack against their software development environment is unstoppable. 71% also admitted that their organizations suffered data lost or compromised assets from successful software supply chain attacks.
As such, some tech companies are already working toward improving the software supply chain. This includes Google which recently revealed plans to work with GitHub to create a forgery-proof method for signing source code as part of its ongoing efforts to better secure software supply chains.
According to Google’s Open Source Security Team, many of the recent high-profile software attacks that have alarmed open-source users globally were consequences of supply chain integrity vulnerabilities. This means attackers gained control of a build server to use malicious source files, inject malicious artifacts into a compromised build platform, and bypass trusted builders to upload malicious artifacts.
“Each of these attacks could have been prevented if there were a way to detect that the delivered artifacts diverged from the expected origin of the software. But until now, generating verifiable information that described where, when, and how software artifacts were produced (information known as provenance) was difficult. This information allows users to trace artifacts verifiably back to the source and develop risk-based policies around what they consume,” stated the Google Open Source Security Team.
For Tim Mackey, Principal Security Strategist with the Synopsys Cybersecurity Research Centre, software supply chains is complex entities often comprising hundreds of “suppliers” per application. He explained that each supplier, or dependency as its also known, represents a vector for software to enter an organization. Mackey said that software is often subject to a vendor risk management review prior to procurement, but for some software, such as open-source software or SDKs, there is no explicit vendor against which to perform a risk assessment.
Mackey highlighted that’s partly due to the decision-making related to supplier selection in an open-source context being made by developers who are measured more by their ability to quickly implement features rather than their skills in risk mitigation or compliance reviews.
Mackey added that given the complexity of software supply chains, and the growing attention to them within the business, it’s reasonable to expect cybercriminals to attempt to disrupt business operations by targeting the supply chains powering the business.
“Addressing the risks present in software supply chains starts by recognizing that a traditional vendor-centric view of supplier validation is insufficient to accurately describe the risks requiring mitigation. Instead, mitigation strategies must be tailored to each of the potential methods for software to enter a business where process threats are identified well in advance of any requirement to mitigate vulnerabilities or address a cyber-incident,” commented Mackey.
20 February 2024
20 February 2024
19 February 2024