NIST researchers take on software supply chain questions
You scarcely hear the word "software" these days, without it being followed by "supply chain." One of the biggest topics in cybersecurity is how to make sure th...
You scarcely hear the word “software” these days, without it being followed by “supply chain.” One of the biggest topics in cybersecurity is how to make sure the thousands of pieces of a software program add up to something safe. For an update on how best to think about software supply-chain security, the Federal Drive with Tom Temin spoke with Jon Boyens, the Deputy Chief of the Computer Security Division at the National Institute of Standards and Technology (NIST).
Interview Transcript:
Jon Boyens Our general guidance on cybersecurity supply chain risk management typically has covered both hardware, software and services in general. It wasn’t until a couple of years ago with the SolarWinds incident and the following executive order 14028 that really focused on software. So kind of at the same time, we were updating our special publication flagship, which is 801-61 rev 1. And we were able to address supply chain risk guidance in that publication specific to supply chain. We focused specifically on providing guidance for software bill of materials, open source software, enhanced vendor risk assessments and vulnerability management. This was also the first time that we were able to move kind of left of center and move out into the development realm. And we developed a secure software development framework or special publication 800- 218 that was very specific in providing guidance to software developers.
Tom Temin And software development. These days is very different from the concept people had maybe in the eighties where a new program was programed by your programmers and everyone wrote different pieces of it and you compiled it into an application and there were all kinds of quality check automation programs back then. Now it’s more like assembling pieces from various sources in a Lego fashion almost. You might get a brand new application, but it’s made of standard Lego like pieces, and that’s changed how we have to deal with software because the supply chain is not simply that supplier, but that suppliers sources of the Lego blocks. Fair to say?
Jon Boyens That is very fair to say. The complexity is enormous right now.
Tom Temin All right. So then that complicates the issue because do you have to look, I guess, in this thinking at the corporate entities that supply these or at just the objects themselves?
Jon Boyens I think both. So I think it’s key to go back to the old kind of blocking and tackling of risk management. And it’s knowing it’s knowing who the critical suppliers of that software is. It’s knowing what software you have in your network, the relationship between the different technologies and software in that network and the risk impacts that they could have. And that was one of the main things we saw in the SolarWinds incident a few years ago.
Tom Temin So the recent thinking then is that you need a software bill of materials in order to understand the supply parts of the software. And this is part of Executive Order 14028. And there’s been a lot of development and guidance on how to use SBOMs. In your experience, does the SBOM provided by your primary supplier in general include everything that it should?
Jon Boyens Well, right now a lot of work is ongoing on SBOMS out of DHS CISA. SBOMS have been around for 35 plus years in the software development field, you know, when they are developing a big software package and they’re using third party software, they usually get the software bill of materials or component inventories, which is another name for them. But that’s a development stage. And there’s usually nondisclosure agreements. SBOMs at the consumer phase or just fairly recently and still fairly nascent. So I would say that understanding the provenance of software SBOMS are clearly where rubber hits the road, how ever organizations need the capability to both consume and proactively use those SBOMs. If they don’t, then SBOMs merely become shelfware until there’s an incident or a known vulnerability. SBOMs are a critical piece of supply chain risk management. But they’re not a silver bullet, and they require an organization to have a broader and deeper vulnerability management program established in order to really reap the benefits of SBOMs.
Tom Temin We’re speaking with John Boyens. He’s deputy chief of the Computer Security Division at the National Institute of Standards and Technology. Yes, that ability to operationalize or do something about what’s in the SBOM, that’s really crucial. Otherwise, yet we got an SBOM. And then you are complying with the need to get an SBOM, but actually not using it in an operational sense to make your organization more secure. That seems like a big bridge between compliance and actually doing something to ensure cyber security.
Jon Boyens It most certainly is. And, you know, outside of the software specific area. I don’t know if supply chain risk management has really become a compliance measure, but definitely in the software space.
Tom Temin Well, what’s your best advice then for agencies that want to get after the supply chain? I mean, I imagine in the federal acquisition space, there are limitations legally, statutorily on the sources of software that can come in to federal systems. But that doesn’t mean it’s always happens.
Jon Boyens Right. And similar to developing a vulnerability management program, trying to conduct cybersecurity, supply chain risk management. You know, in 801-61, we address the critical factors that go into this. And a lot of these are internal processes that a lot of organizations don’t recognize yet, but we put them as key factors. That’s such things as developing a program management office, developing roles and responsibilities specific to supply chain, establishing supply chain information sharing mechanisms. And of course, I think that the key part is having a top down direction and dedicated resources, because without those dedicated resources, then only the bare minimum compliance pieces are going to get addressed.
Tom Temin And what’s your assessment of how agencies are doing? I mean, do they come to you with questions? I mean, NIST is always cited as the reference for what agencies say they’re doing. What’s your sense of how good the government is yet at using SBOMs and at getting after that supply chain conceptually?
Jon Boyens Well, right now, I think a lot of agencies are waiting for additional direction from OMB and DHS CISA with regard to SBOMs and where they fit in. Again, it’s still fairly nascent. So I don’t think a lot of agencies have the capability to consume SBOMs. I mean, that’s not writ large. There are some agencies that do, but it isn’t across the board.
Tom Temin Are there third party sources that might be able to say, well, we’ll look at your SBOMs for you and tell you where the dangers are?
Jon Boyens Yes, actually, that’s you know, I mean, ten years ago, I would say no, there were very few third party vendors at all that really addressed supply chain, let alone the actual services they provide. That’s changed quite a bit over the last few years. I would say that the number of vendors has increased, although I would say that they’ve been more focused recently on supplier illumination and conducting due diligence on critical suppliers. That with a lot of, you know, what these executive orders and other items like SBOMs, those capabilities are expanding. So they are now offering, you know, means for agencies to consume those SBOMs, as well as broader vulnerability management functions.
Tom Temin And a final question, Is it probably good practice to ask your primary software supplier to look at its own library? I mean, for example, I know a programmer many years ago who was programing coding, raw coding communications protocols for a online company at the time. And it’s likely that whatever that was, that that coding resulted in a communications protocol, how to connect was reused and reused in subsequent generations of the software. Corporate takeovers transfers. So a lot of that code wasn’t maliciously done, but it was simply reused and reused and brought forward into new generations of software. And so there might be some historical vulnerabilities built in. Is that something to be concerned with?
Jon Boyens It is, and I think it’s one of the toughest difficulties with open source software right now. So if there is a piece of code in a library, it quite often gets reused over and over again. So that is one of the large initiatives by the administration to address open source software. We’ve provided some guidance to that more in terms of consuming or purchasing open source software. But definitely that is one of the biggest issues, particularly since most, if not all, proprietary software includes open source software.
Tom Temin Sure. So you think we’re making progress overall?
Jon Boyens I would say it’s three steps forward, two steps back. But I have seen a sustained effort and progress over the last two years, so I’m much more hopeful than I was ten years ago.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Tom Temin
Tom Temin is host of the Federal Drive and has been providing insight on federal technology and management issues for more than 30 years.
Follow @tteminWFED
