Dr. Allan Friedman is Senior Advisor and Strategist at the Cybersecurity and Infrastructure Security Agency. He coordinates the global cross-sector community efforts around software bill of materials (SBOM). He was previously the Director of Cybersecurity Initiatives at NTIA, leading pioneering work on vulnerability disclosure, SBOM, and other security topics. Prior to joining the Federal government, Friedman spent over a decade as a noted information security and technology policy scholar at Harvard’s Computer Science department, the Brookings Institution, and George Washington University’s Engineering School. He is the co-author of the popular text “Cybersecurity and Cyberwar: What Everyone Needs to Know,” has a C.S. degree from Swarthmore College and a Ph.D. from Harvard University.
For those unfamiliar with the term, could you explain in simple terms what a Software Bill of Materials (SBOM) is and how it functions in the software development process?
Software Bill of Materials is like a list of ingredients for software. Software isn’t written new from top to bottom. It’s built out of building blocks, those building blocks are more software. SBOMs are meant to document that so we can better understand what’s under the hood of the systems that run our lives.
Why is having an SBOM important in today’s software landscape, especially after incidents like the Log4j vulnerability?
Software is always going to be fallible. There are always going to be flaws, and risks, andvulnerabilities. The key aspect is, as we work on writing better and more secure software, torespond quickly and efficiently when we do find a flaw. So, for the Log4j vulnerability, an SBOM would not prevent it. But, when it was discovered, everyone who had visibility into their software supply chain was able to quickly and easily triage what they needed to worry about and what they didn’t. It made the response efficient.
What role does SBOM play in handling supply chain attacks? Is it enough to cover the attack surface —and if it is not — what are the next steps?
The risk isn’t just vulnerability – things that are natural part of software that we have to find and fix. But we’re also concerned with the determined attacks adversaries are going aftersupply chain as a way of undermining the software. And this isn’t just in terms of identifyingthat an attack has happened, but where is their likelihood? Are there certain software components that are perhaps more exposed to risk from certain national adversaries? Or are we dealing with open source projects that don’t have many maintainers so that an adversary could take over if they wanted to. It’s about getting ahead of the risk. An SBOM is just a data layer. And, just as a list of ingredients, won’t by itself keep someone in your family from eating something that they’re allergic to, an SBOM won’t prevent attacks. But, by illuminating and shining a bright light, it makes it much harder for those attacks to succeed.In identifying risk factors ahead of time – and when we do discover a successful attack, we can respond more cheaply and faster.
SBOM contains supplier, component, version, identifiers. Why is it so important to track these details, and what risks do organisations face if they fail to maintain this level of granularity? So as one contains player component version and the identifiers why it’s so important to track these details?
The primary goal of SBOM is to understand risk, but everyone defines risk a little bit differently. And that’s natural. Wedon’t expect the military to think about the same risks as a health care system or as a school. So, the goal of this transparency is to be able to understand what’s in our software so we can map it to things that we care about. Some organisations, especially at first, will really be focused on the vulnerability management side. Others know that they’re currently under attack from specific types of adversaries that allows them to pivot.
Have you encountered some resistance or pushback from developers and companies in adopting SBOMs? What are the typical concerns they raise?
Anytime you talk about doing something extra, of course that is going to come with a cost, we fully knowledge that.Some of these concerns are made with good faith. Is this going to dramatically increase cost? We think that it won’t be dramatically increased. So, for example, the UK’s National Cyber Security Centre just published a blog post explaining that an SBOMshould be a natural byproduct of good software process. There are people who are concerned about issues around intellectual property, but again, there already is a certain amount of transparency required for things like open source licences; and we’ve built into this idea of SBOM – the fact that you can have known unknowns, depending on who you are sharingwith. And I’ll be honest, sometimes, some of the concerns are just traditional concerns about risk of change. This is a very common, natural human response. But even in the last few years, it’s gone from – Well, this is impossible – to – OK, how do we implement this and where do we start?
You have said – ‘Regulation and compliance are coming…’ There’s no regulatory push at the moment for SBOMs to be made public. Do you foresee that changing in the future?
There are more and more pushes. First – for the companies and organisations who make software, need to know what they are making. And a lot of the push is just to make sure there’s awareness for them. The second piece is to say, OK, we’ll give a copy of an SBOM to the customer or to the regulator. So for example, in the United States, the medical device regulator – the FDA, says you need to give a copy of an SBOM to the regulator. And similarly, if you’re in Europe, the Cyber Resilience Act calls for an SBOM to be made available to the national agency. None of those involve saying “I need to tell everyone what’s in my software”. The primary goal is to make sure that those who are in position of using the software, which is to say the customers and those who are in a position of safeguarding the public -national regulators, have access to the data.
Beyond software, you’ve mentioned a Hardware Bill of Materials and even Cryptographic and AI BOMs. How do you envision these evolving?
The power of SBOM is that by creating the expectation of transparency, we’re pushing accountability onto those who are making software and giving those who are using software a better understanding of risk as they are capable of using it. Transparency doesn’t solve all of our problems, but it empowers us. Similarly, as we look forward to other areas -more and more people are seeing the critical need for having greater transparency around where do our hardware components in our systems come from? Especially as we’re worried about national security risks. What cryptographic materials and algorithms am I using in my systems, especially as we look ahead to post quantum computing. And of course, as we think about AI systems – many of them amount to opaque boxes and we need to start off by saying – let’s understand at least what models, what data, what infrastructure is used to create these.
As a takeaway message, the SB in SBOM does not stand for silver bullet. But when I explain this to people who are outside of the security world? They’re frankly shocked that we don’t already have a habit of transparency. We expect the people who make our candy to be able to tell us what’s in our candy and we should have that same level of transparency as a minimum for the software that runs our critical infrastructure.