Today is Day 1 of the SBOM Challenge – the first of its kind technology challenge issued to vendors to identify the current state of innovation for generating and managing SBOM’s. This is happening at the S4X23 Conference in Miami, FL.
Yes, it stinks to be in Miami Beach in February!
As we settle in for the next four days to dissect and decompose firmware images to assess them for software supply chain risk, we will chronicle our progress in the broader challenge. It is our hope that these posts give you a full perspective on the challenge, the levels of difficulty for elements of the analysis and how the outputs align into the market need for SBOMs.
Idaho National Labs (INL), who has organized the SBOM Challenge, has staggered the pieces of the challenge over three days in order to fully evaluate the critical areas.
INL will be presenting the results from their perspective Thursday, February 16 at 1:00 pm.
So far from the traffic we saw today in the SBOM Pavillion, there is a tremendous amount of interest and engagement from attendees who understand the importance of the SBOM, but also know that managing the SBOM and taking action based on the results of the SBOM are paramount to enhancing vulnerability management.
The market is far more aware and knowledgeable of the business value of the SBOM, as well as the compliance requirements they need to meet for their customers and regulators so they can validate the security of their products and portfolios.
What We Analyzed Today
INL provided three unknown binary images for the SBOM Challenge. Here is a high-level overview of what we’ve discovered so far:
- Artifact 1: Windows .msi installer
- Artifact 2: Motorola 68000 series bare metal firmware image (and associated S-Record formatted file)
- Artifact 3: Linux based firmware based on OpenWRT
The Day 1 challenge was to ingest the binary files for all three artifacts and produce an SBOM for each artifact to provide to the challenge organizers. And we found a few things that we think are unique to the way we analyze firmware!
Artifact 1:
- We analyzed the first artifact, and it took roughly an hour to process it fully.
- We found several third-party components with multiple versions, and a few of these had several vulnerabilities that we were able to pull in. More to come on that tomorrow!
Artifact 2:
- We analyzed Artifact 2 in less than an hour. This was a stripped binary with no identifiable third-party components without any vulnerabilities.
- This firmware came from a ABB TPP 2000 that was developed and released back sometime around 1993.
- We were able to fetch some interesting data based on the strings that indicated the age of this artifact and this is a unique capability for Finite State based on our extensive (2B+) data points, and our ability to efficiently curate results and point to what matters for our customers.
Artifact 3:
- This firmware was from the open source project, OpenWRT. From our perspective, this was an extremely large and complicated firmware that featured over 1700 components.
- We were able to process this as expected in about two hours, inclusive of fetching the vulnerability intelligence.
Our Perspective on the Day 1 Challenge
While some of the artifacts of the challenge may be considered difficult to analyze, INL has selected artifacts that accurately represent the challenges of the S4 attendees in the ICS, OT, and SCADA verticals for SBOM usage.
These artifacts represent many of the software components represented by their attendees for day-to-day operations, especially those affected by Cybersecurity Executive Order 14028.
In cases where the artifacts may be considered “old”, generating SBOMs for components already in the field (and likely to be there for decades more) where the original providers may have limited capabilities for generation on their own, presents a level of challenge. This type of analysis can help drive compliance, as well as a broad inventory of the OT components in an attempt to reduce risk.
Every new artifact is an opportunity to improve component detection across an even wider breadth of binary file types, thus generating ever more accurate SBOMs and associated CSAF and VEX.
Impact Analysis:
How are the Day 1 results impactful to the market? And what did we learn?
From Finite State’s perspective, our customers are focused on driving down software supply chain risk. When we create SBOMs for customers, we do it to make their jobs easier by having the comprehensive workup of the software and components present in any embedded system or connected device.
While important to consider current and future supply chain risk, we should also turn the lens to the supply chain of the past. Applied to industries where devices and software are purchased and are expected to have a lifespan of 30 or more years, evaluation of the software components should likely be re-performed, or performed for the FIRST time.
There is significantly more focus on more accurate, more detailed, standards based reporting for supply chain components than there was maybe, 15 or more years ago. Now is the time to shine, and get a better handle of even our legacy products still in use.
Stay tuned for our Day 2 recap tomorrow!
If you want to see our platform in action, come to the SBOM Pavillion for a demo. If you’re not at S4, you can easily request a demo here.
