Best listening experience is on Chrome, Firefox or Safari. Subscribe to Federal Drive’s daily audio interviews on Apple Podcasts or PodcastOne.

Industry groups seem to support the Biden administration Sept. 14 memo on secure software development and acquisition. It lays out a detailed way for agencies to get the software so they’re in theory assured of the security of the software supply chain. Gordon Bitko is senior vice president of policy at the Information Technology Industry Council. He joined the Federal Drive with Tom Temin.

Interview transcript: 

 Tom Temin:  This specifies a couple of things one self-attestation, under certain conditions by the software vendor, and also a software bill of materials, you’re confident that agencies know they’re not getting a bill of goods here instead of a software bill of materials?

Gordon Bitko: Well, I think that those are great questions. To start with, the overall intent of the executive order. And this additional follow-on guidance is perfect. It addresses real concerns that need to be addressed. But there are still implementation questions as you were hinting at in what you just asked. The agencies need the resources to evaluate the self-attestations or the software building material. And that might prove challenging for them. Right now, there’s not really standards for how to do all that yet, we don’t know that all agencies are going to approach it in same way. And that could lead to additional confusion and challenges. And then I think the other thing that’s really important, Tom, is the scope of the executive order. And what NIST goes on to define as software that’s covered and critical software is potentially huge, because it talks about products containing software as well, that can mean TVs, it could mean cars, it could mean industrial control systems, not just classical information technology systems.

Tom Temin: And one of the I think hang ups could be mentioned the SBOM needed depending on the criticality of the software. But sometimes un-critical software can be the source of attacks, as we found in the log4j, you know, plain old text log file, somebody figured out a way to hack that something no one would have considered critical until that hack came through that way.

Gordon Bitko: That’s right. It really depends in many cases, not just on the software, but the risk environment that it’s in and how it’s being used as to whether or not it’s a vulnerability. Log4j in some cases, was used in very benign circumstances. And in other applications, they it was used in places that had had access to potentially very critical pieces of software, or very sensitive data, the same thing is true across the board. And that is really one of the challenges with figuring these things out. And software bill of materials. While it’s helpful for things like that., it’s not a silver bullet, right? It doesn’t tell you because the vendor doesn’t know where is that software being used? And what other things might the agency already be doing or need to do.

Tom Temin: And I can also see something of a closed loop of never ending train here just to mix my metaphors. If you have a software bill of materials, and it lists a bunch of open source pieces, which even the commercial vendors are using open source components in commercial software, the source of the open source, then becomes an issue.

Gordon Bitko: It does. And the guidance in fact says agencies can apply it to open source software. But then it really does become a question about who’s even responsible for that adaptation in the use of open source software? And who’s responsible if they do decide that they need a third party to attest or to produce artifacts? And it could go on in an indefinite loop, as as you noted.

Tom Temin: And do you feel that or is it your sense that agencies or any organization has the capacity to be able to evaluate a software bill of material? Often you hear it likened to the ingredients on packaged food, but even Fritos and Doritos don’t have 10,000 ingredients on their labels?

Gordon Bitko:  I know this is sound sounding like a cop out. But it depends. There will be certain cases where if an agency truly decides to put a lot of resources into one product, one piece of software that they decide is super high risk, they probably can do a pretty good job. But can they scale that to everything in the agency? And do they really have an understanding of the true risk profile? Unfortunately, Tom, my sense is the answer to that is no, because this along with all the other guidance that’s come out from the White House, from the Office of Management and Budget, from the federal CIO and the federal CISO. So all good and well intentioned, but no resources associated with it. That really leaves us in a bad spot.

        Read more: Cybersecurity

Tom Temin: That’s an old story, I guess. We’re speaking with Gordon Bitko, senior vice president of policy at the Information Technology Industry Council. Well, let’s start with your members, the software vendors, resellers, systems integrators, companies that are dealing in the software, what should they do to make sure that they can meet in an earnest way the requirements that the agencies will place on them from this from this White House guidance?

Gordon Bitko: What we would most like to see Tom in general, regardless of which of our member companies, is continued further dialogue between industry and government to really nail down a lot of the details that we’ve talked about. These uncertainties about how SBOMs can be reported and how versions can be tracked and what each individual agency needs to do to decide criticality. Really, those are things that were going to be best served. I know it takes time, but we’re going to be best served by having an actual constructive dialogue. At the same time, though, all of our member companies, I’m confident would say that they have good software practices today and what they want, what they want to do is have the ability to demonstrate that and to demonstrate that in real ways, not just to figure out how to comply with 20 different agencies all telling you report this way versus that way that that’s counterproductive,

Tom Temin: Right. So agencies have not really issued guidance documents on compliance with this. So maybe that’s a good place to start. And maybe the compliance document could be uniform across the government.

Gordon Bitko: That certainly is the hope. There is a mention in the OMB guidance that the FAR Council is going to take up a case to look at requiring a uniform attestation form and process. That would be great. We all know, Tom, that the regulatory process for new fire regulations can be time consuming. And that’s a real issue. There is a sense of urgency here. But at the same time, if we allow each individual agency to do their own thing, we’re putting the cart before the horse. We’re going to get a bunch of different responses to the same question instead of agencies and industry working together collectively.

Tom Temin: And the memorandum does assign authorities it says the CIO shall do this, the Chief Acquisition Officer should do that. CISA has a role. OMB has a role, and so on and so forth. The question is, you know, in your experience, watching how all these things play out over the decades, often the guidance doesn’t get down to the contracting officer on the front lines there, do you get the sense that perhaps they’ve got to be pulled into this, because that’s really where requirements get laid out.

Gordon Bitko: Undoubtedly, the rubber meets the road in the actual contracting work. One of the things that we’ve advocated for from an industry standpoint frequently is that the contracting process shouldn’t be just dependent on the contracting officer, it should really be an integrated team: security, the program managers, the business owners, the technologists, the contracting officers all working together. That way we don’t have again, after the fact when we’re ready to award a contract, this new requirement for secure software development, that hasn’t been part of the discussion.

Tom Temin: Right, because especially the program owners with all of these digital services, and customer experience, and that’s all leading to lots of new software, you would think they above all, would want to make sure Hey, folks, whatever you deliver me, I don’t want it to be hackable or something.

        Want to stay up to date with the latest federal news and information from all your devices? Download the revamped Federal News Network app

Gordon Bitko: Yeah, absolutely. We would encourage program managers to be thinking about security and their products. And you’re right, they all are software products these days, in one way or another, they use software to some degree. They’ve got to be thinking about security on day one, or even on day zero as they start the project. What does it look like to make sure that this product which might contain sensitive data about our employees here in this agency, or about Americans, that that’s secure, and we want everybody to know that.That’s a collective decision that everybody’s got to be involved in. And I think, Tom, that leads into something we haven’t really touched on all that much, but which is going to be an emerging thing over the next few years. And that’s really how agencies think about these sort of supply chain and cybersecurity issues in the procurement evaluation phase. The FAR Council and I know I’m opening the door to another topic, but the FAR Council has announced this new part 40, that’s going to contain all cybersecurity Scrum guidance going forward. And things like this OMB memo are going to have to be factored in there.

Tom Temin: Well, maybe this should make it FAR part 16 and move everything down a notch because 15 comes up so much, 16 would be nearby in the books.

Gordon Bitko: Indeed. But somehow they say part 40 for cyber supply chain guidance.

Tom Temin: All right, route 40. Gordon Bitko is senior vice president of policy at the Information Technology Industry Counsel.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.