In late March, Microsoft developer and engineer Andres Freund discovered that someone had inserted a backdoor into the open source data compression tool XZ Utils, a ubiquitous feature on Linux installations.

The discovery averted what could be the most disastrous supply chain attack since the SolarWinds malicious software infection, which first came to light in 2020 and affected hundreds of global organizations, including key parts of the U.S. federal government.

It was also another wake-up call for organizations: managing risks in the software supply chain remains a top priority in maintaining overall network and system security.

The Biden administration has taken significant action in the wake of SolarWinds by issuing a sweeping executive order (EO) on cybersecurity, indicating the administration’s commitment to improving the resilience, diversity, and security of the software supply chain.

The Cyber ​​EO included a series of orders for the Cybersecurity and Infrastructure Security Agency (CISA), the Office of Management and Budget, and other government agencies to create new tools, standards, procedures, and procurement guidelines to increase the security of the software underlying the nation’s digital networks.

Supply chain issues persist despite long list of improvements

One of these publications was the publication by the U.S. Department of Commerce of the Minimum Elements Required in a Software Bill of Materials (SBOM), an “ingredients list” of all of the potentially hundreds of different components that typically make up any given piece of modern software.

Perhaps more importantly, the EO also required the National Institute of Standards and Technology (NIST) to develop updated guidance for securing the software supply chain, design a Secure Software Development Framework (SSDF), identify practices that enhance the security of the software supply chain, and produce minimum standards for vendor testing of software code, among other software security tasks.

Additionally, CISA recently launched a secure-by-design initiative to reduce the number of exploitable flaws in software products before they reach the market. In collaboration with private sector partners, CISA will also produce a software assurance buyer’s guide for government enterprise customers.

Additionally, the White House released a 2023 National Cybersecurity Strategy that supports the development of a software liability regime that incentivizes significant investment in secure coding.

Experts say that software supply chain security is headed in the right direction because of this dizzying array of developments. However, despite the rapid progress made by these efforts, implementing good software security practices at the organizational level is still a challenge.

Experts cite challenges including the sheer size of the software supply chain, the lack of clear definitions, the lack of accountability for open source software, the lack of data to guide actions, and the misplaced hope that SBOMs are a central solution for identifying unsafe software components.

Software supply chain solutions are still in the ‘early stages’

“I think it’s very early to say that the industry is managing the security risks of the software supply chain,” Dan Lorenc, CEO of Chainguard, tells CSO. “The challenges are improving the entire software development lifecycle, because it’s huge and it’s complex. There’s first-party code, there’s third-party code, there’s open-source code, where it’s first-party code but it’s written by many different teams within an organization. You can harden certain parts of the software supply chain, but attackers can just find the weakest element in that chain because it’s a very large chain.”

Right now, the job of securing the software supply chain in most organizations falls to the chief technology officer, not the CISO, Lorenc says. But he argues that more collaboration is needed between the two roles.

“Software supply chain is one of the bigger areas where CISOs are feeling the pain, but they’re not the ones who are actually empowered to solve it, unlike other areas of security, because it’s a software development and software lifecycle problem. You really have to address the way that software is written, developed, operated and managed, which typically falls under a CTO. It’s an area where those two groups really have to work together in ways that they haven’t traditionally done in large enterprises.”

Darren Meyer, a research engineer at Endor Labs, believes another change that can help organizations improve the security of their supply chain software is to better define what software is and develop a common set of definitions and framework.

“I think one of the hardest things the industry has to deal with right now is a lack of good shared definitions,” he says. “We see a lot of cases where people can’t agree on where the boundaries of the software supply chain are. Everyone has their own definition. If I go to five different companies and they say they have a supply chain security program, I see five very different things.”

Open source software remains a major problem

Open-source software is a particularly tough nut to crack when it comes to managing security risks in the software supply chain. “Most statistics say that 90% to 95% of the source code in use today within companies is open source,” Lorenc says. “No matter how much your CISO wants to spend or how much your security team cares, they can’t even address risk in that part of the supply chain because it’s coming from outside the organization and they typically don’t even have vendor contracts or anything like that to promote that code.”

Even the federal government is struggling to cover open-source software security. “If you look at a lot of the regulations and everything else that’s going on, they have to explicitly (exempt) open source because CISA can’t just wave a magic wand and demand that open-source projects change how they do things,” Lorenc says.

Meyer says, “I think people are missing the conversation a little bit because everyone is also using open-source software. That’s probably the biggest part of your supply chain these days, and it’s the only supply chain in the world where ‘I found it on the floor’ is a legitimate source.”

“I don’t really have a throat to choke,” he says. “I don’t have a compliance program to worry about. I don’t have a questionnaire that someone can testify to. I don’t have anyone to sue if I get something bad. So a lot of the responsibility for my upstream supply chain falls on me as an organization that builds software.”

The SBOM is not a magic solution to supply chain problems

Another obstacle to better software security is the lack of good data and insight into software components and their potential risks.

“I spend a lot of time there and there are a number of different angles as to why data is so challenging,” Andrea Little Limbago, senior vice president of research and computational risk modeling at Interos, said recently at a CISA conference on supply chain security.

“We’re in a time now where there’s more data available than ever before in human history. The problem is that with that daily deluge, there’s actually a lack of really good quality data to deal with. And then it’s sometimes really hard to know whether it’s real or not.”

Furthermore, much of the data you need, particularly good cyberattack metrics, remains proprietary. “There’s no incentive structure yet to share it. So getting access to some of that critical data that’s needed to build greater resilience in your supply chain becomes very difficult,” Limbago said.

Despite SBOM’s conceptual appeal as a simple tool for spotting potentially problematic software components, its value is still too limited to be useful. “What I see is that SBOM is too early for proactive use by departments and agencies,” Rebecca McWhite, technical lead for cyber supply chain risk management at NIST, said at the CISA conference.

It is critical to create and update software asset inventories

“I think the one area that I’m pretty pessimistic about is SBOMs, which is probably the lowest priority area in this whole space that I would recommend,” Lorenc said. “I think CISA has done a pretty good job of explaining the benefits that they do have, but for some reason a lot of people just jump to SBOMs as this magic bullet that’s going to solve all of these problems.”

Lorenc thinks SBOMs should be a lower priority than more critical tasks, such as creating and updating software asset inventories, which he believes far too few organizations do well. “If you don’t even know what systems you’re running, it doesn’t make sense to consult SBOMs about what’s in those systems. And unless you have really, really, really good asset management, SBOMs aren’t going to add much to your incident reporting.”

Meyer says, “There’s definitely a problem with the maturity of SBOMs and the production and consumption of SBOMs, despite the fact that there are two well-established computer-readable exchange formats (SPDX developed by the Linux Foundation and CycloneDX developed by OWASP) that you can convert between. There are still a lot of people who are asking their compliance teams to be the clearinghouses for SBOMs and other things. And the compliance teams typically don’t have the tooling or the knowledge to use these computer-readable formats.”

There is hope for a more secure software future

Despite some challenges, experts are optimistic about the prospects for a more secure software future. “The supply chain is only as strong as its weakest link,” Limbago said. “If we can help improve that across our entire supply chain, we can improve the security posture of all of our partners and collaborate and work on data sharing. There’s just a tremendous amount of opportunity for all of us to become much more secure and build that collective resilience.”

Lorenc thinks that once all the security efforts mandated by the Biden administration start to trickle down into the software security space, the jobs of cybersecurity professionals will become much easier. “Once we get to a state where software is developed securely, I think it will generally be less effort and work for (security teams) because the tools will just be updated to do all of these things automatically for people.”

But righting the software security ship won’t happen quickly. “A lot of the software out there was written decades ago, and you can’t just rewrite these kinds of things overnight,” Lorenc says. “To make a broad change in the industry, the government moves slowly, and then the industry moves even slower. So it’s a matter of five or 10 years.”