Organizations are waking up to the need to establish better software supply chain risk management policies and are taking action to address the escalating threats and vulnerabilities targeting this expanding attack surface.
These were among the findings of a Coalfire-sponsored, CyberRisk Alliance-conducted survey of 300 respondents from both software-buying and software-producing companies.
Most survey respondents (52%) said they are "very" or "extremely" concerned about software supply chain risks, and 84% of respondents said their organization is likely to allocate at least 5% of their AppSec budgets to manage software supply chain risk.
Software buyers are planning to invest in procurement program metrics and reporting, application pen-testing, and software build of materials (SBOM) design and implementation, according to the findings, released on Tuesday.
Meanwhile, software developers said they plan to invest in secure code review as well as SBOM design and implementation.
The survey also found 59% of software-development company customers have experienced purchase delays of up to three months due to concerns about code provenance.
As Coalfire vice president Dan Cornell explains, this statistic reflects a convergence between cybersecurity risk and more generalized business risk, indicating that organizations perceive software supply chain risks as being significant enough that they are slowing down purchases until those risks can be addressed.
"But in our modern business environment, delays add business risk because they postpone delivering value to stakeholders and open up opportunities for competitors to be first to market," he adds. "So, organizations need to look at how they’re addressing supply chain risk."
He says that if they can address that risk sufficiently but do it faster than their competitors, that means they can be quicker to market and quicker to start delivering value to their stakeholders.
"If they can’t, then the cybersecurity risk of software supply chains will increase the business risk of being late to take advantage of opportunities," he says.
C-Suite Takes Notice of Software Supply Chain Security
Cornell says some of the most significant findings for forward progress were around who in the responding organizations were concerned about software supply chain issues.
For software buyers, 51% of senior management (C-level) raised software supply chain concerns — this was second only to security team members raising the concerns (at 60%).
"I would expect security teams would be raising these questions, but I found it particularly interesting that these senior-level executives were also concerned with this issue," Cornell notes. "That’s fantastic, and a required precursor to making significant progress on this issue. Obviously, security teams care about this, but they don’t set corporate policy and direction — senior executives do."
He says as senior executives get on board, they will start to reflect this priority in budget allocations.
"Then — and only then — will the ball get rolling to address software supply chain issues in a structured and programmatic manner," he says.
On the software suppliers side, Cornell points out that 71% of respondents said that DevOps departments are driving software supply chain decision-making, even more than security teams (at 63%).
"This is really encouraging — I see having these initiatives being driven from outside security teams as being critical," he explains. "Security teams need to be advisers about risk, but DevOps teams are the ones who are selecting the open source components they use in their projects and making the decisions on what to upgrade and when."
He adds that seeing them take this issue seriously — and, arguably, the most seriously based on the responses — gives him hope that these issues will start to get addressed.
DevOps Teams Build Center of Risk Management
From Cornell's perspective, DevOps — or hopefully, DevSecOps groups — should really spearhead the management of software supply chain risk.
"They are the ones who own the software development process, and they see the code that is written," he says. "They see the components that are pulled in. They watch the software get built. And they make it available to whoever is next on down the line."
Given this vantage point, they can help to impact — in a positive way — an organization's software supply chain security status by implementing good policies and practices around what open source code is included in their software and when those open source components are upgraded.
"Forward-leaning DevSecOps teams can take advantage of their automation and testing to start pushing for more aggressive component-upgrade life cycles and other approaches that help minimize technical debt," he explains.
He says they’re also in a position and own the tooling to help generate SBOMs that they can then provide to software consumers who are in turn looking to manage their supply chain risk.
"An organization doesn’t have to adopt a DevSecOps approach to software development to address software supply chain security risks," Cornell says.
Building Frameworks for Risk Evaluation
In May, MITRE unveiled a prototype framework for information and communications technology (ICT) that defines and quantifies risks and security concerns over supply chain, including software.
That same month, the National Institute of Standards and Technology (NIST) updated its cybersecurity guidance for addressing software supply chain risk, offering tailored sets of suggested security controls for various stakeholders.
Meanwhile, a growing number of threat actors looking at supply chain companies as an entry point into enterprise networks, including North Korea's infamous Lazarus Group.