DJ Schleen: 

I remember being pushed back into my seat with a force I had never felt before. 

It was the first time I had ever been in an electric car, and Brian Reed was at the steering wheel with this big smile on his face as we went from 0 to 60 in about 3 seconds. It was just one of the many memorable experiences that I’ve had while spending time with Brian over the years.

It feels like every time I see him, he introduces me to something new, and the discussions we have – they’re extremely illuminating. 

Recently I ran into Brian and we started talking about Software Bill of Materials. As we were catching up, he mentioned something that caught my ear and I really had to hear more about.

He asked…

What do you do when you don’t have source code to create an SBOM?
What do you do when your vendor doesn’t want to give you one?
What do you do if you only have a binary file? 

Well, it turns out you can do a lot… like binary scanning and reverse engineering. 

I never thought of this approach as a way to generate, examine, and share information about the composition of software before – and you know, it makes so much sense. 

Welcome back, to daBOM.

Welcome back to the daBOM. I’m here with Brian Reed from NowSecure. We were talking at RSA quite a bit about software bill materials. We get to meet each other in person a few times a year, and when we do, I just can’t stop talking about some of the latest and greatest technology that you’ve been involved with and what’s happening in the industry.

But before we get into that, I want to know a bit more about Brian Reed. How did you get into the space of technology and security? 

Brian Reed: 

My security journey is the last 17 or 18 years, but I come from application development, databases, middleware, tooling, all of that throughout my journey. 

I’ve been around for a few years. I graduated college in the late eighties. I actually got involved early on in a tech startup that was started by a graduate student when I was in college.

 Like many tech people today, all the way back at the end of the eighties, I started in tech, and from that startup then moved my way through other early stage companies, mostly, eventually wound up working on some pretty cool technology people use today, like Visual Studio, Visual Basic, Microsoft SQL Server. I was in database world for a long time. I helped create data warehousing and Crystal Reports and things like that. Then I got involved in middleware. 

I wound up working on middleware technology, which is really designed to bridge object types, data types, database types and everything else. And that was a really interesting market, to build products in the mid to late nineties, just to figure out how to make all this stuff work together.

Today we have an API economy, largely cloud driven. There’s a lot of interoperability built into the infrastructure today. Back then, it didn’t exist. Not only was there no sense of needing security because everything was locked down back in the nineties, there was no interoperability hardly at all. 

 Connectivity stuff for those of you remember, CORBA and COM and DCOM and that whole adventure in the late nineties that then turned into a stint in the ERP space as Y2K hit.

And then a few years later, I landed in mobile with Blackberry. So I had a start up around Blackberry and started working in that world. And that’s what got me into security was around Blackberry and mobile security. And I’ve now been in mobile security for 15, 16, 17 years. 

DJ Schleen: 

You’re in the mobile space and that brings you to where you are today and you’re heavily involved with mobile security.

 We had talked at RSA this year about source versus binary. We can do analysis on source code, but then there’s the binaries that get thrown out there. And you had mentioned something about creating SBOMs almost from the air. 

Brian Reed: 

For most organizations, they will have access to source code and through access to source code and the tooling they have from their existing vendors, or they can buy a tool that allows ’em to generate an SBOM and that SBOMs going to crawl your repo. From the source code, it’s going to give you an accurate list of what’s all the tech.

What are all the libraries, first party, third party code frameworks, you name it, they’re available in this. Then there’s legislation coming , the government’s going to mandate that software vendors provide the SBOM and a transparency model. 

SBOM is the ingredients list realistically. We have ingredients list on our food, but we don’t have it on our software. I always go back to the ingredients list. 

If I am not the maker of the software and if the software is not open source, and if the software vendor doesn’t provide me with an SBOM, how do I know what’s in the binary?

 There’s this interesting world where the vendors, they’re able to take a binary and analyze it and actually produce what are the components in the app. It’s not the same as source, but it tells you, either indicatively or accurately, Hey, we found that this was written with objective C. We found that it has these 10 libraries in it. We found these two transitive dependencies in it. 

So the source codes can give you accuracy, but the binary is going to give you visibility at runtime of the application when you don’t have a source code based SBOM. That creates an interesting scenario now for certain use cases where I may need to be able to use an app, but I don’t know what its ingredients are. And so I want to try to, know what those are. 

 It’s a whole kind of interesting way to turn the whole thing on its ear. We work with a lot of organizations and their source of applications is the app store. They download and buy mobile apps from the app store. apple and Google don’t have a way to transmit an SBOM with a file from the app store. 

But if you can scan an IPA or an APK and say, Hey, here’s a list of components we discovered in it. Here’s a list of API endpoints we discovered in it. Here’s a list of geographies we discovered. Data’s getting transmitted to Russia and China. Those sorts of things that provides you with some sense of understanding of what’s actually going on in that particular application. 

DJ Schleen: 

When we talk a bit about not having the source code, and in those situations where, you’re not going to get into software bill of materials, but you still want to know. I think that’s extremely important use case. And It’s something that I’ve never heard about before we started talking.

 On the SCA versus SBOM front, there’s like a lot of memes going around the internet says, oh, pull the hood off, Scooby-Doo and it’s an, SBOM is just SCA under the covers. What are your thoughts on that comment? 

Brian Reed: 

If we go to first principles of building an application security program, you are going to buy and deploy multiple tools and techniques. A mature application security program will have SAST and DAST and SCA and pentesting, probably some API security in there, and to a large extent, it takes a village to build a first class application security program.

Now, there are a handful of vendors that have many of those tools. Sometimes you have to buy. each of those individual tools from different places, or use a mix of commercial and open source. 

I think the same thing here is SBOM’s just another one of those meaning. SBOM is your ingredients list, but it doesn’t tell you if there’s poison. SCA tells you if one of the libraries is poisoned, 

The use case of what you’re trying to do with them is different. The SBOM is telling you what are the ingredients in my app, whether I get that from source or binary. The SCA is saying, which of these libraries have known vulnerabilities and potentially can help you patch it or replace it depending on whose SCA you’re working with.

 I was in the food and beverage and medical business for a while. They tracked the supply chain of all the ingredients. So if you have a drug that turns out to have something bad and they recall it, they can trace all the way back to a source ingredient that went into the drug, so they know what batches to recall for a given drug. And that’s the same thing here as SBOM tells me what’s in it. SCA tells me if some of those things are vulnerable.

 As an industry we’re finally talking about software transparency, which is what’s in my apps. What does it mean to have these in my apps. And what are potential risks or liabilities for what’s in my apps? 

DJ Schleen: 

If you tie that back to this binary analysis, that source generation, when we talk about source versus binary, how do you see an SBOM coming out of a binary flowing into a business or a security organization? 

Brian Reed: 

There’s two interesting things. There is, how do I generate it slash where do I push it? Where does it go? Where does it get pulled into? And then there’s the, what do I do with it? Okay, I’ve got this data. Now what do I do with it? Because to an extent, to a degree, the SCA side is more of what I’m worried about. It’s less about what’s in the ingredients, and it’s more about what’s vulnerable in the ingredients.

 In the last 18 months, we’ve had two major third party vulnerable or malicious libraries that hit mobile. Remember Heartbleed an OpenSSL?. Are any of the apps I’m using not once I built, ones I’ve downloaded and I’m using are, do any of them have Heartbleed? Should I be worried about any of the apps? 

Last fall, there was something called pushwoosh. Pushwoosh is a push notification library used in that 97% of the code that you talked about. Very widely, there are over 8,000 apps in the public app stores that use pushwoosh.

It turns out that it was dormant as Russian malware and activated as Russian malware at some point after the Ukraine war got started. And so last fall there was an announcement that Russians were, harvesting data using the pushwoosh library from over 8,000 apps. And those were apps that were built into apps for the US Army, for Unilever and for another number of other 8,000 publicly well-known organizations had used what they thought was a safe commercial library that was a front for some Russian nefarious oriented activities. 

What I did is I said, Hey, I’m going to go look at the ingredients list I have for these apps in the app store and tell you where it matches up. And that’s a real use case. Like when it, there becomes a known issue with a given library, whether it’s a legal liability issue or it knows to transmit data to China, it’s malware, it’s vulnerable. You want to be able to look back at the ingredients list. 

 So that gives us the use case of the how and why 

Now, the data transmission question you started with is interesting. There’s some great OWASP resources out there and tools out there for leveraging SBOM data. 

The most mature work we’ve seen with people working with SBOMs is they have databases inside a number of, banks, for example, and healthcare companies where they are tracking it in centralized databases and trying to track their inventory, and they’re looking at risk, but they’re also looking the security vulnerability risk. But they’re also looking at, 

 What’s interesting about it is there’s a lot of conversation about, should I have it? How do I do it? Where do I put it? One of the most important issues, I think is, what are you going to do with it anyway? Why are you going to do it? 

DJ Schleen: 

You said something really important, about scanning those 8,000 apps and coming out with, these are vulnerable and it’s the true positive nature of this. This is almost a third use case for SBOMs. 

We have the SBOM M of the things that we generate. We have the SBOMs for things that we consume, and then the SBOMs that come out. I never even realized that there could be another use or another use case for almost a proactive generation of SBOMs to answer a specific question.

 I wanted to get back into the, source versus binary and web apps versus mobile. We had talked a bit about that before. When it comes around, software bill materials and the visibility of the components we use, how does that fit into things? 

Brian Reed: 

There are some fundamental difference, of course between web and mobile. From a development perspective, it’s easier to write a secure web app, and I realize some web developers will say, hahaha, that’s not true. But work with me. From an overall security perspective, there’s a lot of security infrastructure built into web apps and the native architecture of a web app where so much is behind the firewall or in the cloud. 

The difference between mobile and web, there is less security inherent in a mobile architecture because the app runs in the wild on a mobile device that is reversible and isn’t hiding behind a firewall. Therefore, the developer needs to be more careful. The developer’s responsible for doing encrypted storage and network connections.

In our mass scale testing of millions of mobile apps, we find 50% of them have vulnerabilities in network transmission. We find 48% of them have vulnerabilities in storage, local storage. Over 42% of them have weak crypto or failures related to encryption of data. Those are just a few examples of the most common patterns of some of the more popular apps you’ve ever seen in the app store.

 The software bill of materials piece of this gets interesting because now it’s okay, I can see what’s going on in the wild. But if you go back to what you said before, if 97% of the app is already third party libraries anyway, who cares? 

DJ Schleen: 

If you create a SBOM off of that mobile binary that’s out in the wild and you compare it to your source SBOM, there has to be some intelligence there where you can say, Hey, these are the things that we can detect out there. Maybe that’s a hardening opportunity for some of the internal code.

Maybe there’s binaries that are showing up in the wild and you’re like, what are they doing out there?

Brian Reed: 

On the Apple side of the house, iOS has a DRM capability to try to protect your iOS binary, but you can still crack through some of that and reverse it not to source, but you can see a lot. Can’t see everything, but you see a lot. 

On Android, there’s a few anti tampering things, but people have to use third party open source or commercial products.

Organizations that really want to protect their code need to buy or download and use anti tampering tools to help protect that code running in the wild. 

The big light bulb for a lot of people in the security and the development world is, wait a minute, you mean a reasonably skilled security analyst using open source tools can reverse this thing down almost to source. That tends to blow most people’s brains like, whoa. Because then that helps lead you to, then I should have a good architecture. I should be careful about the libraries I choose, I should make sure that all my complex functions are done. server side, not on the client side,   

DJ Schleen: 

You said SBOMs can help the architectural decisions.

Brian Reed: 

This comes from one conversation. The statement the CTO made was effectively this.

If it’s open to the world, what is in my software, my team is going to pay more attention to the ingredients I choose to put in my software, So what will happen is we’ll get security through transparency because once these get published, people are start noticing, Hey, I thought that was a reputable software company. Why are they using these three crappy libraries? 

And that’s not even necessarily a vulnerability thing. That’s like a junk code looking thing. It’s dress for the interview, don’t show up in t-shirts, shorts, board shorts, and a flip flops, Assuming you want a professional job.

This is the same kind of thing where the hygiene will matter a little bit more when people can see it. And so it was interesting listening to talk about it becomes, it will drive our architectural decisions and our choices on what software libraries we use when the whole world can see everything that’s in it, 

DJ Schleen: 

Some of the software bill of materials that come out of the binary analysis, and or source code, but especially the binary analysis and the things that are out there that you don’t have SBOMs for, what’s the biggest risk that you see in those. Is there something that would prohibit us from purchasing that software or buying that application?

Brian Reed: 

If you’re a Fortune 100 company, do you want your customers seeing that your developers have used libraries that were built in Russia or that send data to China or things like that, Unbeknownst to you and your team, your management team, or your liability risk team, there may be these libraries that your team is using and you may not have visibility to them, and they may be, they may not be vulnerable or malicious, but they may not be what you want associated with your brand. 

Those Fortune 100 companies, or big commercial software vendors, they don’t want to be embarrassed by discovering that their employees, their developers have been using less than quality or from bad parts of the world software. Those can be a really interesting kind of raise the bar that’s going to occur, as we do that.

 SBOM might be the mechanism by which I get the visibility, but the outcome of the transparency will be software quality should go up.

And that’s not just going to be a security thing, that’s going to be a brand thing for the business where the business doesn’t want to be embarrassed if their team is using bad software, bad components. 

DJ Schleen: 

CycloneDX was a big part of what you’re doing in the SBOM space. Is this a format that you’re generating as you find the source analysis? 

Brian Reed: 

We’re big believers in OWASP. As a part of the standards community, when we can have something under OWASP as a standard way for everybody to agree to do it, you just get more common implementations and predictability out of it.

 That’s why we, think Cyclone DX is an interesting way to go. There are, multitudes of different ways to export the data. and you can look at it as an SBOM. There’s also leaning into the vulnerability side with SCA. 

From our perspective, it’s really about what are the components we can discover and then how do you want consume that. As a general rule in the business, SBOMs in the whole world of using SBOMs in a higher scale, production is still really, emerging for most folks in the market, 

Most folks in the market are still really focused on the source code SBOMs and not the binary ones. The binary ones are these unusual use cases. Like you don’t, you’re a consumer of, or a purchaser of a binary that doesn’t come with SBOM, but you want to know if it’s got a certain thing in it or what might be in it.

It’s not an edge case, but it’s a different case than where I think most people are focused right now. 

DJ Schleen: 

Do you see the industry moving towards the specification for portability of vulnerability information or output from some of the tools that are out there? 

Brian Reed: 

The school’s still out on where we’re going to end up.

 I think there would be some interesting things. To what degree would NIST waded into this and say, Hey, this is the standard way everybody should be communicating, or will these evolving federal mandates turn into not only do we own an SBOM, but we want it in this specific format or stored in this specific way, or accessible through this specific api, or something to that effect.

It’ll be interesting to see if the industry coalesces itself, or any of these standards groups or mandates gets there. I’ll go back to the principle which is you ought to be paying attention to the ingredients in your software. we will have achieved success if we get everybody talking about what ingredients are in their software and starting to track them.

DJ Schleen: 

One of the things I got from our conversation today is even if you’re not provided an ingredient list, we can find it. There’s ways to get that information, at least to a reasonable point that can, again, let us make decisions on the software that we purchase. 

Where do you see SBOMs in five years?

So if you can get your Brian Reed Crystal Ball out, where do you see the industry in five years when it comes to software bill of materials, or any kind of bill of materials. 

Brian Reed: 

I hope that we will have clean software labeling in five years. Whether that is what we call an SBOM today or not, whether that’s federally mandated or not, I really do hope we get to a point where like this can of drink that I have on my desk. I can look at it and it tells me what’s in it and what the calories are. 

 I believe that with as much tech driven our entire global economy is now, and our lives are, that it’s in our best interest to have a little more transparency, We trust our water most of the time, except when there’s a water main break or bad things happen like the city of Detroit.

The transparency will drive better behavior. The security through visibility and software transparency, I think will have material impact. I don’t know if we’ll be still calling it an SBOM, but I do hope that there’ll be a lot of transparency around software ingredients and that will drive better behavior.

The comment made about the CTO and the architectural decisions, I think are true. I really do think that once it’s transparent about what every piece of software has, people make better choices of what libraries they use. 

That actually might even grow a better third party library ecosystem, where people will pay for better libraries and they’ll want to show up as the primary ingredient and applications built by the major software vendors.

There’s a whole interesting world around how a library maker could benefit from software transparency and SBOMs as well. 

DJ Schleen: 

This episode of daBOM was created by me, DJ Schleen, with help from sound engineer Pokie Huang and Executive Producer Mark Miller. This show is recorded in Golden, Colorado, and is part of Sourced Network Productions. We use Captivate.fm as our distribution platform and Descript for spoken text editing.

You can subscribe to daBom on your favorite podcast platform. We’re going to be releasing a new episode every Tuesday at 9:00 AM. I’ll see you next week as we continue to diffuse daBOM.