Software supply chain risks aren’t going away. Here’s how to manage them

Your next cybersecurity incident could be the result of someone else’s breach.

There’s ample evidence to suggest that software supply chain attacks have been on the rise for years. And a recent report by the think tank Ponemon Institute, in conjunction with security firm Synopsys, found 59% of nearly 1,300 IT and IT security practitioners reported their organization had experienced at least one such attack.

Approximately 28% of respondents pinned the attack on an “unpatched open-source vulnerability previously detected, and 23% of respondents say it was the result of a zero day vulnerability,” according to the report. Others pointed to a compromise of build pipelines via malicious injection (21%), malicious dependencies (19%), and other causes (8%).

Asymmetric difficulty

It’s a familiar story to security practitioners: The threat actors behind software supply chain attacks are adopting sophisticated tactics, techniques, and procedures faster than defenders can keep up.

Attackers are picking software supply chains because their growing complexity enables them to exploit “asymmetric difficulty,” said Lloyd Evans, vice president of governance, risk, and compliance at digital services firm Aquia. Attackers with visibility into supply chains can often find low-hanging fruit like configuration errors or unpatched vulnerabilities buried deep enough to avoid scrutiny by security professionals.

“Security teams have to focus on the highest-prioritized, highest-leverage activities that can reduce the most risks,” Evans told IT Brew. Modern software development practices rely on multiple layers of dependencies downstream from each other, he said, and developers of end products might find it difficult or impossible to handle them all without assistance from automation-enabling tools like software bills of materials (SBOMs).

Shandra Gemmiti, senior director of cross-portfolio solutions at Synopsys’s Software Integrity Group, pointed out that 45% of respondents reported increased security budgets, but a little under 40% felt funding or staffing levels were adequate. The survey also showed low adoption rates of labor-saving methods, such as policy-based open-source management or automated monitoring, she said.

“There are so many respondents still relying on manual code reviews, manually monitoring external security feeds for new security vulnerabilities, and manually pulling together and compiling SBOMs,” Gemmiti told IT Brew. “It’s just not sustainable.”

The survey also found just 35% of respondent organizations are generating or producing SBOMs, and those that did were likely to cite industry regulations or customer and government requirements as motivators.

That “indicates they’re really only producing [SBOMs] on an ad hoc basis,” Gemmiti said.

Ranking (and preventing) risk

Traditional methods of ranking risk like the Common Vulnerability Scoring System (CVSS) can be overwhelmed by sheer volume, Evans warned.

“It’s a very unforgiving approach to do vulnerability management in this dynamic,” Evans said. “You scan an application, you might get hundreds, you might even get thousands of findings, all with a severity score.”

One potential solution is the exploit prediction scoring system (EPSS) model, an emerging standard that uses a variety of data sources to rank all published common vulnerabilities and exploits by probability of an actual attack. While EPSS helps security professionals prioritize remediation efforts, it’s also a relatively new standard with some limitations, like having incomplete data that prevents ranking many vulnerabilities.

Developers can also reduce risk by remaining focused on value streams instead of chasing trends or implementing unnecessary features, Evans said—the fewer software components needed to satisfy customer requirements, the better. He also advised weighing the ease and cost savings of relying on open-source components against potential risks, like project abandonment or hijacking.

If developers can’t be confident in their ability to track vulnerabilities and configurations in open-source dependencies, “leveraging software by purchasing from a company who is doing that might be a better option, and a better use of resources,” Evans told IT Brew.