The Biden administration’s executive order on cybersecurity from three years ago alerted the uninitiated to the existence of software bills of material (SBOMs). The idea is, knowing all of the elements that make up a software package can help buyers better understand their cybersecurity holes. But can the SBOM also give hackers the blueprint they need. For analysis, the Federal Drive with Tom Temin talked with Endor Labs adviser and former federal cybersecurity manager Chris Hughes.

Interview Transcript: 

Tom Temin And you’ve seen this from both sides now, from industry and from government. And you testified recently before the House Subcommittee on Cybersecurity, I.T. and Government Innovation. Got to love those titles. And the idea that the bomb is a kind of a two way sluice way. Tell us more about what you feel here. Yeah.   

Chris Hughes So actually, it wasn’t my testimony, but it was a testimony from the Committee on Oversight and Accountability. It was in a talk titled Safeguarding the Federal Software Supply Chain, and it represented folks from private industry as well as some public sector organizations focused on government procurement and things of that nature. And, you know, one of the things that were brought up is, you know, the SBOM serving as a roadmap for an attacker. And this is actually a topic that’s been brought up around SBOMs in the past by groups like NTIA, CISA and Industry that has engaged them. And, you know, obviously some merit to that. If you’re disclosing exactly what’s in a product, it can be vulnerable. But that said, it’s not as if the government is asking for vendors to publicly disclose the SBOM and post it on our website, for example, or share it out for the world to see. They’re asking for it to be delivered to the government, and obviously that’s going to include safeguarding it, you know, having things like access control in place and properly storing it, you know, limiting who has access to it, encrypting at rest and things of that nature. And that said, you know, the reality is that attackers seem to be doing quite well already in terms of exploiting vulnerable products. What this does is it actually, you know, addresses a longstanding information asymmetry between software suppliers and software consumers, in this case being the federal government, clarifying exactly what’s in a product and what vulnerable components, for example, may be in a product that they’re consuming and buying and purchasing. And it represents the government’s attempt to use their large purchasing power, kind of push the systemic change across the ecosystem.   

        Learn how federal agencies are preparing to help agencies gear up for AI in our latest Executive Briefing, sponsored by ThunderCat Technology.

Tom Temin Yeah, it strikes me there are really two pieces of the SBOM that could be vulnerable. One is those references to open source elements, which is what most software is at least partially made of. Some of it’s mostly open source and with a little bit of window dressing to make it proprietary. And therefore, if it’s open source, everybody knows what’s in it anyway. And then there is the proprietary part that was coded by that vendor, which might be less known, but also exploitable. So does the SBOM kind of bring together two things that might have been better left separate?   

Chris Hughes Not necessarily if I’m consuming something just like in the medical industry or food or anything of that nature, I need to understand what’s in it entirely, not just partially what’s in it. I think what this is, is, you know, is some attempt in terms of the industry looking to push back on this requirement because transparency can be intimidating for some if they have a lot of vulnerable components within their product and they haven’t done their due diligence around secure software development, for example. You know, that level of transparency can be a bit intimidating and could be threatening in terms of want to disclose that to the customer. Like you said, maybe it’s largely open source. It’s a little bit of window dressing on it, or maybe it involves a lot of vulnerable components that we haven’t addressed and we kind of just focus on speed to market and getting out there and getting revenue, for example, so that transparency can be intimidating. I think, like you said, we need to see what’s entire in the product, not necessarily just a portion of it, because I need to know entirely where I’m consuming. And then if something happens, I need to be able to understand, you know, where do I have this product in my ecosystem? Where am I vulnerable? You know, for example, the Cyber Safety Review Board showed that some federal agencies spent tens of thousands of hours just trying to find where they had log4J because they didn’t really understand within their ecosystem, you know, whether proprietary products, open source software, things of that nature where they have these components in the enterprise. So we need this level of transparency and visibility.   

Tom Temin Which also points to the fact that the big breaches, whether it’s log4J or something that Microsoft puts out on Patch Tuesdays for its own proprietary software, everybody gets hit both open source and proprietary with some regularity.   

Chris Hughes Yeah, that’s spot on. I think that honestly, there’s been a bit of an overemphasis on open source software. Not that it’s inherently bad. We do need to understand our consumption and use of open source software. But if you look at the past year, for example, there’s been no shortage of breaches and incidents impacting some of the largest, most capable software providers, you know, the Microsoft, the Octus, and, you know, continue to name names, you know, whether it’s open source components they were using or their products themselves that got hacked or breached or caused an incident of some sort, and many of which included impacting several federal agencies. So the software supply chain is much bigger than just open source. It includes all products and all suppliers.   

Tom Temin We’re speaking with Chris Hughes. He’s chief security advisor at Endor Labs and a former federal cybersecurity practitioner in both civilian and DOD agencies. Therefore, what’s the best way to operationalize your use of an SBOM. You mentioned first you have to get it and then second, you have to make. Sure that it’s protected and not just let out to the public because you have it, as you mentioned, at the top. Then what? How do you make use of it in a way that really enhances cybersecurity?   

Chris Hughes Yeah, I think this is actually a very critical question, and this is where the testimony raised some questions that do have some merit is trying to avoid this becoming a compliance checkbox exercise of, yes, I have this document, I just file it away, stuff it in a cabinet drawer somewhere. I never look at it again. It has to be actually made actionable. So, CISA for example has put out some guidance on operationalizing SBOMs and we’re seeing industry using organizations like OWASP or the Linx Foundation, for example, You need to take these artifacts and actually start to integrate them into your broader cybersecurity supply chain risk management program, your vulnerability management program, integrate it into activities like procurement and acquisitions. So you have to take these things, actually enrich them with vulnerability, intelligence, understand, you know, what you’re consuming, where it exists, and then how do you actually take action on that, whether it’s working with suppliers to kind of get vulnerabilities addressed and remediated or being better prepared for things like incident response? If there is another log4J and there will be at some time, I’m sure, as well as, you know, integrating into things like procurement and acquisitions so that you can make more risk informed decisions on the products you buy.   

Tom Temin It sounds like a big exercise and cybersecurity is already a big exercise. Is this something that can be delivered as a service, say, by a vendor or a managed service vendor to do SBOM analysis for you?   

Chris Hughes It is, yeah. And anyone who’s been to a large, you know, kind of cybersecurity events in the past year or two, RSA, Black Hat, things of that nature, you’ll find no shortage of innovative software supply chain vendors, you know, being driven by venture capital and, you know, things across the ecosystem. They’re providing these platforms that can take SBOMs, enrich them or start to kind of provide that centralized hub for your use across the enterprise. So there’s proprietary solutions coming to the market. There’s obviously some open source software solutions and platforms that can be leveraged for this purpose. And you can integrate these and things like CICD city pipelines. There’s a lot of capabilities out there. It’s just much like any other kind of cybersecurity initiative, like Zero Trust. It’s a journey, so organizations just have to make that first step, you know, kind of iterate on that and keep addressing gaps and maturing.   

        Read more: Cybersecurity

Tom Temin And so far as I can tell, the government hasn’t quite made the bridge between its own imposed requirement to use SBOMs, to obtain SBOMs and use them, and the efforts that it is imposing on industry to have compliance and evidence of cybersecurity. Good Practice, the nascent CMC program. There’s also new CISA guidance and so forth for the civilian side, but so far nobody’s asked industry to have SBOMs and provide proof of those SBOMs to the government. Sounds like that could be next though.   

Chris Hughes Oh yeah, that’s definitely coming. You know, if you look at the memos from Office of Management and Budget that came out of the cybersecurity executive order, OMB 2218 and 2316, for example, those specifically call on industry to start providing self attestation, following things like NIST secure software development framework and potentially providing SBOMs in addition to those self attestations. But you know, there is one uncomfortable aspect of that is in those memos it refers to proprietary software and products, but it kind of excludes government developed software, for example, from the same kind of requirements. It’s a bit of a you know, we need to eat our own dogfood and if we’re going to push industry to do these kind of activities, we need to be ensuring that we’re doing them as well because malicious actors, they’re going to target everything, whether it’s developed by the government and contracts in our support or developed by proprietary software vendors. And it also builds trust with the industry when we do what we’re asking them to do themselves.   

Tom Temin Yes, safe to say that even in those instances where the government does develop its own software and that’s kind of returned not to the degree that maybe it was in the seventies and eighties, but it’s somewhat back now that, yeah, they’re also using open source plus their own coding and it looks just like industry and therefore as you say yeah SBOM from you folks too and good practice.   

Chris Hughes Yeah, absolutely. And also, you know, not only does it build trust, but, you know, if we’re going to talk about taking these artifacts and operationalizing them, you know, making them actionable and using them to drive down risk, what better way to do it than do it internally in our own development practices, our own software development activities, you know, kind of practice and muscle memory with, you know, producing these artifacts, integrating them into our broader cybersecurity activities and programs and maturing that aspect of it, so that when we do produce policy or requirements on industry, it’s kind of grounded in practical experience rather than just kind of theoretical or, you know, what would be nice to have. We have experience with doing these things.   

Tom Temin Chris Hughes is chief security advisor at Endor Labs and a former federal cybersecurity practitioner himself. I guess you were in the Air Force. You were at the GSA anywhere else?   

Chris Hughes Yeah, I actually spent four years in the Air Force doing cybersecurity, went from there to the Navy for about four and a half years at an organization called Nitric Atlantic and doing Cloud Security and Devsecops and then went to GSA, part of the Fed Ramp team. They’re reviewing cloud services, and I’ve been around the government contracting space for quite a bit, working with both of you and federal government agencies as well.

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