Harmonizing the Federal Effort on Automating Software Bill of Materials

When the Biden administration released Executive Order 14028, “Improving the Nation's Cybersecurity”, it included guidance to enhance the security of the nation’s software supply chain. As a result, key building blocks are being developed to both strengthen software security and bolster software Supply Chain Risk Management (SCRM) programs across the Federal government. One of those key building blocks is the upcoming requirement of a software bill of materials (SBOM) within federal acquisitions.

What is an SBOM?

An SBOM is a formal record, or list, of nested software components that details the relationships between them. Software is often developed using numerous open source and commercial software components. The SBOM enumerates these nested components in a product.

It is analogous to purchasing food at the supermarket. A consumer will want to understand if their food contains soy, gluten, nuts or other component ingredients to better understand what they are consuming and what risks come with it. When it comes to the ingredients of a software product, an organization will similarly want to know if a nested component may contain a newly discovered vulnerability or if a component manufacturer is known to have inadequate vulnerability management programs (e.g. vendors slow to release patches to exploitable vulnerabilities) in order to assess and mitigate risk.

What is the Government's Approach to SBOM?

The Executive Order is a call to action and lays out a timeline to ensure that Government buyers can use a SBOM to perform vulnerability or license analysis, evaluate product risk and more quickly and easily determine if they are at potential risk of a newly discovered vulnerability. The National Institute of Standards and Technology (NIST) was tasked to issue guidance identifying practices that enhance the security of the software supply chain, including providing a purchaser with an SBOM. The National Telecommunications and Information Administration (NTIA) was tasked to publish minimum elements for an SBOM.

On July 12, 2021, the NTIA published, “The Minimum Elements For a Software Bill of Materials (SBOM)”, to support basic SBOM functionality and to promote further software transparency. These minimum elements include three broad and interrelated areas:

• Data Fields: Outlining baseline information about each nested component within a software product (supplier, component name, version, timestamp, author of SBOM data, dependency relationships, and other unique identifiers);
• Automation Support: A machine-readable SBOM format allowing for greater benefits through automation and tool integration (data formats used to generate and consume SBOM formats include SPDX, CycloneDX, and SWID tags); and
• Practices and Processes: Defining when to request and how to use an SBOM.

On May 5, 2022, the NIST released the final version of Special Publication (SP) 800-161 Revision 1, “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations'', which outlines foundational practices when interacting with system integrators. One of the recommendations in advancing Cyber Supply Chain Risk Management (C-SCRM) practices is for organizations to, “establish a governance capability for managing and monitoring components of embedded software to manage risk across the enterprise” (e.g., SBOMs aligned with criticality, vulnerability, threat, and exploitability assessments to streamline the process).

In a May 17, 2022, hearing by the House Committee on Homeland Security, Subcommittee on Cybersecurity, Infrastructure Protection and Innovation, the Cybersecurity and Infrastructure Security Agency (CISA) echoed the global cybersecurity communities' need to further harmonize an approach to SBOM that is automated and interoperable. CISA is helping to drive the operational framework under the auspices of the broader Federal effort focused on software and security. The foundational work at CISA is a prerequisite to an effective SBOM program and to achieving the changes necessary to advance this initiative.

By the end of 2022, the Office of Management and Budget (OMB) is likely to issue additional guidance on how agencies will incorporate NIST C-SCRM practices in the acquisition of software. Both OMB and the Department of Homeland Security (DHS) will submit contract clause recommendations to the Federal Acquisition Regulation (FAR) Council, closely aligned to the recommendations published by NIST. The general intent of the FAR recommendations is to align Government vendors with the requirements in the NIST framework. Expect the FAR Council to announce a public comment period in fiscal year 2023, prior to SBOM language being included in government contracts.

Efforts to Automate SBOMs

There are two key elements to the Federal government's SBOM initiative: 1) adopting a unified approach across sectors; and 2) focusing on automation to accelerate responses to  vulnerabilities found in component data sets.  

Present day software is no longer the result of monolithic, single source development efforts.  Software components have dependencies on other components, known as transitive dependencies, which may impact a component's runtime, performance or security profile.  As government ecosystems become more modular, analyzing components for transitive dependencies becomes more critical to understanding a product's risk profile as a whole. 

Over the past 10 years, collaboration efforts on communicating SBOM information has also led to two widely accepted standards, OWASP CycloneDX and Software Package Data Exchange (SPDX).  OWASP CycloneDX is a lightweight “Bill of Materials (BOM) standard designed for use in application security contexts and supply chain component analysis.”  SPDX is an “open standard for communicating software bill of material information, including provenance, license, security, and other related information.” These SBOM communication standards are used to reduce workforce redundancy by providing a common format to generate and consume SBOMs.

In 2018, the NTIA launched an initiative to improve Software Component Transparency, which produced the Vulnerability Exploitability eXchange (VEX).  According to NTIA, the primary use for VEX is, “to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.”

As the Federal government develops an operational strategy around SBOM, there should be an emphasis on how automation improves workforce efficiencies. In most cases, the workforce has to manually research what components make up a software product, what transitive dependencies exist and what vulnerabilities are able to be exploited.  

As a use case, imagine an agency who has a specific software product used in a critical system and is asked to provide a report on the security of the product. The agency would request the vendor to provide it with an SBOM for the product, which it would then review manually to check each nested component against a list of known vulnerabilities or other interdependent risk factors. As the agency checks for vulnerabilities against various data sets, like the National Vulnerability Database (NVD), they may find a subset of vulnerabilities deemed critical. However, not all critical vulnerabilities are exploitable at a given time. Other inline protections may exist making a vulnerability non-exploitable. As a result, the vendor will inform the agency that out of the number of critical vulnerabilities identified, only a subset is known to be exploitable. Those exploitable vulnerabilities will then be patched.

As complex as this workflow sounds, and after the many required exchanges between vendor and agency are completed, this process is repeated over and over again, as a regular part of an agency’s vulnerability management program. What the Executive Order and subsequent interagency efforts intend to accomplish is to standardize and eventually automate this process.

CISA is working with industry to help lead the effort to create standardized data formats that can be used to generate and consume an SBOM (e.g., CycloneDX, SPDX) and related vulnerability data (e.g., VEX, NVD) into an automated platform.  

Moving forward, we can anticipate that Congress and the Administration will continue to push the federal government towards a more granular vulnerability risk management model which accounts for risks across the supply chain. We can also anticipate future adoptions of SBOM in areas like process maturities within the Software Development Life Cycle (SDLC) and SBOM transitioning into a proof of Federal Information Security Management Act (FISMA) compliance.

The challenge now becomes – how does the federal government harmonize efforts across sectors to improve our nation's cybersecurity, as intended in the Executive Order? Perhaps the future will come with a parallel paradigm shift, transitioning the whole of government approach to a whole of society effort.

There is a need to build use cases and pilot programs, leveraging strengths across sectors, to solve the complexities surrounding SBOM automation and further enabling software transparency using data and observability. It would be recommended that the federal government leverage existing funding sources like the Technology Modernization Fund (TMF), an Agency’s Non-recurring Expenses Funds (NEF), the DHS Silicon Valley Innovation Program (SVIP) or the Federal Citizen Services Fund (FCSF) towards an investment in an automated SBOM pilot program. This approach would allow for a natural evolution towards a collaborative and cross-government shared service that meets modern expectations, is secure by design, and decreases long term costs by lessening the administrative burden for both Government vendors and the federal workforce.

As the Federal government and private sector work together to solve the SBOM automation riddle, it's important to remember the value of sector harmonization. Close partnership between sectors have led to some of the most historic moments within our nation. In 1961, NASA sent the first American into space, revolutionizing space exploration. The first space flight programs ran at a $400 million per mission cost. Between 1981 and 2011, the Space Shuttle era flew 135 missions at an average mission cost of $450 million, before being retired completely due to cost. Between 2011 and 2020, NASA relied solely on other nations to launch U.S. astronauts into space. In 2020, NASA once again launched American astronauts on American rockets from American soil. This time, at a cost of $62 million per mission. The innovation and cost savings were achieved through investments in public-to-private partnerships, leveraging sector strengths.

There is a common sense of pride and accomplishment that radiates when a rocket launches off U.S. soil into lower earth’s orbit, resulting from sector harmonization. The same investments, agility, cost saving, workforce efficiencies and harmonized approach will hold true across the cybersecurity paradigm. Let us remember those historic whole of society accomplishments and leverage those lessons to improve our nation’s cybersecurity.