When you pick up a can of Diet Coke – or a container of any other processed food – you can readily see that everything inside is spelled out in a listing of ingredients on the exterior of the can. Thus, a potential drinker can judge whether what's inside will be OK to consume.

The U.S. federal government began requiring listings of ingredients in processed food and drinks way back in the FDR administration. The Food, Drug and Cosmetic Act of 1938 required that all food labels list the name and quantity of all ingredients. The law was passed in response to concerns about the safety of processed foods. The labeling has been modified a few times to become more specific since that first legislative act 85 years ago.

Before long, the same kind of requirement potentially could become law of the land for software makers: listing the ingredients (components) prominently, so the user can see them ahead of time. High-level discussions are being held in both private- and public-sector circles in response to increasing concerns about the safety of software. But there are clear pros and cons on this topic, which we discuss here.

Not all software makers are in favor of divulging any of their secret sauces. In fact, a number of prominent companies are keen to keep such detailed information about their software development out of public view. There are good reasons for this.

What is  a software bill of materials (SBOM)?

As a potential remedy, a tool called a software bill of materials (SBOM) has emerged as a key building block in software security and software supply-chain risk management. A SBOM is a nested inventory, a list of ingredients that make up software components. SBOM development has been in process since 2018 as a collaborative community effort, driven by National Telecommunications and Information Administration’s (NTIA) multistakeholder process.

The SBOM is a key inclusion in the Biden Administration's "Executive Order on Improving the Nation's Cybersecurity," issued May 12, 2021, stipulating that SBOMs are now requirements for all software developers.

These lists include information such as the name of each component, each version number and the license. SBOMs help organizations identify and mitigate security risks. For example, if an SBOM shows that a piece of software contains a known vulnerable component, the organization can take steps to update, patch or remove the component.

SBOMs can also be used to track the provenance of software, which can help organizations comply with regulatory requirements. Some of the reasons why SBOMs are important for IT security include the following:

  • They can help organizations identify and mitigate security risks. By knowing what components are in a piece of software, organizations can identify any known vulnerabilities in those components and take steps to mitigate the risks.
  • They can help organizations comply with regulatory requirements. Some regulations, such as the Cybersecurity Maturity Model Certification (CMMC), require organizations to have SBOMs for certain types of software.
  • They can help organizations manage risk throughout the software development lifecycle. SBOMs can be used to track the provenance of software, which can help organizations identify and mitigate risks at all stages of the development lifecycle.
  • They can help organizations make informed decisions about software procurement. By knowing what components are in a piece of software, organizations can make better decisions about whether to purchase or use that software.

SBOMs force software developers to be completely upfront on how they use open source software in their solutions. With most of the world's software containing at least a small number of re-used open source components, runtimes and many other items, decisions about whether SBOMs will be required for all software are incredibly important to the industry.

Does proprietary software become open source?

According to one of the most knowledgeable experts on SBOMs, the answer is yes. Major proprietary software companies shudder when they hear this.

"If you use an open source product, the licensing for that product is defined as it passes on," Walt Szablowski, founder and executive chairman of software asset management provider Eracent, told SDxCentral. Szablowski helped create the SBOM and has been trying to get it codified into law for nearly two decades.

"Copyleft (the legal technique of granting certain freedoms over copies of copyrighted works with the requirement that the same rights be preserved in derivative works) defines the rules of the open source product that you're using. If the open source product says if it's used in your app, then the entire app also has to be open source. You can't use their product and not follow their license rule.

"For example, Log4j (a Java-based logging utility that made headlines for its security vulnerabilities in 2021) is an open source product. It's used a lot. So you have to be very careful when you use open source because it may force you to make your product open source also. Now you can ignore it, or not tell anybody about it. Because once a program is compiled, it's very difficult to find out all the libraries that you use. So now you have a product that potentially is free (for use by anybody). This is why these large companies don't want to do it (allow SBOMs to be required)," Szablowski said.

Overall, SBOMs can serve as an important tool for IT security because they enable organizations to make better-informed decisions about software procurement, Szablowski said. But they are tricky to administer and enforce, because libraries used in software apps can be spread far and wide over the globe. As long as large software makers (such as Apple, Oracle and others) are fighting SBOM implementations, these tools may not become law for years to come. Naturally, these companies are not expecting to give away their software for free, but there are other considerations.

Why do proprietary software makers object to SBOMs?

Some vendors in the proprietary software sector have argued that SBOMs could be used to reverse engineer their software and that they could be a burden to develop and maintain. However, other developers – such as Microsoft – have recognized the value of SBOMs and have produced tools to make them available.

As the debate continues, it is clear that there are still many issues that need to be addressed before SBOMs can be widely adopted. Among them are the following:

  • Developing standards for SBOMs. There is currently no standard format for SBOMs. This makes it difficult for organizations to exchange SBOMs with each other. The Biden Administration has asked the industry for these.
  • Ensuring the accuracy of SBOMs. SBOMs can be complex and time-consuming to create. It is important to ensure that they are accurate, because inaccurate SBOMs can actually make software security worse.
  • Making SBOMs accessible to all stakeholders. SBOMs are not currently accessible to all stakeholders in the software supply chain. This makes it difficult to use them to improve software security.

Despite these challenges, there is a growing momentum behind SBOMs. "As more organizations adopt them, SBOMs have the potential to make a significant contribution to improving software security" the National Institute of Standards and Technology (NIST) said in a 2021 report. NIST is a U.S. government agency that provides standards and guidelines for improving the security of information systems.

In the report, NIST stated that SBOMs are "a critical tool for improving software security" and that "they can be used to identify vulnerabilities, track the provenance of software components and assess the risk of software supply chain attacks." NIST also recommended that organizations adopt SBOMs as part of their overall software security program.

Is supply-chain risk management necessary?

SBOMs are becoming increasingly important as software supply chains become more complex and interconnected. By providing a comprehensive view of the software components used in an application, SBOMs can help organizations to identify and mitigate security risks.

Implementing supply chain risk management (SCRM) for SBOM analysis enables organizations to safeguard their systems against cybersecurity breaches for the following reasons:

  • Increasing complexity of software supply chains: Today's software supply chains are highly complex, consisting of numerous components, vendors and dependencies. As organizations rely more on third-party software components, they also inherit risks associated with those components. SBOM analysis helps identify these risks and vulnerabilities in the supply chain, allowing organizations to address them proactively.
  • Visibility and transparency: SBOM provides a detailed inventory of all software components, their sources and dependencies. This visibility is crucial for organizations to understand the potential risks and attack surfaces in their software supply chain. SCRM helps organizations manage these risks by prioritizing them and taking appropriate actions.
  • Regulatory compliance: Governments and regulatory bodies are increasingly mandating organizations to implement supply chain risk management and SBOM analysis. Ensuring compliance with these regulations not only helps organizations avoid potential legal consequences but also demonstrates their commitment to security.
  • Faster vulnerability detection and remediation: SBOM analysis, as part of a comprehensive SCRM approach, can help organizations detect vulnerabilities and security risks in their software supply chain more quickly. This allows them to take prompt action to remediate these vulnerabilities, reducing the likelihood of a successful cyberattack.
  • Enhanced reputation and trust: Demonstrating a commitment to supply chain risk management and SBOM analysis can help build trust among customers, partners and stakeholders. This trust is essential for maintaining a strong brand reputation and ensuring long-term success.
  • Competitive advantage: Organizations that can effectively manage their supply chain risks and ensure the security of their software components have a competitive edge over others. A strong security posture can attract customers, investors and partners, leading to increased business opportunities.
  • Cost savings: Addressing vulnerabilities and security risks proactively, as part of a comprehensive SCRM strategy, can help organizations avoid the costly consequences of a cyberattack, such as system downtime, data breaches and reputational damage.

Implementing supply chain risk management for SBOM analysis helps organizations understand and manage their software supply chain risks, ensure compliance with regulations, detect vulnerabilities faster, enhance trust and maintain a competitive advantage, all while potentially saving costs in the long run.

Next steps in the SBOM debate

The next step in the SBOM debate for software makers is to develop and implement standards. There is currently no standard format for SBOMs, which makes it difficult for organizations to exchange SBOMs with each other. Developing standards will help to ensure that SBOMs are accurate and consistent and that they can be used effectively to improve software security.

In addition to developing standards, software makers need to make it easier for organizations to obtain and use SBOMs. This could involve providing SBOMs to customers directly or making them available through third-party repositories. Software makers should also make it clear to customers how SBOMs can be used to improve software security.

By taking these steps, software makers can help to make SBOMs a more widely adopted and effective tool for improving software security, the federal executive order said.