The Software Bill of Materials, or SBOM, disclosure requirement is coming for federal agencies and their contractors. Are managers and executives ready?
An SBOM is a formal, machine-readable inventory of software components. They may include open source or proprietary software and are designed to reduce cost as well as security, licensing and compliance risk. The White House Office of Management and Budget last month gave federal agencies a year to collect software attestations and artifacts like SBOMs from government software vendors verifying adherence to secure development practices.
The limit is just 270 days for “critical software.”
Once federal agencies receive an SBOM, what will they do with it, how will they manage it, and how will they integrate it into existing enterprise processes? Managers must begin planning how to operationalize SBOMs now, lest they miss a critical opportunity to enhance the security of the software supply chain.
Technologists compare SBOMs to the list of ingredients found on food packaging. They list the component pieces of software within a larger software product and thus enable consumers to assess their known vulnerabilities. In addition, consumers can determine if software critical to business functions or national security contains other risk indicators, like data about the country of origin, ownership, and frequency of updates. With this information, consumers can quickly take action to mitigate the problem.
For this reason, Congress and the Biden administration are pushing mandates on federal agencies to require SBOMs for all software products these agencies purchase. Last year, President Joe Biden issued Executive Order (EO) 14028, “Improving the Nation’s Cybersecurity,” which required the Department of Commerce’s National Telecommunications and Information Administration to identify the minimum elements an SBOMs should include.
Then, the EO required the National Institute of Standards and Technology to issue “guidance identifying practices that enhance the security of the software supply chain,” including providing consumers with SBOMs. Lastly, the OMB was to mandate federal agencies use this guidance. Last month, it completed this final step, issuing a memorandum stating that agencies may require SBOMs in solicitation requirements.
In parallel, Congress is exploring updates to federal acquisition regulations to require government contractors to provide SBOMs. The Senate’s draft of fiscal 2023 National Defense Authorization Act authorizes the Secretary of Defense to require SBOMs for “all noncommercial software created for or acquired by the Department of Defense.”
The Senate draft also directs the Secretary to develop a plan for receiving SBOMs accompanying commercial software. Congress wants the Pentagon to “understand promptly the cybersecurity risks to Department capabilities posed by discoveries of vulnerabilities and compromises in commercial and open source software.”
These are essential steps to add transparency and security to the software supply chain, but federal agencies still have no guidance on how to use an SBOM once they receive one.
‘Nutrition labels’ for software
The problem is that SBOMs are not as easy to read as nutrition labels. Food labels do not list the origin of each food item or the farmer who handled the components. They do not list the breed of chicken that laid the egg. As a result, consumers cannot go to a restaurant, look at the menu, and assess if their eggs come from a trustworthy farm.
SBOMs, on the other hand, are complex—which makes sense because there’s a lot more risk associated with bad software than with a bad egg. Imagine a jar of salsa, which instead of simply listing “diced tomatoes,” would list the variety of tomatoes used, the farm where the tomatoes were harvested, the farm’s owner, the farmhands that picked the tomatoes, and the fertilizers and pesticides used.
SBOMs are like that – they can list components and subcomponents (dependencies), author(s), build or version number, license terms, technical debt, time series analysis, and maintenance patterns. To be most effective as a tool for risk management, SBOMs must be continuously updated to reflect every time developers change the software.
Today’s consumer understands how to read a nutrition label to assess things like sodium levels and allergens. However, OMB’s memo does not explain to federal agencies how to read the “SBOM label.” The NIST guidance mandated by the OMB memorandum does briefly mention SBOMs in the Secure Software Development Framework as an example of an artifact used to collect, safeguard, maintain, and share provenance data for software components.
However, the Software Development Framework does not explain how federal agencies should understand the information. Software consumers will need to establish processes to use SBOMs to identify, for example, component pieces developed by a particular entity in a specific location, such as in an adversarial foreign nation.
Multiple vendors means multiple SBOMs
Federal agencies will receive multiple SBOMs from vendors, contractors, and internal software development teams. They will need a process to validate, analyze, store, manage, and integrate multiple SBOMs to make informed decisions based on risk acceptance and security requirements.
For example, a diabetic consumer at the grocery store understands that buying a pint of ice cream might be safe if consumed in quantities amenable to their total daily allowance. However, purchasing and consuming cookies, cakes, and candies may surpass the daily limit of allowable sugar intake, which could be too risky for their health.
Federal agencies need an analogous understanding of the totality of their software and its dependencies to make informed decisions based on the information contained in multiple SBOMs.
They also need more guidance to understand how SBOMs contribute to and integrate into existing enterprise processes around acquisitions, risk management, asset management, and defensive cyber operations. That guidance can come from OMB, but much of the expertise about SBOM use resides in the private sector. Thus, federal agencies should leverage existing public-private partnerships around software supply chain assurance to minimize costs and maximize private sector expertise.
SBOMs can play an important role in cybersecurity, adding transparency and security to the software supply chain. But receiving an SBOM is pointless if an organization does not know how to use it effectively.
Dr. Georgianna Shea is the chief technologist of the Center on Cyber and Technology Innovation (CCTI) at the Foundation for Defense of Democracies. Annie Fixler is CCTI deputy director and an FDD research fellow. FDD is a Washington, D.C.-based, nonpartisan research institute focusing on national security and foreign policy.
