SBOMs are a needed ingredient but not the full recipe for software supply chain security

Validating the integrity of IT products’ supply chain has been a critical part of cybersecurity for years. Historically, hardware bill of materials were scrutinized by federal agencies to ensure that their products contained components from trustworthy sources. In the wake of major data breaches caused by malicious code injected during the software development process, the same scrutiny is now being applied to software. Enter the advent of the Software Bill of Materials (SBOM)—a term that has been a frequent topic of conversation since the National Cyber Strategy was released.

While an SBOM is an important part of the cybersecurity mix, it’s essentially a checkbox to mark – an important part of the vetting process, but not a fix in itself.

As more emphasis is placed on SBOMs, it’s essential that both agencies and vendors keep in mind that what we’re talking about here is essentially an ingredient list for software security. It’s not to be confused with the recipe.

A SBOM crash course

Let’s have a quick primer for those new to the SBOM game. As explained by the Cybersecurity and Infrastructure Security Agency (CISA), a SBOM is a “key building block in software security and software supply chain risk management.” The idea first gained attention in 2018, as an initiative promoted through the National Telecommunications and Information Administration. 

The problem proponents of SBOMs hope to address is supply chain risk mitigation. To ensure that products sold to the federal government are not susceptible to security incursions, the government is turning to SBOMs as a proof point that software built into various solutions is trustworthy.

CISA has committed to advancing the cause of SBOMs, the organization states, “by facilitating community engagement, development, and progress, with a focus on scaling and operationalization, as well as tools, new technologies, and new use cases.”

From this starting point, the SBOM concept has been inextricably woven into the National Cybersecurity Strategy. The strategy specifically notes that software supply chain risk mitigation will include “the Software Bills of Material (SBOM) efforts, NIST’s Secure Software Development Framework, and related efforts to improve open-source software security.”

The strategy document goes on to say that “the Administration will encourage coordinated vulnerability disclosure across all technology types and sectors; promote the further development of SBOMs; and develop a process for identifying and mitigating the risk presented by unsupported software that is widely used or supports critical infrastructure.”

The Executive Order on Improving the Nation’s Cybersecurity (EO14028) puts the onus on the Ssecretary of Commerce and NIST to provide guidance on practices to improve software supply chain security. This guidance, according to the EO, will include “providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.”

Secure by design

This emphasis on SBOMs is part of the government-wide demand that cybersecurity be baked into products sold to the government – to shift the responsibility for cybersecurity away from agencies and put it in the hands of vendors and integrators.

But a SBOM is only a necessary part of the process to mitigate software risk. As CISA notes, SBOMs are “a key building block in software security,” and “a list of ingredients that make up software components.” There are no specifics regarding what makes for a good SBOM. It’s not synonymous with supply chain security. As a “list of ingredients,” to use CISA’s language, what’s missing is the recipe – the process by which those ingredients are incorporated into a product or solution.

It's up to vendors to do their absolute best to provide confidence in an SBOM. The federal government has to do more to guide the vendor community to appropriate tools, so that it is not such a time-consuming manual process. Down the road, it would be ideal, for example, to be able to reference a list of open-source or third party products through the National Vulnerability Database. From there it would be possible to assess whether there are vulnerabilities in the solutions integrated into products, and to validate the SBOM itself.

If products and solutions are to be “secure by design,” as it were, there must be more comprehensive requirements from the government to provide compliance milestones.

This notion of “secure by design” is also an initiative spearheaded by CISA, through a draft document that seeks to shift the balance of cybersecurity risk from the customer to the vendor. Many in the industry are evaluating that document to glean guidance as to what that means in practical terms.

DevOps demands DevSecOps

All of this is important for the federal market because in many cases not only are vendors developing software and products, but so are their agency customers. The idea of incorporating security in the development process is still a somewhat novel concept. After all, in the early days of application development, before the Internet, no one had to worry about security. All systems were run in a closed environment. Now, you can’t have a conversation about DevOps without including DevSecOps.

It has become incumbent on both vendors and agencies alike to be aware of security vulnerabilities as they are developing solutions. For some organizations it might mean integrating a hardware security module (HSM) into your DevOps. That would allow for secrets management or code signing security to be brought into the DevOps process –leveraging a HSM root of trust to create a higher level of security around the development process. Security needs to be a forethought, not an afterthought.

All of this is to say that a SBOM is a necessary part of cybersecurity strategy, but it is not nearly sufficient for cybersecurity. As the responsibility for cybersecurity shifts from clients to vendors, the ingredient list is essential, and it requires further guidance from the government to ensure compliance from the vendor community. But the ingredient list for cybersecurity must not be confused with the recipe itself.

Gina Scinta is the deputy chief technology officer for Thales Trusted Cyber Technologies.