NTIA to Host Proof-of-Concept Summit in Software Transparency Effort

Over the last two years, the National Telecommunications and Information Administration has been working to popularize and standardize a way for software consumers to make more informed decisions—with security in mind—and is planning an event for stakeholders to compare notes on how to get to the goal.

“The working group reviewed plans for an upcoming proof-of-concept summit, where we can bring together folks from different sectors, energy, finance, telecommunications, national security to sort of say here's how we've done it, here are some of the other ways that you could think about doing it, and create a space for folks to really think about it,” said Allan Friedman, NTIA’s director of cybersecurity initiatives. “That's something that NTIA is going to be working with our stakeholders to plan over the next few months.” 

The transparency project is centered around what’s called a “software bill of materials,” which indicates where all the various code that goes into a product is derived. Friedman spoke with Nextgov about how it came about and where it might lead.

“This is not a new idea, it's been a standard part of manufacturing for decades,” Friedman said. But times are changing, and industry standards haven’t kept up with the use of opaque software sourcing.

“If I buy, say a giant generator for my facility, it will come with a list of all the parts so that I know what the total cost of ownership and maintenance is going to look like,” Friedman said. “If I buy that generator today, it's going to be connected to the internet, it's going to have a lot of software, and we don't have the same visibility that we still need from a maintenance, support, and, of course, security perspective.”

Software is typically built on top of groupings of code that are often open-source and picked up and compiled by developers without tracking the components. But vulnerabilities do pop up in these components and customers often do not know they need to patch their systems. If customers had access to an SBOM, they could know, not just whether that grouping exists in their software, but where it is within the rest of the software so they can quickly remediate it.

The idea behind the SBOM is not that the presence of a vulnerability should immediately disqualify a product, but that consumers should have the information they need to make the best decision for their use case.

“Most of the time if I buy a piece of candy in the store I don't care [about all the ingredients], but all of us know someone with a food allergy or dietary restriction and then they need that data to be available in an accessible format,” Friedman said using another analogy. “Similarly, knowing what pieces of software go into making a bigger, more useful piece of software, empowers that risk-based decision.”

The idea is that if customers ask for this information it will provide an incentive for software makers to do a better job of tracking components and avoiding counterfeit, outdated or otherwise sketchy sources of code in the rush to market their products. 

“I think one of the big failures was this lack of what we call a shared vision,” Friedman said. “No one was asking for it, so no one was supplying it, a traditional chicken and egg problem. That's why NTIA's approach to tackling that challenge was to bring the folks who make software and the folks who use software together to say what will be useful.”

NTIA’s multistakeholder group includes security researchers, major software manufacturers, and their customers. The makers of medical devices and major health care organizations—two groups where tensions have flared in the past over who should be liable for security breaches—are both participants, for example. And they’ve produced a proof of concept to show the utility of an SBOM in the healthcare sector.

SBOMs can be significantly different in the amount of information they disclose. A customer might ask a vendor to produce a full list of known vulnerabilities in the software, for example, so they can check it against a national database of such vulnerabilities. In setting a baseline that would encourage the greatest possible adoption, Friedman said it was important for the group to narrow its focus.

“We wanted to capture the entire supply chain, starting from the open-source community, going all the way down to middleware, commercial, embedded and then of course the enterprise customer of the software,” he said. “We're not trying to tackle the entire software supply chain challenge and we're not trying to tackle the entire software assurance challenge. We're just looking at the narrow space around making sure that folks know what dependencies are in their software.”  

One thing that everyone in the group agreed on was the need for whatever format the SBOM is delivered in to be machine readable so it can be folded into automated processes. 

“The community I think has done a great job of defining the basic set in a way that is flexible to build on all of the different things that are in the world today but still have some power to integrate into the tools, so we can take advantage of automation,” Friedman said.

A significant challenge for the NTIA working group will be to develop a translator tool to bridge the approach of different formats currently used to deliver SBOMs, as they may require the inclusion of different elements.

“Each has its own strengths and that's great, what we want to do is focus on the commonality, so that as people select the data format, based on its strengths or the tools that are available, it still follows the overall model and vision of SBOM and we can emphasize cross-compatibility and translatability,” he said.

Whatever form it takes, the SBOM idea is catching on with a number of government agencies and departments.

The Food and Drug Administration, which is responsible for the safety of medical devices, for example, calls for a “Cybersecurity Bill of Materials” in guidance for companies seeking the agency’s permission to market their products. The Department of Energy recently asked major utilities whether they use an SBOM to get visibility into their systems’ reliance on Chinese providers Huawei and ZTE. The Air Force’s Enterprise DevSecOps initiative requires submission of an SBOM for quick and continuous access to its collaborative environment. 

And SBOM will only become more important as U.S. officials push for telecommunication networks of the future to be open and software-defined.

“We think there's a natural fit between the emphasis on open interfaces in the future of 5G and software transparency,” Friedman said. “Because we're going to be building on more software, especially more open-source software, and the need to understand how different layers build on top of each other, and that's a very traditional supply chain story.”

As operators start to understand the risks that are built into next-generation telecom networks and start to think about the need to monitor for active supply-chain attacks, that again builds on transparency. Friedman noted that transparency alone won't identify whether there’s such attacks, but it can guide efforts and help figure out where greater monitoring and security research should be focused in core networks.

“And if there is a vulnerability or an attack discovered, it also helps you to understand how to remediate it and fix it because you know where it is in your own network,” he said.

Friedman said the NTIA working group is near consensus on producing comprehensive guidance for companies and organizations that want to create and use SBOMs.