The Government's Software Transparency Journey Moves from Plan to Practice

Having piloted the Commerce Department’s effort to shape the definition and implementation of a software bill of materials—likened to an ingredients list of components in complicated supply chains—Allan Friedman will now play an instrumental role scaling and operationalizing the concept from his new perch at the Cybersecurity and Infrastructure Security Agency. 

Friedman discussed the work ahead of him in an interview with Nextgov. From within the vulnerability management unit of CISA’s cybersecurity division, he is positioned to influence coming guidelines and potential procurement regulations under a May 12 executive order requiring agencies to ask their suppliers to provide so-called SBOMs.

“I’m very excited to be here,” he said. “These are the people who sort of live and breathe understanding and reacting to risks in the ecosystem. CISA was looking to expand on their role in the vulnerability space and it seemed like a good fit.”

Most recently, CISA issued a binding operational directive requiring agencies to publish vulnerability disclosure policies that welcome security researchers searching for bugs on government systems, and launched a platform to assist and track agencies’ remediation of their submissions.

During his years as director of cybersecurity initiatives at the Commerce Department’s National Telecommunications and Information Administration, Friedman worked to bring software vendors, customers and other interested parties together on baseline elements for a standard SBOM. Vulnerability disclosure by manufacturers was a controversial issue at the start of the multistakeholder process. Some consumer advocates argued that the initiative would do little for security if vendors didn’t point out where vulnerabilities can be found in their products while vendors said it would be overwhelming to innumerate every instance of a vulnerability, and unnecessarily and unfairly alarming and misleading to buyers if measures were taken to neutralize them in the development process.    

Friedman said CISA is looking to be “a little more proactive around managing the vulnerability ecosystem. The industry buzzword for the past few years is to ‘shift left,’ and to sort of help us understand not just how to deal with vulnerabilities, but what we can do to make managing them more effective and ultimately to eliminate them or reduce them in the ecosystem.”

To operationalize SBOM means to “make sure that we can integrate this into daily operation, into existing tools, and the final status of hooking it into the existing vulnerability and cybersecurity ecosystem,” he said. “​​SBOM was never meant to be a standalone concept. Its value is that it helps support other ongoing efforts and enables further intelligence efforts for the cybersecurity and data management approaches. SBOM, in the long run, shouldn't be thought of as a unique suite, it should just be part of a multifaceted cybersecurity agenda that we should be pushing and fostering.” 

Currently, an SBOM may contain a lot of information, shining light deep down into components—often open-sourced—that make up a product, or it can be more superficial, describing basic attributes such as the name of the supplier and the version of the product without disclosing lower-tier code libraries that may be associated with vulnerabilities researchers discover.

In line with the executive order, Friedman and his team at NTIA in July issued “minimum elements of a software bill of materials,” a step toward creating a potential federal benchmark and market standard. They’ve also proposed a way to get past disagreements over the vulnerability disclosure issue: vendors could include a “vulnerability exploitability exchange,” or VEX, appendix that lists vulnerabilities but declares that their product is unaffected by them.

But that minimum elements document won’t directly translate into the requirements agencies will be expected to implement under the order, Friedman said, noting room to raise the bar or otherwise adjust it.    

“I think the report that the White House asked for, that NTIA delivered in a very short timeline, is [the basis of] an evolving effort,” he said. “This is the minimum today but we might expect more additions or tweaks or clarifications or indeed new technologies over time. We should build that into our expectations.”

Construction of the agency guidelines, as well as potential changes to federal acquisition regulations down the line, will be the responsibility of a host of agency participants including those from the Office of Management and Budget, the Secretary of Defense, the Attorney General’s office and the Office of the Director of National Intelligence. But Friedman and CISA will be in the room and have opportunities to steer the process.  

“One of our core goals is going to be to sort of help advise those that are actually building out either guidelines or explicit requirements to say, one, ‘when we say something about SBOM, what do we mean?’ making sure that we're all aligned,” he said. “And then, two, helping [make] an appropriate case for, you know, scaling this up so that it's something that, on one hand reflects the White House's sense of urgency for making progress, but at the same time making sure that we're not overwhelming it, or creating imperfect implementations that will actually set back the agenda.”

Friedman said that as the concept continues to evolve, members of the software security community will definitely need to be more involved. 

Matt Howard, executive vice president of Sonatype, which he describes as a software supply chain automation vendor, puts the company in that class. He’s been a cheerleader for the administration’s inclusion of SBOM requirements in the executive order, perhaps not surprisingly, as Sonatype stands to do more business generating them. But, he says, these are the very first steps of a process toward meeting the full promise of SBOMs’ security benefits. 

“I am generally not naive about this being a journey, I am generally not naive about this being very complicated with lots of constituents, and lots of opinions, both technical and commercial,” he told Nextgov. “These initial steps that have been taken by Allan and the folks at [NTIA] are important first steps but that's all they are.”

One of the often-cited examples for how SBOMs could help with cybersecurity is in the Heartbleed attack of 2014 when hackers exploited a bug in a software library called Open SSL. If users had a software bill of materials, proponents argue, they would have more quickly been able to locate and fix the bug in their systems.

But Howard said OpenSSL is closer to the plumbing underneath the counter than the handles of the faucets on a sink. And if an SBOM doesn’t list all those transitive dependencies, as they’re called, then they will not provide the transparency necessary to deliver the desired incident response scenario.  

Still, he’s optimistic. “I think this is going to cause people to ask questions that they've never asked before, and when they ask the question, they may be surprised by the answer, which is ‘we don't know,’ and that's a great example of why this is an important first step,” he said. “The next sort of logical step that you might take is to sort of say to yourself, ‘well, what should I do, or what can I do to know that which I currently don't.’” And that, he said, may spur buyers–such as federal agencies and others—to reexamine the adequacy of the standard.

A few other stakeholders, some from the software manufacturer side, and the high-profile vulnerability disclosure and management entrepreneur Katie Moussouris, have argued that the SBOM requirement could end up creating work that federal employees aren’t resourced to do. “An SBOM requiring too little information at a minimum would force additional skilled security analysis in order to determine risk,” reads testimony she delivered to Congress. “With limited cybersecurity workers, performing this data enrichment step could displace vital security work that might have a greater [return on investment] towards the desired secure supply chain outcomes.”

That doesn’t totally compute for Friedman. “It's a fair criticism to say there aren't as many sophisticated actors who are processing SBOMs,” he said. “It's not true that there aren't any. Quite far from it, there are many organizations that are starting to work on this, thinking about it, and are integrating it into their processes, but it is the fact that because fewer companies share SBOMs with their customers, fewer customers process them.” That’s a chicken-and-egg situation the federal government can help dislodge by creating more demand for SBOMs, he said, noting that just as innovation and competition have grown on the supply side—where companies like Sonatype sit—it will on the consumption side as well.

He added: “There's absolutely nothing that requires specific activity” from the user and compared the burgeoning field to a longstanding one in cybersecurity. “No one says it takes too many people to do asset management,” he said. “We say, ‘asset management can be difficult, here are some tools.’ We expect sophisticated actors to do it very well and we're focused on helping the unsophisticated actors put their arms around it today. SBOM is just going to follow that model at the next layer down.” 

Further, Friedman foresees SBOMs helping to reduce agencies’ workload by helping them to more quickly comply with exclusion orders like the ban on Kaspersky software. 

“One vision is that a particular piece of software represents an undue risk so now we sort of say ‘hey, we should make sure that it's not on certain systems.’ That's one thing to do if it's easy to identify … you know, name on the outside of the box, name shows up in every network scan,” he said. “But that's not the case for a lot of software. It's resold and repackaged and integrated into other pieces of software. That's where an SBOM can really help not just identify where something is but also allow agency security staff to more effectively move on. They can say ‘yes, we can show that we don't have this piece of software, and so now we have complied and we can go back to [working on] the more immediate mission that we have in front of us.”

Outside of work on the order, Friedman and his new team at CISA’s vulnerability management operation is also interfacing with parts of the government that had already put SBOM initiatives in motion, most notably the Food and Drug Administration and the Defense Department.

Before even settling on a new title, for example, Friedman said CISA and FDA officials met Tuesday about not just how to build SBOMs—which the FDA requires medical device manufacturers to provide when seeking approval to market their products—but how to integrate them into existing areas of software assurance and supply chain risk management.  

He said CISA is able to offer an “outside perspective on the broader security landscape” and expertise on what’s already being done so there isn’t a duplication of work.

RELATED PODCAST