There is lot of talk about Software Bill of Materials (SBOMs) in industry publications, social media, and even the news. Different countries have either already instigated regulations or are in the process. Instead of piling on the why and how let’s dive into the topic with a couple of examples. Let’s look at some SBOM examples: we will look at some of the snippets from an SBOM from software that I use on a semi-regular basis. 

Before getting started, realized that I am looking at an SBOM from the point of perspective of a software consumer. I depend on software from many aspects of my life, from the moment that I wake up (and step on my smart scale), to the moment that I go to bed. A smart thermostat manages the temperature, my smart fan checks air quality, my phone tells me what the weather forecast is, and I can send the location of the ski hill for the weekend to my car via my wireless router that is attached to my home lab that has a NAS into it for storage. I am sure I am not alone. 

For these examples, we will use the firmware for my NAS, which is available online, or I could grab it from the NAS itself, as well as an iPhone app. The easiest way to grab the latter is by installing the iPhone app on my laptop. I will not mention the actual brands or applications here to protect the innocent. 

For each of the apps, I am not going to publish the full SBOM, instead, I am going to the contents of the SBOM to explore what components were used to build the applications. This gives me an idea as to what my security exposure for these applications is.  

NAS 

Starting with the NAS, I downloaded the firmware and then passed it to CodeSecure’s CodeSentry, which is a SaaS platform that performs detailed Binary Software Composition Analysis and will generate an SBOM for me, complete with additional information (which we’ll get to). In my case, a SaaS platform is fine, however, many of CodeSecure’s customers are in a field where SaaS cannot be used and they typically rely on an air-gapped version of the same platform. 

How to review an SBOM differs case-by-case, in this case, as expected, the NAS is based on Linux, which means there will be thousands of open-source components included, which will be a lot to review. In this case, I typically do 2 things: 

• A spot check of the type of components the device has and if there is something that seems out-of-whack. For example, there should be no Firefox on it, there should be little desktop content, it should be a fairly tight Linux version based on sharing protocols and some media handling 
• Keep the SBOM handy, and when an exploit hits the news, I check if my system is vulnerable. Think log4j and those types of things.  

The SBOM shows that the Linux version 4.1.165, which is from early 2021, is a 2-year-old Linux version. To be honest, I had feared the worst. The spread of vulnerabilities for that Linux version is: 

So 7 critical vulnerabilities and 111 high. A quick look into the vulnerabilities themselves shows that they are the typical kernel things that you would expect. Driver issues (iscsi, which the NAS does not have), hugeTLB problems, and IPv6 problems (which I don’t use in my network). This is a NAS behind the firewall, only accessible to me and my 16-year-old son, so we are probably okay here.  

Scrolling through the rest of the components list shows ffmpeg, again, as expected as many NAS devices nowadays can also function as your multi-media host. 

This is certainly something I would be more concerned about, but again, the device is on a closed network and others cannot get to it. 

I was pleasantly surprised to see WolfSSL over OpenSSL for the crypto aspect: 

Lots of content related to samba of course, as you would expect for a NAS, The version is 4.16, which is from early 2022, so that is about 2 years old by now. Somewhat surprising. 

There is no log4j in the installation, which is a relief. There is some OpenSSL, however is still version 1.0 and 1.1, which is disappointing and something to keep in mind. 

iPhone App 

Switching to the iPhone app, this is from a local business that allows me to order, pay, and get things delivered to my front door. I was able to download this app to my Mac laptop and upload it into CodeSentry from there. 

This has a lot less components compared to the NAS, so we can spend a bit more time investigating.  

The app is based on Swift 5.0, it could likely do with an updated compiler and run-time system. I know the owner of the business, so this is something I will suggest next time I visit them. 

The app uses nanopb, likely to do some interaction with Google. Not unsurprising, they must store data somewhere and Google seems like a reasonable approach. 

They also use a component called expo to make the app work across multiple mobile devices. 

One thing that stands out is that the SBOM indicates using protonvpn-mac-app. Which seems odd. This is likely a component mismatch. I spent a bit of time Googling that component and based on the fact that this component is detected in the file ‘Sentry’, makes me think the app uses sentry.io ((https://github.com/getsentry/sentry), which is a component for error tracking and performance monitoring.

We can exclude the protonvpn and add Sentry. With this, the component list is short and sweet and there is nothing truly out of the ordinary, or anything that is concerning: 

We can also look at the histogram of the vulnerabilities associated with the app: 

Lastly, the CycloneDX output for this application has been added to the end of the blog post. 

Summary 

We looked at two very different components, one a NAS, utilizing a full Linux install and one an iPhone app. Very different results of course. The SBOM examples that we are looking at for the NAS are a couple of grabs from thousands of entries. For the iPhone, the list is much smaller. 

In both cases, we can learn valuable information about what is contained in the software that runs our lives. I often call this the inventory of my software inventory. Using SBOMS, even post-production, I can generate the component inventory of my software inventory. Then, when, not if,  the next big security scare is published, I will be able to l do a quick look-up to see if I need to power off my modem. 

In my case, for a small household, this is more of a project out-of-interest. For a company that depends strongly on software, this is now a necessity. 

CycloneDX SBOM for SampleApp: 

The post SBOM Examples appeared first on CodeSecure.

*** This is a Security Bloggers Network syndicated blog from TalkSecure | CodeSecure authored by Mark Hermeling. Read the original post at: https://codesecure.com/learn/sbom-examples/