Unpacking SBOMs: Software Supply Chain Risks & Compliance Challenges

[00:00:00] Max: Welcome to Reckless Compliance Podcast, where we learn about unintended consequences of federal compliance brought to you by ignyteplatform.com. If you’re looking to learn about cyber risk management and get your product into the federal market, this podcast is for you. Or, if you’re a security pro within the federal space looking for a community, join us. We’ll break down tools, tips, and techniques to help you get better and faster to get through the laborious federal accreditation processes. It doesn’t matter what type of system or federal agencies you’re dealing with. If you’ve heard of confusing terms like ATOs, FedRAMP, RMF, DISA Stigs, SAAB SARS, or newer terms like CATO, Big Bang, OSCAL, and SBOMs, we’ll break it down all one by one. And now, here’s the show. 

Hello everyone, thank you for tuning into Reckless Compliance where we learn about unintended consequences of bad compliance practices or good compliance practices. So, today I’ve got a pretty exciting topic about SBOMs, Software Bill of Materials. We’ve heard about Software Bill of Materials, but we’re really gonna learn about what got us started down this path.

Why are we talking about it? What type of activity as risk management professionals can we expect when it comes to SBOMs? And of course, there’s a lot of supplementary guidance out there, so we’ll touch on that as well. So, and I also have a guest with me today, Aaron Bray, Aaron is a prior Air Force guy, but I’m gonna let him introduce himself.

He’s also a co-founder of Phylum. But Aaron, give me a little bit of your background for those that are not familiar, and then let’s get right into talking about SBOMs. 

[00:01:33] Aaron: Absolutely, Max. And thanks so much for having me on. So I’m Aaron. And as Max mentioned, , I started out my career working in the Air Force/DoD.

I did that for a number of years, long background, sort of working in the Department of Defense, Intel community, really kind of at the intersection of software development and cybersecurity. 

[00:01:51] Max: Nice. And Aaron, I’m just curious, how long were you in for? 

[00:01:55] Aaron: About eight years active duty, then a couple of years after that on the civil service side.

And then I spent a few years after that prior to launching Phylum working in industry. 

[00:02:05] Max: Okay. Okay. So you didn’t cross the 10 year barrier. Usually I feel bad for people are like at 10 years and like, man, you’re 50 percent there. So that’s awesome. So, so tell me a little bit about Phylum. What do you guys do? And, then how does that relate to software bill of materials? 

[00:02:20] Aaron: Yeah, so that’s a great question. At a high level, what we do is we really look at open source software. So think about all the third party libraries that are described in the context of the software bill materials. It’s going to be the vast majority of what shows up in one of those documents. And, , we look across all of those open source software packages for a wide variety of things. We look for software supply chain attacks in progress. We look for sort of systemic risks around the authors, contributors, maintainers, engineering practices that are dangerous to security.

I think it’s important to realize that for the organizations and companies and agencies that are consuming these packages, not only is there no real supplier relationship with the people that are authoring and maintaining them, these are also, , just developed by sort of strangers on the internet from, , all over the globe.

They’re provided as is. And, , we see more and more of these supply chain attacks getting executed every day. 

[00:03:17] Max: Yeah, I think I don’t know, somebody said like, Even majority of the proprietary software, and we can’t validate this, has a ton of open source components. 

[00:03:27] Aaron: Oh, absolutely. I mean, if you look at a modern project that has any level of complexity at all, something that’s going to be out running in production, that’s going to underpin all of your critical infrastructure, your mission critical applications, 90 percent plus of it’s going to end up being open source.

And that’s going to translate to thousands to tens of thousands of individual software libraries that are being pulled in and consumed. And each of those has a set of contributors processes and inputs that go in into their development. 

[00:04:00] Max: Nice. So this term software bill of material SBOM, it can be intimidating to some people, right?

But I believe a lot of RMF ATO types of professionals. We’ve had to do some level of a technical analysis using Fortify, those kinds of things, right? Where we’re scanning the source code, things like that. At a fundamental level, what makes this SBOM type of activity different from that? And how would you even define a software bill of material?

[00:04:28] Aaron: So that’s a great question. And I think the best place to start is how do we define a software bill of materials? Well, A software bill of materials is really the supposed to be notionally the ingredients list of the software that you’re either consuming or publishing. So think all of the unit components that went into that software executable or library or whatever it is you’re delivering.

And so really, this is just without additional context, just a big list. It’s a snapshot in time, right? And so. What it is is a way for consumers at some point to be able to understand a little bit about what they’re leveraging, what they’re receiving, but what it is not by itself is something that gives you really a lot of context into how these libraries are being used, what some of the risks involved might be sort of like getting the ingredients list without getting the nutritional facts.

If you think about it that way. 

[00:05:22] Max: That makes sense. Yeah. And conceptually, that small component could break down into even smaller components, the actual routines and things like that. So, it can go pretty deep in terms of how much analysis goes into these kinds of things.

[00:05:37] Aaron: Absolutely. And to your other question about how does this differ from say running Fortify or a traditional SAST style tool against the code you’re writing, the vast majority of what’s going to end up showing up in something like an SBOM isn’t going to be that internal code that you’ve developed in house, it’s going to be a description of all the software libraries and dependencies that you’re pulling in as part of the development process of this software.

And none of that stuff is really going to be touched by a product like Fortify. 

[00:06:09] Max: That makes sense. And I think for a large part, the government recognized the industry certainly knew that, okay, we’re pulling in all of these libraries. We’re kind of inheriting trust. That’s shouldn’t be there by importing in libraries into code and things like that.

But. When I started to hear about this, it was around 2021 when the executive order came out. What’s the latest in your opinion? Is that, is that an enforceable thing? Cause I’m starting to see some enforcement, but not a lot. I know a history of your company, right? You guys, there’s a lot of people that are trying to do this because of this executive order.

Have you guys, I guess, what’s the enforcement mechanism behind this? 

[00:06:48] Aaron: So, I mean, that’s, that’s a really great question. I think at a high level, what we’re seeing a lot is folks are really struggling to try and figure out what to do to operationalize SBOMs.They’re now being required by regulatory bodies, whether it’s somebody that’s looking at them from a CMMC or FedRAMP perspective, or if it’s a different regulatory agency.

And so now, they’re starting to have to deal in SBOMs, whether it’s giving or receiving. And especially the big security buyers and decision makers, they feel like they don’t have a lot of context largely on what kind of risks they’re exposed to, what things they might be exposing themselves to by handing this document over to customers or folks they have business relationships with or regulators.

And the other thing that we start seeing a lot is folks are worried about the liability associated with having these documents and not really having a way to manage in an automated fashion, understanding what risks they might be exposed to over time. 

[00:07:43] Max: Yeah, I think of two things that could go wrong.

One is people are always talking about intellectual property, those kinds of things, but then the other is just if once you’re liable to do something and you, you may have all this tech debt that you really can’t take care of right now 

[00:08:01] Aaron: right. 

[00:08:01] Max: And yet you’re making all this revenue. 

[00:08:04] Aaron: Yeah.

And if you think about the other side of that, I mean, take a lot of more foundational organizations that are having to deal with these now, they may not have an application security team at all. 

[00:08:14] Aaron: They may have a very limited number of software developers and their whole organization. And so now they’re having to deal with really a whole new domain of vulnerability management and risks and a whole host of other things that they just might not be very well equipped to manage against.

[00:08:29] Max: Yeah. And so let’s talk about how does this get operationalized? Because I think that there’s a lot of different ways. So from a compliance standpoint, people look at RMF framework, which is very abstract. It’ll give you two to three controls, but not really actual meat on the bones, what to do, how to fix the problem.

What are your thoughts on the SSDF, right? The Secure Software Development Framework that the NIST put out, the 800218 or something like that. 

[00:08:59] Aaron: It’s really interesting because I think we’re at a spot right now where a lot of these frameworks are so high level that it’s hard for people, I think, to conceptually understand from a first principles perspective, what kind of risk exposure they need to think about protecting themselves from.

Another thing that’s interesting is when you look at like the 800-161 and the portions of the framework that are more focused on supply chain risk management. They largely don’t differ between differentiate between hardware and software components. So if you think about that from the perspective of something like SBOMs, that creates a bit of a hairball because maybe you have a couple tools that will tell you about vulnerabilities, and that’s about it.

But how can you take and effectively build a program that’s going to, stand up under scrutiny, especially in the event that something were to happen where you’re saying, yep, I’ve got all of these checkboxes checked. So I understand the geopolitical risks of the contributors and authors of these things I’m sourcing and all these other things that most of these tools and capabilities don’t even touch.

[00:10:07] Max: Yeah, I was going to comment on that because I think when we look at the NIST RMF, it’s actually a misnomer cause it’s going to turn into a, sadly, a checkbox that nobody knows how to check. So I really  wish there was like a better set of questions. 

[00:10:24] Aaron: Absolutely. Yeah, and a lot of the guidance that’s coming down, especially from CISA is now putting all the burden on effectively the end companies to make sure that what they’re doing is secure and compliant, and that they’re sourcing things from trusted locations.

And I would suspect that from the security side of the house, for a lot of folks, this is kind of new territory. And it seems like there’s a bit of a struggle to kind of get arms around where to even begin. So from our perspective, the way that we’ve sort of tried tackling the problem is to say, well, clearly we need an automated solution.

We need a way for people to define what acceptable use looks like in policy, and have some technical controls that will help keep them protected and make sure that they can say with a straight face, we have some concept, some notion of what the chain of custody of this package looked like when we downloaded it and installed it.

We’ve done at least as much as we can knowing that we’re dealing with it. Anonymous users in some cases with these software libraries and packages. We’ve done at least our due diligence to try and understand at a high level, who is involved if they’re effectively us sourcing software products from a company that we’re not supposed to due to embargoes or other issues of that nature that we have an understanding upfront of all of the vulnerabilities and risks.

And we have a way to kind of automatically keep an eye on that over time because obviously Unlike hardware components, software is very dynamic and new vulnerabilities and new findings, new issues continually emerge. So it’s important for organizations as they move forward to make sure that they continuously keep an eye on these sorts of issues.

[00:12:04] Max: It almost, Aaron, it almost reminds me of there was an old school term we used to use in the insurance industry, software escrow, but not for the purpose of vulnerability management, but for the purpose of critical software, something happens to the manufacturer. Now we need the source code.

So we, our critical business can run. It almost reminds me of that plus a marketplace where you need escrow, trusted escrow service, where you can pull from a central central place, is that kind of what you’re seeing out there? Cause I know we’ve seen that with other trusted markets for approved products list and 3PAOs or C3PAOs, some sort of vetting of individuals, practices, things like that where do you see this going? I mean how do you solve this thing?

[00:12:51] Aaron: So, from our perspective, automation’s the only answer just because the volume of these components ends up being so large in most cases it’s not a situation where you’re looking at a dozen components or a couple of dozen components, it’s thousands or tens of thousands in most cases. An on top of those controls, there are a whole host of other downstream issues that I think we’re going to face with SBOMs in the long run.

Just having a way to really build a program around SBOMs that can run in an automated fashion that can allow end users to apply those sort of checkbox controls to make sure that they’re protected and that they remain compliant. And having something that they can give to the regulators and the auditors to say, Yep, I feel confident signing off that I’ve done everything I can to be safe and secure.

And here are my controls, here’s my policy is probably the right approach, especially given how little time auditors typically have to go look at all of the artifacts that get collected to say, yeah, we’ve got a good story in place to help make sure that we’re protected and compliant.

[00:13:58] Max: Yeah, I read that CSED document. I think everybody laughed. It was like four hours or something. Right. So automation is definitely the key, right? But I’m still thinking  maybe, I don’t know if this will ever happen, but some sort of a centralized trusted source, I don’t even know if that will happen, but some sort of a centralized trusted source.

Not within the organization and definitely not as a public service, cause that’ll deteriorate. And we’ll be using like FIPS, we’ll use encryption. That’s very old because it’s not certified. Right. But some sort of a solution where, where there’s a centralized. Trusted source available for, for any developer.

[00:14:36] Aaron:.Yeah. So that’s actually something that we’ve been working on because we see some demand in that space, right? So we have some capabilities that enable folks to pull packages directly through our service and we’ll handle the proxying and sort of the outreach and chain of custody to wherever those things might initially be hosted.

[00:14:55] Max: So Aaron, you’re saying if you make a million dollars, you owe me something. Cause I just gave you my ideas. That’s awesome. So let’s talk about some of the challenges in terms of upstream kind of value and intelligence gathering. So if this marketplace kind of existed, or you guys are building it, things like that, what kind of insight is provided and what should a cyber professional look for, especially most cyber professionals that are credentialing and certifying things.

They’re non technical. I mean, they’re somewhat technical, but they’re not maintainers themselves, right? They’re not developers themselves. What should they be looking for? 

[00:15:35] Aaron: I mean, this is a great question because I think this is something that extends far beyond just the regulatory and compliance space.

This is something that we see everywhere in industry too, where security now is forced to take a bigger role in the software development process, just by virtue of the fact that it’s now become a massive attack surface, lots of bad stuff is getting in the door. And a lot of security professionals are great at their job, but they just don’t, it’s really a new domain for many of them.

And so I think a lot of the challenges come from a couple of different places. So one, the origins of application security are very rooted in vulnerability management. Which is certainly an important part of the problem, but it doesn’t really align with the way that things are going now, where we’re seeing a lot more introduction of malicious code, we’re seeing a lot of very targeted attacks there’s now a lot more stuff especially when you look at the NIST RMF around.

Controlling against real no joke supply chain risks. And a lot of the state of the industry tools out there really aren’t well equipped to help tackle some of those problems because a lot of what they’ll give you is things like this has a couple of CVEs in it. And this has some license issues that you need to be aware of, which depending on who you’re selling to, especially if it’s government project, may or may not be that big of a deal, but certainly it’s on the commercial side. And that’s really about where the buck stops with a lot of those sort of problems. And so when you think about more of the systemic risks that are involved in sourcing and consuming these software libraries, the things that you typically look at when you’re trying to source physical components, like where in the world is this person at, who do they work for does this thing actually have malicious components in it?

Does it seem like it may have backdoors or other problems? What is the security posture of the vendors, right? Because we don’t really have a vendor relationship with most of these open source contributors and maintainers. For all intents and purposes, we’re sourcing software from them as if they were a vendor, what does their security posture look like? Are they applying appropriate and compliant controls to their development processes and how they manage things? And so a lot more of that is the stuff that we’re looking at from our perspective, you have to take a bit more of a holistic view of the whole problem instead of focusing specifically on just kind of own management, which is what we do.

And that’s an approach that was very relevant when you had a handful or dozens of these open source libraries that you had to work with. And you could do the other portion of that manually. But now the volume is so great that the organizations that we see trying to tackle this through manual effort or some in house tools plus manual effort, the lag time in bringing new product, new packages in house for development is weeks or months and so you can only think about how that translates to impacts on time to field.

And getting revenue and delivering on seed rules and things of that nature. 

[00:18:37] Max: Yeah. I think the old CVSS model, it’s easy, but it’s totally a misfit. Counting VSS’s number of high, medium, and low. Unfortunately as a FedRAMP auditor, that’s what we look at. But I always think we’re always day late, a dollar short, never correct.

I think we need something different, something new. I have seen the exploit EPS score, right? Exploit prediction. Do you foresee for SBOMs where there might be its own scoring system, something that drives a little bit more context? 

[00:19:13] Aaron: So, I mean, that’s, that’s an excellent question. We’re actually starting to see some new extensions to the SBOM format start to emerge.

So there’s something called VEX, which is stands for vulnerability exchange, and basically that’s trying to tackle some portion of that problem by saying in effectively in line with the SBOM, Hey we’ve got these vulnerabilities in here. They may be high or critical, but they’re not actually reachable We’re not using them in the product in a way that would cause the vulnerability to be triggerable effectively.

[00:19:47] Max: So VEX has like a sub model built within it. 

[00:19:50] Aaron: Yeah, yeah. I will say that it has its own challenges given the fact that like many other things in this space, it relies on the vendor to be honest about which things are exploitable and reachable and how they’re using things and that assumes that fundamentally they understand whether or not it is reachable in their project.

But it’s at least a start and to your point, I mean, CVSS is a bit of a dated model at this point. And obviously there’s a lot of folks in the industry focusing on things like EPSS. I think we can’t lose sight of vulnerabilities even if some of the metrics we measure them by are still fairly crude.

We just need even from a compliance perspective, as we start looking more incorporating some of the 100-161 type controls into our development processes, it just isn’t enough by itself, right? Because it doesn’t give the folks making risk decisions at the end of the day. Enough meat to really understand what they’re signing off on.

[00:20:49] Max: And then making that scoring model interoperable with something that you actually are supposed to be measured by some sort of accreditation standards, the whole AM scores and all of that. There’s a lot of work to be done. There’s so much work to be done in our industry. And that’s what keeps it exciting.

[00:21:06] Aaron: Absolutely. 

[00:21:07] Max: Well, Aaron, I know this was supposed to be a very short mini thing around SBOMs, but I would love to invite you to,  maybe do another one. Maybe we go deeper into a topic, but I really appreciate you coming on. And before I let you go, any, any other parting pieces of wisdom about SBOMs and, and how compliance professionals should really look at this so it just doesn’t turn into a same old checklist driven kind of non productive exercise. 

[00:21:36] Aaron: Absolutely. I think from that perspective, if you’re a producer focus on trying to integrate this stuff as early as possible into the development process is critical because otherwise you’re going to end up with a huge burden technical debt that you have to pay off later on down the road we find it creates a lot of friction and contention between security and engineering teams. If things are kind of caught after the fact and you’re having to go back and rush to triage and fix a bunch of issues. So, getting things as far left into the development process as possible is critical.

I think if you’re on the consumer side making sure that you understand what things your vendors and OEMs and the folks that you have relationships with are putting into the SBOMs they give you is also really important. Because there’s a lot of flexibility in the standards in terms of what you can include and what might be optional.

And even being able to understand a year from now, if a new novel vulnerable, critical vulnerability, or some new issue or incident were to come out with something that’s in one of the SBOMs you’ve received, having an understanding of making sure that you have a concrete understanding of what versions, what the package names are, what ecosystems they’re from, all of the information you need to really drill in and see if you’re impacted or not through one of those SBOMs is going to be really crucial to being successful.

[00:22:54] Max: Awesome. Well, Aaron, thank you so much. That is some fantastic advice. And I look forward to seeing you out there and we’ll definitely have you back on the show. 

[00:23:03] Aaron: Absolutely. And thank you so much for having me. 

[00:23:05] Max: Thank you for tuning in. If you enjoyed the podcast, head over to Ignyteplatform.com/reckless.You’ll find notes, links, and additional content head over to iTunes to subscribe, rate, and leave a review.