In May of 2021 – following the Log4Shell vulnerability and other software supply chain incidents – the White House directed government agencies to adopt software bills of material (SBOMs) in executive order (EO) 14028. Two years later, the federal security community is still debating how to implement them.

There’s a long road ahead for SBOM adoption: even so, SBOMs will undoubtedly impact government contractors who make and distribute software in the not-too-distant future. Moreover, the ability to utilize SBOMs in a supply chain risk management strategy will likely be required by future cybersecurity regulations.

Opinions on this development are split. While SBOMs are sure to help organizations anticipate software supply chain incidents and respond rapidly, they also represent a new and rapidly developing toolset with many unanswered questions. So how are agencies tackling the directive set forth in 2021, and what do contractors need to know in the meanwhile? In this article, we’ll tackle both questions.

Software Supply Chain Challenges

Government agencies, contractors, and businesses in the private sector share one thing in common: they all depend on technology that incorporates third-party software components, including APIs, SDKs, and open-source frameworks. The sheer number of these dependencies is hard to keep track of, making them ideal targets for cyber actors seeking vulnerabilities to exploit.
Between 2019 and 2022, software supply chain attacks leveraging software flaws to infiltrate global businesses increased by an alarming 742%, giving rise to some of the largest cyberattacks ever seen by number of businesses affected. More recently – as many government and industry leaders foresaw – software supply chain vulnerabilities have played a key role in attacks against federal agencies by foreign actors.

How SBOMs Help

To help organizations keep track of third-party components in their software products, SBOMs were introduced in 2018 by the National Telecommunications and Information Administration (NTIA), which remains active in their ongoing development.
According to the Cybersecurity and Infrastructure Security Agency (CISA), an SBOM is – at its most basic – “a nested inventory, a list of ingredients that make up software components,” complete with component names and versions, and other unique identifiers.
Software developers can provide customers with SBOMs to disclose which third-party and open-source components are included in their product, preventing situations like the scramble to identify which software packages included Log4j in the aftermath of the Log4Shell incident.
Following EO 14028, SBOMs have seen rapid adoption in the private sector, with Sonatype reporting that 92% of enterprises currently maintain SBOMs or plan to implement them within the next year. In the face of mounting cybersecurity challenges, the healthcare industry in particular has embraced SBOMs as a way to ensure the security of medical devices.

Progress Towards SBOM Adoption

Following EO 14028, the NTIA released simplified guidelines surrounding SBOMs, and introduced a new standard – Vulnerability Exploitability Exchanges (VEXes) – to supplement the component inventory in SBOMs with information about component vulnerabilities.
Early the following year, NIST released the first version of its Secure Software Development Framework (SSDF), which directs software developers to collect provenance data for the creation of SBOMs. Several months later, the Office of Management and Budget (OMB) issued a memorandum encouraging all federal agencies to require SSDF compliance by their vendors.

SBOMs Are the Future

More recently, CISA has held exploratory sessions and public events to further establish SBOM standards. These events have tended to show that SBOMs are currently not well-defined enough to achieve widespread implementation as soon as some might hope.
Nevertheless, EO 14028 requires agencies to make progress in that direction, and many are trying. Eventually, they will ask for SBOMs and likely VEXes as well from their software suppliers. It’s also probable that contractors who don’t produce software will be required to make use of SBOMs for cybersecurity purposes. The road ahead is long, but its destination is sure.

Preparing for SBOMs

With mandatory SBOMs on the horizon, government contractors who want to stay abreast of government regulations and implement cybersecurity best practices should start preparing now. Here’s a few things that software developers and suppliers should know:

1. 1. Minimum requirements for an SBOM
      NIST’s guidance directs organizations to follow the minimum SBOM elements described by NTIA. SBOMs must include data fields that document baseline information about each software component, including supplier, component name, version of component, dependency relationship, author of data, timestamp, and other unique identifiers. SBOMs must be machine-readable, as their purpose is to be integrated with other security tools and used to continually monitor/identify risks.
   2. The function of VEXes
      While SBOMs include an inventory of components in a software product, VEXes disclose or attest to any vulnerabilities present in those components, whether they are exploitable, and any recommended actions for the customer. VEXes are not the same thing as an SBOM and may be provided separately from an SBOM – but they are both machine-readable standards that provide critical information for rapidly assessing software security issues.
   3. Types of SBOMs
      CISA currently defines six SBOM types, with benefits and limitations for each type, although this list may be expanded. SBOMs can be created at any stage of the software development cycle, including the planning, development, compilation, and post-compilation stages. SBOMs can also be created for software that is already deployed on a customer’s system.
   4. SBOM creation
      The SBOM creation process has been one of its most controversial aspects due to the time and effort required to manually create an inventory of software components. Even with automation, SBOM creation can be cumbersome. However, many tools and varieties of tools already exist. CISA recommends using a software composition analysis (SCA) tool during the development process, and third-party tools for the post-build stage.
      OWASP maintains a list of component analysis tools which organizations may want to consider. Until SBOMs are further standardized – and beyond the minimal criteria set forth by NTIA – there is wide latitude for the exact format of SBOMs, and the information they include.
   5. For Non-Software Developers
      Government contractors who do not develop or distribute software should still understand how to consume information from SBOMs and use them for supply chain risk management. The data provided both by SBOMs and VEXes are incredibly useful, enabling rapid response in the event of a supply chain security incident, and proactive measures to prevent them from occurring.

Organizations who would like to get a head start on implementing SBOMs into their ongoing security efforts should implement NIST CSF (which now includes the SSDF in its informative references) and review materials from CISA’s SBOM site.

Getting a Head Start

It remains to be seen what shape federal adoption of SBOMs will take, but it’s clear that the standard will eventually be crucial both for government contractors and organizations in the private sector.

With Gartner predicting that nearly half of global businesses will experience a software supply chain attack by 2025, now is the time to take ownership of your software assets and resolve vulnerabilities before they are exploited.
Securicon helps your business to stay ahead of government regulations and navigate emerging standards like SBOMs and VEXes. With a team comprised of veterans from the U.S security community – including DoD, DHS, and the U.S Cyber Command – we are equipped to provide organizations with gap analysis, compliance consulting, assessment support, audit preparation and risk assessment. To learn more, contact us todayContact.