Open-source software underpins nearly everything in the digital world: In fact, it’s estimated to constitute up to 90% of modern software.

But while it has many advantages — it is collaborative, flexible and cost-effective, for starters — open source is also vulnerable because anyone can use, analyze, modify and distribute it. The modern software supply chain is full of open-source code, making it an enticing target for attackers.

The problem is that organizations simply don’t know what’s in their software supply chains, essentially making them sitting ducks.

This precarious situation is giving rise to software bills of materials (SBOMs), which are essentially an inventory of all components of a supply chain. Federal agencies are increasingly pushing for this model, with the National Security Agency (NSA) recently releasing recommendations on SBOM management.

“There has been a tremendous amount of uptick in software supply chain attacks,” said Chris Hughes, CISSP and chief security advisor at Endor Labs and Cyber Innovation Fellow at the Cybersecurity and Infrastructure Security Agency (CISA). “Attackers have realized ‘I can target something that everyone uses and have a massive downstream impact.’ It’s just more effective for them, kind of a spray and pray.”

Recommendations for software providers and users

SBOMs, a relatively new concept taken from the manufacturing industry, provide a catalog of all software components. Until their emergence, both providers and users had been largely blind to what’s in their supply chains — and they have misguidedly trusted them outright.

While they are still evolving, the NSA recommends that software providers and their customers “mature the mode of SBOM exchange” to protect IP and security while allowing for the “authenticity, accuracy, timeliness and efficiency” of SBOM information sharing.

Industry and government agencies should also expand research to better understand minimum requirements for safe SBOMs and share best practices toward standardization for other susceptible tech platforms such as operations technology, cloud and Software-as-a-Service and hardware/firmware), the agency says.

“Software developers must take ownership of their customers’ security outcomes rather than treating each product as if it carries an implicit caveat emptor,” the NSA says. Providers must make their products “secure by design and by default.”

On the other side of things, the NSA advises software users to refer to the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) and the Software Component Verification Standard (SCVS). They can also look at the Open Web Application Security Project (OWASP) and materials from CISA.

As Hughes noted, the recommendationscall for a collaboration between software providers and users. “It’s pushing secure by design, it’s changing that paradigm,” he said.

For providers, the guidance emphasizes the concept of “taking pride in securing products,” rather than just pushing them out the door and letting customers deal with subsequent problems.

On the customer side, “you essentially just bought the product, you didn’t necessarily know what was in it,” Hughes said, whether that was open-source or proprietary code. With SBOMs, customers can know exactly what components are in their software and applications and where they came from.

“There’s a lot of industry buzz around SBOMs,” said Hughes. “There’s a lot of effort by organizations like CISA encouraging manufacturers and suppliers to take ownership.”

Why so much open source?

Technology is moving fast with digital transformation efforts, the advent of cloud computing — and most recently the emergence of generative artificial intelligence (AI), which is moving at breakneck pace.

“Software quickly became part of every aspect of society, whether consumer goods or cybersecurity,” said Hughes.

He pointed out that the average code base has 500-plus different components. “The modern software ecosystem is very complex, there are a lot of moving parts and pieces.”

Building software can be expensive and time-consuming, and enterprises have learned that they don’t have to make everything from scratch; they can use what already exists, essentially pulling together different pieces and parts.

“It can save on time and cost if they don't have to buy everything themselves,” said Hughes, describing a “great thriving OS ecosystem.”

However, “that doesn’t mean there isn’t risk of using these things.”

Chad Loeven, VP of business development at cybersecurity company OPSWAT, agreed, saying “it's so easy to grab a random open-source library, stick it in your code, and hope for the best.”

However, open-source libraries remain a “weak underbelly” and pose significant security risks because they are easily targetable by attackers “aiming to compromise their integrity by inserting vulnerabilities or backdoors,” he said.

Both providers and consumers are responsible

Hughes points out that the recommendations go deeper on SBOM tooling and platform considerations than previous federal SBOM guidance. Many organizations and their leaders now know what the method is, but need help incorporating it.

While they may still be confused as to what to follow,  “the key is to not fall into analysis paralysis, and instead focus on starting somewhere,” he said.

This can include experimenting with SBOMs and integrating them into broader cybersecurity supply chain risk management (C-SCRM) programs that incorporate vulnerability and incident management.

“It’s important to understand what’s actually exploitable, are components known to be exploited, have they been exploited, can you actually reach it,” said Hughes.

This means providing details about all elements of a software supply chain, as well as security and vulnerability posture.

“If you’re a software supplier, you need to start to have mechanisms in place to provide that transparency,” Hughes advised.

Software consumers, meanwhile, should look at top SBOM platforms and identify necessary baseline elements as well as features and functionalities specific to their business.

Ultimately, responsibility shouldn’t fall into the hands of one or the other, Hughes emphasized.

“The goal is to have a top-down aspect from providers taking responsibility,” he said, “but also a bottom-up aspect of consumers demanding transparency.”